Log4j-Schwachstelle: Betroffene Systeme erkennen und richtig handeln

Ich versuche in diesem Artikel einen Weg zu beschreiben,  wie das Risiko für die eigene Umgebung bewertet werden kann und wie man mit betroffenen Systemen umgehen sollte.Viel hängt von Vorsorge ab.  Von Maßnahmen, die man vielleicht schon vor Jahren getroffen hat. Von Architektur-Entscheidungen, die vielleicht lange zurückliegen. Maßnahmen, die gerne — auch manchmal von mir — belächelt werden. Die aber jetzt darüber entscheiden, ob ein System oder ganze Netzwerk-Zonen als Totalschaden zu werten sind oder nicht.

Schon alle Log4j gefunden?

Die erste Frage ist: Kennen sie schon alle Systeme, auf denen die Log4j-Bibliothek eingesetzt wird? Eigene Software, Software von Dienstleistern oder Herstellern, Applicances von Herstellern. Hier muss die Suche beginnen.

Das Internet ist mittlerweile voll von Scannern, die den schon berühmten Fußabdruck ${jndi} in den Logfiles hinterlassen, dass man dort kaum noch zwischen gut und böse, Test, Scan oder Angriff unterscheiden kann. Ziel sind aktuell primär J2EE Applikation-Server, die im Internet als Web-Applikation-Server arbeiten. Hier lassen sich für Angreifer und Script-Kiddies schnell die meisten Opfer finden. Mittelfristig und heute sicher schon im Bereich der professionellen Hacker und APTs, sind aber auch nicht web-basierte Systeme das Ziel. Ich will jetzt aber im ersten Schritt auf den dramatischen Fall der exponierten Web-Services schauen.

Neben der Notwendigkeit, dass die verwundbare Log4J-Bibliothek auf dem System eingesetzt wird, sind noch einige andere Rahmenbedingungen notwendig, ob der Angriff erfolgreich sein kann oder konnte.

Wer sich an die berühmte 3-Ebenen-Architektur für J2EE und Webserver erinnert, der wird folgendes Bild kennen:

Um es nochmal in Erinnerung zu holen: In einer solchen sauberen Architektur reden wir bei Log4j hauptsächlich von einem Problem in der J2EE Zone, also der Zone mit den Applikation-Servern. Aber so einfach ist es nicht: Wenn der Webserver ebenfalls ein JAVA-System ist (also kein NGINX oder Apache HTTPd-Server) könnte auch er betroffen sein.

Und es gibt natürlich Datenbanken, die in Java geschrieben sind. Die bekanntesten, die auch Log4j verwenden, sind Elasticsearch, Solr oder Neo4j. Diese Datenbanken können das Problem bis in die DB-Zone oder das Intranet ziehen, wenn sie entsprechend getriggert werden können.

Dass auch die Realität nicht immer dem Ideal entspricht, sehen wir daran, dass es möglicherweise Appliances gibt, die ohne Ebenen-Trennung komplett in der Webzone angesiedelt sind, beispielsweise Soft- oder Hardware-Appliances.

Wie die Lücke ausgenutzt wird

Um als Angreifer die JNDI-Lücke auszunutzen, muss ich es schaffen, meine speziell erstellten Eingabe-Daten einmal durch das Log4j-Modul des Zielsystems zu schleusen, um sie in Access-Logfiles oder Debug-Logs zu bringen. Log4j kann aber auch andere Ziele wie Datenbanken oder Log-Kollektoren mit Logs beschicken. Hier greift das gleiche Prinzip: Einmal muss der ${jndi}-String durch das Log4j-Modul verarbeitet worden sein, um ausgeführt zu werden. Hier beginnt die Analyse des Vorfalls.

Wenn jetzt im Webserver-Log des nicht in Java geschriebenen Webservers ein Eintrag mit einem jndi-Request zu finden ist, oder im Feld des UserAgent verwendet wird, heißt das noch nicht, dass dieser Request an den J2EE-Server weitergegeben wurde. Der Request könnte wegen unbekanntem Pfad, falscher Request-Methode oder sonstiger individueller Konfiguration nicht an das Backend gegeben worden sein.

Wenn ich den Eintrag jedoch im Logfile des J2EE-Servers finde, befinde ich mich in einer ganz neuen Bedrohungslage wieder. Denkbar ist natürlich, dass der Angreifer die Logs auf dem kompromittierten System bereinigt hat.

Firewalls schützen

Für die Triage ist dann die Frage, was muss den jetzt noch „passen“, damit der Angriff erfolgreich sein kann? In diesem Fall betrachten wir nur einmal einen externen Angriff aus dem Internet. Damit der Angriff erfolgreich sein kann, muss das System, auf dem der Log4j läuft, auf das Internet zugreifen können, und zwar über den Port, den der Angreifer in seiner URL definiert.

Und hier kommt die gute alte Firewall wieder ins Spiel. Darf ein System aus der J2EE Zone vollumfänglich auf das Internet zugreifen? Oder darf es gar nichts oder nur seinen Update-Server erreichen? In diesem Fall entscheidet sich genau hier, ob man anfällig für die Ausnutzung der Schwachstelle ist. Wenn das Firewall-Regelwerk so gebaut sein sollte, dass der Server weite Teile des Internets erreichen kann, ermögliche ich dem Angreifer, dass er mir seinen Schadcode unterschieben kann.

