LOG4J -KRITISCHE SICHERHEITSLÜCKE

zero day exploit

Am Freitagmorgen, 10.12.2021, wurde eine kritische Sicherheitslücke in einer beliebten und weit verbreiteten Java-Bibliothek namens «Log4j» bekannt.

GovCert.ch schreibt dazu:

"Log4j ist eine beliebte Java-Bibliothek, die von der Apache Foundation entwickelt und gepflegt wird. Die Bibliothek ist weit verbreitet und wird in vielen kommerziellen und Open-Source-Softwareprodukten als Logging-Framework für Java verwendet.

Die Sicherheitslücke (CVE-2021-44228 1) ist kritisch, da sie von einem nicht authentifizierten Angreifer ausgenutzt werden kann, um beliebigen Code auszuführen (Remote Code Execution - RCE). 

Die Kritikalität der Schwachstelle wird im Common Vulnerability Scoring System (CVSS) mit 10 (von 10) bewertet, was den Schweregrad der Schwachstelle angibt." 

Quelle: https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/

Anmerkung:
Die «Apache Software Foundation» ist eine Organisation, welche hunderte Open Source Software Projekte fördert. Unter anderem das Log4j Logging Framework, oder auch den bekannten HTTP Webserver. Der Apache HTTP Server  ist nicht Java basiert, und hat mit dem Log4j ausser dem Namen und der Stiftung nichts zu tun und ist selbst nicht von der Sicherheitslücke betroffen.

Was versteht man unter: «Zero-Day Exploit»?

Zero-Day-Exploit nennt man einen Exploit, der eingesetzt wird, bevor es einen Patch als Gegenmaßnahme gibt. Entwickler haben dadurch keine Zeit („null Tage“, englisch zero day), die Software so zu verbessern, dass der Exploit unwirksam wird, um Nutzer zu schützen. Entdeckt eine Person eine Sicherheitslücke und meldet sie nicht dem Software-Hersteller, sondern entwickelt einen Exploit, um diese auszunutzen, wird die Schwachstelle der Software oft erst lange nach dem ersten Angriff bekannt. Von Hackern werden Zero-Day-Exploits gern geheim gehalten, um sie lange auszunutzen. Außerhalb der Öffentlichkeit werden Zero-Day-Exploits unter Hackern gehandelt oder Herstellerfirmen zu hohen Summen angeboten.Die Preise stiegen seit 2012 etwa um den Faktor 10 an.Seit staatliche Organe offensive Cyberwar-Szenarien vorbereiten, versuchen legale staatliche und privatwirtschaftliche Organisationen Exploits zu kennen, um durch die Veröffentlichung von Patches Systeme abzusichern – oder um feindlichen Systemen schaden zu können.

Vorbeugend versuchen Experten, Sicherheitslücken im Voraus aufzuspüren und Software-Herstellern aufzuzeigen. Dies wird in Fachkreisen manchmal kritisiert, da die Tester dabei mitunter Gesetze oder Hersteller-Richtlinien verletzen. 

Quelle: https://de.m.wikipedia.org/wiki/Exploit#Zero-Day-Exploit

Was tut Polynorm?

Unsere Spezialisten stehen derzeit in engem Kontakt mit den entsprechenden Herstellern und untersuchen, ob und wenn ja, welche Produkte und/oder Anwendungen von dieser Sicherheitslücke betroffen sein könnten.

Die gewonnenen Erkenntnisse dokumentieren wir hier laufend und geben, wenn möglich, entsprechende Handlungsempfehlungen ab. Es kann sein, dass wir Sie ggf. direkt kontaktieren werden.

Disclaimer: Polynorm übernimmt keinerlei Garantie/Haftung für Schäden irgendwelcher Art. Diese Seite dient lediglich der Information unserer Kunden über mögliche Zusammenhänge der Log4j-Lücke und den durch Polynorm entwickelten/vertriebenen Produkte.

Beim Einsatz von Webservices im i/2-Umfeld kommt Apache Tomcat zum Einsatz. In der Standard-Installation von Tomact kommt «JULI» als Logging-Framework zum Einsatz und nicht «Log4j». Die Polynorm-Installationen von Apache Tomcat werden i.d.R. mit den Standard-Settings ausgeführt.

Quelle: https://tomcat.apache.org/tomcat-8.0-doc/logging.html

Comarch ERP Enterprise

Comarch ERP Enterprise ist bekanntlicherweise eine Java-basierte Anwendung und daher potentiell gefährdet.

Die betroffene Klasse «JndiLookup» wird jedoch nicht eingesetzt. 

Vom Hersteller selbst haben wir soeben folgendes Statement erhalten:

CEE ist im Standard inklusive APPs nicht von der Lücke betroffen. Die eingesetzte Version von log4j enthält die Sicherheitslücke nicht.

Wir können nicht völlig ausschließen, dass im Rahmen einer Adaptierung über eine Bibliothek, diese vulnerable Version in das System gekommen ist. Auch in diesem Fall wäre ein Angriff über die CEE Oberfläche nicht möglich. Wir können aber nicht ausschließen, dass nicht doch ein möglicher Angriffsvektor existiert. 

Mit dem Befehl: dspcls -class:org.apache.logging.log4j.core.lookup.JndiLookup 

können Sie prüfen, ob die Schwachstelle überhaupt im System vorhanden ist. Wenn der Befehl die Klasse nicht findet, ist Sicherheitslücke nicht vorhanden. Falls sie gefunden wird, müssen Sie prüfen, aus welche Bibliothek sie kommt.


Polynorm E-Business Plattform / eShop 3.x / X-Media Manager

Die Polynorm E-Business Plattform sowie die Vorgänger-Version Shop 3.x setzen als Suchtechnologie auf «ElasticSearch».

Die Docker-Instanzen von ElasticSearch unserer aktuellen E-Business Plattform laufen alle unter ElasticSearch 6. In diesem Kontext sind nur Installation mit einer JDK-Version <= 8 betroffen. Alle unsere Installationen laufen mit JDK-Version zwischen JDK12-JDK14 und sind daher nicht betroffen.

Quelle: https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476

Bei Kunden mit der Vorgängerversion Shop 3.x und ElasticSearch 5.x zeigt sich die Situation leider etwas anders.

Aktuell ist noch unklar, wann mit einer sauber gepatchten Version zu rechnen ist. Wir haben daher auf Basis des offiziellen 5.0.2 ElasticSearch Docker-Images ein eigenes Image erstellt, in welchem die entsprechende Java-Klasse entfernt wurde.
Ihr Ansprechpartner nimmt mit Ihnen direkt Kontakt auf, falls Sie davon betroffen sind und koordiniert mit Ihnen gemeinsam das Vorgehen.

Update vom 14.12.2021

In diversen Medien wurde in den letzten Tagen auch beschrieben, dass die In-Memory-Datenbank "Redis", welche auch wir in unserer aktuellen E-Business Plattform einsetzen, ebenfalls von der Sicherheitslücke betroffen ist.
Wir möchten hier konkretisieren, dass es sich dabei "nur" um den Java Client "Jedis" handelt, welcher betroffen ist und welcher in der Polynorm E-Business Plattform nicht zum Einsatz kommt.

Weiterführende Infos finden sich online im Artikel auf der Redis-Webseite.

Apache NiFi

