Hier eine andere Möglichkeit zur Prüfung.

Hinweis: Diese Methode soll als schneller Check auf Log4j dienen, eignet sich aber nicht für embedded Log4j.

Lösung

In Windows die Eingabeaufforderung oder auf Linux ein Terminal öffnen und den entsprechenden Befehl einfügen.

Hinweis: Der Laufwerkbuchstabe kann angepasst werden.

dir c:\*log4j*.jar /s

find / -iname "*log4j*.jar"

Sollte der Befehl Log4j Dateien finden, kann über deren Dateinamen die Bibliothekversion abgeleitet werden.

Im unteren Beispiel wäre log4j-1.2.12.jar die Version 1.2.12 und damit nicht von der Sicherheitslücke CVE-2021-44228.

Hinweis: Um ganz sicher zu gehen, sollte die Version im Manifest der Datei geprüft werden.

Der Beitrag Windows und Linux Systeme auf Log4j Bibliothek überprüfen erschien zuerst auf Daniel Gutermuth.

Hier geht es nun um die Log4j Erkennung und Benachrichtigung bei allgemeinen Anwendungen im Falle eines Treffers. Als Beispiel wird eine Methode erläutert, welche einfach realisierbar ist.

Eine weitere Möglichkeit findet sich hier.

Hinweis: Alles auf eigene Gefahr!

Lösung

Zuerst auf die Seite von Canary Tokens gehen und ein entsprechendes (kostenloses) Token für Log4Shell generieren. Hierzu wird eine E-Mail-Adresse benötigt, da an diese eine Nachricht versendet wird, falls das Token getriggert wurde.

Nachdem das Token generiert wurde, erhält man ein Snippet. Dieses kann nun für Tests auf Systemen verwendet werden.

Sobald dieser Code von einer anfälligen Log4J Bibliothek verarbeitet wurde, sendet Canary eine E-Mail an die im Token hinterlegte E-Mail-Adresse mit Angabe des entsprechenden Hostnamens. Auch wenn im Snippet ein Eintrag mit ldap zu finden ist, so wird die Erkennung mit hoher Wahrscheinlichkeit durch DNS realisiert.

Hinweis: Es können mehrere Tokens erstellt werden. Besonders bei vielen Systemen erhält man dadurch eine bessere Übersicht, falls der Hostname nicht korrekt ausgegeben wurde.

Ein einfacher Weg potentiell anfällige Webanwendungen zu testen, ist die Verwendung eines Internet Browsers und eines benutzerdefinierten User-Agents.

Dazu im Browser (in diesem Beispiel Google Chrome) auf einer beliebigen Internetseite einen Rechtsklick machen und Untersuchen wählen.

Im öffnenden Teilfenster oben rechts auf den Doppelpunkt klicken und über Weitere Tools den Punkt Netzwerkbedingungen auswählen.

Im Reiter Netzwerkbedingungen nun zum Punkt User-Agent navigieren und den Haken bei Browserstandard verwenden entfernen. Im Dropdownmenü Benutzerdefiniert wählen und in das Textfeld das vorher erstellte Snippet einfügen.

Navigiert man nun über den Internet-Browser auf eine Webanwendung mit anfälliger Log4j Bibliothek und diese verarbeitet das Snippet, erhält man eine E-Mail von Canary mit Angaben zum betreffenden System.

Zur Wiederherstellung des standardmäßigen User-Agents, einfach die benutzerdefinierte Zeile löschen und den Haken bei Browserstandard verwenden wieder setzen.

Es sei nochmals erwähnt , dass das generierte Snippet nicht ausschließlich mit dem Browser verwendet werden muss. Dieses Beispiel ist eines von vielen Möglichkeiten.

Der Beitrag Log4j / Log4Shell – Erkennung und Benachrichtigung bei Schwachstellen in Anwendungen erschien zuerst auf Daniel Gutermuth.

Das BSI stuft diese Lücke auf der CVSS-Skala mit dem höchstmöglichen Wert 10 (CVE-2021-44228) ein.

Bis es zu flächendeckenden Patches durch die Hersteller kommt, existieren bereits erste Workarounds für verschiedenste Produkte.

Auch das vCenter von VMware ist von dieser Sicherheitslücke betroffen – ESXI nicht!

In diesem Beitrage möchte ich den VMware vCenter Workaround erläutern.

Hinweis: Alles auf eigene Gefahr!

Lösung

Gültig für:

• vCenter 7.0 GA, 7.0.0a, 7.0.0b, 7.0.0c, 7.0.0d
• vCenter 7.0 Update 1, U1a, U1c, U1d
• vCenter 7.0 Update 3, 3a
• vCenter 7.0 Update 2, 2a, 2b, 2c, 2d

Lösungen für vCenter 6.7, 6.5 und 6.0 sind im verlinkten VMware KB-Artikel beschrieben. Das Vorgehen ist fast identisch.

Eine SSH-Verbindung mit dem vCenter (z. B. via Putty) aufbauen.

Eventuelle Zertifikatswarnungen bestätigen.

