LOG4J Sicherheitslücke JAVA

Zwei Beispiele: Die vielfach verwendeten Uqibiti WLAN-Access Points der amerikanischen Firma Unifi. Die Controller-Software, um ganze WLAN-Netzwerke zu verwalten, lässt sich auf einer Hardware-Appliance, unter Linux oder unter Windows (-Server) als Dienst betreiben. Nur mit der aktuellen Version sind die Lücken geschlossen. Firmware- bzw. Software-Updates sind unbedingt erforderlich. Als JAVA-Runtime kann das kostenlose Adoptium Temurin eingesetzt werden.

Seccommerce, der Anbieter von Digitalen Signatur-Lösungen (z.B. E-Rechnung mit digitaler Signatur gegen Fake E-Mails) hat veröffentlicht, dass sie kein LOG4J einsetzen in deren Server-Softareprodukten – und am Client Adoptium JRE unterstützen.

Handlungsbedarf

1. Ermitteln Sie den Software-Bestand auf Ihren Servern und Endgeräten (Windows und Linux), sowie auf Hardware-Appliances (wie Kamera-Servern, Zeiterfassungs-Software und Diensten auf Servern). Hierbei kann Open-Audit (audit und nmap scan) insbesondere für die Windows-Umgebung hilfreich sein.
2. Nehmen Sie mit den Herstellern der Software Kontakt auf, und/oder prüfen, ob es aktuelle Versionen oder Firmware Updates gibt.
3. Führen Sie diese Updates durch (oder lassen sie vom Anbieter durchführen).

Scan-Tool (nur für Windows)

Für das Entdecken von Lücken auf der Windows-Plattform (erkennt damit nicht Log4J in Hardwaregeräten oder Linux-Systemen) gibt es auf GitHub ein Befehlszeilen Werkzeug, das man auf jedem Windows-Server oder PC, auf denen JAVA installiert ist, ausführen muss. Es sucht (nur die angegebenen Laufwerke) nach anfälligen Bibliotheken und schreibt einen Bericht darüber. Die Java-Komponente aktualisieren oder entfernen (wenn die Software sie nicht benötigt), muss man immer noch:

Eine Beschreibung wie man das Werkzeug nutzt und der direkte Download sind hier beschrieben. An der administrativen Befehlszeile oder Powershell ist dann: Log4j2-scan c:\ --fix auszuführen und das Ergebnis auszuwerten.

https://github.com/logpresso/CVE-2021-44228-Scanner

Die gängigen Tools finden auch alte (Version 1.x) Bibliotheken von LOG4J. Im Regelfall eignet es sich, solche unbenutzten JAR-Dateien zu isolieren und wenn keine Nebenwirkungen auftreten, dann zeitverzögert zu entsorgen. Lässt sich eine genutzte Software (die diese Bibliotheken und JAVA benötigt) nicht mehr nutzen, wenden Sie sich bitte an den jeweiligen Software-Hersteller.

Ein Leben ohne JAVA ist möglich (und nicht sinnlos)

Ungeachtet der oben genannten Schritte gilt: Wenn möglich und geprüft, JAVA Runtimes komplett deinstallieren oder den Hersteller fragen, ob sich Adoptium Temurin Runtime einsetzen lässt. Hier gibt es regelmäßig Sicherheitsupdates.

Produktmatrix und Status

