Wie viele von Ihnen sicherlich schon mitbekommen haben, ist in der vergangenen Woche eine neue Sicherheitslücke in dem Java API von Apache Log4j bekannt geworden.
Auf dieser Seite informieren wir Sie über den aktuellen Status zu dieser Lücke und ob und wenn ja, wie sie unsere Kunden betrifft.
UPDATE 15.12.2021:
Wie nun bekannt wurde, schützt auch der Patch in Version 2.15 nicht vollständig gegen mögliche Angriffe. Erst Version 2.16 soll nun komplett sicher sein.
https://www.cve.org/CVERecord?id=CVE-2021-45046
An dieser Stelle Danke an Manuel für den Hinweis!
UPDATE:
Einige unserer Kunden haben berichtet, dass ihre Firewalls bereits zahlreiche Angriffe auf diese Lücke gemeldet haben.
Das BSI und andere Organisationen haben festgestellt, dass zahlreiche Bot Netze die Schwachstelle bereits ausnutzen. D.h. schnelles handeln ist gefragt (s. unten).
UPDATE:
Hier finden Sie ein White Papier des Bundesamt für Sicherheit in der Informationstechnik (BSI), welches ebenfalls permanent aktualisiert wird. Dort finden sich auch weitere Hinweise
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.pdf?__blob=publicationFile&v=8
IceBreak
Zunächst die sehr gute Nachricht:
Alle IceBreak Kunden können durchatmen. Da IceBreak ein natives ILE Produkt ist, welches native auf dem Betriebssystem IBM i läuft, ist es nicht von irgendwelchen Java Sicherheitslücken betroffen.
IceCap
Unser browser basierter JavaScript 5250 Emulator IceCap ist ebenfalls nicht betroffen.
Anders, als die IBM Produkte oder freie Open Source Alternativen (s.u.).
BSI warnt
Für alle, die meinen, es wäre nicht so schlimm, hier ein Link zum Bundesamt für Sicherheit in der Informationstechnik, welche die kritische Lage unterstreicht:
https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2021/211211_log4Shell_WarnstufeRot.html
Wer und was ist betroffen?
Betroffen sind alle Java Anwendungen, die die Apache Log4j Komponente/API nutzen. Dabei spielt es keine Rolle, ob diese Anwendung aus dem Internet zugänglich ist oder intern im Firmennetzwerk läuft. Auch dort kann die Schwachstelle ausgenutzt werden!
Desktop Anwendungen gelten als weniger kritisch. Ausgeschlossen werden kann eine Ausnutzung der Schwachstelle jedoch auch hier nicht.
Hier eine Liste von Produkten, die ggf. betroffen sind:
- IBM Integrated Web Service Server (IWS)
Dieser basiert auf dem IBM Websphere Application Server und soweit bekannt ist, ist dieser betroffen - IBM HTTP Server for i
Dieser basiert auf dem Apache Webserver, welcher betroffen ist - IBM RDi
Soweit uns bisher bekannt ist, ist auch die IBM Entwicklungsumgebung Rational Developer for i betroffen - IBM ACS
Das Java basierte IBM Tool nutzt noch die seit 2015 nicht mehr supportete Version 1.2.13 von log4j.
Lt. unseren Informationen ist auch diese Version betroffen, sofern man in der Konfiguration JNDI verwendet.
https://access.redhat.com/security/cve/CVE-2021-4104
Zusätzlich bestehen weitere Sicherheitslücken für die Versionen 1.2.x, welche nie gefixt wurden.
https://www.cvedetails.com/cve/CVE-2019-17571/
UPDATE:
IBM listet Log4j 1.2.13 beim ACS als genutzte Komponente auf.
Gleichzeitig konnten unsere Kollegen von System & Methode aus Dänemark mit div. Sicherheitsscannern Log4j nicht darin finden. Ob es also wirklich genutzt wird oder nicht ist noch nicht sicher. Ggf. ist die Information von IBM in der Komponentenauflistung nicht aktuell. - TN5250J
Auch diese Java basierte 5250 Emulation nutzt noch die Version 1.x von Log4j. D.h. es gelten die gleichen Risiken, wie beim IBM ACS. - Oracle SQL Developer
Leider ist auch diese Java Entwicklungsumgebung betroffen - Microsoft Azure
Es sind zahlreiche Microsoft Azure Dienste betroffen, wie z.B. Azure Active Directory und Azure App Services.
Microsoft informiert hier über den Stand und die Maßnahmen
https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/ - Liste auf GitHub
Auf GitHub finden Sie hier eine Liste mit betroffenen Programmen, welche permanent aktualisiert wird
https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592 - Sonstige Programme
Es sind unzählige Anwendungen und Dienste von diesem Problem betroffen. Wenn Sie bei sich prüfen möchten, welche dies genau sind, scheint dies nicht immer sehr einfach zu sein.
Eine Möglichkeit, auf der IBM i zumindest alle Verzeichnisse zu finden, die Log4j irgendwo beinhalten bietet dieses SQL Script von Scott Forstie
https://gist.github.com/forstie/9662d4c302f5224c66b7a4c409141a2c
Eine weitere Möglichkeit betroffene Programme auch auf anderen Plattformen zu finden stellen div. Sicherheitsscanner, wie z.B. Grype dar
https://github.com/anchore/grype
Daneben gibt es mittlerweile zahlreiche Scripts und Tools, welche ebenfalls nach Log4j in Verzeichnissen und Projekten suchen. Eines davon ist der log4j detector
https://github.com/mergebase/log4j-detector
Der log4j-detector funktioniert auch auf der IBM i. Im Gegensatz zum o.g. SQL Ansatz scannt er nicht nur Dateinamen, sonder jegliche Java Programme. Es kann sein, dass log4j in ein anderes Paket eingebunden wurde und somit gar nicht namentlich auftaucht. Der log4j-detector findet auch diese. Kopieren Sie die Jar Datei am besten in Ihr /home Verzeichnis ins IFS. Gehen Sie dann in die Shell Ihrer Wahl (CALL QP2TERM tut es auch) und rufen Sie es wie folgt auf:
java -jar log4j-detector-2021.12.13.jar / > treffer.txt
Auf dieser Seite finden Sie einen Überblick von IBM zu dem Problem:
https://www.ibm.com/blogs/psirt/an-update-on-the-apache-log4j-cve-2021-44228-vulnerability/
Lösungsansätze und Workarounds
Aktuell gibt es verschiedene Aussagen, wie man mit dem Problem umgehen kann.
Fakt ist, dass die Lücke wohl erst ab Version 2.16 (Update 15.12.2021) geschlossen ist. D.h. eine echte Lösung stellt rein das Update auf diese Version dar. Das muss aber jeder Hersteller der betroffenen Produkte tun. D.h. es stehen zahlreiche Updates an.
Die Aussage, dass man nicht betroffen ist, wenn man eine Version <2 nutzt ist lt. verschiedenen Quellen, u.a. des BSI, falsch. Lt. des o.g. RedHat Dokuments können auch ältere Versionen von Log4j betroffen sein.
Unabhängig von dieser Sicherheitslücke gibt es für Version 1.x jedoch andere Sicherheitslücken, die nicht weniger kritisch sind. Von daher sollten Sie unbedingt bei Ihrem Hersteller nachfragen, wann ein Update auf 2.16 oder höher erfolgt.
ACHTUNG:
Die folgenden Workarounds können dazu führen, dass Ihre Anwendung/en nicht mehr korrekt funktionieren, sofern Sie die Funktion Lookup verwenden!!!
Es gilt daher abzuwägen, was derzeit schlimmere Folgen für Ihr Unternehmen haben wird.
Diese Workarounds funktionieren nur mit Log4j ab Version 2.10 oder höher.
Jesse Gorzinski von IBM hat folgenden Vorschlag für IBM i Kunden getwittert, welcher die Nutzung der Schwachstelle verhindern soll:
ADDENVVAR ENVVAR(JAVA_TOOL_OPTIONS) VALUE(‘-Dlog4j2.formatMsgNoLookups=true’) REPLACE(*YES) LEVEL(*SYS)
Die gleiche Option kann man auch bei jeder Java Runtime als Parameter beim Start mit angeben.
Bis eine Lösung (Updates) in Sicht ist, sollte das schützen.
Diese Lösung geht auf allen Plattformen, die Java unterstützen.
Die Nutzung der Umgebungsvariable betrifft in dem Fall ALLE Java Anwendungen. Sollte eine Ihrer Anwendungen, die o.g. Lookup Funktion nutzen, wird sie nicht mehr (korrekt) funktionieren. Sofern diese Anwendung kritisch ist, sollten Sie die Umgebungsvariable nicht setzen und stattdessen alle anderen Anwendungen via Parameter aufrufen.
Microsoft empfiehlt dringend aktuelle Updates zu installieren. Gleichzeitig empfiehlt man auch dort die o.g. Umgebungsvariable zu setzen. Näheres findet sich hier:
https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/
Bei Versionen, die kleiner 2.10 sind aber größer als 2.0, kann mit dem Befehl:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
die betroffene Klasse JndiLookup entfernt werden. Die Auswirkungen auf die Anwendung bleiben die gleichen. Sollte diese Klasse benötigt werden, wird die Anwendung nicht mehr (korrekt) funktionieren.
Wir halten Sie weiterhin auf dieser Seite und ggf. per Email auf dem Laufenden, sobald uns neue Erkenntnisse vorliegen.
Alle Kunden, die den Newsletter abonniert haben, erhalten auch hierüber Infos.