BSI: Kritische Schwachstelle in log4j veröffentlicht (CVE-2021-44228)
Sachverhalt
Log4j ist eine beliebte Protokollierungsbibliothek für Java-Anwendungen. Sie dient der performanten Aggregation von Protokolldaten einer Anwendung.
Das Blog eines Dienstleisters für IT-Sicherheit [LUN2021] berichtet über die Schwachstelle CVE-2021-44228 [MIT2021] 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 [GIT2021a] und auf Twitter geteilt [TWI2021]. Neben dem PoC existieren auch Beispiele für Skripte, die Systeme stichprobenartig auf Verwundbarkeit hin untersuchen [GIT2021b]. 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.
Update 1:
Der Schwachstelle wurde nach Veröffentlichung des Blog-Posts ein CVSS-Wert von 10.0 zugewiesen.
Erste öffentliche Quellen weisen auf breitflächiges Scannen nach verwundbaren Systemen hin. Das BSI kann derartige
Scan-Aktivitäten bestätigen.
Update 2:
Im Gegensatz zur ursprünglichen Einschätzung kann die kritische Schwachstelle ggf. auch auf internen Systemen
ausgenutzt werden, sofern diese externe Daten entgegennehmen oder verarbeiten.
Einige Produkthersteller haben bereits öffentlich bzgl. einer möglichen (Nicht-)Betroffenheit ihrer Produkte
hingewiesen und teilweise bereits Updates veröffentlicht ([APA2021c], [BRO2021], [CIS2021], [FSE2021], [MCA2021],
[SOP2021], [TRE2021], [VMW2021a], [VMW2021b], [UNI2021]). Zu den betroffenen Herstellern gehören z. B.:
• VMWare
• Apache
• UniFi
Diese Liste ist nicht abschließend und erhebt keinen Anspruch auf Vollständigkeit. Zahlreiche weitere Hersteller prüfen
aktuell noch eine Betroffenheit.
Update 3:
Auf Github wurde unter [GIT2021e] eine Liste mit Sicherheitswarnungen für Produkte von über 140 Herstellern
veröffentlicht. Einige der Links verweisen direkt auf Herstellerseiten, die neben Informationen zur Betroffenheit auch
Updates für Ihre Produkte bereitstellen. Die Inhalte wurden durch das BSI stichprobenartig verifiziert und sollen als
erste Orientierungshilfe dienen.
Das NCSC NL (Nationaal Cyber Security Centrum Netherlands) plant im Laufe des Nachmittages die Veröffentlichung
eines Github-Repositories unter [NCSC2021] mit gesicherten Informationen zu betroffenen Herstellern. Zum
Redaktionsschluss war das Repository noch nicht veröffentlicht.
Bewertung
Log4j wird in vielen Java-Anwendungen eingesetzt. Der Schutz gegen eine aktive, breite Ausnutzung ist 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.
Update 1:
Aufgrund der weiten Verbreitung der Bibliothek ist es nur schwer absehbar, welche Produkte alle betroffen sind.
Das BSI sieht aktuell eine Erhöhung der IT-Bedrohungslage für Geschäftsprozesse und Anwendungen. Durch das aktuell
breitflächige Scannen ist eine mögliche anschließende Infektion von anfälligen Systemen und Anwendungen, auch auf
Grund aktuell oftmals noch fehlenden Patches, nicht auszuschließen.
Update 2:
Das Ausmaß der Bedrohungslage ist aktuell nicht abschließend feststellbar. Die Reaktions- und Detektionsfähigkeit des
IT-Betriebes ist kurzfristig geeignet zu erhöhen, um angemessen die Systeme überwachen zu können bzw. zu reagieren.
Aus mehreren CERT-Quellen erreichten das BSI Benachrichtigungen über weltweite Massenscans und versuchte
Kompromittierungen. Es gibt bereits erste Meldungen über erfolgreiche Kompromittierungen (bislang u.a. mit
Kryptominer).
Es sind zudem Ausnutzungen der Schwachstelle zu beobachten, die kein explizites Nachladen eines Schadcodes
benötigen und einen maliziösen Code direkt in der Abfrage enthalten. Dies gefährdet auch Grundschutz-konforme
Systeme, die i.d.R. keine Verbindung ins Internet aufbauen können.
ktuell ist noch nicht bekannt in welchen Produkten diese Bibliothek eingesetzt wird, was dazu führt, dass zum jetzigen
Zeitpunkt noch nicht abgeschätzt werden kann, welche Produkte von der Schwachstelle betroffen sind.
Auch interne Systeme, die Informationen oder Daten von anderen Systemen verarbeiten, können ggf. kompromittiert
werden und sind daher umgehen zu patchen.
Aufgrund der neuen Sachverhalte hat das BSI entschieden die Warnmeldung von der Warnstufe Orange auf Rot
hochzustufen.
Update 3:
Neben erfolgreichen Kompromittierungen mit Kryptominern gibt es unter [3602021] erste Hinweise darauf, dass die
Schwachstelle auch von Botnetzen ausgenutzt wird. Die Wahrscheinlichkeit ist groß, dass die mit dieser Schwachstelle
in Verbindung stehenden Angreiferaktivitäten in den nächsten Tagen deutlich zunehmen werden.
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. [BSI2021b]
Es sollte entsprechend dem Grundschutzbaustein [BSI2021a] ein Update auf die aktuelle Version 2.15.0 [APA2021] (git-
tag: 2.15.0-rc2 [GIT2021c]) 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.
Update 2:
Alternativ kann auch die Umgebungsvariable LOG4J_FORMAT_MSG_NO_LOOKUPS auf true gesetzt werden. Diese
beiden Mitigationsmaßnahmen funktionieren erst ab Log4J Version 2.10.
Achtung: Diese Maßnahme kann die Funktionsweise der Applikation beeinträchtigen, wenn die Lookup-Funktion
tatsächlich verwendet wird.
Update 2:
Die Log4J Versionen 1.x sind von der aktuellen Schwachstelle nach aktueller Kenntnis nicht betroffen [GIT2021d]. Die
Version 1.x wird, auch wenn sie noch in diversen Produkten eingesetzt wird, nicht mehr vom Hersteller unterstützt. Sie
ist End-of-Life und durch andere Schwachstellen verwundbar. Daher sollten auch noch eingesetzte Log4J Versionen 1.x
ebenfalls auf eine nicht-verwundbare Version 2.x aktualisiert werden.
Sofern das Log4j als eigene jar-Datei vorliegt, kann diese ggf. ausgetauscht werden. Hier ist vorab die
Herstellerdokumentation zu prüfen, ob und unter welchen Umständen dieses Verfahren das System absichert.
Als Alternative, die auch in Versionen ab 2.0-beta9 und höher funktioniert, empfiehlt der Hersteller die Klasse
JndiLookup aus dem Klassenpfad zu löschen [APA2021b]:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Sofern die Hersteller Updates zur Verfügung stellen, sollten diese umgehend installiert werden.
In den jeweilig zu verantwortenden Bereichen sollte qualifiziertes IT-Personal eingesetzt werden, um die kritischen, vor
allem von außen zu erreichende Systeme engmaschig zu überwachen.
Um potentiell betroffene Systeme leichter zu identifizieren, kann zunächst überprüft werden, welche Systeme Java als
Installationsvoraussetzung haben oder Java installieren. Zu solchen Systemen sollten die Meldungen des jeweiligen
Herstellers prioritär geprüft werden. Sofern seitens des Herstellers noch kein Security Advisory veröffentlicht wurde,
sollte eine entsprechende Anfrage gestellt werden.
Da eine Ausnutzung nicht zwingend ein Nachladen von Schadcode aus dem Internet benötigt, sondern bereits mit
einer einzigen Anfrage möglich ist, muss für alle verwundbaren Systeme die Angriffsfläche reduziert werden. Konkrete
Schritte hierzu sind:
• Nicht zwingend benötigte Systeme abschalten.
• Netzwerke segmentieren, sodass verwundbare Systeme von nicht extern-verbundenen/internen Systemen
isoliert werden
Systeme, die aufgrund der Kritikalität für unabdingbare Geschäftsprozesse nicht abgeschaltet werden können:
• In Web-Application-Firewalls (WAF), Intrusion Prevention Systemen (IPS) oder Reverse Proxies Verbindungen,
die Angriffsmuster aufweisen, direkt ohne Weitergabe an die Fachapplikation abweisen oder nicht zwingend
benötigte HTTP-Header auf statische Werte setzen.
• Blockieren aller nicht zwingend notwendigen, ausgehenden Verbindungen.
• Umfassendes Logging und die Protokollierung aller eingehender und ausgehender Verbindungen, um im
Nachgang eine Kompromittierung leichter feststellen zu können.
• Anomaliedetektion auf dem Host betreiben.
• Prüfen, mit welchen Rechten der betroffene Dienst betrieben wird und diese auf das notwendige Minimum
reduzieren.
• Verbindungen zu anderen Systemen sollten getrennt werden.
Für nach Bekanntwerden der Schwachstelle gepachte Systeme muss zusätzlich untersucht werden, ob diese bereits
kompromittiert wurden. Dies betrifft auch Systeme, die nicht direkt mit dem Internet verbunden sind, da diese über
verbundene Systeme kompromittiert worden sein könnten.
Informieren Sie sich auf den Webseiten der von Ihnen eingesetzten Hersteller (u.a. den oben genannten) über Patches
und Workarounds und spielen sie diese unverzüglich ein.
Update 3:
Unter [GIT2021e] und [NCSC2021] (möglicherweise erst am späten Nachmittag verfügbar) wurden Hinweisen zu einer
möglichen Betroffenheit zahlreicher Produkte veröffentlicht. Als erste Orientierungshilfe ist es zu empfehlen, diese
Listen mit eigenen eingesetzten Produkten abzugleichen. Das BSI hat die Inhalte nicht vollständig verifiziert. Die Listen
werden mit hoher Wahrscheinlichkeit fortlaufend aktualisiert, so dass eine mehrmalige Überprüfung notwendig ist.
Dieser Abgleich kann die zwingend erforderlichen eigenen Überprüfungsmaßnahmen ergänzen.
Da zum aktuellen Zeitpunkt keine gesicherte Aussage darüber getroffen werden kann, in welchen Produkten die
Bibliothek eingesetzt wird, kann das unter [GIT2021h] veröffentlichte Tool zum Suchen von betroffenen log4j
Bibliotheken verwendet werden. Das Tool durchsucht dabei Hashsummen-basiert .jar und .war Archive nach
eindeutigen Java-Klassen. Da lediglich die offiziell kompilierten Releases erkannt werden, kann es insbesondere bei
Linux-Systemen vorkommen, dass betroffene log4j Bibliotheken nicht erkannt werden.
Unter [GIT2021f] wurde eine Auflistung von Befehlen veröffentlicht, mit denen man Log-Daten auf eine mögliche
Ausnutzung der Schwachstelle überprüfen kann. Im Falle von Treffern ist es dringend zu empfehlen weitere
Maßnahmen sofort einzuleiten. Zu diesen zählen z.B.: Netztrennung, Suche nach den Schwachstellen, deren Schließung
(ggf. durch Neuinstallation) und dann die Feststellung/Bereinigung einer möglichen Kompromittierung mit Schadcode
unter Betrachtung auch weiterer benachbarter und dahinterliegender Systeme (lateral movement).