Die Sicherheitslücke Log4Shell ist unsere Strafe für 2021

Von Steve Povolny und Douglas McKee 19. Januar 2022

Überblick

Am 9. Dezember wurde auf Twitter eine Schwachstelle (CVE-2021-44228) im Zusammenhang mit der Protokollierungsbibliothek Log4j von Apache bekannt gegeben und parallel dazu in GitHub ein PoC bereitgestellt. Apache wurde zuerst am 24. November von Chen Zhaojun vom Alibaba Cloud-Sicherheitsteam über den Programmfehler informiert.

Die Schwachstelle hat potenziell schwerste Auswirkungen, weil sie jedes Produkt betreffen, das die Log4j-Bibliothek in seine Anwendungen integriert hat. Dazu gehören auch Produkte von Internet-Giganten wie Apple iCloud, Steam, Samsung Cloud-Speicher sowie tausende weitere Produkte und Dienste. Dies ist erst der Anfang, da Java in Anwendungen fast aller Branchen intensiv genutzt wird. Es gibt jedoch Vorsichtsmaßnahmen und Strategien, die Unternehmen anwenden können, z. B. einen proaktiven Schutz, um Resilienz aufzubauen und sich vor diesen immer neuen und häufigeren Bedrohungen zu schützen.

Was ist das?

Die Schwachstelle wird durch das Verfahren ermöglicht, mit dem die Java Naming and Directory Interface-Funktion (JNDI) Variablen auflöst. Wenn eine JNDI-Referenz in ein Protokoll geschrieben wird, ruft JNDI alle Anforderungen für die Auflösung der Variablen ab. Dazu lädt sie alle erforderlichen Remote-Klassen herunter und führt sie aus. Dies gilt für Server-seitige und Client-seitige Anwendungen, da die Hauptvoraussetzungen für die Schwachstelle ein angreiferkontrolliertes Eingabefeld und die Weitergabe dieser Eingabe an das Protokoll sind.

Um diesen Angriff zu koordinieren, kann ein Angreifer mehrere unterschiedliche JNDI-Suchen verwenden. Die beliebteste Suche, die momentan in PoCs und der aktiven Ausnutzung beobachtet wird, arbeitet mit LDAP. Andere Suchen wie RMI und DNS sind jedoch ebenfalls praktikable Angriffsvektoren. Die simplen LDAP/RMI-Angriffsvektoren funktionieren jedoch nur bei älteren JDK-Versionen. Es gibt Publikationen, in denen Methoden zur Umgehung dieser Einschränkung beschrieben werden, um die Code-Ausführung zu erreichen, allerdings erhöhen sie die Komplexität des Angriffs.

Schwachstellen im Zusammenhang mit der Deserialisierung von Java-Objekten stellen keine neue Art von Schwachstellen oder Angriffen dar. Sie können hierfür bereits vorhandene offensive Aufklärungsinstrumente wie "marshalsec" nutzen, die die Code-Ausführung erleichtern.

Zeitleiste und Gegenmaßnahmen

• Am 14. Dezember wurde bestätigt, dass die Log4j-Version 1.2 für ähnliche Angriffe über die JMSAppender-Komponente anfällig ist, und am selben Tag wurde CVE-2021-4104 veröffentlicht. Diesmal ist die Ausnutzung jedoch nicht so einfach wie bei den Versionen 2.0-alpha1 bis 2.16.0. Damit sie gelingt, muss JMSAppender aktiviert sein und TopicBindingName- oder TopicConnectionFactoryBindingName-Konfigurationen besitzen, die ihm die Ausführung von JNDI-Anforderungen erlauben. Dies ist nicht standardmäßig der Fall.

Nach der Bestätigung hat Apache eine neue Version von Log4j veröffentlicht, Version 2.16.0. Durch dieses Update wurde JDNI standardmäßig deaktiviert, sodass ein Benutzer die JNDI-Funktion explizit aktivieren muss. Zudem wird die Nachrichtensuche nicht mehr unterstützt.

