Die Schwachstelle Log4J im Blick von Pentest-SpezialistenEntscheidend ist die JNDI-Payload
21. Dezember 2021
Bei der Log4J-Schwachstelle handelt es sich um ein sehr großes Problem in der weit verbreiteten Protokollierungsbibliothek Log4j der Programmiersprache Java. Dabei sind alle Versionen vor 2.15.0 /2.16 betroffen. Das Gefährliche an dieser als CVE-2021-44228 bezeichneten Schwachstelle ist die Möglichkeit, dass es bei ihrem Ausnützen zu sehr riskanten Situationen kommen kann. Zu diesem Resümee kommen die Security-Experten der SySS GmbH in einem Webcast zum Thema Log4J.
In Bezug auf diese Ausnutzbarkeit der Log4J-Schwachstelle existieren zwei Optionen: Zum einen kann man Schadcode ausführen, und zum anderen Daten exfiltrieren. Das Ausführen von beliebigen Systemkommandos ist möglich, wenn eine veraltete Java-Version zum Einsatz kommt, zum Beispiel Java 8, Patchlevel 1.0.1. oder wenn bestimmte Anwendungsserver (Apache Tomcat oder Websphere) Verwendung finden. Im Falle dieser Anwendungsserver betrifft die Schwachstelle auch neuere Java-Versionen.
Diese Schwachstelle ist besonders kritisch, weil es bereits öffentlich verfügbare Tools gibt, die es Angreifern sehr einfach machen, diese Schwachstelle auszunutzen. Zudem lässt sich nur schwer bestimmen, ob die eingesetzte Applikation betroffen ist, denn man kann derzeit kein Tool einsetzen, das 100prozentig prüft, ob die Schwachstelle in der Anwendung besteht.
Der zweite Problembereich, das Exfiltrieren von Daten, besteht darin, dass man Systemvariable auslesen kann, und sie über eine initiale DNS-Anfrage an das System des Angreifers ausschleusen. Das kann in allen Java-Versionen auftreten.
Ausnutzen der Schachstelle
Um die Schwachstelle auszunutzen muss der Angreifer lediglich die Möglichkeit haben, bestimmte Daten an die Anwendung weiterzugeben, die dann protokolliert – also geloggt – werden. Dies wird wohl immer der Fall sein, wenn man die Log4J-Library verwendet. In der Grafik wird verdeutlicht, wie der Angriff abläuft.
Der Angreifer schickt die JNDI-Payload (JNDI steht für Java Naming and Directory Interface) mit der Adresse des böswilligen Servers an den Anwendungsserver – in dem String für den User-Agent. Der angegriffene Server möchte den User-Agent loggen und sendet die Information an Log4J weiter. Dann wird dieser Ausdruck ausgewertet und Log4J meldet sich dann an dem angegebenen (böswilligen) LDAP-Server und lädt über diesen Server ein Java-Objekt nach.
In der Grafik ist auch zu sehen, wo man geeignete Gegenmaßnahmen ergreifen kann: Am Punkt 1 kann eine Web Application Firewall (WAF) verwendet werden, um den Angriff zu blockieren. Doch eine WAF kann auch umgangen werden, daher sollte man sich nicht auf diese Aktion alleine verlassen. Generell sollte der Ansatz „Defense in Depth“ verfolgt werden, bei dem mehrere Schichten zum Einsatz kommen, um den Angriff generell abzuwehren.
Eine weitere Verteidigungslinie wäre das komplette Deaktivieren der Log4J-Schnittstelle, wenn das die Applikation erlaubt. Damit entfällt allerdings das Logging der entsprechenden Aktionen. Die beste Variante wird aber das Patchen der Log4J-Bibliothek selbst sein, die ebenfalls in der Grafik zu sehen ist. Doch das empfiehlt sich nur für Situationen, in denen das Know-how für diese Aufgabe vorhanden ist.
Maßnahmen gegen die Schwachstelle
Aufgrund der Vorgehensweise bei den Angriffen sollte man verschiedene Gegenmaßnahmen ergreifen. Zuerst sollte man identifizieren, welche Systeme im eigenen Netzwerk betroffen sind. Des Weiteren empfiehlt sich die Isolation der betroffenen Systeme. Das lässt sich umsetzen, wenn man ausgehende Verbindungen auf TCP-Basis verhindert und DNS-Anfragen unterbindet. In diesem Fall kann die Schwachstelle nicht ausgenutzt werden.
Zudem sollte man verfolgen, ob der Hersteller der Java-Anwendung bereits an einem Patch arbeitet bzw. ihn sogar schon bereitgestellt hat. Wenn der einsatzfähig ist, sollte man schnell das Update einspielen.
Falls es noch keinen Patch gibt, sollte man das System definitiv isolieren oder einen der publizierten Workarounds einsetzen. Die Entwickler bei Apache.org haben dazu entsprechende Informationen bereitgestellt. Um festzustellen, ob die eigene Java-Applikation betroffen ist, sollte man versuchen, von seinem Lieferanten eine valide Aussage zu bekommen, ob das der Fall ist. Zudem existiert eine Sammlung von Aussagen verschiedener Hersteller zu dieser Schwachstelle. Zudem hat die „Community“ eine „inoffizielle“ Sammlung von „verwundbaren Produkten“ erstellt – die naturgemäß nicht komplett vollständig sein dürfte sowie eine mit Bezug zu Datenbanken.
Gefährdungslage bei mobilen Endgeräten
Android verwendet die Android Java-Runtime. Sie bietet JNDI-Lookups gar nicht an, sprich Android-Endgeräte sind nicht betroffen. Bei Apples iOS werden die meisten Anwendungen in Objective-C geschrieben. Diese Programme verwenden standardmäßig kein Java. Derzeit sind keine Informationen bekannt, dass es hier zu erfolgreichen Angriffen im Kontext der Log4J-Schwachstelle kommen könnte.
Rainer Huttenloher nach Informationen der SySS GmbH.