Produkt	enthält unsicheres LOG4J 2.x	Empfehlung
w.safe Firewall	Nein	abschalten und durch Managed | Firewall ersetzen, Supportende der ubuntu Version erreicht, nur 1Gen Firewall
Blackbox alt	Nein	durch Managed | VPN Access ersetzen, da Supportende der ubuntu Version erreicht
Managed | Firewall und Managed | vpn Access	Nein	neue 2. Generation Firewall und Blackbox mit Azure Cloud Option
Seccommerce Secsigner Server und Komponenten	Nein	verwendet JAVA (Adoptium), Logging ist aber anders gelöst
Uqibiti Controller Firmware/Software	Ja	Update verfügbar. Version auf 6.5.55 aktualisieren, ab dieser Version keine Gefährdung mehr. Mit dem 55er Update wurde auch die in LOG4J 2.15 entdeckte zweite Lücke niedrigen Grades geschlossen.
Fujitsu IRMC	unbekannt	Vorsorglich aktuelle Firmware-Version einsetzen, Konsole auf HTML5 umstellen (Einstellungen, Dienste, erweiterte Videoumleitung - AVR)
Fujitsu ServerView Suite	Ja	Problem noch nicht gelöst, kritische Komponente enthalten, Die ServerView-Suite, wenn Sie auf Ihren Server installiert ist, sowie die dazugehörige JAVA Plattform deinstallieren! PDF Advisory von FTS
Fujitsu RAID Manager	Ja	Auch wenn laut Fujitsu eine nicht betroffene Version eingesetzt wird: Deinstallieren, sowie die alten JAVA-Versionen unter Windows, die diese Software mit sich führt. Die RAID Konfiguration lässt sich auch im UEFI/BIOS des Servers verändern.
s.dok d.3 Presentation Server	Nein	JAVA wird verwendet, LOG4J laut d.velop nur wenn individuelle Webdienste dies nutzen und mitbringen. Wir haben keine solchen Webdienste im Einsatz in s.dok.*
d.velop documents (d.3ecm) ab Version 2020.07	Nein	Betrifft nicht direkt log4j, ist aber eine andere Sicherheitslücke, über die der Hersteller informiert. Patch verfügbar von d.3, Das Risiko eines Angriffs wird als sehr niedrig vom Hersteller eingestuft, der Patch sollte aber installiert werden.
s.dok d.3 andere Komponenten	Nein	Aus unserer Sicht sind keine der betroffenen Module in unseren s.dok Installationen installiert oder in Verwendung. Hersteller-Information hier: https://kb.d-velop.de/s/article/000001798?language=de*
s.scan Verify	Nein	The following products do not use Log4J: IRISXtract
Managed | Monitoring	Nein	Paessler PRTG Network Monitor ist nicht betroffen
IGEL UMS Software (Thin Clients)	Ja	Patch verfügbar. Update to UMS 6.09.120, which contains Log4j version 2.17. Details hier: https://kb.igel.com/securitysafety/en/isn-2021-11-ums-log4j-vulnerability-54086712.html
E/D/E Multishop	Nein	Der Multishop ist von der aktuellen Bedrohung nicht betroffen. Präventiv wurden zusätzliche Schutz-Maßnahmen durch unseren Hosting-Partner ergriffen. Darüber hinaus wird die aktuelle Bedrohungslage überwacht. Der Dienst "Elasticsearch", wurde entsprechend der Empfehlungen der Elastic-Entwickler, abgesichert.
Syntellect CT-Connect CTI (end of life)	Ja	Noch vorhandene Installationen auf (alten) Servern sollten ebenso wie alte JAVA-Versionen gelöscht werden, da diese Middleware sowohl JAVA, als auch die Bibliothek verwendet. Diese Middleware war bei der GWS Telefonsteuerung in den 2000ern im Einsatz.Hierbei ist nur die Serverkomponente, nicht der Client betroffen. Mittlerweile gibt es das Unternehmen nicht mehr. Als Nachfolge-Middleware kommen CATS und CATSpro von Spuentrup Software zum Einsatz.
s.tel und s.tel Pro bzw. CATS und CATSpro	Nein	Keine Versionen der CATS – Software nutzen das Modul Log4J. Die CATS Server sind somit generell nicht betroffen. Java-Code wird nur in CATS/3 Servern eingesetzt, wenn sie auf der TAPI Schnittstelle aufsetzen. Auch hier wird Log4J nicht verwendet.
w.shop, w.info, Managed|Transfer	Nein	Sofern in den Server-Komponenten das LOG4J Modul von uns entdeckt wurde, ist es entweder nicht von den Sicherheitslücken betroffen oder wurde zeitnah auf aktuelle Versionen, die nicht von der Lücke betroffen sind, aktualisiert, bzw. die betreffende JAVA-Klasse entfernt
gevis (classic und ERP | BC) Azure Plattform	Nein	In unserer Warenwirtschaft und dem darunter liegenden Microsoft Dynamics 365 Business Central bzw. Dynamics NAV werden keine LOG4J Komponenten eingesetzt. Kein Handlungsbedarf. Details: https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/

Eine weitere Sammlung von Softwareprodukten und Hersteller-Erklärungen ist auf Gist zu finden. Allerdings unterscheidet die Liste nicht, ob das Produkt ein verwundbares LOG4J enthält oder nicht. Wenn Sie die von Ihnen verwendeten Produkte in der Liste durchklicken, erfahren Sie, ob Ihre Produkte betroffen sind oder gar kein LOG4J enthalten.

https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

Mobile Geräte mit Bitlocker verschlüsseln

