Einführung

Meldet derzeit log4j-core-Versionen 2.3.2, 2.12.4 und 2.17.1 als _SAFE_, 2.3.1, 2.12.2, 2.12.3, 2.15.0, 2.16.0 und 2.17.0 als _OKAY_ und alle anderen Versionen als _VULNERABLE_ (obwohl es Versionen vor 2.0-beta9 als _POTENTIALLY_SAFE_ meldet). Es meldet ältere log4j-1.x-Versionen als _OLD_.

Kann log4j in ausführbaren Spring-Boot-Jars/Wars, Abhängigkeiten, die in Uber-Jars vermischt sind, Shaded-Jars und sogar entpackte Jar-Dateien, die einfach unkomprimiert auf dem Dateisystem liegen (auch *.class), korrekt erkennen.

Wir pflegen derzeit eine Sammlung von log4j-Samples, die wir zum Testen verwenden.

Beispielverwendung:

Die Ergebnisse verstehen

_VULNERABLE_ -> Sie müssen diese Datei aktualisieren oder entfernen.

_OKAY_ -> Wir melden dies für Log4J-Versionen 2.3.1, 2.12.2, 2.12.3, 2.15.0, 2.16.0 und 2.17.0. Wir empfehlen ein Upgrade auf 2.17.1.

_SAFE_ -> Wir melden dies derzeit nur für Log4J-Versionen 2.3.2, 2.12.4 und 2.17.1 (und höher).

_OLD_ -> Sie sind vor CVE-2021-44228 sicher, sollten aber ein Upgrade planen, da Log4J 1.2.x seit 7 Jahren EOL ist und mehrere bekannte Schwachstellen aufweist.

_POTENTIALLY_SAFE_ -> Die Datei "JndiLookup.class" ist nicht vorhanden, entweder weil Ihre Log4J-Version sehr alt ist (vor 2.0-beta9) oder weil jemand diese Datei bereits entfernt hat. Stellen Sie sicher, dass es sich um jemanden aus Ihrem Team oder Unternehmen handelte, der "JndiLookup.class" entfernt hat, wenn dies der Fall ist, da Angreifer dafür bekannt sind, diese Datei selbst zu entfernen, um zu verhindern, dass zusätzliche konkurrierende Angreifer Zugriff auf kompromittierte Systeme erhalten.

Verwendung

Aus dem Quellcode erstellen:

Testen:

Wir pflegen eine Sammlung von log4j-Beispielen hier: https://github.com/mergebase/log4j-samples

Lizenz

GPL Version 3.0

Häufig gestellte Fragen

Wie funktioniert es?

Der Java-Compiler speichert String-Literale direkt in den kompilierten *.class-Dateien. Wenn log4j-detector eine Datei namens "JndiManager.class" auf Ihrem Dateisystem erkennt, untersucht es diese Datei auf den String: "Invalid JNDI URI - {}". Es stellt sich heraus, dass dieses spezifische String-Literal nur in der gepatchten Version von Log4J (Version 2.15.0) vorhanden ist. Alle Versionen von Log4J ohne diesen String sind verwundbar.

Diese gleiche Technik der Untersuchung von *.class-Dateien auf String-Literale wird weiter erweitert, um sichere Versionen 2.3.2, 2.12.4 und 2.17.1 genau zu erkennen.

Dieser Scanner meldet nur Treffer gegen die log4j-core-Bibliothek. Was ist mit log4j-api?

