UPDATE vom 20.12.2021

Der Denial-of-Service-Angriff wird jetzt unter dem Bezeichner CVE-2021-45105 geführt und mit der neuen Version 2.17.0 adressiert.

https://logging.apache.org/log4j/2.x/security.html#Fixed_in_Log4j_2.17.0

UPDATE vom 17.12.2021

Für die Ausführung beliebigen Programmcodes in Log4j 2.15.0 trotz aktiver Mitigationen wurde kein neuer CVE-Bezeichner vergeben. Stattdessen wurde die Bewertung von CVE-2021-45046 (ehemals Denial-of-Service, CVSS 3.7) angepasst auf Ausführung beliebigen Programmcodes, CVSS 9.0. Aktuell wird eine neue Denial-of-Service (DoS)-Schwachstelle diskutiert, die Apache Log4j bis inklusive Version 2.16.0 betrifft (bisher ohne CVE) und auch das Ausleiten von Informationen beispielsweise aus Umgebungsvariablen ist in Apache Log4j 2.16.0 weiterhin möglich. Aufgrund der großen Aufmerksamkeit, die das Projekt im Moment erfährt, ist davon auszugehen, dass weitere Schwachstellen kurzfristig identifiziert und veröffentlicht werden.

UPDATE vom 16.12.2021

Der mit Log4j eingeführte Fix zur Behebung der Schwachstelle CVE-2021-44228 ist für manche Konfigurationen unzureichend und ermöglicht einen Denial-of-Service-Angriff (CVE-2021-45046) auf Log4j 2.15.0 und nach aktuellen Erkenntnissen auch weiterhin die Ausführung beliebigen Programmcodes aus der Ferne (noch ohne CVE). Die Diskussion zu diesem Problem hat auch zutage gebracht, dass die über log4j2.formatMsgNoLookups=true umgesetzten Mitigationen in Log4j < 2.15.0 nicht in jedem Fall erfolgreich sind. Die Entwickler haben sich daher dazu entschlossen, die neuen Versionen Log4j 2.16.0 und 2.12.2 bereitzustellen, in denen Message Lookups vollständig entfernt werden und der Zugriff auf JNDI standardmäßig deaktiviert wird:

https://logging.apache.org/log4j/2.x/security.html#Fixed_in_Log4j_2.16.0

Die Entfernung der Klasse JndiLookup aus dem Klassenpfad mitigiert die Angriffe weiterhin.

Kritische Schwachstelle in Apache Log4j betrifft Java-Anwendungen (CVE-2021-44228)

In der von unzähligen Java-Anwendungen eingesetzten Logging-Komponente Apache Log4j besteht eine kritische Schwachstelle, die auf triviale Weise die Ausführung beliebigen Programmcodes erlaubt und die bereits umfassend aktiv ausgenutzt wird. Es stehen Sicherheitsupdates und Workarounds zur Verfügung. Anwendungen, die Log4j einsetzen müssen allerdings gesondert geprüft werden. Das Ausmaß der betroffenen Anwendungen ist immens, eine laufend aktualisierte Übersicht finden Sie hier: https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

CVE-2021-44228 (Log4Shell)

Die Schwachstelle basiert auf der Unterstützung der 'Message Lookup Substitution' des Java Naming and Directory Interface (JNDI) in Apache Log4j. Für einen Angriff legt der Angreifer eine Nutzlast in einem Namens-/Verzeichnisdienst auf einem Server unter seiner Kontrolle ab. Der Angreifer injiziert dann die passende URL in eine JNDI-Lookup-Methode. Die Anwendung führt den Lookup durch und verbindet sich mit dem Namens-/Verzeichnisdienst des Angreifers, der die Nutzlast zurückliefert. Anschließend dekodiert die Anwendung die Antwort, wodurch die Nutzlast ausgeführt wird. Beschrieben wurde der Angriffsvektor zuerst bei der Black Hat USA 2016 (PDF).

Die Schwachstelle ist im Kontext von Apache Log4j kritisch, da es hier ausreicht, die URL für den Lookup in die Logdateien betroffener Anwendungen zu schreiben. Dies ist im Fall von Webanwendungen oft einfach über einen speziell präparierten User-Agent des Browsers beim Besuch der Webseite oder durch angepasste Parameter möglich. Entsprechende Beispiele können Sie seit 10.12.2021 in Ihren Serverlogs finden:

Mitigation

Die Schwachstelle in Apache Log4j selbst wird durch ein Update auf Version 2.15.0 behoben:

https://logging.apache.org/log4j/2.x/security.html#Fixed_in_Log4j_2.16.0

In Versionen ab 2.10.0 können alternativ die Systemeigenschaft log4j2.formatMsgNoLookups oder die Umgebungsvariable LOG4J_FORMAT_MSG_NO_LOOKUPS auf true gesetzt werden. Das ist auch unabhängig von der Schwachstelle eine sinnvolle Einstellung. In Versionen zwischen 2.0-beta9 und 2.10.0 kann die Klasse JndiLookup über zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class aus dem Klassenpfad entfernt werden.

Für Java-Anwendungen, die Log4j einsetzen, kann beim Aufruf der Anwendung der Parameter -Dlog4j2.formatMsgNoLookups=true verwendet werden, bspw. 

$ java -Dlog4j2.formatMsgNoLookups=true -jar anwendung.jar.

Suche nach Log4j

Um die Mitigation umzusetzen, sollte zunächst sichergestellt werden, wo überall Log4j eingesetzt wird. Die Kolleginnen und Kollegen vom KIT haben dazu eine kurze Checkliste veröffentlicht. Bei Unklarheiten empfiehlt sich ein Blick in die Entwicklermailinglisten oder GitHub/-Lab-Repositories der jeweiligen Produkte. Wenn Sie auf einen externen Scanner zurückgreifen können, gibt es hier einen niedrigschwelligen Einstieg: https://log4shell.huntress.com (Quellcode).

Kritikalität

Das BSI stuft die Schwachstelle mittlerweile mit der höchsten Gefährdungsstufe ein. Aktuell laufen zahlreiche weltweite Scans nach möglicherweise betroffenen Systemen und Coinminer, Botnets und Malwaredistributoren werden ihre Schadprodukte zeitnah aktualisieren. Eine Übersicht über aktive Gruppen findet sich bei abuse.ch: https://urlhaus.abuse.ch/browse/tag/log4j/. Es ist davon auszugehen, dass die Schwachstelle Sicherheitsteams weltweit noch Wochen und Monate beschäftigen wird.