In den BSI-Grundschutz-Katalogen 200-1 und im Prüfungsstandard 330 und auch aus der DSGVO lässt sich ableiten, dass mobile Geräte (Notebooks, Laptops) Daten (insbesondere personenbezogene Daten) verschlüsselt speichern müssen. Unter Windows steht dafür der Bitlocker ab den Pro-Versionen von Windows 10 zur Verfügung.

In diesem etwa 12 Minuten langen Tutorial zeige ich Ihnen anhand einer virtuellen Windows 10 Maschine, Laufwerke verschlüsseln und gegen unberechtigten Zugriff mit einer Systemstart-PIN sichern.

Das Video ist nur für vollständig zertifizierte Syskos verfügbar.

[ddownload id="28495"]

Gruppenrichtlinien

Die Einstellungen für den Bitlocker lassen sich domänenweit über Gruppenrichtlinien festlegen. Die Einstellungen für BitLocker finden sich unter:

Computerkonfiguration => Administrative Vorlagen => Windows Komponenten => BitLocker-Laufwerks-verschlüsselung.

Hier gibt es den Eintrag BitLocker-Wiederherstellungsinformationen im Active Directory Domaindiensten speichern.
Auch lässt sich hier festlegen, ob beim Einschalten eine PIN eigegeben werden muss:

Dazu im Unterordner: „Betriebssystemlaufwerke“ => Zusätzliche Authentifizierung beim Start anfordern

Die minimale PIN-Länge lässt sich mit einer weiteren Richtlinie in dem Ordner auf 4 oder 6 Zeichen setzen (nach BSI Grundschutz ist eine 4-stellige numerische PIN zum Entsperren des Gerätes ausreichend, da damit noch kein Zugriff auf Daten möglich ist (dieser erfolgt erst nach der Windows Domänen-Anmeldung).

Bitlocker aktivieren

Nach Neustart des Rechners und Anmeldung als Domänen-Admin kann über die klassische Systemsteuerung oder den Windows-Explorer der Assistent zur Bitlocker-Laufwerksverschlüsselung gestartet werden.

Hierbei wird der Wiederherstellungsschlüssel zusätzlich auf einem Netzwerklaufwerk oder Speicherstick zu speichern sein.

Wiederherstellungsschlüssel aus AD auslesen

Auf einem der Domänencontroller (dort wo Admins die Schlüssel auslesen wollen) im Server-Manager zwei Features aktivieren: BitLocker Wiederherstellungskennwort - Viewer und Tools zur BitLocker-Laufwerks­verschlüsselung. Danach sollte in Active Directory-Benutzer und -Computer beim Öffnen eines Computer-Objektes ein neuer Reiter mit der Beschriftung BitLocker-Wiederherstellung zu sehen sein. Der Powershell-Befehl lautet:

$computer = Get-ADComputer -Identity CRECOVERY01
$recoveryInformation = Get-ADObject
-Filter {objectClass -eq 'msFVE-RecoveryInformation'}
-SearchBase $computer.DistinguishedName
-Properties *

Neulich in Outlook

Wie der „Kudnenservice“ der Sparkasse mitteilt, ist es unbedingt erforderlich, auf den Link in der E-Mail zu klicken. Durch das neue Verfahren S-CERT leert sich dann Ihr Girokonto, nachdem Sie alle Zugangsdaten eingegeben haben, automatisch 😉 und Sie sparen das vielfach erhobene Verwahrentgelt.

Mittlerweile machen die kriminellen Organisationen auch recht wenig Rechtschreibfehler. Dennoch wird es immer wieder Mitarbeitende geben, die in solchen E-Mails (mal abgesehen davon, dass hier der Spamfilter erfolgreich markiert hat) auf die enthaltenen Links klicken. Die E-Mail selbst enthält zusätzlich 1-Pixel Elemente, die dem Absender melden, dass die von ihm gewählte E-Mail-Adresse existiert (in dem Fall mein Spam honeypot).

Dennoch kann man nicht oft genug wiederholen: Weder ein Geldinsitut, noch ein namhafter Lieferant schickt einen Link in einer E-Mail, geschweige denn eine Rechnung als Word-Datei oder einen Anhang, der bösartigen Code enthält. Selbst wenn Sie von einem Ihnen bekannten Absender eine Excel- oder Word-Datei erwarten, öffnen Sie diese nicht und aktivieren Sie keinesfalls Makros darin (Bei Microsoft 365 können Admins per Richtlinie alle Makros und Weblinks in solchen Dokumenten blockieren, bei den Kaufversionnen wie Office 2021 Home & Business geht das nicht)

Fazit

Sensibilisieren Sie Ihre Mitarbeitenden REGELMÄßIG im Umgang und Verhalten mit E-Mails. E-Mails, die HTML-Code und Links enthalten, sollten gar nicht erst geöffnet, sondern ungesehen gelöscht werden.

Hören Sie mehr dazu in unserem kostenlosen Webcast im November.

Drucken oder nicht – Septemberpatch

Update vom 21.09.2021: Wer seine Systeme bestmöglich absichern möchte, kann nun doch das September-Update installieren. Damit weiterhin gedruckt werden kann, müssen vorher zwei Registry Schlüssel gesetzt werden. Danach die betreffenden Systeme neu starten und dann erst das Update installieren. Laut Meldungen in der Microsoft Community (und empirischen Beweis in eigener Umgebung) kann danach wieder auf Netzwerkdrucker im LAN gedruckt werden. Das Installieren des Patches ist unter Risikoaspekten deshalb empfehlenswert, weil eine viel kritischere Lücke (MSxHTML) geschlossen wurde, die das Ausführen von Schadcode bereits in der Vorschauansicht des Windows Explorers erlaubte.

Zusätzlich sollte darauf geachtet werden, dass die Druckertreiber der verwendeten Drucker auf dem aktuellen Stand sind. Hierzu müssen sie auf dem Druckserver aktualisiert werden. Mit den Registry-Einstellungen sollte dann auch der User auf einem Terminalserver mit dem neuen Treiber versorgt werden, ohne dass es zu einer Fehlermeldung kommt. Hier die Codezeilen der .reg-Datei:

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print] "RpcAuthnLevelPrivacyEnabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint] "RestrictDriverInstallationToAdministrators"=dword:00000000

