Sicherheitslücke Log4Shell: Internet in Flammen
Die Zero-Day-Sicherheitslücke Log4Shell war zu leicht auszunutzen. Das Ausmaß lässt sich noch immer nicht abschätzen.
(Bild: Composing | Quelle: Misha - stock.adobe.com)
Die Brisanz lässt sich nicht überschätzen, Vergleiche mit Hafnium, Heartbleed und ShellShock sind durchaus angebracht: Die am 10. Dezember bekannt gewordene Sicherheitslücke Log4Shell zählt zu den schwersten und weitreichendsten der letzten zehn Jahre, deren konkrete Tragweite sich auch Tage und Wochen später noch nicht abschätzen lässt.
Die Schwachstelle gibt es seit September 2013 und sie schlummert in unzähligen Java-Apps auf Servern in aller Welt. Doch nicht nur Server sind betroffen, auch in manchen Clients sowie in Netzwerk-Equipment wie Routern und WLANs wurden verwundbare Versionen von Log4j entdeckt. Und weil die Lücke seit so langer Zeit existiert, dürften außerdem etliche Embedded- und IoT-Systeme unter anderem aus dem Bereich Smart Home betroffen sein.
Die hohe Brisanz rührt vor allem daher, dass sich Log4Shell extrem leicht ausnutzen lässt. Meist genügt es, dass ein Serverdienst überhaupt aus dem Internet erreichbar ist, um Zugang mit Administratorrechten zu erlangen und beliebigen Code ausführen zu können. Als das BSI (Bundesamt für Sicherheit in der Informationstechnik) am 11. Dezember herausfand, dass Schadcode sogar direkt in die erste Anfrage eingefügt werden kann, stufte es die Lücke in die Warnstufe Rot hoch und löste Großalarm aus.
Das ist der Albtraum für jeden Admin, denn nun galten nicht mehr nur Systeme als verwundbar, die direkten Internetzugang hatten – Schadcode konnte etwa auch auf Datenbankserver im Backend gelangen, die aus Sicherheitsgründen hinter Firewalls eingekerkert sind und selbst keinerlei Internetverbindung herstellen können.
Funktioniert besser als vorgesehen
Für die ganze Aufregung ist eine kleine, aber folgenreiche Schwachstelle in der Bibliothek Log4j verantwortlich. Log4j ist das Schweizer Taschenmesser für alle Logging-Aufgaben in Java, ungefähr vergleichbar mit stderr in C oder logging in Python. Seit über zehn Jahren im Umlauf, millionenfach erprobt und bewährt, geeignet für alle Anwendungsfälle vom Zehnzeiler bis hin zur unternehmenskritischen Enterprise-App. Und genau das war der Knackpunkt: Als in 2012 und 2013 die Version 2.0 von Log4j fast vollständig neu entwickelt wurde, rüstete man im Juli 2013 auf Feature Request LOG4J2-313 hin einen JNDI-Handler (Java Naming and Directory Interface) nach. So ließ sich Log4j nicht mehr nur über die Systemeinstellungen oder das Environment konfigurieren, sondern auch über eine lokale XML-Datei. Genau diese Arbeitsweise prüft auch der automatisierte JNDI-Test, der im Rahmen des Patches für den JNDI-Handler in Log4j in Version 2.0-beta9 eingefügt wurde.
Was die Log4j-Entwickler offenbar damals und weitere acht Jahre lang auch alle anderen übersehen haben: JNDI ist ein noch viel größeres Schweizer Taschenmesser als Log4j. JNDI nur zum Nachladen lokaler XML-Konfigurationsdateien einzusetzen ist ungefähr so, als würde man das legendäre Wenger Giant mit seinen 87 Werkzeugen allein als Nagelfeile benutzen – das funktioniert, ist aber nur eine von 141 Funktionen. Denn JNDI kann nicht nur auf lokale Ressourcen zugreifen, sondern beherrscht auch etliche Netzwerkprotokolle, um im Fall von Log4j Dateien mittels LDAP von zentralen Konfigurationsservern in einem Rechenzentrum beziehen zu können – oder aus dem Internet, wenn die angegebene URL dorthin verweist.
In Log4j verarbeitete der JNDI-Handler sämtliche Log-Daten und untersuchte sie nach Anweisungen, Dateien nachzuladen. Diese Anweisungen haben zum Beispiel die Form ${jndi:ldap://127.0.0.1:1389/a} – wobei JNDI via DNS auch Hostnamen auflöst und dann die Daten eines externen Servers nachladen würde. Wann immer also eine solche Zeichenkette protokolliert werden sollte, lud Log4j via JNDI eine externe Datei nach und führte deren Code aus.
Server und Clients verwundbar
Bei Apples iCloud zum Beispiel diente der Gerätename als Einfallstor: Fügte man die "magische Zeichenkette" in den Gerätenamen ein, luden Apples Server Code von der angegebenen URL nach. Bei vielen anderen Diensten genügte es, die JNDI-Anweisung in den HTTP-Header einzubauen oder den User-Agent des Browsers entsprechend zu ändern.
Die Server des Spiels Minecraft waren mit die ersten, die der JNDI-Schwachstelle von Log4j zum Opfer fielen. Hier genügte es sogar, die "magische Zeichenkette" als einfache Chat-Nachricht einem anderen Spieler zu schicken, um Minecraft-Server zu übernehmen. Doch nicht nur die Server waren akut gefährdet, auch die Minecraft-Java-Clients enthielten die Log4Shell-Lücke. Damit war erstmals offiziell bestätigt, dass Log4Shell keineswegs nur Server betrifft, sondern auch Privatanwender.
Für Angreifer bestand die einzige Schwierigkeit darin, einen Weg zu finden, in irgendeinem Log verewigt zu werden, um eine Bash oder PowerShell zu starten und dann den Rechner zu übernehmen – daher auch der Name Log4Shell. Betroffen waren die Server praktisch aller namhaften Firmen, von Amazon bis VMware – plötzlich stand das ganze Internet lichterloh in Flammen.
»Das Internet ist gerade in Flammen aufgegangen.«
Adam Meyers, Senior Vice President of Intelligence, Crowdstrike
Großalarm für Admins
Admins in aller Welt lieferten sich in der Folge einen Wettlauf mit kriminellen, aber auch staatlichen Angreifern, um die Log4j-Lücke zu schließen, bevor Hintertüren und Brückenköpfe etwa für zukünftige Ransomware-Erpressungen installiert werden konnten. Dabei war es für Admins keineswegs trivial, alle verwundbaren Dienste zu finden, und noch schwieriger, die Lücke zu schließen, bis Updates bereitstanden und getestet waren. Denn längst benutzen Anwendungen nicht mehr nur die vom jeweiligen Server systemweit bereitgestellten Bibliotheken. Es genügt deshalb nicht, etwa über die Paketverwaltung nach älteren Versionen der Bibliothek log4j-core zu suchen.
Heute laufen Anwendungen oft als Docker-Container oder anderweitig virtualisiert, wo sie ihren eigenen Satz Bibliotheken mitbringen. Damit man verwundbare Versionen von Log4j in Containern aufspüren kann, lieferte das Docker-Projekt am 11. Dezember ein Update des Plug-ins "docker-scan-plugin" aus. Allerdings findet docker scan verwundbare Log4j-Installationen nur dann, wenn sie nicht in einem Java Archive (JAR) stecken oder sich gar als JAR in einem JAR verbergen. Auch Flatpaks, Snaps und AppImages bringen haufenweise eigene Bibliotheken mit, deren Versionsstand regelmäßig unbekannt ist. Sollte darunter auch nur eine verwundbare Log4j-Version sein, ist der gesamte Rechner angreifbar.
Dunkelziffer unbekannt
Netzwerkkomponenten sind von Log4Shell zum Teil ebenfalls betroffen, Cisco etwa hat schnell reagiert und schon etliche verwundbare Produkte identifiziert, manche Updates sollte es aber erst im neuen Jahr geben. Auch Ubiquiti hatte die Log4Shell-Lücke in seiner UniFi Network Application früh bestätigt und bereits am 11. Dezember gefixt. Das Programm ist unter anderem für die Authentifizierung von WLAN-Gästen zuständig und damit auch über das WLAN vor Ort anfällig. UniFi Access Points findet man in unzähligen Hotels, Arztpraxen, Bankfilialen, bei Firmen, Frisören und auch bei vielen Privatanwendern.
In wie vielen Embedded- und IoT-Systemen sich Log4Shell versteckt, wurde bislang kaum untersucht. In diesem Bereich ist Java extrem weit verbreitet, etwa im Smart Home, aber auch in elektronischen Schließsystemen. Das Hauptproblem ist hierbei, dass die Schwachstelle in Log4j acht Jahre weit zurückreicht – somit könnten auch ältere Systeme betroffen sein, die vor Jahren verkauft wurden und für die es längst keine Updates mehr gibt. Quellcode, in den man hineinsehen könnte, gibt es hier genauso wenig wie die Möglichkeit, sich auf den Systemen einzuloggen und die Versionsstände der Bibliotheken zu überprüfen.
Man könnte meinen, man müsste dem betreffenden Gerät lediglich eine Browser-Anfrage mit der "magischen Zeichenkette" im User-Agent schicke, um herauszufinden, ob es von Log4Shell betroffen ist. Dabei wird jedoch nicht angezeigt, was konkret protokolliert und ob Code nachgeladen wurde. Deshalb benutzt man sogenannte Canaries.
Auf canarytokens.org etwa können Sie kostenlos harmlose JNDI-Aufrufe für die Log4j-Lücke generieren und erhalten eine E-Mail, falls ein verwundbares System versucht, Code nachzuladen (aber auch, wenn eine Link-Vorschau eines Browsers oder Messengers versucht, den Hostnamen aufzulösen). Doch diese Methode greift zu kurz, denn nicht immer landet der User-Agent im Log, manchmal auch nicht der Verbindungsaufbau, sondern etwa nur ein erfolgreicher Anmeldeversuch. Es kann also sein, dass man Log4Shell nicht über den User-Agent, sondern nur über den Benutzernamen bei einer Anmeldung oder den im DNS-Resolver gesetzten Hostnamen des Testsystems ausnutzen kann. Es gibt keine generischen Tests, mit denen man von außen alle verwundbaren Log4j-Bibliotheken aufspüren könnte.
Fazit
Log4Shell ist zweifellos eine der weitreichendsten und schwerwiegendsten Sicherheitslücken der letzten zehn Jahre. Derzeit arbeiten die Admins mit Hochdruck daran, verwundbare Server zu fixen und erfolgreiche Angreifer wieder vor die Tür zu setzen. Die Schwachstelle wird Admins und Entwickler noch über Monate beschäftigen und abertausende Updates zur Folge haben. Auch Privatanwender müssen auf der Hut bleiben und die auch für sie anstehenden Updates für Router, WLANs, NAS und Smart Home zügig einspielen.
Dabei ist das erst die Spitze des Eisbergs: Staatliche und kriminelle Angreifer haben Log4Shell überwiegend dazu genutzt, um möglichst lautlos und unerkannt Hintertüren und Brückenköpfe in bislang hoch gesicherten Bereichen zu installieren. Die eigentlichen Angriffe auf die IT-Infrastruktur durch Datenklau oder Verschlüsselungstrojaner und anschließenden Erpressungen stehen erst noch bevor. Typischerweise erkunden Angreifer ihr Opfer erst ausgiebig, bevor sie zuschlagen – auch deshalb, weil aktuell alle Admins alarmiert sind und schon auf kleinste Anzeichen achten. Im Frühjahr, wenn wieder der Alltag eingekehrt und etwas Gras über Log4Shell gewachsen ist, dürfte erst die heiße Phase beginnen.
In c’t 2/2022 haben wir für Sie das c’t-Notfall-Windows 2022 zusammengestellt. Mit dem Bausatz für das vom USB-Stick laufendes System finden Sie Viren, retten Daten oder setzen Passörter zurück. Wir beleuchten, wie die EU Schlupflöcher der DSGVO für Content-Scanner nutzen will, wir haben Highend-Smartphones getestet, mobile USB-C-Monitore und Server-Software für die private Mediensammlung. Ausgabe 2/2022 finden Sie ab dem 31. Dezember im Heise-Shop und am gut sortierten Zeitschriftenkiosk.
(mid)