Wer hier seine Server limitiert hat und gar keine Internet-Kommunikation erlaubt, hat für externe Angriffe nur mit einem geringen Risiko zu rechnen. Das Gleiche gilt für alle anderen oben beschriebenen Netzzonen: die Webzone und am Ende auch für das Intranet, wenn dort ein J2EE-Server beheimatet ist.

Wenn die eingeschleusten Requests der Angreifer auf einem Server ausgeführt werden, der wiederum die Internet-Systeme der Angreifer erreichen kann, dann muss man diesen Server als kompromittiert betrachten.

Laterale Ausbreitung

Jetzt ist zu prüfen, welche weiteren Wege der Verbreitung der Angreifer gegangen sein kann. Wenn er den betroffenen Server übernommen hatte, ist zu prüfen, wie die anderen Systeme in der gleichen Netzwerk-Zone, in der Regel ja ohne weitere Filterung,  betroffen sind. Hier ist die sogenannte laterale Verbreitung über SSH und RDP-Ports denkbar. Also diese und weitere Ports, die durch den direkten Zugriff aus dem Internet ansonsten durch die Firewall geschützt wurden. Diese Mechanik hat er nun unterlaufen.

Böser Domino-Effekt

Wenn die Domino-Steine nun beginnen zu fallen, gibt es zwei schlimmste anzunehmende Szenarien:

• Der Hypervisor, auf dem die virtuelle Maschine läuft, ist schlecht gepflegt und unzureichend gepatcht und würde über eine Sicherheitslücke den Ausbruch aus der virtuellen Maschine in das Host-System ermöglichen. Hier sind je nach eingesetztem Produkt immer wieder Fälle dokumentiert und beobachtet worden. In diesem Fall könnte der Angreifer jede virtuelle Maschine übernehmen oder mit einer Ransomware den gesamten Data-Storage der Virtualisierungsumgebung, also alle virtuellen Festplatten, verschlüsseln.
• Der zweite katastrophale Fall wäre ein schreibender Zugriff auf das Active Directory vom übernommenen System aus. Hier müsste streng genommen das komplette Active Directory geprüft und neu aufgebaut werden. Denn eine hier eingeschleuste Hintertür ermöglicht dem Angreifer die einfache Rückkehr in wenigen Monaten.

Geeignete Maßnahmen

Bei allen klar kompromittierten Systemen hilft nur eine Neu-Installation. Jede übernommene Konfiguration aus dem kompromittierten System ist zu auditieren. Sie könnte vom Angreifer schon manipuliert sein.

In Systemen ohne großen Datenbestand, möglicherweise aber mit komplexen Konfigurationen, kann es eine Überlegung wert sein, ein 2 Wochen altes Backup zurückzuspielen. Es ist nicht auszuschließen, dass der Angriff schon zuvor angewendet wurde, allerdings eher als unwahrscheinlich zu betrachten.

Dies trifft vor allem dann zu, wenn noch keinerlei der prägnanten Einträge in den Logfiles zu finden sind, die auf ${jndi} hindeuten. Wichtig hingegen ist nur, das System, bevor es wieder im Internet exponiert wird, mit allen Updates und besonders denen für log4j zu versorgen. Dann kann man davon ausgehen, dass das System wieder verwendet werden kann.

Über einen möglichen Bodenabfluss und die Versuche der lateralen Ausbreitung sagt das nichts. In der Regel werden die betroffenen Systeme ja auch abgeschaltet, sodass ein spezialisierter Forensik-Dienstleister nur noch auf den alten Festplatten-Images nach Spuren suchen kann.

Fazit

Wir haben es auch bei Shitrix erlebt, dass viele Angreifer im ersten Schritt nur eine Backdoor platziert haben, um wenige Monate später auf die Systeme zurückzukehren.

Ein System ist als kompromittiert zu betrachten, wenn jndi-Logs existieren, eine vulnerable Log4j-Version läuft oder gelaufen ist und Internet-Kommunikation erlaubt war. Dann müssen die Systeme konsequent neu installiert und aufgesetzt werden. Zusätzlich sind die Systeme der gleichen Netzwerkzone auf andere Angriffe vom kompromittierten System zu überprüfen.

Wir unterstützen Sie!

Wir bieten ihnen an, ihre öffentlich erreichbaren Systeme auf diese Schwachstelle hin zu überprüfen. So können sie:

• sicherstellen, dass die Schwachstelle beseitigt wurde oder
• verifizieren, ob Ihre Systeme verwundbar sind

Wenn Sie Interesse haben, wenden Sie sich dazu bitte an vertriebsinnendienst@to.com.

Log4Shell einfach erklärt (Webinar-Aufzeichnung)

„Was Sie jetzt zu Log4Shell wissen müssen“: Diesen Webcast haben wir kurz nach Veröffentlichung der kritischen Log4j-Schwachstelle am 14. Dezember 2021 aufgezeichnet.
Schauen Sie auch gleich in den dazugehörigen Blogartikel.