Auch diverse Apache-Produkte sind von der Log4j-Sicherheitslücke betroffen. Nicht so Apache NiFi, welches anstelle von «Log4j» «Logback» einsetzt. (https://logback.qos.ch/)

Nifi-Apache.org listet keine Sicherheitslücken zum Thema Log4j:

Quelle: https://nifi.apache.org/security.html

Bestimmte Plugins für NiFi hingegen können von sich aus Log4j verwenden. Uns ist aktuell jedoch nicht bekannt, dass bei unseren Kunden ein solches Plugin eingesetzt würde.

Update vom 16.12.2021

Seit heute ist der NiFi Release 1.15.1 verfügbar in dem alle log4j und logback Verwendungen auf der aktuellsten Version sind. Obwohl die Plugins mit log4j aktuell nicht verwendet werden, empfehlen Apache NiFi sowie Polynorm dringend einen Update auf die neueste NiFi Version 1.15.1, um auszuschliessen, dass doch irgendwie auf die Schwachstelle im log4j zurückgegriffen werden kann.

https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.15.1

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12351055


MicroStrategy

MicroStrategy hat zwischenzeitlich ebenfalls bestätigt, dass gewisse Versionen Ihrer BI-Lösung von der aktuellen Sicherheitslücke betroffen sind.

Konkret schreibt MicroStrategy dazu:

"This vulnerability is under active investigation and impacts any application using Apache Log4j v2 prior to version 2.15.0.  MicroStrategy products for all updates on platform versions 2021 (11.3.x) and 2020 (11.2.x) as well as version 2019 Update 7 (11.1.7) and Update 8 (11.1.8) use vulnerable versions of Log4j."

Des Weiteren schreibt MicroStrategy, dass sie an einem Security Update arbeiten, welches Apache Log4j2 auf Version 2.15.0 anhebt. Zudem werden einige Massnahmen beschrieben, welche getroffen werden können solange das Update nicht verfügbar ist bzw. ein Update nicht möglich ist.

Update vom 14.12.2021
MicroStrategy hat uns soeben schriftlich informiert, dass für Mircostrategy 2021 ein Update 4 und für die Version 2020 ein Update 6 mit einer aktualisierten Log4j library für nächste Woche geplant ist.

Bis diese Updates verfügbar sind, sollten entsprechende technische Massnahmen ergriffen werden um die Angriffsvektoren einzudämmen. Betroffene Kunden werden von unserem Ansprechpartner gezielt kontaktiert.

Update vom 15.12.2021
MicroStrategy hat ihr Statement aktualisiert und geht davon aus, dass das benötigte Update dieses Wochenende zur Verfügung gestellt werden kann.
"MicroStrategy continues to actively follow developments surrounding Log4j and recommended mitigations, including the new CVE-2021-45046.  We have completed an initial review of whether our platform is at risk after applying the Message Lookup mitigations detailed in this article.  Based on our review the MicroStrategy platform is not vulnerable to CVE-2021-45046.   We continue to focus on providing a version of MicroStrategy 2021 Update 4 and 2020 Update 6 with Log4j version 2.16.0 as a comprehensive fix.  We are currently targeting to have both Updates available over this weekend.  An update will be posted once firm dates are available.”

Update vom 18.12.2021
Folgendes Update haben wir seitens MicroStrategy am Samstag erhalten. Ihr Ansprechpartner kontaktiert Sie bezgl. des weiteren Vorgehens.

"We are announcing the availability of MicroStrategy 2021 Update 4 in our Download Site.  We strongly recommend that you apply this update to completely resolve the Apache Log4J Vulnerability described in this article: 

MicroStrategy’s response to (CVE-2021-44228) The Log4j Vulnerability  

MicroStrategy 2021 Update 4 enhances our platform’s security posture and provides additional features to enhance your experience.  Further information is available in the MicroStrategy 2021 Update 4 Readme.

Additionally, MicroStrategy 2020 Update 6 is planned to be released on Sunday, December 19, 2021."

Talend

Von Talend gibt es bisher nur ein kurzes Statment aus dem hervorgeht, dass die Cloud-Komponenten nicht betroffen sind. Die on premise Komponenten (Remote Engine, Tac, Studio) hingegen schon.

Der Hersteller schreibt dazu folgendes:

"Our Security team is aware of the recently reported CVE-2021-44228 and ist working towards a permanent fix.
Talend Cloud Applications are configured to block exploits against this threat and thus will not be affected by this CVE.
For any On Prom Talend applications such das Remote Engines, Tac and Studio. Customers my add the following flag: "-Dlog4j2.formatMsgNoLookups=true" to the Tac, Studio and Remote Engine."

Update vom 14.12.2021
Talend hat uns soeben per Mail über den weiteren Verlauf informiert.

"...Talend is working to identify all modules in Talend affected and are working on a permanent solution. We should be able to provide your team with an official in depth update in the coming days on the status of this issue..."

Ebenfalls wurde uns eine Umgehungslösung präsentiert, mit welcher das Problem entschärft werden kann, bis der benötigte Patch ausgeliefert wird.
Unsere Ansprechpartner nehmen mit den betroffenen Kunden direkt Kontakt auf und stimmen das Vorgehen gemeinsam mit Ihnen ab.

Update vom 16.12.2021
Talend aktualisiert den jeweiligen Stand ihrer Untersuchungen und Massnahmen laufend auf dieser Seite.

Kendox

Update vom 14.12.2021

Zwischenzeitlich hat auch Kendox ein entsprechendes Statement veröffentlicht.

Gemäss Kendox verwendet Kendox Infoshare sowohl bei on-prem Installationen als auch in der Cloud die betroffene Library "Log4j" nicht.

Weiterführende Informationen zum Rechenzentrumsbetrieb, anderen Kendox Produkten wie "Purchase-to-Pay" oder "Taskline" (beide nicht durch Polynorm vertrieben) finden sich in obenstehendem Link.

Engomo

Auch engomo hat den Vorfall zwischenzeitlich untersucht und gibt mit folgendem Statement Entwarnung:

Wir haben diesen Sachverhalt umgehend und ausführlich für alle Versionen von engomo mit folgendem Ergebnis überprüft:

engomo ist nicht von der Sicherheitslücke CVE-2021-44228 betroffen.

Es besteht kein Handlungsbedarf.

Sowohl der engomoServer selbst als auch der Tomcat-Applikationsserver nutzen standardmäßig keine der betroffenen Libraries und Komponenten.

Bitte beachten Sie:

Sollten Sie die Logging-Einstellungen der engomo-Installation oder des Tomcat-Applikationsservers abweichend unserer Standardeinstellungen verändert haben, empfehlen wir Ihnen, diese Einstellungen auf die Verwendung der Log4J-Komponente zu prüfen.

Evalanche

Die Newsletter-Lösung "Evalanche" läuft grundsätzlich auf den Servern von Evalanche selbst und ist daher kein direktes Risiko für Sie als Kunde.

Evalanche selbst hat uns soeben aber auch per Mail über den aktuellen Stand informiert und wir geben diese Infos nachfolgend gerne weiter. 

Evalanche schreibt:

"...Wir möchten Sie hiermit darüber informieren, dass daraus derzeit keine Folgen für den Betrieb von Evalanche zu erwarten sind. Evalanche ist keine auf Java basierende Software und das Framework „log4j“ in einer betroffenen Version wird auch nicht als direkte Abhängigkeit anderer, interner Software in Systemen verwendet, die aus einem öffentlichen Netzwerk erreichbar sind oder externe Daten empfangen oder verarbeiten...."

Veeam (Backup)

Der Hersteller der Backup-Lösung scheint log4j nicht zu verwenden. Ein offizielles Statement gibt es aber anscheinend bisher nicht.

Update vom 14.12.2021

Veeam hat zwischenzeitlich ebenfalls ein Statement veröffentlicht und kommuniziert, dass Veeam-Produkte nicht betroffen sind von der Sicherheitslücke und Log4j in den Veeam-Produkten nicht eingesetzt wird.
Weiterführende Infos siehe Link.

Citrix

Die Produkte von Citrix scheinen ebenfalls grösstenteils nicht betroffen zu sein. Die Untersuchungen seitens des Herstellers laufen aber noch und werden online dokumentiert.

Quelle: https://support.citrix.com/article/CTX335705

SecurEnvoy (2FA)

Die Lösung SecurEnvoy (2FA) scheint ebenfalls nicht betroffen zu sein.

Vom Hersteller haben wir folgendes Statement erhalten:

"Mit großer Freude können wir Ihnen mitteilen, dass die Sicherheitslücke in der Apache log4j Java-Bibliothek keine Auswirkungen auf die sichere Nutzung von SecurAccess hat. 

Daher sind für die SecurEnvoy-Anwendungen keine Maßnahmen erforderlich. "

Quelle: https://www.prosoft.de/news/news-details/hinweis-zu-log4j-schwachstelle/

Microsoft allgemein

Folgt

Ich unterstütze Sie gerne bei Ihrem individuellen IT-Sicherheitskonzept.

Peer Gandowitz

Leiter System Integration

Diese Website ist durch reCAPTCHA geschützt und es gelten die Datenschutzbestimmungen und Nutzungsbedingungen von Google.

Gerne kontaktieren wir Sie für ein unverbindliches Gespräch.