13.12.2021 – zuletzt aktualisiert am 17.12.21
OTOBO und die Log4j-Zero-Day-Lücke / Log4Shell
Apache Log4j2 Remote Code Execution (RCE) Vulnerability
CVE-2021-44228 – ESA-2021-31 (CVE-2021-45046 ganz unten)
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 (s. Heise).
Wir haben die Bedrohungslage in Bezug auf OTOBO analysiert und sind zu folgenden vorläufigen Ergebnissen gekommen:
- Im OTOBO Applikationsverbund verwendet lediglich Elasticsearch die Log4J und könnte deshalb potenziell betroffen sein.
- 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.
OTOBO Docker Umgebung
Die OTOBO Docker-Compose-Umgebung ist unserer Einschätzung und der Aussage von Elastiksearch zufolge nicht betroffen, da dort die Java JDK 16 im Betrieb ist.
Manuelle OTOBO Installation mit Apache2
Elasticsearch 6 und 7 sind aufgrund der Verwendung des Java Security Managers nicht anfällig für Remote Code Execution mit dieser Sicherheitslücke.
Elasticsearch, das unter JDK8 oder darunter läuft, ist anfällig für ein Informationsleck über DNS, das durch die unten genannte JVM-Eigenschaft behoben werden kann:
=> Set the JVM option Dlog4j2.formatMsgNoLookups=true
Deaktivieren von Elasticsearch in OTOBO
Sollten Sie Elasticsearch deaktivieren möchten, ist dies jederzeit möglich, ohne die Systemfunktion zu gefährden. Lediglich die Elasticsearch Suche kann dann nicht mehr verwendet werden. Die normale Suche und alle weiteren Funktionen stehen ganz normal zur Verfügung.
Bitte gehen Sie hierfür wie folgt vor:
- Bitte wechseln Sie unter Admin -> Systemkonfiguration und deaktivieren Sie die Option „Elasticsearch::Active“.
- Navigieren Sie zu -> Webservices und setzen Sie den Webservice „Elasticsearch“ auf ungültig.
- Stoppen Sie den Dienst Elasticsearch.
Neues Patch mit aktuellster Elasticsearch-Version – OTOBO 10.0.14
Obwohl auf Grundlage aller uns vorliegenden Informationen nicht davon auszugehen ist, dass OTOBO Instanzen mit aktuellen Elasticsearch-Komponenten von Log4Shell betroffen sind, stellen wir mit OTOBO 10.0.14 ein Patch Level Release zur Verfügung, in dem die neueste Elasticsearch Version 7.16.1 eingesetzt wird. In dieser ist die JVM Property standardmäßig enthalten, einige Log4J-Komponenten wurden vorsichtshalber entfernt (Original-Statement von Elastic).
Neue Vulnerability CVE-2021-45046
Die Empfehlung von Elastic zu Elasticsearch bleibt nach Bekanntwerden der neuen Sicherheitslücke unverändert. Für OTOBO ändert sich also nichts gegenüber dem Vorstehenden.
Der Originaltext von Elastic: “Update 15 December
A further vulnerability (CVE-2021-45046) was disclosed on December 14th after it was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. Our guidance for Elasticsearch, APM Java Agent, and Logstash are unchanged by this new vulnerability.” (Quelle)
