Log4j – Kritische Sicherheitslücke 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

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.

Die zugrundeliegende Technologie des Polynorm i/2ERP basiert auf OpenEdge der Firma Progress Software Corporation. Die Progress Software Corporation hat ihrerseits bereits einen entsprechenden knowledgebased-Artikel zu diesem Thema veröffentlicht.

Konkret sind gemäss Progress drei Komponenten betroffen, welche i.d.R. bei unseren Kundeninstallationen nicht im Einsatz sind.

Quelle: https://knowledgebase.progress.com/articles/Knowledge/Is-OpenEdge-vulnerable-to-CVE-2021-44228-Log4j

Comarch ERP Enterprise ist bekanntlicherweise eine Java-basierte Anwendung und daher potentiell gefährdet.
Die betroffene Klasse «JndiLookup» wird jedoch nicht eingesetzt. 

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.

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 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."

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.

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.

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.

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...."

Der Hersteller der Virtualisierungslösung «VMWare» scheint von der Lücke ebenfalls betroffen zu sein und informiert auf seiner Webseite über die betroffenen Produkte und Arbeit an entsprechenden Patches. 

Quelle: https://www.vmware.com/security/advisories/VMSA-2021-0028.html

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.

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

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/

Die Abklärungen beim Hersteller der Antiviren-Lösungen laufen noch und werden online dokumentiert. Die Endpoint Detection and Response Lösung «MVision» scheint nicht betroffen zu sein:

Quelle: https://kc.mcafee.com/corporate/index?page=content&id=KB95091

Die von Polynorm eingesetzten Firewall-Produkte der Firma Fortinet sind gemäss Angaben des Herstellers nicht betroffen.

Quelle: https://www.fortiguard.com/psirt/FG-IR-21-245?utm_source=blog&utm_campaign=blog

Folgt