• Am 18. Dezember wurde eine neue Denial of Service-Schwachstelle (DoS) (CVE-2021-45105) im Zusammenhang mit den Versionen 2.0-alpha1 bis 2.16.0 von Log4j entdeckt. Um die ursprüngliche Log4j-Schwachstelle zu beheben, hat Apache die JNDI-Suche in Version 2.16.0 komplett deaktiviert. Bei nicht standardmäßigen Konfigurationen bleibt jedoch die Möglichkeit der selbstreferenziellen Suche. Wenn eine verschachtelte Variable durch die Klasse StrSubstitutor ersetzt wird, ruft sie rekursiv die Klasse substitute() auf. Wenn diese verschachtelte Variable die ersetzte Variable rekursiv referenziert, ergeben sich eine unendliche Rekursion und ein DoS-Zustand auf dem Server. Aktuelle Untersuchungen zeigen, dass dies im Gegensatz zu den vorherigen Schwachstellen keine Code-Ausführung auslöst.

Daraufhin hat Apache eine neue Version von Log4j – Version 2.17.0 – veröffentlicht, um die neueste DoS-Schwachstelle zu behandeln. Es wurden zwei zusätzliche Klassen aus StrSubstitutor erstellt, um Analysezeichenfolgen zu verwalten, die Benutzereingaben enthalten können. Sie erlauben keine rekursive Auswertung. Da die Ausnutzung dieser Schwachstelle zu einem DoS-Angriff führt, gilt sie als weniger kritisch als die zuvor gemeldeten Log4j-Schwachstellen, die eine Remote-Code-Ausführung ermöglichen können.

Für eine erfolgreiche Ausnutzung müssen mehrere nicht standardmäßige Bedingungen erfüllt sein. Da sich die Log4j-Lage ständig weiterentwickelt, empfehlen wir Ihnen, auf Version 2.17.1 zu aktualisieren und sich zu Beginn dieses Jahres die Zeit zu nehmen, um alle Sicherheitsstrategien und -praktiken auf den Prüfstand zu stellen.

Ein positiver Ausblick

Es gibt zahlreiche Informationen zu den verschiedenen Behebungsmöglichkeiten für diese Schwachstelle, sodass Mensch und Maschine ständig lernen und sich anpassen können. Mit den Bedrohungen müssen auch die Strategien und Prozesse dynamischer werden, um Geschäftsabläufe zu optimieren und zu schützen. Log4j bietet Unternehmen die Chance, Bedrohungen nicht mehr als unvermeidbares Übel hinzunehmen, sondern als Chance für Wachstum, Weiterentwicklung und Anpassung zu betrachten, um Resilienz und im weiteren Verlauf einen Wettbewerbsvorteil daraus zu entwickeln.

Wir haben diese Schwachstelle seit ihrer Bekanntgabe aufmerksam verfolgt, weil wir wissen, wie wichtig es ist, Sicherheit als lebendige Einheit zu betrachten, um mit schnell entstehenden Bedrohungen wie Log4j Schritt zu halten. Mit dem von uns reproduzierten und bestätigten PoC wollten wir zunächst bestimmen, wie einfach die Schwachstelle ausgenutzt werden kann. Dabei kamen der öffentliche Docker-Container, eine Client-Server-Architektur mit LDAP und RMI sowie marshalsec zum Einsatz, um die Log4j-Version 2.14.1 auszunutzen.

Im weiteren Verlauf planen wir, Variationen des Exploits zu testen, die mit Diensten wie DNS bereitgestellt werden. In der Zwischenzeit haben wir die Netzwerksignatur KB95088 für Kunden veröffentlicht, die NSP (Network Security Platform) nutzen. Sie erkennt Versuche, CVE-2021-44228 über LDAP auszunutzen. Die Signatur kann auf weitere Protokolle oder Dienste ausgedehnt werden. Zudem können weitere Signaturen zur Verbesserung des Schutzumfangs veröffentlicht werden.

Weitere Ressourcen

Umfassende Informationen zu dieser Schwachstelle finden Sie in unserem Sicherheitsbulletin. Darüber hinaus gelangen Sie über die folgenden Links zu einer ständig wachsenden Zahl von PoCs und Tools:

• https://github.com/pedrohavay/exploit-CVE-2021-44228
• https://github.com/christophetd/log4shell-vulnerable-app
• https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
• https://www.greynoise.io/viz/query/?gnql=tags%3A%22Apache%20Log4j%20RCE%20Attempt%22
• https://rules.emergingthreatspro.com/open/
• https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes
• https://github.com/corretto/hotpatch-for-apache-log4j2
• https://github.com/nccgroup/log4j-jndi-be-gone