Vorsicht, Gefahr: Live-Hack – so funktioniert ein Log4Shell-Exploit

Die Log4Shell-Sicherheitslücke überraschte Ende 2021 die Java-Community. Viele Unternehmen arbeiten noch immer daran, ihre Auswirkungen einzudämmen. Damit Entwicklungsteams über die weitere Entwicklung auf dem Laufenden bleiben, hat Snyk ein Ressourcencenter zur Log4j-Sicherheitslücke eingerichtet, das regelmäßig aktualisiert wird.

Bei einem aktuellen Stranger Danger Live-Hack haben Simon Maple, Field CTO bei Snyk, Eric Smalling, Senior Developer Advocate bei Snyk, und Micah Silverman, Director of DevSecOps Acceleration, die Log4Shell-Sicherheitslücke besprochen und demonstriert, wie ein Exploit funktionieren könnte.

Log4Shell kurz erklärt

Log4Shell ist eine weitverbreitete, kritische und leicht auszunutzende Sicherheitslücke im Java-Logging-Framework Log4j2. Da Log4j2 in vielen weiteren Open-Source-Bibliotheken zum Einsatz kommt, waren zahlreiche Java-Anwendungen von dieser Sicherheitslücke betroffen.

„Wie die Tatsache zeigt, dass diese Sicherheitslücke seit 2013 unentdeckt bestand, kann es manchmal zu unerwarteten Nebenwirkungen kommen“, sagte Micah. „Das liegt gewissermaßen in der Natur von Open-Source-Projekten.“

Um diese Sicherheitslücke zu beheben, müssen Entwicklerinnen und Entwickler ermitteln, wo ihre Anwendungen die Log4j2-Bibliothek als direkte oder indirekte Abhängigkeit verwenden, und auf Version 2.17.1 aktualisieren. Dadurch wird nicht nur die Log4Shell-Sicherheitslücke eingedämmt, sondern auch eine weitere kurz darauf bekannt gewordene Denial-of-Service-Sicherheitslücke.

Möchten Sie mehr erfahren? Wir haben einen umfassenden Leitfaden zur Behebung von Log4Shell zusammengestellt.

Anatomie von Log4Shell

2013 wurde der Log4j-Bibliothek die Möglichkeit hinzugefügt, über interpolierte Zeichenfolgen in Logmeldungen auf Referenzen der Java Naming and Directory Interface (JNDI) zuzugreifen. Interpolierte Zeichenfolgen können Variablen, Funktionsaufrufe oder andere auflösbare Ausdrücke enthalten. Das Problem: JNDI kann in diesen auflösbaren Zeichenfolgen URLs nachschlagen und so einen Netzwerkaufruf an einen schädlichen Endpunkt auslösen.

Darüber hinaus kann ein nicht autorisierter LDAP-Server auf die JNDI-Anfrage mit einer schädlichen Referenz auf eine entfernte Java-Klasse oder anderen unerwünschten Code antworten. Diese Klasse kann anschließend deserialisiert werden – selbst wenn sie sich nicht im Klassenpfad der Anwendung befindet. Das kann zu einem Remote-Code-Execution-Angriff (RCE) führen.

Log4Shell-Exploit-Demo

Für unsere Live-Hack-Demo verwenden wir ein von uns entwickeltes Java-Beispiel für einen Log4Shell-Exploit (auf GitHub verfügbar), das wir auf einem Tomcat-Server ausführen. Wenn wir auf der Anmeldeseite ein falsches Passwort eingeben, informiert uns die Anwendung, dass unsere Daten protokolliert werden.

„Bei Fehlern oder Ausnahmen – und manchmal auch bei ganz normalen Transaktionen – wird häufig in Java-Frameworks und Anwendungen protokolliert“, erklärte Simon. „So können Sie die verschiedenen Abläufe nachvollziehen und sehen, wie einzelne Personen Ihre Website nutzen.“

Im Anwendungscode sehen wir, dass wir Log4j verwenden, um einen falschen Benutzernamen zu protokollieren. Situationen wie diese, in denen Benutzer Daten eingeben können, die anschließend protokolliert werden, sind der häufigste Angriffsweg für die Log4Shell-Sicherheitslücke.

Zum Beispiel können wir über das Anmeldefeld eine schädliche Zeichenfolge einschleusen, die einen RCE-Angriff ermöglicht. Sehen wir uns zunächst unser Python-Exploit-Skript an. Wichtig ist dabei: Das Skript generiert eine Java-Klasse, die beim Initialisieren einen neuen Socket erstellt und sich anschließend mit unserem eigenen Server verbindet.

