Ein Rückblick auf Log4j Teil 1: Hintergründe der Schwachstellen

Zeitachsen

Am 24. November 2021 wird die Apache Foundation vom Cloudsicherheitsteam von Alibaba privat darüber informiert, dass Log4j, eine Java-basierte Protokollierungsbibliothek, eine schwerwiegende Sicherheitslücke enthält, durch die private Informationen preisgegeben und Code aus der Ferne ausgeführt werden könnte (Remote Code Execution, RCE).  Diese Sicherheitslücke gibt es seit 2013.

Am Tag darauf reservierte die Apache Foundation CVE-2021-44228 und begann mit der Suche nach einer Lösung.  In den nächsten 12 Tagen wurden mehrere Änderungen am Quellcode vorgenommen, um das Problem zu beheben, und am 9. Dezember 2021 wurde die Sicherheitslücke öffentlich bekannt gegeben.

Dies führte zu einer Flut von Exploit-Versuchen, die seither mit besorgniserregender Geschwindigkeit zunehmen.

Was ist Log4j?

Um die Schwachstelle wirklich zu verstehen, müssen wir wissen, was Log4j ist. Log4j ist eine Bibliothek, die von vielen Java-Entwicklern verwendet wird. Sie bietet ein einfaches, aber robustes Framework für die Protokollierung von Fehlermeldungen, Diagnoseinformationen und mehr.

Besonders beeindruckend ist unter anderem die Möglichkeit, an mehrere Ziele zu protokollieren, einschließlich, aber nicht beschränkt auf die Konsole, eine Datei, ein Remote-Server über TCP, Syslog, NT Event Logs und E-Mail.  Darüber hinaus ermöglicht sie die hierarchische Filterung von Protokollmeldungen, Protokollebenen, nutzerdefinierten Layouts und vielem mehr.

Kurz gesagt: Sie verfügt über einen umfassenden Funktionssatz, mit dem sie besonders für Entwickler interessant ist. Das hat auch dazu geführt, dass sie von Webanwendungen bis hin zu eingebetteten Geräten überall zu finden ist.

Abfragen und Verschachtelung

Eine der wirklich leistungsstarken Funktionen, die Log4j unterstützt, sind die so genannten Abfragen (Lookups). Mit Abfragen kann ein Entwickler Variablen oder Ausdrücke in den Text einbetten, die von Log4j vor der Ausgabe automatisch ausgewertet werden. Ein Entwickler könnte beispielsweise einen Code schreiben, der den folgenden Text protokolliert:

„${date:MM-dd-yyyy} Alle Systeme gut“

Log4j erkennt das Muster ${date:MM-dd-yyyy} als Datumsabfrage und ersetzt diesen Ausdruck pflichtgemäß durch das heutige Datum. Wäre das Datum zum Beispiel der 20. Dezember 2021, würde der Text wie folgt geändert, bevor er an ein Ziel ausgegeben wird:

„12-20-2021 Alle Systeme gut“

Das ist für Entwickler äußerst hilfreich. Ohne diese Funktion müssten sie manuell einen Code schreiben, der das Datum abfragt, es in eine Zeichenkette formatiert, der Protokollzeile voranstellt und dann ausgibt. Und obwohl der obige Code nicht besonders schwierig oder aufwendig ist, bezieht er sich nicht auf die Kerngeschäftslogik der Software und wird schließlich für jedes folgende Projekt wiederholt.

Durch die Nutzung der bereits codierten Funktionalität innerhalb der Log4j-Bibliothek können sich Entwickler auf die für ihr Projekt wichtige Differenzierung konzentrieren und Log4j die Protokollierung überlassen.

Es gibt viele Arten solcher Abfrageausdrücke, die von Log4j unterstützt werden. Sehen wir uns zwei weitere an, die in diesem Artikel eine wichtige Rolle spielen werden: env und lower. Mit env werden Umgebungsvariablen auf dem Hostsystem in die Protokollzeilen einbezogen. Protokolliert ein Entwickler beispielsweise diesen Text:

„Der aktuelle Nutzer ist ${env:USER}“

würde die folgende Ausgabe erzeugt werden, vorausgesetzt, die Software wird als Nutzeradministrator ausgeführt.