Ursprünglicher Artikel

Für diejenigen von Ihnen, die noch die alte Version von #Windows 10 im Einsatz haben (#1809, aktuell ist 21H2) gilt. Sie dürfen das obengenannte September-Patch-Release nicht installieren, weil Nebenwirkungen aufgrund der erhöhten Sicherheitseinstellungen auftreten können. Haben Sie es bereits über die automatische Updatefunktion installiert, sollten Sie es wieder deinstallieren.

Die Probleme (#Drucken funktioniert nicht mehr) können auch bei Windows Server 2019 (build 17763) auftreten. Betroffen sind dort jedoch nur der Druck- und die Terminalserver (RDS, Citrix). Auch in diesem Fall führen Sie ein Update-Rollback durch.

Wie finden Sie heraus, ob das Update installiert ist?

Start/Ausführen/Winver : Wird  Build 17763.2183 angezeigt, ist das Update installliert

gilt für Druckserver 2019, Terminalserver 2019 und alte Windows 10 Versionen 1809 (end of support)

Windows 10 Maßnahmen

Stattdessen ist es ratsam, betroffene Rechner auf die aktuelle Windows Version 21H2 zu aktualisieren. Da das von der oben genannten alten Version einer Migration gleichkommt, dauert das pro System zwischen 40 und 60 Minuten. Danach ist die aktuelle Windows 10 Version installiert, wo nach bisherigen Erkenntnissen das Sicherheitsupdate vom September (dieses hat eine andere KB-Nummer, nämlich kb5005565) keine Beeinträchtigungen auftreten.

Hintergrund: Microsoft unterstützt die aktuelle Windows Version immer 18 Monate lang. In diesem Zeitraum sollte auf das aktuelle Funktionsupgrade hochgezogen werden. Dieses wird auch (wenn man es administrativ nicht verhindert), bei ausreichender Internetverbindung mit angeboten und installiert. In allen anderen Fällen ist das System nicht mehr im Microsoft Support und Nebenwirkungen bei Sicherheitspatches sind wahrscheinlich.

Aktuell gilt für Windows 10, Version 21H2 (19044): Mit Erscheinen von Windows 11 im Oktober 2021 erhält Windows 10 bis Oktober 2025 nur noch #Sicherheitsupdates. Dennoch sollten Sie alle Systeme auf diese letzte Version 21H2 bringen.

Tipp: Den Windows 10 Stand erkennen Sie, wenn Sie Start/Ausführen: WINVER eingeben. Dort muss Version 21H2 (Build 19044.1237) stehen.

Windows Server 2019 Maßnahmen

warten, bis Microsoft eine Lösung anbietet. Solange diese Server nicht aktualisieren und die möglichen Risiken (MSTHML-Lücke und Print Nightmare Lücke) kalkulieren.

Jetzt auch noch HIVE Nightmare

Elm Street lässt grüßen: Beim Schließen der kritischen #Sicherheitslücken in #Windows hat Microsoft die Print Nightmare Lücke nicht vollständig gepatcht. Deshalb kann ein Angreifer, nur wenn er sich bereits im selben IP-Netzwerk befindet, immer noch im System-Kontext Schadprogramme installieren. Die Lücke ist damit nicht mehr ganz so kritisch, aber immer noch vorhanden. Eine andere Lösung, als gänzlich auf das Drucken zu verzichten, gibt es nicht. Zusätzlich wurde vor wenigen Tagen eine weitere Lücke entdeckt: Der so benannte HIVE #Nightmare. Damit kann ein Angreifer Sicherheitsinformationen und Kennwort-Hashes der lokalen Benutzer auslesen und somit sich leichter Adminrechte über das Gerät verschaffen. Betroffen sind die SAM, SYSTEM, and SECURITY registry #hive files, aber auch nur, wenn man die Volumen-Schattenkopien (VSS) nutzt. Ohne diese Schattenkopien bedeutet eine defekte Registry Neuaufsetzen des ganzen Systems. Für die untere Lücke beschreibt Microsoft eine Art Workaround, die zwar die Sicherheitslücke schließt, die Nebenwirkung hat, dass das System nach einem Fehler neu aufgesetzt werden muss. Registry-Fehler lassen sich so nicht mehr über eine Datensicherung restaurieren. Systemkoordinatoren sollten selbst entscheiden, zumal die Lücke auch nur dann genutzt werden kann, wenn man sich im selben Netzwerk befindet, ob sie eine Registry ohne Datensicherung (VSS) oder das Restrisiko eines internen Angriffs in Kauf nehmen. Da die Passwort-Hashes der lokalen Benutzer nicht sonderlich gut verschlüsselt sind, ist es insbesondere bei unsicheren Passwörtern eine Fragen von wenigen Minuten, bis der Angreifer dann lokale Adminrechte über diesen Rechner hat. Domänencontroller und das Active Directory sind von der Lücke nicht betroffen. Laut Microsoft Artikel sind zwar auch Server 2019 betroffen, sowie Windows 10 (ab Version 1809) und Windows 11, es geht aber nur um die lokalen Benutzer und nciht die Active Directory Datenbank. Ein Angreifer kann damit nicht die Domain admin Rechte hacken.

Quelle: Microsoft Security Bulletin https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36934

Print- und HIVE-Nightmare Sicherheitslücken

Die Elm Street und Freddy lassen grüßen: Beim Schließen der kritischen #Sicherheitslücken in #Windows hat Microsoft etwas nicht gepatcht. Deshalb kann ein Angreifer, nur wenn er sich bereits im selben IP-Netzwerk befindet, immer noch im System-Kontext Schadprogramme installieren. Die Lücke ist damit nicht mehr ganz so kritisch, aber immer noch vorhanden. Eine andere Lösung, als gänzlich auf das Drucken zu verzichten, gibt es nicht.

Zusätzlich zum #Print-Nightmare wurde vor wenigen Tagen eine weitere Lücke entdeckt: Der so benannte HIVE Nightmare. Damit kann ein Angreifer Sicherheitsinformationen und Kennwort-Hashes der lokalen Benutzer auslesen und somit sich leichter Adminrechte über das Gerät verschaffen.

Betroffen sind die SAM, SYSTEM, and SECURITY registry hive files, aber auch nur, wenn man die Volumen-Schattenkopien (VSS) nutzt. Ohne diese Schattenkopien bedeutet eine defekte Registry Neuaufsetzen des ganzen Systems.

Für die untere Lücke beschreibt Microsoft eine Art Workaround, die zwar die Sicherheitslücke schließt, die Nebenwirkung hat, dass das System nach einem Fehler neu aufgesetzt werden muss. Registry-Fehler lassen sich so nicht mehr über eine Datensicherung restaurieren.

Systemkoordinatoren sollten selbst entscheiden, zumal die Lücke auch nur dann genutzt werden kann, wenn man sich im selben Netzwerk befindet, ob sie eine Registry ohne Datensicherung (VSS) oder das Restrisiko eines internen Angriffs in Kauf nehmen.

Da die Passwort-Hashes der lokalen Benutzer nicht sonderlich gut verschlüsselt sind, ist es insbesondere bei unsicheren Passwörtern eine Fragen von wenigen Minuten, bis der Angreifer dann lokale Adminrechte über diesen Rechner hat.

Domänencontroller und das Active Directory sind von der Lücke nicht betroffen. Laut Microsoft Artikel sind zwar auch Server 2019 betroffen, sowie Windows 10 (ab Version 1809) und Windows 11, es geht aber nur um die lokalen Benutzer und nciht die Active Directory Datenbank. Ein Angreifer kann damit nicht die Domain admin Rechte hacken.

Quelle: Microsoft Security Bulletin

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36934

Crypto-Angriffe - wenn nur noch eine Datensicherung hilft

Wenn ein Crypto Angriff erfolgt, ist trotz technischer Sicherungsmaßnahmen meist ein Mitarbeiter Schuld, der auf Links oder Anhänge klickt, die nicht das enthalten, was sie vorgeben. Ein Restrisiko bleibt also trotz aktuellem Virenscanner und einer Gen2 Firewall mit SSL-Interception und Content Filtering.

Hat man eine #Datensicherung - egal auf welchem Medium - würde diese aber auch schon verschlüsselte Daten wegsichern. Die meisten Trojaner installieren sich zunächst und legen dann zeitverzögert los. Sie verschlüsseln Dokumente und machen sie unbrauchbar, die im Schreibzugriff des Benutzers liegen oder verschaffen sich über Zero-Day-Lücken Adminrechte.

Wer dann eine Bandsicherung von der Zeit vor dem Befall hat, kann man in der Regel noch unversehrte Dateien rücksichern. Entscheidend ist also die letzte erfolgreiche Datensicherung, bevor Daten verschlüsselt wurden.

Generell gibt die Faustformel 3 - 2 - 1 für Datensicherungen, d.h. auf einem Band, auf einem Datenträger und in der Cloud oder auf einem Offline-Medium in anderem Brandabschnitt).

