1 Die Schwachstelle Log4Shell

Wer selbst schon mal eine Anwendung programmiert hat, weiß, dass man sich um verschiedene Arten von Status-, Warnungs- oder Fehlermeldungen kümmern muss. Das ist eigentlich der weniger spannende Teil, denn man möchte ja gerne neue Funktionen einbauen, anstatt zu protokollieren. Dennoch sind aussagekräftige Meldungen sehr wichtig für den Betrieb jeder Anwendung, denn nur sie ermöglichen ein effektives Debugging.

In einigen Fällen reicht es, eine simple print-Funktion zu nutzen, um Statusmeldungen auszugeben. In Java wäre das bspw. System.out.print(). Diese Funktion bietet allerdings keine weiteren Features und ist damit ungeeignet für komplexere Applikationen. Für nahezu jede Programmiersprache bzw. jedes Framework gibt es daher eigene Bibliotheken, die es einem Programmierer ermöglichen, Logging durchzuführen. Somit muss das Rad nicht bei jeder weiteren Anwendung neu erfunden werden. Im Falle von Java heißt diese Bibliothek Log4j. Praktisch keine Java-Applikation kommt ohne Log4j aus.

Quelle: https://skeptics.stackexchange.com/questions/9870/do-3-billion-devices-run-java

Java ist eine sehr beliebte Programmiersprache, die mittels der JRE auf Systemen lauffähig wird. Java existiert auf fast allen erdenklichen Plattformen und Architekturen. Um einige zu nennen: x86, x64, ARM, Android, Windows, MacOS und sogar Chipkarten. Wer sich händisch die JRE installiert, erhält den Hinweis, dass Java auf 3 Milliarden Geräten läuft. Auch wenn diese Zahl eine ungenaue Schätzung ist, wird klar, dass auf einer enormen Anzahl von Systemen weltweit Java-Anwendungen ausgeführt werden, die wiederum zum Großteil Logging mittels Log4j betreiben. Damit ist die Anzahl angreifbarer Systeme natürlich ebenso enorm groß. Eine Schwachstelle, die einen Kernbestandteil von Java betrifft, wäre somit eine direkte Gefahr für einen Großteil aller Systeme weltweit. Genau dieser Super-GAU ist nun eingetreten. Zu der enormen Anzahl angreifbarer Systeme gesellt sich leider auch eine sehr einfache Möglichkeit, die Schwachstelle in Log4j auszunutzen. Zusätzlich sind die Auswirkungen pro kompromittiertes System sehr schwerwiegend. Daher ergibt sich der kritische CVS-Score von 10.0/10.0. Das ist die höchstmögliche Kritikalität einer einzelnen Schwachstelle.

Aber wie funktioniert die Schwachstelle nun eigentlich? Die abstrakte Erklärung ist trivial, aber auch die konkrete technische Erklärung bzw. der zugehörige Exploit ist eher simpel. Log4j interpretiert bestimmte Zeichenketten, die vom Angreifer als Steuerzeichen vorgegeben werden können und erlauben es diesem somit, eine RCE- Schwachstelle (Remote Code Execution) auszunutzen. Dies kann zur vollständigen Kompromittierung des angegriffenen Systems führen. Diese Zeichenketten können beispielsweise bei einem Webserver in Form eines User-Agent-Strings vorgegeben werden, wenn der Java-Webserver Log4j nutzt, um User-Agent-Strings zu protokollieren.

2 Die Schwachstelle finden

Um die eigene Infrastruktur schnell auf Herz und Nieren zu prüfen, eignen sich verschiedene kostenlose Tools und Scanner. Eine Warnung sei bei jeglichen 3rd Party Tools aber ausgesprochen: Es wäre denkbar, dass sich Angreifer die allgemeine Panik zu Nutze machen und gezielt Tools verbreiten, die verwundbare Systeme an die Angreifer weiterleiten. Nicht nur aus diesem Grund empfiehlt NSIDE, die Tests von einem professionellen, offensiven IT-Sicherheitsdienstleister durchführen zu lassen. Auch die Gründlichkeit und Zielgenauigkeit der Tests kann nur gewährleistet werden, wenn Fachpersonal zum Einsatz kommt.

Dennoch möchte NSIDE den Lesern ein paar wichtige Tipps bzw. Tools an die Hand geben, um erste rudimentäre Checks durchzuführen. Empfehlenswert ist beispielsweise der Tester von Trend Micro: https://log4j-tester.trendmicro.com. Dieser erlaubt es, beliebige eigene Eingabefelder auf die Schwachstelle hin zu untersuchen oder eigene Anwendungen zu scannen. Auf dem Screenshot (1) wird die einzigartige ID angezeigt, die in beliebige Eingabefelder Ihrer Applikation kopiert werden kann. Im unteren Teil des Screenshots (2) kann ein Scanner von Trend Micro benutzt werden, um bestimmte Endpunkte automatisiert scannen zu lassen.

Quelle: NSIDE

Wenn man weiter auf der Website herunterscrollt, werden die potenziellen Ergebnisse des Scans sichtbar. Falls hier keine Ergebniszeilen auftauchen, waren die Anwendungen gegen die Schwachstelle immun.

Quelle: NSIDE

Wer sich nicht auf einen 3rd-Party Dienstleister verlassen möchte und Erfahrung im Umgang mit Python-Skripten besitzt, hat außerdem die Möglichkeit, mit folgendem Tool die eigene Infrastruktur manuell zu scannen.

Quelle: https://github.com/fullhunt/log4j-scan/blob/master/README.md

Dieses von externer Infrastruktur unabhängige Tool kann große Mengen von URLs bzw. IPs gleichzeitig scannen. Außerdem können Parameter präziser konfiguriert werden.

3 Die Schwachstelle beheben

Um die Schwachstelle zu beheben, sind Patches für die Log4j Bibliothek notwendig. Der erste Patch (Log4j 2.15.0) ist dabei nicht ausreichend und es muss zwingend Version 2.16.0 auf die betroffenen Systeme aufgespielt werden. Um die aktuellen Entwicklungen der Patches zu verfolgen sei an dieser Stelle auf https://logging.apache.org/log4j/2.x/security.html verwiesen. Eine detaillierte Anleitung, wie der Patch für verschiedene Systeme durchzuführen ist, findet sich hier. Falls ein System nicht gepatcht werden kann und zwingend weiterlaufen muss, gibt es Workarounds, die für solche Systeme in Frage kommen. Ein Java Agent kann die verwundbare Komponente von Log4j (JNDI) temporär abschalten. Dafür wird einfach die Zeichenkette -javaagent:path/to/log4j-jndi-be-gone-1.0.0-standalone.jar als Startparameter für die gewünschte Applikation gesetzt. Der komplette Befehl könnte wie folgt aussehen:

$ java -javaagent:path/to/log4j-jndi-be-gone-1.0.0-standalone.jar -jar path/to/some.jar. Der Agent lässt sich hier herunterladen. Das zugehörige GitHub-Repository findet sich hier.

Im folgenden Blogpost wird NSIDE einen PoC-Exploit (Proof of Concept) der Schwachstelle vorstellen.