Log4Shell

Ich habe lange gezögert, ob ich eine Seite zu Log4j schreiben soll, denn diesmal betrifft es nicht Exchange. Log4j würde ich als ähnlich oder sogar schlimmer als den Hafnium Exploit einschätzen, wobei mehr als "fremde Systeme anonym ohne Mithilfe zu kapern" schon kaum mehr zu toppen ist. Aber nur wenn Sie ein Windows Admin sind, sollten Sie auch die Log4j-Lücke ernst nehmen, denn das Logging Framework ist schon an vielen Stellen im Einsatz und gefährdet durchaus ihr System. Insbesondere, wenn Sie nicht wissen, wo es eingesetzt wird.

Diese Lücke wurde um den 9. Dez öffentlich. Exploits gab es sehr schnell und mittlerweile erfolgen die Angriffe automatisiert von den üblichen Verbrechern.

Passend dazu ein Video meines Kollegen bei Net at Work
https://www.netatwork.de/log4shell-analyse-mit-defender-for-endpoint/

Log4Shell-Analyse mit Defender for Endpoint
https://www.youtube.com/watch?v=20wpCbsT24w

Vektor

Ich habe mit nun nicht genau die Wege angeschaut aber Log4j ist ein Logging-Framework für Java, welches von vielen Entwicklern gerne genutzt wird. Wir alle, auch PowerShell und C#-Entwickler müssen immer mal wieder Diagnose-Ausgaben und Protokolldaten ablegen und warum sollte jeder Entwickler für sich immer wieder das gleiche Problem selbst lösen. Sicher ist in PowerShell ein "White-Host", "Write-Verbose"  oder Write-Debug mal schnell geschrieben. Aber dann will man doch noch einen Zeitstempel mit drin haben oder die Ausgabe in eine Datei umleiten oder remote per SYSLOG an ein andere System senden oder per HTTPS/REST in eine Datenbank. Und all diese Funktionen macht Log4j einfacher. Sie instanzieren ein Log4j-Objekt, geben die Ausgabeziele an und schreiben im Code einfach ihre Ausgaben an das Objekt. Sie können dann unabhängig vom Code einfach per Konfiguration die Ausgaben anpassen.

Der Fehler liegt aber nun darin, dass ein Text in der Ausgabe , vereinfacht ausgedrückt", als Code interpretiert werden kann und ein Angreifer z.B. an ein System eine Nachricht schickt, die dieses System dann ins Log schreiben will und stattdessen mit den Rechten des Loggers ausführt. Wenn ich so im Code dann eine Java-Klasse instanziere, die Java dann z.B. aus dem Internet nachlädt, kann ich auch komplexe Angriffe davon ableiten. Selbst wenn mein System nun nicht "ins Internet" darf und damit ein Download erschwert ist, kann ich dennoch genug Unfug anstellen.

Prüfen Sie, ob sie betroffen sind, installieren Sie vom Hersteller aktualisierte Versionen oder schotten Sie das System ab.

Aber warten Sie nicht darauf, dass jemand anderes ihren Server "patched". Angriffe müssen nicht von extern kommen. Es reicht auch eine Mail mit einer unscheinbaren Anlage oder eine Webseite mit etwas JavaScript, die ein unbedarfter Anwender aufruft und nach internen Systemen sucht.

CVE-2021-44228 - Log4j - MINECRAFT VULNERABLE! (and SO MUCH MORE)
https://www.youtube.com/watch?v=7qoPDq41xhQ

Betroffene Systeme

Als Kunde oder Nutzer sollten Sie alle eingesetzten Programme sowohl selbst nach betroffenen Versionen absuchen als auch die Herstellerinformationen zurate ziehen. Sobald ein Hersteller veröffentlicht, welche Version betroffen ist, können auch die bösen Jungs dran gehen, genau nach diesen Systemen zu suchen. Dabei beschränken sich Lücke nicht nur auf Java-Programme. Java ist durchaus weiter verbreitet.

Auch in der Microsoft Welt und insbesondere Azure können z.B. Instanzen von Apache u.a. Programmen laufen, die Log4j einsetzen.

Hunting mit Defender

Mein Kollege hat nach den ersten Hinweisen auf Log4Shell natürlich bei Net at Work schnell geprüft, welche Systeme eventuell eine angreifbare Version von log4j ausführen und dann haben wir auch geschaut ob es schon entsprechende Hinweise auf Angriffe gibt.

Die nun gezeigten Funktionen sind nicht Bestandteil der einfachen Office 365 E3-Lizenz. Defender for Endpoint gibt es als eigene Lizenz oder in Microsoft 365 E5 oder E5 Security etc.