• Zusätzlich gilt: Nach BSI sind erfüllen nur Offline-Sicherungen (physikalisch getrennt) auf passive Medien (Geräte ohne Elektronik wie LTO-Bänder) den Grundschutz.
• Ferner müssen die Daten ordnungsgemäß und sicher gelagert und beide Stufen der Datensicherung (SQL-Backup und Veeam Backup Reports) täglich kontrolliert werden
• Zusätzlich müssen regelmäßige Bandsicherungsprüfungen (Proberücksicherungen auf anderem Gerät) durchgeführt werden, um sicher zu sein, dass das, was gesichert wurde, auch wiederherstellbar ist.

Den Check Ihrer #Datensicherung (Bandprüfungen) können Sie bei uns hier beauftragen. Im Dutzend etwas günstiger.

Wenn Sie das komplette Szenario und die Anforderungen nach BSI Grundschutz testiert haben möchten, buchen Sie bitte unseren IT-Sicherheitscheck. Dieser liefert Ihnen ein mit Prüfungsverbänden abgestimmtes Dokument und zeigt potenzielle Mängel auf.

Datenübertragungen richtig verschlüsseln

Lange Zeit gab es verschiedene Verschlüsselungsverfahren, um Daten sicher von A nach B zu übertragen. Einige davon (SSL 3.0, TLS 1.0 und 1.1 und #Verschlüsselung mit RC4-Hashwerten) sind so alt, dass Sie leicht zu entschlüsseln sind. Viele Provider haben daher längst die alten Verfahren abgeschaltet.

Versucht man nun Daten zu übertragen, kommt eine Fehlermeldung und die Verbindung kommt nicht zustande. Viele - fast alle - Schnittstellen und Programme basieren dabei auf der Programmierschnittstelle "Microsoft .net Framework". Da je nach verwendeter .net Version unterschiedliche Fehler auftreten, sollte auf allen Systemen mit einem Registry-Schlüssel dafür gesorgt werden, dass nur noch sichere Verfahren ausgewählt werden.

Zusätzlich muss natürlich die versendene Software überhaupt in der Lage sein, nach TLS 1.2 Standard zu verschlüsseln. Ein Beispiel: Seit das frühere s.net "Managed Transfer" heißt, unterstützt es nur noch die sicheren Standards. Dennoch sollte auch hier der Registry-Schlüssel gesetzt werden:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.2\Client]
„DisabledByDefault“ = dword:00000000

