Kritische Schwachstelle in log4j

Log4j ist eine beliebte Protokollierungsbibliothek für Java-Anwendungen. Das Blog eines Dienstleisters für IT-Sicherheit berichtet über die Schwachstelle CVE-2021-44228 in log4j in den Versionen 2.0 bis 2.14.1, die es Angreifern gegebenenfalls ermöglicht, auf dem Zielsystem eigenen Programmcode auszuführen und so den Server zu kompromittieren.

Diese Gefahr besteht dann, wenn log4j verwendet wird, um eine vom Angreifer kontrollierte Zeichenkette wie Beispielsweise den HTTP User Agent zu protokollieren. Ein Proof-of-Concept (PoC) der Schwachstelle wurde auf Github veröffentlicht und auf Twitter geteilt. Neben dem PoC existieren auch Beispiele für Skripte, die Systeme stichprobenartig auf Verwundbarkeit hin untersuchen. Skripte solcher Art können zwar Administratoren keine Sicherheit über die Verwundbarkeit geben, aber erlauben Angreifern kurzfristig rudimentäre Scans nach verwundbaren Systemen.


Diese kritische Schwachstelle hat demnach möglicherweise Auswirkungen auf alle aus dem Internet erreichbaren Java-Anwendungen, die mit Hilfe von log4j Teile der Nutzeranfragen protokollieren.

Bewertung

Log4j wird in vielen Java-Anwendungen eingesetzt. Die Hürden für eine aktive, breite Ausnutzung sind durch die Verfügbarkeit eines PoC sehr gering. Das Patchmanagement von Java-Anwendungen ist nicht trivial, sodass bis zu einer Update-Möglichkeit die kurzfristigen Mitigationen empfohlen werden. Wenngleich das Nachladen von Schadcode über den im PoC aufgezeigten Weg bei Grundschutz-konform eingerichteten Systemen fehlschlagen sollte, sind auch andere Wege denkbar, ggf. auch automatisiert und ohne Nachladen Schadcode zur Ausführung zu bringen. Hierbei ist die Komplexität im Vergleich zum PoC deutlich erhöht.

Maßnahmen

Server sollten generell nur solche Verbindungen (insbesondere in das Internet) aufbauen dürfen, die für den Einsatzzweck zwingend notwendig sind. Andere Zugriffe sollten durch entsprechende Kontrollinstanzen wie Paketfilter und Application Layer Gateways unterbunden werden. Es sollte entsprechend dem Grundschutzbaustein ein Update auf die aktuelle Version 2.15.0 von log4j in allen Anwendungen sichergestellt werden. Da Updates von Abhängigkeiten in Java-Anwendungen häufig nicht zeitnah erfolgen können, sollte bis dahin die folgende Mitigationsmaßnahme ergriffen werden: Die Option “log4j2.formatMsgNoLookups” sollte auf “true” gesetzt werden, indem die Java Virtual Machine mit dem Argument


“–Dlog4j2.formatMsgNoLookups=True”


gestartet wird.


Achtung: Diese Maßnahme kann die Funktionsweise der Applikation beeinträchtigen, wenn die Lookup-Funktion tatsächlich verwendet wird.

www.bsi.bund.de