„Das wird effektiv Teil eines Remote-Proxys sein, den wir einrichten“, erklärte Simon. „Die Klasse läuft in einer Endlosschleife, nimmt Befehle entgegen, führt sie aus und sendet sie an unseren verbundenen Dienst zurück.“

Wir erstellen und kompilieren die Java-Datei auf unserem schädlichen Server und stellen sie über einen HTTP-Dienst bereit. Anschließend richten wir unseren LDAP-Server ein, der eine Zeichenfolge zurücksendet, mit der die JNDI der Zielanwendung unsere schädliche Java-Klasse nachschlägt.

Sobald LDAP- und HTTP-Server eingerichtet sind, können wir den Exploit fast ausführen. Für den „Shell“-Teil von Log4Shell richten wir außerdem mit netcat, einem Netzwerkdienstprogramm, einen Reverse-Proxy-Server ein. Damit können wir letztlich Remote-Befehle auf dem Tomcat-Server ausführen. Dadurch werden die Anwendung und der Server anfällig für weitere Angriffe.

Wir führen den Exploit aus, indem wir die schädliche Zeichenfolge in das Anmeldefeld der Zielanwendung eingeben. Sobald Log4j diese Zeichenfolge protokolliert, versucht die Bibliothek auch, die interpolierte Zeichenfolge aufzulösen. Dadurch greift die Anwendung über den JNDI-Dienst auf den LDAP-Server zu, ruft die Referenz auf unsere schädliche Java-Klasse vom HTTP-Server ab und führt sie lokal aus. Diese Java-Klasse verbindet sich anschließend mit netcat und richtet unseren Reverse-Proxy ein.

Log4Shell mit Snyk eindämmen

Wie bereits erwähnt, lässt sich Log4Shell am besten eindämmen, indem Sie alle Log4j-Instanzen in Ihren direkten und indirekten Abhängigkeiten ermitteln und aktualisieren. Snyk Open Source kann Ihre Abhängigkeiten automatisch auf Pakete mit Sicherheitslücken wie Log4Shell überprüfen.

Die Snyk-Plattform ermittelt und kategorisiert zunächst alle Artefakte in Ihrem Projekt, um festzustellen, wie sie überprüft werden können. Snyk führt beispielsweise Software-Composition-Analysis-Scans (SCA) für pom.xml-Dateien und Static-Application-Security-Testing-Scans (SAST) für Java-Dateien durch. Außerdem kann Snyk Infrastructure-as-Code-Konfigurationen (IaC) und Docker-Dateien für containerisierte Anwendungen überprüfen.

Nachdem wir die oben gezeigte anfällige Anwendung überprüft haben, können wir die Scan-Ergebnisse für unsere Datei pom.xml öffnen. Dabei handelt es sich um die Maven-Konfigurationsdatei mit unseren Abhängigkeiten. In der Snyk-Oberfläche sehen wir außerdem den Abhängigkeitsbaum: Unsere Anwendung verwendet Log4j sowohl als direkte als auch als indirekte Abhängigkeit. Wenn Sie auf die Option Diese Sicherheitslücke beheben klicken, kann Snyk automatisch einen Pull Request (PR) erstellen, um alle Log4j-Instanzen auf Version 2.17.1 zu aktualisieren. Führen wir den vorherigen Exploit erneut aus, sehen wir, dass er nicht mehr funktioniert.

Entwicklerinnen und Entwickler können Sicherheitsprobleme auch während der Entwicklung direkt mit dem Snyk-Plugin für IntelliJ (oder eine andere IDE) oder der Snyk CLI erkennen und beheben. Snyk lässt sich in den gesamten Entwicklungsprozess integrieren und vereinfacht so das Management von Sicherheitslücken in Anwendungen.

In manchen Fällen können Unternehmen die anfälligen Pakete nicht sofort aktualisieren und müssen daher andere Möglichkeiten in Betracht ziehen, die Risiken von Log4Shell einzudämmen. Entwicklerinnen und Entwickler könnten die JNDI-Lookup-Klasse entfernen oder andere kurzfristige Korrekturen implementieren. Diese sind jedoch nicht so wirksam wie der offizielle Patch in neueren Bibliotheksversionen.

Unabhängig davon, wie Entwicklerinnen und Entwickler die Log4Shell-Sicherheitslücke eindämmen: Snyk kann dabei helfen, Log4j-Instanzen und Tausende weiterer potenzieller Sicherheitslücken zu finden, indem die Open-Source-Abhängigkeiten oder Container eines Projekts überprüft werden. So erhalten Unternehmen den nötigen Einblick in das Risikoprofil ihrer Anwendungen.