Sollten die Schlüssel „TLS 1.1“ und „TLS 1.2“ und „Client“ noch nicht existieren, dann bitte anlegen. Damit .NET das Systemdefault-TLS-Protokoll verwendet, müssen die folgenden Schüssel gesetzt werden:

Hier für x64 bzw. Eine 64-Bit .NET-Anwendung
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

und für x86 bzw. eine 32-Bit .NET-Anwendung
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

Windows Print Nightmare Lücken – geschlossen

Updates verfügbar: 07.07.2021

Microsoft hat außerplanmäßig das Update KB5004945 und andere Updates bereitgestellt. Stand 8.7. auch für Server 2016 und alte Windows 10 Versionen. Diese schließen die Print Nightmare Lücke. Die Updates werden allerdings nur für alle Produkte, die noch nicht „end of life“ sind, unterstützt (auch wenn in der Liste Fixes für ältere Betriebssysteme gelistet werden). Windows 7 PCs und Server 2008 R2 bleiben damit grundsätzlich ungeschützt, es sei denn man hat das ESU (extended Support Abo) gebucht. Auf diesen Systemen sollte kein Druckdienst gestartet sein. Wer Sitzungsdrucker unter RDP oder Citrix über den Windows Druckserver auf Server 2008 R2 Basis betreibt, sollte jetzt erst recht über eine Cloud Migration (bei IaaS Installation auf Azure 2019 Servern) nachdenken. Denn dort werden in der Regel nur Betriebssysteme eingesetzt, die aktuell bzw im erweiterten Support sind. Zusätzlich wichtig (weil sich die Lücke sonst trotz Patches ausnutzen lässt): In der Registry unter HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint sicherstellen, dass die folgenden Einträge nicht vorhanden – standardmäßig der Fall – beziehungsweise deaktiviert sind:

