Kritische Schwachstelle in log4j veröffentlicht

Die Mitteilung des Bundesamt für Sicherheit in der Informationstechnik (BSI) vom 11.12.2021 zur Meldung „Kritische Schwachstelle in log4j veröffentlicht (CVE-2021-44228)“ nehmen wir als Anlass, Sie hinsichtlich unserer Lösungen zu informieren.

Eine als kritisch eingestufte Schwachstelle in der weitverbreiteten Java-Bibliothek Log4j ermöglicht es, Angreifern beliebigen Code ausführen zu lassen. Da die Schadstelle ohne explizites Nachladen von Schadcode ausgenutzt werden kann, hatte das Bundesamt für Sicherheit in der Informationstechnik (BSI) die Zero-Day-Lücke am vergangenen Wochenende nachträglich auf die höchste Warnstufe Rot hochgestuft.

__________________________

i-doit setzt vollkommen auf PHP und setzt gar kein Java ein. Dort gibt es, auch nach Scans auf unseren i-doit Instanzen, keine log4j Dateien.

__________________________

Ebenso nutzt keine Version von OTRS, Znuny LTS oder Znuny standardmäßig log4j. Lediglich OTOBO-Installationen, die Elasticsearch nutzen könnten betroffen sein.

Im OTOBO Applikationsverbund verwendet lediglich Elasticsearch die Log4Shell und könnte deshalb potenziell betroffen sein. https://otobo.de/de/otobo-und-cve-2021-44228/

Aktuellen Aussagen von Elasticsearch zufolge ist OTOBO von den größeren Security-Bedrohungen (Remote Code Execution, Datenlecks) grundsätzlich nicht betroffen. Der zentrale Satz ist hier: „Supported Versions of Elasticsearch (6.8.9+, 7.8+) used with recent versions of the JDK (JDK9+) are not susceptible to either remote code execution or information leakage.“

Zu Deutsch: „Unterstützte Elasticsearch-Versionen (6.8.9 und neuer, 7.8 und neuer), die mit aktuellen JDK-Versionen eingesetzt werden (JDK9 und neuer) sind weder durch Remote Code Execution noch Datenlecks gefährdet.“ (zur Stellungnahme von Elasticsearch)

OTOBO setzt JDK 16 ein, Elasticsearch seit der ersten Beta in Version 7.14+. In manuell aufgesetzten Instanzen, die Elasticsearch mit OpenJDK 8 einsetzen, könnten vermutlich begrenzt .env-Daten geleakt werden.

__________________________

JDisc verwendet bis zu Build 5091 log4j in Version 1.2.17. Die ist zwar auch angreifbar, aber nur in der Config, wenn JMSAppender verwendet werden. Dies wird vom Hersteller nicht verwendet und der Build wurde auf Version 2.15.0 angepasst. https://blog.jdisc.com/2020/12/03/lldp-med-improved-discovery/

__________________________

Die Schwachstelle, die es einem Angreifer ermöglichen kann, durch das Senden von präparierten Protokollnachrichten beliebigen Code auszuführen, wurde als CVE-2021-44228 identifiziert und trägt den Namen Log4Shell. Laut https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot sind OpenCelium-Nutzer von dieser Schwachstelle nicht betroffen, da wir anstelle von log4j das Standard-Logging-System verwenden.

Wenn Sie jedoch Abhängigkeiten für log4j aktualisieren möchten, müssen Sie der nächsten Anweisung folgen:

Open build.gradle file and put implementation

'org.apache.logging.log4j:log4j-core:2.16.0'

in dependencies.

__________________________

Wir unterstützen Sie gerne bei etwaigen Aktualisierungsmaßnahmen.

Freundliche Grüße,
das Team der becon GmbH