Zuerst schauen wir uns die "Thread Analytics"-Seite auf https://security.microsoft.com/threatanalytics3 an. In der Übersicht listet Microsoft sehr viele Theads auf und Log4j steht ganz oben

Wir sehen auch, dass es noch kein "Impacted Devie" gibt aber zwei Gerät "vulnerable" sind. Hier hat also Defender auf dem Client die fragliche Komponente gefunden. Mit einem Klick auf den Thread kann ich mir die Details dazu anschauen

Über die CVE-Nummern kann ich dann direkt die Geräte finden. (Authentifizierung erforderlich)

Dabei trifft es nicht immer nur die Server sondern auch Workstations können darunter sein. Ich habe da Fenster hier "zusammengeschoben". Die Tabelle zeigt natürlich noch mehr Details an.

Hier ist es sogar mein Desktop, auf dem eine 3rd Party Software die Komponente mitgebracht hat. Über die Details des Device finde ich dann neben dem log4j-Lücke und einem scheinbar fehlenden -NET Update natürlich noch ganz viele andere "Empfehlungen", die ich zum besseren Schutz umsetzen könnte:

Hinweis: Die Liste der Pfade zeigen die Vorkommen auf allen Geräten und nicht nur mein Gerät. Bei mir steht da wohl ein Update von mqttfx an. Leider gibt es für meine Version 1.7.1 anscheinend kein Update und nur einen Verweis auf eine kommerzielle Version 5.x. Auf auf https://www.apache.org/dyn/closer.lua/logging/log4j/2.17.0/apache-log4j-2.17.0-bin.zip gibt es eine aktuelle Version. Ich habe dann einfach versucht, die vorhandenen alten Versionen von log4j-* durch die neueren Versionen zu ersetzen. MQTT.fx startet danach aber nicht mehr. Dann habe ich es erst einmal deinstalliert. Die drei neueren Dateien musste ich von Hand entfernen.

Sehr viel umfangreicher ist aber der Analyst-Report, von dem ich hier nur einen kleinen Ausschnitt zeigen, auf dem Sie z.B. die Querys sehen, mit denen Sie Events von versuchten oder erfolgreichen Angriffen finden können.

Das funktioniert natürlich nur, wenn Sie möglichst alle unterschiedlichen Quellen auch erfassen und z.B. in Azure Sentinel konsolidieren. Wenn ich den kompletten Text in ein Work-Dokument übertrage, dann sind des 19! DIN-A4 Seiten und das Changelog zeigt, dass Microsoft hier sehr früh und regelmäßig das Dokument erweitert.

2021-12-21 22:47 UTC | Added a note on testing and benign activity assumptions
2021-12-20 22:00 UTC | Updated advisory for EDR alerts
2021-12-18 02:32 UTC | Updated investigation, analysis, detection, and protection details
2021-12-17 02:36 UTC | Updated detection, and protection details
2021-12-16 01:43 UTC | Updated investigation, analysis, detection, and protection details
2021-12-14 06:51 UTC | Updated detection and protection details
2021-12-13 00:05 UTC | Updated protection details
2021-12-12 05:00 UTC | Updated detection and protection details
2021-12-11 02:03 UTC | Entry created

Einschätzung

Die Angriffe werden immer ausgefeilter und wer in der IT arbeitet, für den sind Exploits in Software oder Hardware nicht unbekannt. Allerdings sorgt allzu oft das Tagesgeschäfts dafür, dass Sie sich selbst um die Details kümmern können. Dabei geht es gar nicht darum bestimmte Hersteller oder Betriebssysteme zu verteufeln. So unterschiedlich sind die nämlich gar nicht und auch die Entwickler machen ähnliche Fehler. Der Hafnium Exploit im Frühjahr 2021 war für das Microsoft Exchange Teams ein deutlicher Weckruf aber genauso macht Log4Shell nun vielen Firmen klar, dass es zwar gute, kostenfreie und daher oft genutzte Bibliotheken gibt, aber vieleicht doch über ein Sponsoring nachgedacht werden müsste. Denn das Team um log4j hat relativ schnell reagiert aber mehrere Versionen gebraucht, bis die Lücken scheinbar geschlossen wurden. Damit sind die alten Versionen aber noch nicht auf allen installierten Systemen "ersetzt".

Vor allem ist es für Anwender und Administratoren ohne passende Produkte erst einmal schwer zu ermitteln, wo überhaupt welche Komponente im Einsatz ist. Letztlich darf ein "Inventory"-Programm nicht mehr nur den Namen und die Version eines installierten Gesamtpakets ermitteln, sondern jede Einzelkomponente oder einzelne Datei.

Weitere Links