• NoWarningNoElevationOnInstall = 0 (DWORD) oder nicht vorhanden
• UpdatePromptSettings = 0 (DWORD) oder nicht vorhanden

In allen #Windows Betriebssystemen (für Clients und Server) steckt eine neue #Sicherheitslücke, die bisher noch nicht geschlossen wurde. Betroffen sind alle Server und auch PCs und Notebooks, wo der Dienst „Druckwarteschlange“ gestartet ist. Damit kann ein Angreifer ohne Adminrechte schadhafte Bibliotheken und Schadcode in das System schleusen (und ausführen). Microsoft stuft die Lücke als kritisch ein und empfiehlt den #Druckspooler (Druckwarteschlange) Dienst zu deaktivieren – was nicht zielführend ist. Schließlich kann dann nicht mehr über den Server gedruckt werden. Update: Mittlerweile hat Microsoft die Lücke als kritisch auf einer Skala von 1 bis 10 mit 8.1 eingestuft. Mit einem offiziellen Patch ist nicht vor nächstem Dienstag, dem Juli-Patchday 2021 zu rechnen.

Ursprünglicher Artikel

In allen #Windows Betriebssystemen (für Clients und Server) steckt eine neue #Sicherheitslücke, die bisher noch nicht geschlossen wurde. Damit kann ein Angreifer ohne Adminrechte schadhafte Bibliotheken und Schadcode in das System schleusen (und ausführen). Microsoft stuft die Lücke als kritisch ein und empfiehlt den #Druckspooler (Druckwarteschlange) Dienst zu deaktivieren – was nicht zielführend ist. Schließlich kann dann nicht mehr über den Server gedruckt werden.

Funktionsweise eines Angriffs

Im Prinzip stehen einem Angreifer an jedem Gerät Angriffspunkte zur Verfügung, wo der Druckerwarteschlangen Dienst läuft. Das ist ab Werk auf allen Windows Clients – unabhängig von der Version der Fall und auf Druckservern. Wie ein Angreifer diese Geräte erreicht, steht auf einem anderen Blatt – meistens indem er Benutzer in Mails oder Webseiten auffordert, auf irgendwas zu klicken. Das angeklickte Schadprogramm wird dann im Benutzerkontext ausgeführt und greift als erstes alle Systeme an, wo der Druckdienst läuft. Hier werden dann Schadprogramme injiziert und verschlüsseln zB alle Daten. Bis zum Patchday bzw. bis ein Fix zur Verfügung steht, ist es also eine Risikoabwägung, ob man den Workaround nutzt und nachher wieder deaktiviert (auch hier können Nebenwirkungen entstehen) oder das Risiko eingeht, dass etwas eingeschleust wird.

