eNVenta ERP – Java Schwachstelle log4j – BSI Meldung

20.12.2021 (aktualisierte Infos nach dem Klick auf Quelle)

Bei einem unserer Hardware Partner Herrmann und Lenz erhielten wir folgende Infos bezüglich Oracle:

Quelle

17.12.2021 (aktualisierte Infos nach dem Klick auf Quelle)

Auch die Firma Proxess als eNVenta ERP Partner für Archivierung und Belegerkennung empfiehlt Updates aufgrund der Sicherheitslücke.

Quelle

Detail-Infos zum Thema:

11.12.2021

Kritische Java Schwachstelle log4j veröffentlicht (CVE-2021-44228)

BSI Meldung Schwachstelle log4j

Erhöhung der Warnstufe auf Rot
CSW-Nr. 2021-549032-1232, Version 1.2, 11.12.2021

Sachverhalt Java Schwachstelle log4j

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.

Bewertung Java Schwachstelle log4j

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.

Aktuell 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.

Maßnahmen Java Schwachstelle log4j

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.