Viele Scanner (einschließlich GitHub's eigenem Dependabot) melden derzeit sowohl "log4j-core"- als auch "log4j-api"-Bibliotheken als verwundbar. Diese Scanner sind falsch. Derzeit gibt es keine existierende Version der "log4j-api"-Bibliothek, die durch eine dieser Schwachstellen ausgenutzt werden kann.

Bei MergeBase sind wir stolz auf unsere Scan-Genauigkeit. Sie sind bereits beschäftigt genug mit dem Patchen und Verteidigen Ihrer Systeme. Wir möchten nicht, dass Sie Ihre Zeit mit falschen Positiven verschwenden. Deshalb melden wir keine Treffer gegen log4j-api.

Warum wird über 2.3.1, 2.10.0, 2.12.2, 2.12.3, 2.15.0, 2.16.0 und 2.17.0 berichtet?

Version 2.10.0 ist wichtig, da dies die erste Version ist, in der die verwundbare "Nachrichtensuche-Funktion" von Log4J über die Log4J-Konfiguration deaktiviert werden kann.

Version 2.12.2 ist wichtig, da es sich um eine Java-7-kompatible Version von Log4J handelt, die nicht anfällig für CVE-2021-44228 ist.

Die Versionen 2.15.0 und 2.16.0 sind wichtig, da dies die ersten Versionen sind, in denen die Standard-Out-of-the-Box-Konfiguration von Log4J nicht anfällig für CVE-2021-44228 ist.

Und die Versionen 2.3.2, 2.12.4 und 2.17.1 sind wichtig, da sie nicht anfällig für kürzlich entdeckte CVEs wie CVE-2021-45046 und CVE-2021-45105 sind. Obwohl dies viel weniger schwerwiegende Schwachstellen sind, gehen wir davon aus, dass jeder auf eine der Versionen 2.3.2, 2.12.4 oder 2.17.1 patchen möchte.

Was bedeuten diese Ergebnisse "file1.war!/path/to/file2.zip!/path/to/file3.jar!/path/to/log4j.jar"?

Das "!" bedeutet, dass der log4j-detector ein Zip-Archiv betreten hat (z. B. *.zip, *.ear, *.war, *.aar, *.jar). Da Zip-Dateien Zip-Dateien enthalten können, kann ein einzelnes Ergebnis mehr als einen "!"-Indikator enthalten.

Hinweis: Der log4j-detector betritt nur rekursiv Zip-Archive. Er betritt keine tar-, gz- oder bz2-Archive. Der Hauptgrund dafür ist, dass Java-Systeme oft so konfiguriert sind, dass sie Jars innerhalb von Jars ausführen, aber sie sind nie so konfiguriert, dass sie andere Dateiformate ausführen (soweit ich weiß!). Und daher ist eine log4j-Kopie in einer *.tar.gz-Datei wahrscheinlich für ein laufendes Java-System nicht erreichbar und daher keine meldungswürdige Schwachstelle.

2. Hinweis: Für Zips-in-Zips lädt unser Scanner das innere Zip vollständig in den Speicher (mittels ByteArrayInputStream), bevor er versucht, es zu scannen. Möglicherweise müssen Sie Java etwas mehr Speicher geben, wenn Sie extrem große innere Zips auf Ihrem System haben (z. B. 1 GB oder größer).

Was ist mit Log4J 1.2.x?

Nur Versionen von Log4J 2.x (von 2.0-beta9 bis 2.14.1) sind anfällig für CVE-2021-44228.

Wie kann ich sicher sein, dass dies kein Trojaner ist, der sich als Log4J-Detektor ausgibt?

Gute Frage! Da wir den vollständigen Quellcode hier auf Github (alle 2500 Zeilen Java) sowie die Schritte zur Erstellung enthalten, und da dieses Tool null Abhängigkeiten hat, sollte es nicht zu lange dauern, den Code zu Ihrer Zufriedenheit sorgfältig zu studieren. Wenn Sie Maven nicht vertrauen, können Sie direkt in das Verzeichnis "src/main/java/com/mergebase/log4j" gehen und "javac *.java" eingeben. Das funktioniert auch!

Wir signieren auch das vorkompilierte Jar, das wir im Stammverzeichnis des Repositorys aufbewahren (./log4j-detector-2021.12.29.jar), mit dem MergeBase-Codesignaturschlüssel. Bitte führen Sie "jarsigner -verbose -verify log4j-detector-2021.12.29.jar" aus, um dies zu bestätigen.

Worum geht es bei MergeBase?

MergeBase ist ein SCA-Unternehmen (Software Composition Analysis) mit Sitz in Vancouver, Kanada. Wir sind ähnlich wie Unternehmen wie Snyk, Sonatype, Blackduck usw., indem wir Unternehmen helfen, verwundbare Open-Source-Bibliotheken in ihrer Software zu erkennen und zu verwalten. Schauen Sie uns an! Wir haben eine großartige Genauigkeit, großartige Sprachunterstützung und sind auch nicht zu teuer: mergebase.com/pricing.

Wir würden uns freuen, wenn jemand eine 2-wöchige kostenlose Testversion unseres SCA-Produkts ausprobiert! Und wenn Sie unserem CEO ([email protected]) mit dem Betreff "log4j-detector" eine E-Mail senden, verlängern wir Ihre kostenlose Testversion auf 4 Wochen.