LOG4J - Hinweise
Bereich wird aktualisiert und ergänzt, wenn neue Informationen vorliegen.
Schritt für Schritt-Anleitung zur Prüfung und Sicherung Ihres Systems
-
Allgemeine Prüfung des Systems
Wir schlagen folgendes Tool vor, um Ihr System auf die Schwachstelle CVE-2021-44228 zu prüfen: Das Open Source Projekt log4j-detector. (Dieses Tool identifiziert LOG4J Bibliotheken auch in JAR Archiven, wo diese typischerweise verpackt sind.)
Die Ausführungszeit kann mehrere Stunden betragen.
Laden Sie die Datei direkt aus dem GIT Hub Projekt herunterladen, um sicher zu stellen, dass sie die neueste Version des kleinen Tools nutzen. Hierfür gehen Sie auf das
und wählen die aktuelle jar Version des Detectors aus.Im Anschluss laden Sie die jar Datei auf den Computer herunter.
Nun haben Sie das Werkzeug und müssen dieses nur noch verwenden. Dafür öffnen Sie ein Konsolenfenster (als Admin) und führen folgenden Befehlt aus:
java -jar [PFAD zur lof4j Detector Datei] --verbose [Ziel welches Sie durchsuchen wollen] > [Pfadangabe und Name der Logdatei die erstellt werden soll]
Beispielausführung:
Die log4j jar Datei liegt direkt auf Laufwerk C:\ und es soll die Festplatte D:\ durchsucht werden. Das Logfile welches die Funde der Schwachstelle dokumentiert soll in den Windows temp Ordner geschrieben werden.
java -jar C:\log4j-detector-2021.12.13.jar --verbose D:\ > C:\temp\log4jHITS.txt
-
Betroffene Versionen
Die Log4J Versionen 1.x sind von der aktuellen Schwachstelle nach aktueller Kenntnis nicht betroffen.
Anfällige Versionen sind Log4J 2.x (2.0-beta9 bis 2.15).
Die Version 2.16 gilt als gefixt. -
Maßnahmen für Siemens/BCT
Inzwischen hat sich ein Tool - auch empfohlen durch Siemens - bewährt, die Maßnahmen automatisiert durchführen zu lassen. Dieses Tool heißt logpresso und ist unter folgendem Link verfügbar.
Folgender Ablauf hat sich in der Anwendung durch unsere Consultants bewährt.:
- Abscannen des Systems auf betroffene log4j Vorkommnisse:
log4j-scan.exe --all-drives --report-csv - Abscannen des Systems auf betroffene log4j Vorkommnisse in zip-Dateien:
log4j-scan.exe --all-drives --report-csv --scan-zip - Stoppen der Dienste und Applikationen - Downtime
- Durchführung der Maßnahmen die nach aktuellem Stand durchgeführt werden. Nähere Informationen dazu können im GitHub Projekt von logpresso selbst eingesehen werden:
log4j-scan.exe --all-drives -fix - Neustart des Systems und Start der Dienste/Applikationen
- Erneuter Scan wie in Punkt 1 ergänzt durch den Scan wie in Punkt 2 oben beschrieben mit laufenden Diensten.
- Evaluierung der Ergebnisse des abschließenden Scans und gegebenenfalls die manuelle Anpassung vornehmen wie weiter unten beschrieben.
Anmerkungen
Die Konsole unbedingt als Administrator starten.
Dort wo die logpresso.exe ausgeführt wird, wird ein Backup-Verzeichnis zum Herstellen des Ausgangszustandes erzeugt. Bitte stellen Sie sicher, dass ausreichend Speicherplatz vorhanden ist (20 GB).
Zu Punkt 1 und Punkt 2: dies kann auch in einem Befehl durchgeführt werden. Der Scan der *.zip Dateien ist allerdings zeitintensiver weshalb wir diesen separat aufgeführt haben. Zip-Dateien sollten ebenfalls mit den bekannten Maßnahmen angepasst werden. Durch Teamcenter Deploys oder spätere Installation/Ausführung könnte die Schwachstelle so wieder im System verteilt werden.
Zu Punkt 4: Während wir einen Scan des gesamten Systems empfehlen um sich einen Überblick zu verschaffen, empfehlen wir bei der Durchführung der Maßnahmen nur BCT und Siemens Produkte zu berücksichtigen. Für andere betroffene Software bitten wir Sie die entsprechenden Software Hersteller zu kontaktieren und sich über die jeweiligen Maßnahmen in Kenntnis setzen zu lassen. Das Argument -all-drives ist deshalb anzupassen entsprechend der Übersicht die Sie durch die vorherigen Scans erhalten.
Anleitung zur manuellen Anpassung, falls diese notwendig ist
JndiLookup aus dem betroffenen Klassenpfad löschen. BCT schlägt folgendes Vorgehen vor:Nachdem die das obige Tool die betroffenen log4j-core-*.jar Dateien identifiziert hat, könnte eine Zeile aus dem log wie folgt aussehen:
C:\EXAMPLE\BEISPIELservice.jar!/BOOT-INF/lib/log4j-core-2.7.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-(Öffnen Sie nun die .jar Datei an dem in dem Log angegebenen Pfad z.B. mit 7zip. Hier im Beispiel ist der Pfad zur gefundenen Datei C:\EXAMPLE\BEISPIELservice.jar!/BOOT-INF/lib/log4j-core-2.7.jar
Da hier jars in jars gepackt sind, muss nun mit Hilfe des 7zip zu der JndiLookup.class navigiert werden um diese aus dem Archiv heraus zu löschen.
Den Ablageort dieser JndiLookup.class finden Sie immer über den Substring \org\apache\logging\log4j\core\lookup\Daraus ergibt sich der Ablageort im vorliegenden Beispiel:
C:\EXAMPLE\BEISPIELservice.jar\BOOT-INF\lib\log4j-core-2.7.jar\org\apache\logging\log4j\core\lookup\
Nun löschen (oder umbenennen) Sie die JndiLookup.class und aktualisieren das Archiv im Anschluss, was durch ein Pop-up Fenster bestätigt wird (wenn das Fenster geschlossen wird).
Es sollte im Anschluss an die ausgeführten Maßnahmen unbedingt ein weiterer Scan erfolgen.
- Abscannen des Systems auf betroffene log4j Vorkommnisse:
-
Mögliche Folgeprobleme der Maßnahmen
Problembeschreibung:
Ausführbare jar Dateien mit eingebettetem log4j-core-2.x.jar werden unbrauchbar, wenn sie wie beschrieben (in den Maßnahmen) ausgeschnitten werden. 7-zip komprimiert die Dateien beim Schreiben, eingebettete (nested) jar Dateien dürfen aber nicht komprimiert sein.
Dies ist beispielsweise bei der bct-checkitdesigner.jar der Fall ist, wird nach umgesetzter Maßnahme die betroffene jar Datei nicht mehr ausgeführt kommt es zu folgenden Fehlermeldungen:
java -jar "bct-checkitdesigner-service_1.jar"
Exception in thread "main" java.lang.IllegalStateException: Failed to get nested archive for entry BOOT-INF/lib/log4j-core-2.7.jar
at org.springframework.boot.loader.archive.JarFileArchive.getNestedArchive(JarFileArchive.java:108)
at org.springframework.boot.loader.archive.JarFileArchive.getNestedArchives(JarFileArchive.java:86)
at org.springframework.boot.loader.ExecutableArchiveLauncher.getClassPathArchives(ExecutableArchiveLauncher.java:70)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:49)
at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:51)
Caused by: java.io.IOException: Unable to open nested jar file 'BOOT-INF/lib/log4j-core-2.7.jar'
at org.springframework.boot.loader.jar.JarFile.getNestedJarFile(JarFile.java:256)
at org.springframework.boot.loader.jar.JarFile.getNestedJarFile(JarFile.java:241)
at org.springframework.boot.loader.archive.JarFileArchive.getNestedArchive(JarFileArchive.java:103)
... 4 more
Caused by: java.lang.IllegalStateException: Unable to open nested entry 'BOOT-INF/lib/log4j-core-2.7.jar'. It has been compressed and nested jar files must be stored without compression. Please check the mechanism used to create your executable jar file
at org.springframework.boot.loader.jar.JarFile.createJarFileFromFileEntry(JarFile.java:284)
at org.springframework.boot.loader.jar.JarFile.createJarFileFromEntry(JarFile.java:264)
at org.springframework.boot.loader.jar.JarFile.getNestedJarFile(JarFile.java:252)
Behebung des Problems:Das Jar-Tool aus dem JDK hat dazu den Schalter „0“ um ohne zu komprimieren zu speichern. Dies ergibt folgende Empfehlung als Reparatur, sollte das Problem auftauchen:
- JndiLookup.class mit 7-Zip-FileManager suchen und im jar löschen, Änderung schreiben
- Mit dem Command-Line Jar-Tool aus dem JDK das log4j-core-jar extrahieren
%JDK_HOME%\bin\jar -xvf bct-checkitdesigner-service.jar <Pfad-zum-log4jcore.jar> - Importieren ohne zu komprimieren
%JDK_HOME%\bin\jar -u0vf bct-checkitdesigner-service.jar <Pfad-zum-log4jcore.jar> - Mit rmdir /S /Q exportiertes Verzeichnis löschen.
Die beschriebene Reparatur können Sie direkt bei eingebetteten log4j-core-2.x.jar anwenden. Wenn Sie die Maßnahmen bereits ausgeführt haben und bemerken, dass beschriebene Fehler auftauchen dann steigen Sie entsprechend bei Punkt 2 in den Reparatur Maßnahmen ein um das Problem zu beheben.
Wenn Sie hierzu Rückfragen haben, melden Sie sich gerne bei uns im Support.
-
BCT Software / Siemens Software
BCT Software
Bezüglich dieser Schwachstelle als sicher gelten alle BCT Produkte ab Version v21R3.
In den vorherigen Versionen sind von der Schwachstelle betroffen:- BCT CheckIt Designer Microservice
- Microservices für BCT Active Workspace AddOns
Die Schwachstelle kann nur ausgenutzt werden, wenn die entsprechenden Microservices laufen, d.h. entweder manuell gestartet, in einem Applikationsserver deployt, oder als eigener Service installiert wurden.
Grundsätzlich empfehlen wir Ihnen ein Upgrade oder Patch auf die aktuellste Version der BCT Software. Ab Version v21R3 wird die von der Schwachstelle betroffene jar Bibliothek nicht mehr verwendet. Eventuell noch installierte Microservices aus alten Versionen sollten entfernt werden.
Falls Sie eines der betroffenen Module (in einer Version <21R3) im Einsatz haben und nicht auf eine aktuelle Version upgraden oder patchen können, führen Sie bitte die Maßnahmen unter untenstehendem Punkt 3 durch. Wenn Sie Hilfe benötigen, wenden Sie sich an den Support.
Sofortmaßnahmen die wir für alle Kunden empfehlen:- Scannen Sie Ihre Umgebung mit einem log4j Detector.
- Qualifizieren Sie die Ergebnisse.
Sind die Funde (in dem generierten Logfile) produktiv im Einsatz? Installer, Verzeichnisse aus vorherigen Installationen können entfernt werden. Sind Microservices betroffen muss geprüft werden, ob diese tatsächlich in Verwendung sind. Trifft dies nicht zu entfernen Sie bitte die Microservices. - Wenden Sie die beschriebenen „Maßnahmen für Siemens/BCT“ an, sofern Sie kein direktes Upgrade/ Patch einspielen können.
- Führen Sie einen erneuten Scan durch.
Hinweis: Es gibt BCT Software, die log4j 1.x verwendet. Diese Version ist nicht von Schwachstelle CVE-2021-44228 betroffen.Siemens Software
Siemens hat für seine Produkte eine Dokumentation herausgegeben die ständig aktualisiert wird. Darin sind betroffene Siemens Applikationen aufgelistet, sowie die erforderlichen Maßnahmen die zu ergreifen sind.
FAQs
-
Welche Systeme sind im Allgemeinen besonders gefährdet?
Als besonders gefährdet gelten Applikationsserver die Zugriffe von außerhalb des Firmennetzwerkes zulassen/nutzen. Auch Server und Clients die IoT Anwendungen nutzen, gelten als besonders gefährdet. Diese Systeme sollten priorisiert mit den empfohlenen Schritten behandelt werden.
-
Kann ich den Detektor Scan im laufenden Betrieb ausführen?
Wir haben hierzu einen Test durchgeführt und identische Ergebnisse in den Funden bei laufendem Betrieb und gestoppten Services erhalten. Eine Downtime ist für die Scans nicht notwendig.
-
Kann ich die JndiLookup.class bedenkenlos löschen?
Diese Frage kann nicht allgemeingültig beantwortet werden und muss mit jeweiligen Software-Herstellern geklärt werden.
Bei BCT Software Produkten wird die Klasse nicht genutzt. Sie kann wie in der Anleitung beschrieben entfernt werden. Bei Siemens prüfen Sie bitte vorab die betroffene Software unter folgendem Link.
-
Ich kann die JndiLookup.class nicht löschen, was muss ich tun?
Wenn Sie die Klasse nicht löschen können, liegt das sehr wahrscheinlich daran, dass das entsprechende jar Archiv in Verwendung/Zugriff ist. Planen Sie deshalb eine Downtime ein, für das hiervon betroffene jar Archive.
-
Gibt es ein Update für NX12 bzgl. der Schwachstelle?
NX12 ist schon seit einiger Zeit aus der Wartung. Hierfür wird es keine Updates geben. Siemens arbeitet daran, entsprechende Updates und Patches zu veröffentlichen für Produkte die aktuell unter Wartung stehen.
-
Ist BCT Inspector im Opcenter betroffen?
Der BCT Inspector im Opcenter ist nicht betroffen.
Nutzen Sie aber Teamcenter Quality im Active Workspace, dann sind die Microservices betroffen bis einschließlich BCT Version v21R2.
Das Opcenter selbst kann aber betroffen sein. Siemens gibt hier Workarounds und Anleitungen und der folgendem Link.
BCT Support Center
Sie erreichen uns Montag-Freitag, 08:00 - 12:00 Uhr und 13:00 - 17:00 Uhr
Deutschland: +49 7852 996-222, Schweiz: +41 41 562 96 77 oder support@bct-technology.com