In der SSH-Sitzung als Root anmelden und mit dem Befehl Shell den Shell-Zugriff aktivieren.

vMON-Dienst

Die bestehende Java-wrapper-vmon Datei sichern.

cp -rfp /usr/lib/vmware-vmon/java-wrapper-vmon /usr/lib/vmware-vmon/java-wrapper-vmon.bak

Anschließend diese im VI-Editor öffnen und mit a in den Bearbeitungsmodus wechseln.

vi /usr/lib/vmware-vmon/java-wrapper-vmon

Dort die letzte Zeile löschen…

exec $java_start_bin $jvm_dynargs $security_dynargs $original_args

..und folgende zwei Zeilen einfügen:

log4j_arg="-Dlog4j2.formatMsgNoLookups=true"
exec $java_start_bin $jvm_dynargs $log4j_arg $security_dynargs $original_args

Hinweis: Die zwei oberen Zeilen beziehen sich auf :

• vCenter 7.0 Update 3, 3a
• vCenter 7.0 Update 2, 2a, 2b, 2c, 2d

Für die unteren vCenter-Versionen gilt:

• vCenter 7.0 GA, 7.0.0a, 7.0.0b, 7.0.0c, 7.0.0d
• vCenter 7.0 Update 1, U1a, U1c, U1d

//Löschen
exec $java_start_bin $jvm_dynargs "$@"

//Einfügen
log4j_arg="-Dlog4j2.formatMsgNoLookups=true"
exec $java_start_bin $jvm_dynargs $log4j_arg "$@"

Mit ESC den Bearbeitungsmodus verlassen und mit :wq das Dokument speichern und den Editor verlassen.

Die Berechtigungen der Datei anpassen.

chown root:cis /usr/lib/vmware-vmon/java-wrapper-vmon
chmod 754 /usr/lib/vmware-vmon/java-wrapper-vmon

Alle vCenter Dienste neu starten.

service-control --stop --all
service-control --start --all

Update Manager Dienst

Die bestehende start.ini sichern.

cp -rfp /usr/lib/vmware-updatemgr/bin/jetty/start.ini /usr/lib/vmware-updatemgr/bin/jetty/start.ini.bak

Wieder die Datei im VI-Editor öffnen und mit a in den Bearbeitungsmodus wechseln.

vi /usr/lib/vmware-updatemgr/bin/jetty/start.ini

Dort anschließend folgende Zeile am Ende des Dokuments einfügen, den Bearbeitungsmodus beenden und speichern.

-Dlog4j2.formatMsgNoLookups=true

Neustart des Update Manager Dienstes.

service-control --restart vmware-updatemgr

Analytics Dienst

Sichern der bestehenden log4j-core-2.8.2.jar Datei.

log4j-core-2.8.2.jarcp -rfp /usr/lib/vmware/common-jars/log4j-core-2.8.2.jar /usr/lib/vmware/common-jars/log4j-core-2.8.2.jar.bak

Die Klasse deaktivieren.

zip -q -d /usr/lib/vmware/common-jars/log4j-core-2.8.2.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Den Analytics Dienst neu starten.

service-control --restart vmware-analytics

DBCC Dienstprogramm

Die bestehende log4j-core-2.8.2.jar Datei sichern.

cp /usr/lib/vmware-dbcc/lib/log4j-core-2.8.2.jar /usr/lib/vmware-dbcc/lib/log4j-core-2.8.2.jar.bak

Anschließend ebenfalls deaktivieren.

zip -q -d /usr/lib/vmware-dbcc/lib/log4j-core-2.8.2.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Hinweis: Falls die Meldung „zip error: Nothing to do!“ erscheint, war dieser Schritt nicht notwendig, da DBCC nicht verwendet wird.

Schritte verifizieren

vMON Dienst:

Der Eintrag -Dlog4j2.formatMsgNoLookups=true muss in der Ausgabe des folgenden Befehls erscheinen.

ps auxww | grep formatMsgNoLookups

Update Manager Dienst:

Nach Eingabe des unteren Befehls, muss unter Properities der Eintrag log4j2.formatMsgNoLookups = true vorhanden sein.

cd /usr/lib/vmware-updatemgr/bin/jetty/
java -jar start.jar --list-config

Analytics Dienst und DBCC Dienstprogramm:

Die Ausgabe beider Befehle muss 0 ergeben.

grep -i jndilookup /usr/lib/vmware/common-jars/log4j-core-2.8.2.jar | wc -l
grep -i jndilookup /usr/lib/vmware-dbcc/lib/log4j-core-2.8.2.jar | wc -l

Zum Abschluss der Arbeiten kann die Shell-Sitzung mit exit beendet und die SSH-Verbindung geschlossen werden.

Damit ist das vCenter, bis zum Erscheinen von Patches, gegen die Log4j Sicherheitslücke gerüstet.

Der Beitrag VMware – Log4j Sicherheitslücke im vCenter mit Workaround schließen erschien zuerst auf Daniel Gutermuth.