[English]In der zum Logging benutzen Java Bibliothek log4j gibt es eine kritische Schwachstelle, die ungepatcht ist. Diese Software ist in vielen anderen Produkten integriert. Tausende Dienste von Apple, Amazon, Twitter, Minecraft etc. sind über diese Schwachstelle anfällig. Inzwischen wurden bereits erste Angriffe auf Honeypots beobachtet. Hier ein kurzer Überblick, was Sache ist.
Anzeige
Ein Leser hat in einem Kommentar auf dieses Problem hingewiesen, welches u.a. hier beschrieben ist. Bei log4j handelt es sich um eine Apache-Bibliothek zum Logging für Java. Diese Bibliothek ist wohl sehr leistungsfähig und flexibel und auch recht populär. Daher wird diese Bibliothek in fast jeder Java-Anwendung zur Protokollierung verwendet.
Leider gibt es in log4j eine ungepatchte Schwachstelle in der JNDI-Lookup-Funktion. Die JNDI-Lookup-Funktion von log4j ermöglicht den Abruf von Variablen über das JNDI – Java Naming and Directory Interface. Dabei handelt es sich um eine API, die Java-Anwendungen Namens- und Verzeichnisfunktionen zur Verfügung stellt. Es gibt zwar viele Möglichkeiten, aber log4j unterstützt (AFAIK) LDAP und RMI (Remote Method Invocation).
Schwachstelle CVE-2021-44228
Am 9. Dezember 2021 wurde ein Proof of Concept (PoC) für die Remote Code Execution-Schwachstelle in log4j veröffentlicht. Der PoC benötigt nur wenige Zeilen Code mit dem eine Zeichenkette in Form einer URL in die Protokolldatei schreibt. Der Verzeichnisdienst JNDI kontaktiert darauf hin den im Protokoll aufgeführten LDAP-Server, um von diesem Daten anzufordern. Das kann auch Java-Klassen umfassen, die dann ausgeführt werden. Gelingt es einem Angreifer die URL auf einen von ihm kontrollierten Server in der Protokolldatei anzugeben, kann er einen Server über das Logging kapern (Log4Shell).
Die Schwachstelle CVE-2021-44228 wird laut heise als kritisch bewertet und hat den CVE-Index 10 (von 10 möglichen Punkten) erhalten. Die Pen-Testing-Gruppe 0x0021h, die den PoC-Exploit entwickelte, gibt an, dass dieser für Apache Struts2, Apache Solr, Apache Druid, Apache Flink und funktioniert. Auf dieser GitHub-Seite werden betroffene Dienste aufgelistet – da ist alles dabei, was Rang und Namen hat. Neben Apple iCloud, Amazon, CloudFlare, Steam, Twitter und selbst das populäre Mindcraft ist alles dabei. Laut Bleeping Computer wurde Minecraft aber bereits per Notfall-Patch über die Version Minecraft: Java Edition 1.18.1 geflickt.
Anzeige
Administratoren von Anwendungen sollten nach Updates der Software-Hersteller Ausschau halten und diese zeitnah installieren. Da die Ausnutzung der Sicherheitslücke es erfordert, dass der betroffene Server/Client einen anderen Server im Internet erreicht (der die JNDI-Referenz bereitstellt), können laut SANS-Institute die folgenden Maßnahmen durchgeführt werden:
- Blockieren des ausgehenden Datenverkehrs, der nicht erforderlich ist. Wer einen Server hat, auf dem eine Java-Anwendung läuft, die nur eingehenden Datenverkehr annehmen muss, sollte der gesamte ausgehende Datenverkehr verhindert werden.
- Wer den Datenverkehr überprüft, sollte nach LDAP- und RMI-Protokollen suchen und diese filtern.
Ich denke, wir werden in den nächsten Tagen noch über Vorfälle aus dem Bereich eines Angriffs über die log4j-Schwachstelle lesen. CERT Telekom berichtet hier über Angriffsversuche, die man in den eigenen Honeypots beobachtet.
Apache patcht und Gegenmittel
Neben Microsoft, die einen Patch für Minecraft bereitgestellt haben, gibt es von Apache den Patch Log4j 2.15.0 um die Schwachstelle zu schließen. Und es gibt seit dem 10.12.2021 noch ein universelles Gegenmittel der Sicherheitsfirma Cybereason, wie ich bei den Kollegen von Bleeping Computer lese.
Ein auf GitHub bereitgestelltes Script Logout4Shell ermöglicht eine Einstellung in einer anfälligen Log4Shell-Instanz remote zu deaktivieren. Logout4Shell führt den Benutzer durch die Einrichtung eines Java-basierten LDAP-Servers und enthält eine Java-Payload, die die 'trustURLCodebase'-Einstellung in einem Remote Log4j-Server deaktiviert. Dies ermöglicht die Schwachstelle CVE-2021-44228 zu entschärfen.
Während die beste Abschwächung gegen diese Schwachstelle darin besteht, log4j auf 2.15.0 und höher zu patchen, kann dieses Verhalten in Log4j-Versionen (>=2.10) durch das Setzen der Systemeigenschaft log4j2.formatMsgNoLookups auf true oder durch das Entfernen der JndiLookup-Klasse aus dem Klassenpfad abgeschwächt werden, heißt es auf der GitHub-Seite.
Wenn der Server über eine Java-Runtime Version >= 8u121 verfügt, sind außerdem die Einstellungen com.sun.jndi.rmi.object.trustURLCodebase und com.sun.jndi.cosnaming.object.trustURLCodebase standardmäßig auf "false" gesetzt, wodurch das Risiko einer Ausnutzung gemindert wird. Weitere Details sind der GitHub-Beschreibung zu entnehmen.
Ergänzung: Ich wurde gefragt, ob auch Ports wie log4net etc. betroffen sind. Laut dieser Einschätzung eher nicht.
Anzeige
Hm. Das ist übel.
Von dem Zeug steckt einiges in Systemen, die z.B. im öffentlichen Bereich recht verbreitet sind und die Updatefrequenzen von alle paar Monate haben.
Und du kriegst "von oben" nie eine Freigabe, da selbst reinzupatchen oder die Läden massiv unter Druck zu setzen.
Geht also der Dauerstreit zu dem Thema weiter und man mitigiert mit hohem Aufwand vor sich hin…
Fast wünscht man sich ja, dass es da mal richtig kracht, damit endlich ein Umdenken machbar ist und die Hersteller von Fachsystemen aufhören müssen, sich die kostenlosen Dienste für ihre Systeme zusammenzuklicken und die dann ungepatcht wegaltern zu lassen.
Da kommen jetzt fast minütlich Meldungen:
https://www.huntress.com/blog/rapid-response-critical-rce-vulnerability-is-affecting-java
John Hammond ist einer der aktivesten CTF-Player auf youtube.
Böse: https://twitter.com/i/status/1469343827228086278
0.
Einen Proof of Concept gibt es bereits seit 13.März:
github[.]com/nice0e3/log4j_POC
1.
vmware vCenter 7.0.3 ist auch betroffen.
twitter[.]com/tnpitsecurity/status/1469429810216771589
2.
Cryptominer laufen bereits auf gekaperten Servern
Screenshot der base64 Codierung
twitter[.]com/GossiTheDog/status/1469322120840708100
3.
Test einer App oder eines Servers:
3a)
go to canarytokens[.]org/generate#
choose the Log4shell token
enter email and any number
generate token
copy token
3b)
Use that token in search forms, profile data, settings etc. of your apps
3c)
Get notified via email when you triggered a reaction
4.
Im Prinzip kann sich log4j in jedem beliebigen jar befinden.
Man müsste in Windows also alle jars zB mit jd-gui dekompilieren und nach log4j durchsuchen.
5.
in Linux kann man die installierten rpm-Pakete durchsuchen:
– rpm2cpio ThatRpmYouInstalled2Yearsago.rpm | cpio -idvm && find . -type f -name *log4j*
6.
Github-Projekt, um getarnte (Obfuscated oder base64-codierte) Befehle in den Logs zu enttarnen:
gist[.]github[.]com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
"ldap" muss gar nicht im Klartext in der Befehlszeile vorkommen, sondern kann auch umschrieben werden und der Parser erkennt dann trotzdem, was der Hacker meinte. Beispiel für getarnten Code:
${jndi:${lower:l}${lower:d}a${lower:p}://loc${upper:a}lhost:1389/rce}
Solche Tarncodes können auch in Archiven (.gz) stecken.
Das wird noch spaßig werden, weil log4j weit verbreitet ist, man die Lücke leicht ausnutzen kann und weil man den Befehl nicht unbedingt so leicht erkennen kann, wenn der Hacker ihn getarnt hat, denn der log-Parser ist hoch entwickelt und kann die verschleierten Befehle trotzdem verstehen.
@Bolko
"Einen Proof of Concept gibt es bereits seit 13.März:
github[.]com/nice0e3/log4j_POC"
Da geht es um CVE-2019-17571 und nicht um CVE-2021-44228.
"Die Schwachstelle CVE-2021-44228 wird laut heise als kritisch bewertet und hat den CVE-Index 10 (von 10 möglichen Punkten) erhalten."
CVE ist der "Index" bekannter Schwachstellen, die Bewertung des Risikos erfolgt mittels CVSS-"Index". Das eine hat mit dem anderen nichts zu tun.
Ich würde dem Ding eher 11 von 10 Punkten geben.
Hier gibt es eine Liste von IP-Adressen, von denen Angriffe gesteuert werden, könnten natürlich auch gute Sicherheitsforscher sein, wird ständig aktualisiert…
https://gist.github.com/blotus/f87ed46718bfdc634c9081110d243166