Log4j Sicherheitslücke ermöglicht vollständige Systemübernahme!

21.12.2021 - Robert Siedl

Die weit verbreitete Open Source Bibliothek Apache Log4j, die in vielen Softwarepaketen verwendet wird, um Anwendungsmeldungen zu protokollieren, enthält eine kritische Zero Day Sicherheitslücke (CVE-2021-44228). Die auch Log4Shell genannte Schwachstelle ist trivial ausnutzbar und kann weitreichende Folgen nach sich ziehen. Laut CERT.at ist die vollständige Kompromittierung des betroffenen Systems möglich! (siehe: https://cert.at/de/warnungen/2021/12/kritische-0-day-sicherheitslucke-in-apache-log4j-bibliothek)

Log4shell ist sehr einfach ausnutzbar und wird bereits von Angreifern aller Art massiv ausgenutzt. Das Spektrum reicht von Cyberkriminellen, staatlich gesteuerten Akteuren sowie unbedarften Trittbrettfahren. Dabei kann Ransomware in dein Unternehmensnetzwerk eingespielt werden, Server offline geschaltet oder deine Daten gestohlen oder gelöscht werden.

Welche Maßnahmen müssen getroffen werden um das Ausnützen der Schwachstelle zu verhindern?

Das BSI empfiehlt allgemein, nicht zwingend benötigte betroffene Systeme abzuschalten sowie Netzwerke zu segmentieren, um verwundbare Systeme zu isolieren. Bei kritischen Systemen sollten Angriffsmuster auf WAF (Web Application Firewalls), IPS (Intrusion Prevention Systems) und Proxys unmittelbar abgewiesen oder nicht zwingend benötigte HTTP-Header auf statische Werte gesetzt werden. Ausgehende Verbindungen, die nicht zwingend benötigt werden, sollten blockiert werden. Alle Verbindungen sind für eventuelle spätere Incident Response Maßnahmen mitzuloggen und zu protokollieren. Es empfiehlt sich, die Rechtvergabe betroffener Dienste zu prüfen und ggf. zu reduzieren, Verbindungen zu anderen Systemen zu trennen und Hosts auf Anomalien zu überwachen.

Abhilfe gegen Log4Shell sollte ein Patch auf die Log4j-Version 2.17 schaffen, daher empfehlen wir ihre Server so rasch wie möglich zu patchen!

Vorherige Versionen lösten das Problem nur unzureichend oder waren selbst von Sicherheitsmängeln betroffen.

Die folgende Darstellung des nationalen CERT der Schweiz skizziert verfügbare Abwehrmaßnahmen:

In der letzten Woche haben wir mit allen unseren Herstellern und Partnern Kontakt aufgenommen um zu prüfen, ob diese von der Sicherheitslücke betroffen sind. Anbei findest du die Liste zur Info:

Liste Softwarehersteller:

Software	betroffen ja/nein	Anmerkung	Zusatzinformationen
Proxmox	nein	lt. Forum nicht betroffen	https://forum.proxmox.com/threads/proxmox-log4j-cve-2021-44228.101282/#post-436921
Univention	nein	UCS 5.0 und UCS 4 sind im Kern nicht von der aktuellen Sicherheitslücke log4j/log4shell betroffen. UCS 5.0-0 liefert zwar apache-log4j2 als Debian-Paket aus, dieses ist aber standardmäßig nicht in Verwendung. Updates für dieses Paket haben wir bereits am 13.12.2021 für unsere Kunden verfügbar gemacht, da sie nicht im regulären Errata-Tracking enthalten sind. Weitere Informationen zum Update finden Sie im Help-Forum unter: https://help.univention.com/t/status-of-log4j-log4shell-vulnerability-cve-2021-44228-in-ucs-and-apps/19020. Das UCS-4-Paket apache-log4j1.2 ist mit einer damit zusammenhängenden Sicherheitslückebetroffen, die allerdings keine Remotecodeausführung (RCE) ermöglicht, soweit uns derzeit bekannt ist. Auch dieses wird standardmäßig nicht in UCS verwendet. Hier warten wir auf ein Upstream-Upate.	https://www.univention.de/meldungen/2021/12/update-log4j-sicherheitsluecke/ https://security-tracker.debian.org/tracker/CVE-2021-4104
Zimbra	nein	After intensive review and testing, Zimbra Development determined that the zero-day exploit vulnerability for Log4j (CVE-2021-44228) does not affect the current Supported Zimbra versions (9.0.0 & 8.8.15). Zimbra Collaboration Server currently uses Log4j version 1.2.16. The cause of the vulnerability is found in the lookup expression feature in Log4j versions 2.0 to 2.17. Also, the Redhat (CVE-2021-4104) vulnerability does not affect the current Supported Zimbra Collaboration Server versions (8.8.15 & 9.0.0). For this vulnerability to affect the server, it needs JMSAppender and the ability to append configuration files. Zimbra does not use the JMSAppender. We are in the process of upgrading Log4j and expect it to be completed within the first quarter of 2022.
Kopano	nein	Log4Shell is critical 0-day vulnerability occuring in the Open Source Java library log4j. log4j is used by thousands, if not millions, software packages and often included in tools like application servers. The Log4Shell vulnerability is highly critical (rated 10 out of 10) because there are already documented exploits going on, and because if exploited the attacker might be able to execute remote code, even as root user. There are several ways to mitigate this vulnerability, the best way depends heavily on the individual situation. A quite up-to-date guide seems to be from lunasec.io But good news last: No Kopano package makes use of log4j in any kind or version.	https://kopano.com/blog/log4shell/
Rocket.Chat	nein	Rocket.Chat application is not affected by the log4j vulnerability as it does not use log4j	https://de.rocket.chat/blog/log4j-software-vulnerability
Jitsi Meet	ja	Some of the Jitsi components load a version of log4j which is affected by CVE-2021-44228108. According to our review, jigasi and older jitsi-videobridge instances configured to use callstats may be affected, while all other jitsi components and jigasi instances with no callstats configuration are not affected.	https://community.jitsi.org/t/cve-2021-44228-and-jitsi-components/108844
SEP Sesam	nein	Nein, wir verwenden das log4j Modul nicht.	kb.sep.de/131
ownCloud	nein	ownCloud 10 and ownCloud Infinite Scale are not affected by the important security issue in log4j.	https://central.owncloud.org/t/owncloud-not-directly-affected-by-log4j-vulnerability/35493
NextCloud	nein	log4j is a Java library. Nextcloud is written in PHP and JavaScript and I do not know of any other Nextcloud component that is written in Java. Maybe you use a Nextcloud App that depends on a Java application, but then again, that is not part of Nextcloud itself.	https://github.com/nextcloud/server/issues/30242
OPSI	nein	opsi hat als Java Komponenten den opsi-configed und den opsi-logviewer. Beide Komponenten nutzen das log4j-Modul nicht. Ebenfalls gibt es aktuell auch in den verwendeten Fremdbibliotheken von opsi keine verifizierte Anfälligkeit für diese Lücke. Somit ist opsi (4.1 & 4.2) Stand Heute von dieser Lücke nicht betroffen.	https://forum.opsi.org/viewtopic.php?t=12749
CheckMK	nein	CheckMK verwendet kein Java	https://forum.checkmk.com/t/checkmk-not-affected-by-log4shell/28643 Check: https://checkmk.com/blog/automatically-detecting-log4j-vulnerabilities-in-your-it
priacyIDEA	nein	No. The privacyIDEA server is written in Python. The only Java component is the keycloak plugin. It does not use this.	https://community.privacyidea.org/t/cve-2021-44228-log4shell-log4j-vulnerability/2243
onlyOffice	nein	ONLYOFFICE Docs (Document Server) doesn’t use the log4j library and that’s why is not affected by the important security issue in log4j. This applies for all installation types of the editors.	https://www.onlyoffice.com/blog/2021/12/apache-log4j-security-bulletin-stay-safe-with-onlyoffice/
OPNsense	nein	lt. Forum nicht betroffen	https://forum.opnsense.org/index.php?topic=25951.0
Benno Mailarchiv	nein	hiermit möchten wir Sie darüber informieren, dass Benno MailArchiv nicht von der aktuellen log4j Sicherheitslücke betroffen ist.	Newsletter vom 13. Dezember 2021
Atlassian JIra und Confluence	nein	Some on-premises products use an Atlassian-maintained fork of Log4j 1.2.17, which is not vulnerable to CVE-2021-44228. We have done additional analysis on this fork and confirmed a new but similar vulnerability that can only be exploited by a trusted party. For that reason, Atlassian rates the severity level for on-premises products as low. Specifically, Atlassian products that use Log4j 1.x are only affected if all of the following non-default configurations are in place: The JMS Appender is configured in the application's Log4j configuration The javax.jms API is included in the application's CLASSPATH The JMS Appender has been configured with a JNDI lookup to a third party. Note: this can only be done by a trusted user modifying the application's configuration, or by trusted code setting a property at runtime The following products use the Atlassian-maintained fork of Log4j 1.2.17: Bamboo Server and Data Center Confluence Server and Data Center Crowd Server and Data Center Fisheye / Crucible Jira Server and Data Center	https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html
HeliumV	nein	lt. HeliumV: Überprüfungen und Einschätzungen zeigen, dass HELIUM5 nicht betroffen ist. Selbstverständlich beobachten wir die Situation weiterhin und werden Sie sofort informieren, wenn wir zu anderen Ergebnissen kommen
Passpolt	nein	No passbolt is not affected. Passbolt doesn’t use Java.	https://community.passbolt.com/t/question-log4j-log4shell-exploit-is-passbolt-affected/4594
GitLab	nein	On 2021-12-16 the Scala programming language announced that sbt includes a Log4j dependency that is vulnerable to CVE-2021-44228, although it is not enabled by default. The Spotbugs SAST analyzer for Java, Scala, Groovy, and Kotlin code includes sbt. GitLab has updated the sbt version in this analyzer to version 1.5.7, which includes an updated version of Log4j. By default, this analyzer only runs when Java, Scala, Groovy, or Kotlin language code is detected, and sbt is only invoked when Scala code is found.	https://about.gitlab.com/blog/2021/12/15/updates-and-actions-to-address-logj-in-gitlab/
Firmix FAX32 VoIP	nein	FATS2 ist davon nicht betroffen (log4j2 wird nicht verwendet).
Elasticsearch	ja	December 10th started with the public disclosure of the Apache Log4j vulnerability - CVE-2021-44228 affecting the popular open source logging framework adopted by several Java based custom and commercial applications. This vulnerability, affecting versions 2.0-beta9 through 2.14.1 of Log4j2, and is already being exploited by nation state attackers and ransomware groups, such as APT35 and Hafnium. Research by Google using Open Source Insights estimates that over 35,000 packages (over 8% of Maven Central repository) have been impacted by the recently disclosed vulnerabilities, as of December 16th.	https://www.elastic.co/de/blog/new-elasticsearch-and-logstash-releases-upgrade-apache-log4j2
Odoo ERP	nein	Grundsätzlich besteht für Odoo Community und Enterprise Edition keine Gefahr, da keine java-basierten Technologien zum Tragen kommen	https://www.myodoo.de/blog/neuigkeiten-odoo-50/post/unsere-information-zur-zero-day-lucke-in-log4j-447
Thinstuff	nein	We can assure our customers that Thinstuff software is not affected by the recently discovered Apache CVE-2021-44228 (Log4j) vulnerability nor does it use any of the affected libraries. Log4j is a library that is used by Java applications only. TSX Gateway connects the RDP protocol with the HTTPS protocol to provide a secure connection to XP/VS Server without any Java application needed. These users simply use a modern Remote Desktop Client (recommended) to connect to their Remote PC.	https://thinstuff.com/news/2021-12-15-thinstuff-software-is-not-affected-by-log4j-vulnerability/
eJabberd	nein	verwendet kein Java	https://hub.docker.com/r/ejabberd/ecs
Guacamole	nein	No, CVE-2021-44228 does not affect Apache Guacamole. Guacamole uses Logback as its logging backend, not Log4j.	https://blogs.apache.org/security/entry/cve-2021-44228 https://guacamole.apache.org/security/
SAP	ja	This blog is related to a recent issues with the popular Java logging library log4j version 2 (open source component for logging and tracing of application events) — only touching on the topic related to SAP IdM and the components that might be related to it, such as the AS Java, ASE, Oracle, VDS. You will find a more general discussion of this CVE, SAP impact and mitigation at this SAP Note 3130476 – Detecting and remediating log4j CVE-2021-44228 vulnerabilities in BTP Cloud Foundry applications.	https://blogs.sap.com/2021/12/17/sap-idm-and-recent-log4j-2-vulnerabilities-cve-2021-44228/

Liste Hardwarehersteller

Produkt	Betroffen?
Fujitsu	nicht betroffen. laut Mail von Fujitsu vom 14.12.2021
Thomas Krenn, Synology	siehe: https://www.thomas-krenn.com/de/wiki/Log4shell_Zero-Day-Sicherheitsl%C3%BCcke
Dell	Einige Storage Systeme betroffen, jedoch keine welche von uns verkauft wurden 14.12.2021
Huawei	https://www.huawei.com/en/psirt/security-notices/huawei-sn-20211210-01-log4j2-en eine weitere Stellungnahme folgt noch
Zyxel	nicht betroffen laut Mail vom 14.12.2021
EMA	nicht betroffen: https://www.artec-it.de/de/Presse_und_Aktuelles/Aktuelle_Nachrichten.aspx#/Presse_und_Aktuelles/News/log4j-Schwachstelle_EMA_von_ARTEC_ist_nicht_betroffen.aspx
IGEL	zum Teil: https://kb.igel.com/securitysafety/en/isn-2021-11-ums-log4j-vulnerability-54086712.html

Liste mit weiteren betroffenen Applikationen und Programmen:

https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

Wir monitoren log4j

Wir haben unser Monitoring mit einem zusätzlichen Check erweitert, sodass die Server auf log4j Vulnerabilities geprüft werden. Der CheckMK Check wurde bei dir (insofern du eine aktive SLA-Vereinbarung (lt. SLA-Leistungsschein bzw. Wartungsvertrag hast) am Montag, dem 20. Dezember ausgerollt. Im Monitoring ist das wie folgt ersichtlich: