[English]Zum 23. Januar 2024 wurde eine Schwachstelle bekannt, die die Ereignisprotokollieren (Event-Logging) unter Windows abstürzen lässt. Die als EventLogCrasher bezeichnete Schwachstelle lässt sich auch remote in Windows Clients und Windows Server ausnutzen und es gibt noch keinen Patch von Microsoft. Die Nacht hat mich der Gründer von ACROS-Security aber kontaktiert, weil er einen Micro-Patch für seinen 0patch-Agenten für alle betroffenen Windows-Versionen bereitgestellt hat. Die Lösung ist für alle Windows-Nutzer kostenlos. Hier einige Informationen.
Windows „EventLogCrasher“ 0-Day-Schwachstelle
Am 23. Januar 2024 hat Sicherheitsforscher Florian Hinweise und einen Proof of Concept zu einer Schwachstelle veröffentlicht (siehe folgender Tweet), die es jedem authentifizierten Benutzer in einer Windows-Umgebung (auch in einer Windows-Domäne) ermöglicht, den Windows-Ereignisprotokolldienst entweder lokal oder auf einem beliebigen Remote-Computer zum Absturz zu bringen. Ab diesem Zeitpunkt würden dann keine Ereignisse mehr aufgezeichnet, ideale Voraussetzungen, um einen Angriff zu verschleiern.
Florian hat Microsoft kontaktiert und diesen Bug gemeldet, bekam aber vom MSRC die Rückmeldung, dass die Schwachstelle die Anforderungen für einen Patch (als Wartung) bezeichnet, nicht erfüllt. Außerdem gab das Microsoft Sicherheitsteam an, dass der gemeldete Bug ein „Duplikat eines anderen Fehlers aus dem Jahr 2022 sei der die Anforderungen für die Wartung nicht erfüllte.“ Das bewog Florian, ein Proof of Concept (PoC) auf GitHub für den EventLogCrasher zu veröffentlichen.
Der PoC-Exploit ist recht einfach: Es reicht ein einziger Aufruf an RegisterEventSourceW, der ein Handle zu einem Ereignisprotokoll auf dem angegebenen Computer abruft. Mit entsprechenden Manipulationen der speicherinterne Struktur bewirkt der PoC-Exploit, dass der empfangende Ereignisprotokolldienst über eine Null-Zeiger-Dereferenz den Dienst abstürzen lässt. Der Angriff dauert nur eine Sekunde und funktioniert zuverlässig.
0Patch Micro-Patch als Fix
Mitja Kolsek hat mich die Nacht in einer direkten Nachricht auf seinen nachfolgenden Tweet und den 0patch-Beitrag The „EventLogCrasher“ 0day For Remotely Disabling Windows Event Log, And a Free Micropatch For It hingewiesen.
Der Bug betrifft wohl alle Windows-Systeme von Windows 7 bis Windows 11 sowie die zugehörigen Server-Pendants. Mitja Kolsek hat das Ganze untersucht und schreibt, das die Sicherheits- und Systemereignisse nicht verloren gehen, weil diese in eine interne Warteschlange gespeichert werden. Windows versucht dann regelmäßig, alle Ereignisse in der Warteschlange zu protokollieren, bis das schließlich erfolgreich ist.
Details zum Problem
Die Ereigniswarteschlange, die sich vermutlich im Arbeitsspeicher befindet, wird auf der Festplatte gespeichert, wenn das System ordnungsgemäß heruntergefahren oder neu gestartet wird, und beim Neustart wieder eingelesen. Sobald der Ereignisprotokolldienst wieder läuft, wird die Warteschlange in die entsprechenden Protokolle geleert, allerdings mit korrekten Zeitstempeln. Gelingt es einem Angreifer aber, dass System per Blue Screen abstürzen zu lassen, gehen diese Ereignisse in der Warteschlange verloren.
Bisher haben die Entwickler von ACROS Security herausgefunden, dass ein Angreifer mit geringen Privilegien den Ereignisprotokolldienst sowohl auf dem lokalen Computer als auch auf jedem anderen Windows-Computer im Netzwerk, bei dem er sich authentifizieren kann, zum Absturz bringen kann. In einer Windows-Domäne bedeutet dies alle Domänencomputer, einschließlich Domänencontrollern. Die Windows Firewall kann dies auch nicht verhindern, schreibt Kolsek, weil der Angriff über eine benannte Pipe (d. h. das SMB-Protokoll) erfolgt.
Micro-Patch für alle gratis verfügbar
Mitja Kolsek schreibt, dass der für die obige Schwachstelle entwickelte Micro-Patch, wie alle 0day-Patches kostenlos ist und solange auch bleibt, bis Microsoft einen offiziellen Patch dafür bereitstellt. Alles, was Nutzer tun müssen, um den Patch anzuwenden, ist, ein 0patch-Konto zu registrieren und den 0patch Agent auf dem Windows-System zu installieren.
Ich spare mir an dieser Stelle die Details zu erläutern. ACROS Security ist für Blog-Leser kein Unbekannter (siehe folgende Links). Die analysieren Schwachstellen und stellen Micropatches zum Schließen der Sicherheitslücken bereit. Die Micropatches werden zur Laufzeit über den 0patch-Agenten in den Speicher geladen und bewirken, dass die Schwachstellen sich nicht mehr ausnutzen lassen. Hinweise zur Funktionsweise des 0patch-Agenten, der die Micropatches zur Laufzeit einer Anwendung in den Speicher lädt, finden Sie in den Blog-Posts (wie z.B. hier).
Ähnliche Artikel:
0patch: Fix für Internet Explorer 0-day-Schwachstelle CVE-2020-0674
0patch-Fix für Windows Installer-Schwachstelle CVE-2020-0683
0patch-Fix für Windows GDI+-Schwachstelle CVE-2020-0881
0-Day-Schwachstelle in Windows Adobe Type Library
0patch fixt 0-day Adobe Type Library bug in Windows 7
0patch fixt CVE-2020-0687 in Windows 7/Server 2008 R2
0patch fixt CVE-2020-1048 in Windows 7/Server 2008 R2
0patch fixt CVE-2020-1015 in Windows 7/Server 2008 R2
0patch fixt CVE-2020-1281 in Windows 7/Server 2008 R2
0patch fixt CVE-2020-1337 in Windows 7/Server 2008 R2
0patch fixt CVE-2020-1530 in Windows 7/Server 2008 R2
0patch fixt Zerologon (CVE-2020-1472) in Windows Server 2008 R2
0patch fixt CVE-2020-1013 in Windows 7/Server 2008 R2
0patch fixt Local Privilege Escalation 0-day in Sysinternals PsExec
0patch fixt Windows Installer 0-day Local Privilege Escalation Schwachstelle
0patch fixt 0-day im Internet Explorer
0patch fixt CVE-2021-26877 im DNS Server von Windows Server 2008 R2
0patch fixt Windows Installer LPE-Bug (CVE-2021-26415)
0Patch bietet Support für Windows 10 Version 1809 nach EOL
Windows 10 V180x: 0Patch fixt IE-Schwachstelle CVE-2021-31959
0Patch Micropatches für PrintNightmare-Schwachstelle (CVE-2021-34527)
0patch-Fix für neue Windows PrintNightmare 0-day-Schwachstelle (5. Aug. 2021)
0patch-Fix für Windows PetitPotam 0-day-Schwachstelle (6. Aug. 2021)
2. 0patch-Fix für Windows PetitPotam 0-day-Schwachstelle (19. Aug. 2021)
Windows 10: 0patch-Fix für MSHTML-Schwachstelle (CVE-2021-40444)
0patch fixt LPE-Schwachstelle (CVE-2021-34484) in Windows User Profile Service
0patch fixt LPE-Schwachstelle (CVE-2021-24084) in Mobile Device Management Service
0patch fixt InstallerTakeOver LPE-Schwachstelle in Windows
0patch fixt ms-officecmd RCE-Schwachstelle in Windows
0patch fixt RemotePotato0-Schwachstelle in Windows
0patch fixt erneut Schwachstelle CVE-2021-34484 in Windows 10/Server 2019
0Patch fixt Schwachstellen (CVE-2022-26809 und CVE-2022-22019) in Windows
Windows MSDT 0-day-Schwachstelle „DogWalk“ erhält 0patch-Fix
0Patch Micro-Patch gegen Follina-Schwachstelle (CVE-2022-30190) in Windows
0patch fixt Memory Corruption-Schwachstelle (CVE-2022-35742) in Microsoft Outlook 2010
Windows 7/Server 2008 R2: Erhalten auch 2023 und 2024 0patch Micropatches
Windows: 0Patch Micropatch für MOTOW-ZIP-File-Bug (0-day, kein CVE)
Windows: 0Patch Micropatch für MotW-Bypassing 0-day (kein CVE)
0patch sichert den Microsoft Edge für Windows 7/Server 2008/2012/R2 bis Jan. 2025 ab
0patch Micropatches für Microsoft Office Security Feature Bypass (CVE-2023-33150)
Wer keinen Kanarienvogel betreibt ist selbst schuld.
Ich glaube ich sagte schon das es unter Linux so ein nettes Tool gibt, das prüft ob alle Dienste die laufen dies auch tun, versucht neu zu starten oder halt einen Syslog-Event ins Netzwerk schiebt.
Das muß es doch auch unter Windows geben?
Kann doch nicht sein, das Dienste absemmeln und niemand merkt es? Muss ja kein Angriff sein
Sowas gibt es. Du kannst in services.msc für jeden einzelnen Dienst festlegen, was passieren soll, wenn er nicht läuft. Das ist dreistufig, man kann z.B. zwei mal festlegen, dass der Dienst neu gestartet wird, und beim dritten Mal der ganze Rechner neu gestartet werden soll, um größere Probleme auf diese Weise zu lösen. Muss man sich überlegen, ob der Dienst so wichtig ist, dass man das will, dass der Server dann mal für schlimmstenfalls ein paar Minuten ganz weg ist.
Aber das nützt alles nichts, denn wenn ein Angreifer den Dienst einmal abschießen kann, dann kann er das auch immer wieder, er kann z.B. automatisiert prüfen, ob der Dienst wieder läuft, und ihn dann erneut abschießen. Und dieses Problem wäre auch unter Linux nicht lösbar, sofern das Problem nicht weggepatcht wird.
Und da komme ich auf den Eventlog-Dienst… Für Privatleute ist der Eventlog meistens irrelevant, die gucken da meistens eh nicht rein. Naja gut, etwas engagiertere Nutzer vielleicht schon, wenn sie mal ein Problem haben. Aber sonderlich relevant ist das für Privatnutzer eher nicht. Also, wenn der Eventlog da abgeschossen wird, meistens eher egal.
In Firmen dagegen kann der Eventlog sehr wichtig sein, zum Beispiel wenn man diese Events zentral in einem Syslog, SIEM, SOAR oder besser sammeln will oder muss. Dann ist es natürlich fatal, wenn der Eventlog Dienst nicht läuft, dann kommt da nämlich nichts an. Das Problem ist nur, dass ernsthafte Admins wohl eher keinen 0Patch installieren werden, weil sie damit womöglich den Support von Microsoft verlieren, wenn die damit ausgestatteten Systeme dann irgend ein Problem zeigen.
Daher muss ein Patch von Microsoft kommen. Muss. Unbedingt.
Eine bessere temporäre Schutzmaßnahme könnte evtl. aber tatsächlich die Windows-Firewall sein, kann nur mühsam sein, das SMB-Protokoll auf die Remote-Computer beschränken, die tatsächlich auf einen bestimmten Computer zugreifen zu können. Das würde zumindestens einen Teil der Systeme im Netz von dem Angriffsvektor ausschließen.
Das ist der Job von „system surveillance“ Systemen wie Nagios oder MS SC / MS MOM.
Ja, sollte man im Netzwerk haben und eben die Eventlogs, Logfiles, Verfügbarkeit benötigter Dienste, … regelmässig checken und bei Fehlern benachrichtigen und/oder ein Reparaturscript anstossen.
Das Logfiles unvollständig geschrieben werden wenn die Kiste vrasht ist klar. Deshalb kann man eigentlich auch per Netzwerk auf einem Syslog Server loggen…
Auch kann man sogar Windows veranlassen, bei einem bluescreen einen Memory dump anzulegen.
Das dauert natürlich bei großen Rechnern etwas.
Aber was ist schlimmer?
Oh, wir hatten einen BlueScreen, aber die Kiste läuft wieder nach 3 Minuten, wie wissen aber nicht wo durch. Oder man bekommt einen Core dump und kann im Debugger genau sehen, wie der Absturz erfolgte?
oh je… das hört sich schlimm an.
Der EventViewer verstößt gegen die elementarsten Programmier-Grundregeln, und prüft keine Daten die von außen gekommen sein könnten. Was für eine Müllsoftware?
Ob es von Microsoft da auch einen Patch für Windows 7 geben wird?
Mei, natürlich wird es auffallen, wenn der Eventlogger nicht mehr läuft. Aber wer sollte das feststellen und wo loggen, weil ja auch alle anderen Rechner keinen logger mehr laufen haben? Auf einen Linux logserver?
Man kann nur annehmen/hoffen das Einbrecher eine so auffällige Aktion vermeiden werden.
Standardmäßig ist aber doch beim Ereignisprotokolldienst eingestellt, das er nach einem Crash des Dienstes automatisch nach 1 Minute neu startet.
Tut er das hier nicht?
Ja, er macht es aber nur 2 mal, dann gibt er auf.
So die Beschreibung auf dem lesenswerten Link bei 0patch.
Ich kann nur raten so eine Kanarienvogel Software zu installieren.
Irgendwann bekam ich die Warnung, das ein Drucker Port aufgemacht worden sei. Das war ein Installations Script für einen Zeichensatz, der aber nur auf dem Server angeboten werden sollte aber meinte, der Druckerport aktivieren zu müssen, was ich nicht haben wollte.
Selbst wenn er nach einer Minute wieder neu startet – inzwischen laesst sich viel Schabernack treiben, ohne dass etwas protokolliert wuerde…
Nö, wird doch weiter protokolliert, nur bei beendetem Protokolldienst nicht in die Protokolle geschrieben, sondern im RAM gehalten.
Startet der Dienst wieder, wird das aus dem RAM in die Protokolle geschrieben.
Und in den Diensteinstellungen kann man ja einstellen, was beim 3. Crash passieren soll.
Z.B. eine Warnung an die Admins senden oder gleich das Betriebssystem herunterfahren.
Dann würden zwar auch die Dienste beendet, aber die Angreifer könnten auch nicht auf diesem Server weitermachen.
Und dieser Angriffsweg funktioniert ja eh nur bei authentifizierten Nutzern. Und wenn die Angreifer schon authentifiziert sind, ist eh alles zu spät.
step1: auf den clients Tür zu. Zugriff nur von Admin Workstation.
egal welches Protokoll attackiert wird, der Client antwortet nicht.
Server sind leider eine Baustelle, die aufwendiger ist, die müssen Antworten, aber warum jedem Client auf jedem Port und Protokoll?
https://www.gruppenrichtlinien.de/artikel/microsoft-defender-firewall-mit-erweiterter-sicherheit
Zugriff bei den Benutzern einschränken, das die sich nur noch über Computer anmelden können, die Mitglied der Domäne sind.
Stöpselt man dann einen Rechner an, der nicht Mitglied der Domäne ist und versucht dann von diesem Rechner aus Zugriff auf die Domäne zu bekommen, wird das abgewiesen, selbst wenn Username und Passwort stimmen.
Das ist insbesondere bei Accouns mit administrativen Rechten sehr zu empfehlen!
Ich habe das hier sogar auf Abteilungen ausgedeht.
Z.B. ein Konstrukteur kann sich nur an Rechnern in der Konstruktion anmelden. Ein Anmeldeversuch an einem Rechner einer anderen Abteilung wird abgewiesen.
Ich habe mal auf allen Servern den Dienst nun in die Überwachung mitaufgenommen…