Möglicher Workaround 

Es gibt aber auch einen Workaround, der den Zugriff auf den Druckserver sperrt. Damit soll weiterhin gedruckt werden können. Möchte man eine Konfigurations-Änderung am Druckserver vornehmen (also zum Beispiel einen neuen Drucker installieren oder eine Einstellung ändern), muss man die Änderung wieder zurücknehmen. Das Ganze gilt, solange bis Microsoft einen Notfall Patch liefert. Die benötigten (administrativen) Powershell-Skripte hier (Benutzung auf eigenes Risiko, Nebenwirkungen sind nicht ausgeschlossen)

$Path = "C:\Windows\System32\spool\drivers" $Acl = (Get-Item $Path).GetAccessControl('Access') $Ar = New-Object System.Security.AccessControl.FileSystemAccessRule("System", "Modify", "ContainerInherit, ObjectInherit", "None", "Deny") $Acl.AddAccessRule($Ar) Set-Acl $Path $Acl

und zum Deaktivieren der Sperre:

$Path = "C:\Windows\System32\spool\drivers" $Acl = (Get-Item $Path).GetAccessControl('Access') $Ar = New-Object System.Security.AccessControl.FileSystemAccessRule("System", "Modify", "ContainerInherit, ObjectInherit", "None", "Deny") $Acl.RemoveAccessRule($Ar) Set-Acl $Path $Acl

Fix for PrintNightmare CVE-2021-34527 exploit to keep your Print Servers running while a patch is not available Fabio Viggiani, Blog-Artikel

Exchange Server betreiben? Nicht mehr!

Bereits im März und im April wurden in den #Exchange Server Produkten kritische #Sicherheitslücken geschlossen. Die als #Hafnium betitelten Angriffe auf Server weltweit machten Schlagzeilen und sorgten für zahlreiche Schäden und Ausfälle.

Exchange 201x versus Exchange online

Bei Einsatz und Betrieb eines Exchange Servers im eigenen Hause ist der Systemkoordinator für das manuelle Installieren der Sicherheitsupdates auf den Servern verantwortlich. Im Gegensatz zu den halbautomatisch (nur installieren und neu starten) durchführbaren Windows Updates erfordert die Installation von Exchange Patches größere Wartungsfenster und sie müssen komplett von Hand heruntergeladen und installiert werden. Vielfach sind mehrere Updates und Neustarts des Exchange Servers erforderlich.

Mit dem Online Dienst "Exchange online" kümmert sich Microsoft um alle Updates der Plattform. Die Erfahrung hat gezeigt, dass erkannte Sicherheitslücken dort 2-3 Wochen eher geschlossen sind, bevor sie in den Medien publik werden.

Mit Skykick Backup lassen sich auch Langzeit-Sicherungs- und Aufbewahrungs-Szenarien abbilden, so dass auch die Datenmengen in der Bandsicherung von veeam signifikant reduziert werden und die Nachtsicherung schneller fertig ist.

Kritische Sicherheitslücken auch im Mai 2021 geschlossen

Am Dienstag (gestern) um 1900 Uhr war wieder Patchday. Wieder wurden kritische Lücken geschlossen. Wie auch im April gab es KEINE Updates mehr für den Exchange Server 2010. Wer ein solch altes Produkt noch im Einsatz hat, handelt vorsätzlich und Versicherungen kürzen die Leistungen im Schadenfall rigoros.

Die aktuellen Mai-Updates setzen wieder voraus, dass der Exchange Server den Update-Stand von April bereits hat, ansonsten müssen auch die Updates von April zuvor installiert werden. Das sind:

Exchange Server 2013 CU23
Exchange Server 2016 CU19 and CU20
Exchange Server 2019 CU8 and CU9

Quelle: Microsoft Security Blog

Fazit

Das Risiko, Opfer eines Angriffs mit einem Exchange Server im Hause zu werden ist, mit allen Konsequenzen auch im Datenschutz- und strafrechtlichen Bereichs kritisch. Unternehmen sollten umgehend auf Exchange online in Verbindung mit Skykick Langzeitsicherung umstellen. Auch im Mai gilt wieder: Alle Exchange online Kunden sind nicht betroffen.
Wenden Sie sich gern an unser Team Cloud Vertrieb unter Leitung von Andreas Lübke für ein Angebot für eine Exchange online Migration.