„Der aktuelle Nutzer ist Administrator“

Im Gegensatz zu env und date, die neue Daten in den Text einfügen, kann lower verwendet werden, um bereits vorhandene Daten zu manipulieren.  Log4j schreibt einfach klein, was innerhalb des Ausdrucks erscheint.  Zum Beispiel:

„Der kleingeschriebene Text ist ${lower:ABCDEFG}“

würde ergeben:

„Der kleingeschriebene Text ist abcdefg“

Dieses Beispiel ist für sich genommen nicht sehr interessant. Warum kann man die Zeichenfolge nicht einfach selbst kleinschreiben?  Die Wirksamkeit dieser Methode wird deutlicher, wenn man bedenkt, dass Log4j die Verschachtelung von Abfrageausdrücken ermöglicht.

Wir können die beiden vorherigen Ausdrücke wie folgt kombinieren:

„Der kleingeschriebene aktuelle Nutzer ist ${lower:${env:USER}}“

Dies veranlasst Log4j dazu, zunächst den Ausdruck ${env:USER} als Administratorauszuwerten und dann kleinzuschreiben, was zu administratorund schließlich zur folgenden Zeile führen würde:

„Der kleingeschriebene aktuelle Nutzer ist administrator“

JNDI

Auch wenn date, envund lower alle interessant und sehr nützlich sind, wäre diese Schwachstelle ohne die JNDI-Abfrage nutzlos.  JNDI(Java Naming and Directory Interface) ist ein in die Java-Entwicklungs- und -Laufzeitumgebung integrierter Mechanismus, der eine vereinfachte Abfrage verschiedener Verzeichnisdienste nach Informationen über eine gemeinsame Schnittstelle ermöglicht.

Wie sich herausstellt, werden viele verschiedene Arten von Verzeichnisdiensten unterstützt.  So unterstützt JNDI beispielsweise die Abfrage von DNS-Servern, um die IP-Adresse eines Hosts zu ermitteln, sowie die Abfrage von AD- und LDAP-Verzeichniseinträgen.  Es unterstützt sogar die Abfrage der laufenden Java-Umgebung selbst nach Umgebungseinträgen, die als spezielle Konfigurationsoptionen für die aktuell ausgeführte Software angesehen werden können.

Der JNDI-Abfrageausdruck in Log4j ermöglicht Entwicklern den direkten Zugriff auf dieses enorm leistungsfähige Subsystem durch eingebettete Ausdrücke im protokollierten Text.  Wenn ein Entwickler beispielsweise versuchen würde, die folgende Zeichenfolge zu protokollieren:

„Der aktuelle Mail-Host ist ${jndi:java:comp/env/mailhost}“,

würde Log4j ${jndi:java:comp/env/mailhost} als eine JNDI-Abfrage erkennen und die Pseudo-URL von java:comp/env/mailhost an das JNDI-Subsystem weitergeben.  JNDI würde diesen speziellen URL-Typ als Abfrage erkennen, um eine Konfigurationsoption namens mailhost für die aktuell laufende Komponente zu ermitteln.

Nehmen wir an, dies ist konfiguriert als mymailserver.example.com. JNDI würde diese Informationen an Log4j zurückgeben, die dann den Abfrageausdruck durch mymailserver.example.com ersetzen würde, was die folgende Ausgabe zur Folge hätte:

„Der aktuelle Mail-Host ist mymailserver.example.com“

Verstehen, wie die Sicherheitslücke entsteht

Kurz gesagt, die Schwachstelle in Log4j von Apache stellte für Angreifer eine große Chance dar, da die Bibliothek sehr beliebt ist und insbesondere über Abfrage-, Verschachtelungs- und JNDI-Funktionen verfügt. Diese sind zwar für Entwickler sehr nützlich, bieten aber auch die Möglichkeit, Anfragen weiterzuleiten, die Daten ausspionieren oder RCE verursachen können. Mit diesem Wissen können wir nun der Schwachstelle auf den Grund gehen und herausfinden, wie Angreifer das System ausnutzen können.

So geht’s weiter

In Teil 2 dieser Serie werden wir uns ansehen, wie Angreifer diese Sicherheitslücke für die Datenextraktion und Codeausführung aus der Ferne ausnutzen.