Am 9. Dezember wurde eine Zero-Day-Lücke bekannt, welche das allseits bekannte und weit verbreitete Framework Apache Log4j betrifft. Die Schwachstelle trägt den Namen Log4Shell und wird als CVE-2021-44228 identifiziert. Die Lage und der Wissensstand verändern sich kontinuierlich, insofern stellt dieser Artikel nicht den Anspruch auf Vollständigkeit. Wir empfehlen, regelmäßig die einschlägigen Quellen von Sicherheitsbehörden zu konsultieren.
Was ist Apache Log4j?
Log4j ist eine Bibliothek in Java, welche zum Logging von Anwendungsmeldungen genutzt werden kann. Dazu werden Informationen ähnlich wie in einem Logbuch dokumentiert. Der Umfang der Dokumentation, kann dabei umfangreich konfiguriert werden. Log4j wird in den allermeisten Java Programmen als De-Facto-Standard verwendet und ist dadurch auch innerhalb von Unternehmensanwendungen eine der meistgenutzten Programmbibliotheken.
Was genau ist Log4Shell oder CVE-2021-44228? Wie läuft ein Angriff ab?
Die Schwachstelle wird als extrem kritisch eingestuft (BSI IT-Bedrohungslage: rot), da sie Angreifern beliebige Angriffsmöglichkeiten bietet – von der Ausführung einzelner Programme bis hin zur vollständigen Systemübernahme. Dies erfolgt alles aus der Ferne und ohne Authentifizierung (Remote Code Execution).
CVE-2021-44228 wird durch einen Mechanismus in Log4j ermöglicht, welcher protokollierte Ereignisse auswertet und versucht zu interpretieren. Dieser sogenannte Lookup führt z. B. bei URLs zum Aufruf des entsprechenden Pfades. Sollte unter der URL ausführbarer Programmcode verfügbar sein, wird auch dieser lokal ausgeführt.
Im Detail ist die Java-Klasse „JndiLookup.class“ als Teil des Java Naming and Directory Interface (JNDI) dafür verantwortlich. So ist es möglich, dass Informationen über Protokolle, z. B. das Lightweight Directory Access Protokoll (LDAP), aus der Ferne abgerufen werden können.
Im Beispiel findet Log4j eine bestimmte Zeichenkette, löst diese mit der Lookup-Funktion auf und weist die JNDI an, den LDAP-Server nach Informationen zu fragen.
Genau hier können Angreifer ansetzen, denn Log-Nachrichten können mit etwas Kreativität durch Benutzer gezielt manipuliert werden. Der Angriff wird in folgender Abbildung dargestellt:
Log4j 1: Angriff (Quelle: Zero-Day Exploit Targeting Popular Java Library Log4j (govcert.ch))
Die Auswirkungen eines Angriffs werden in folgender Grafik dargestellt:
Log4j 2: Infektionskette und Auswirkungen eines Angriffs (Quelle: Patch Now Apache Log4j Vulnerability Called Log4Shell Actively Exploited (trendmicro.com))
Wer ist betroffen?
Sicherheitsfirmen berichten von 100 Angriffen pro Minute in den ersten 72 h nach Bekanntwerden der Sicherheitslücke. Mittlerweile sind weit über 800.000 Angriffe registriert worden. Angriffe haben durch bekannte Schadsofftware wie Mirai die betroffenen Systeme für Botnetze gekapert oder Rechenkapazität für Cryptomining genutzt.
Clientsysteme von Nutzern sind nicht im Fokus, dafür aber zentrale Dienste, die über Server, Firewalls, CloudServices etc. angeboten werden und Log4j in Versionen 2.0-beta9 bis 2.12.1, sowie 2.13 bis 2.15 nutzen. Es dürften aber auch zunehmend Software Supply Chains in den Fokus geraten. Selbst der NASA Mars-Helikopter „Ingenuity“ nutzt Log4j, auch wenn man sich auf dem Mars vermutlich weniger Sorgen darum machen muss.
Anbieter und Hersteller von Software sind von dieser Schwachstelle gleichermaßen betroffen. Da die Schwachstelle erst vor kurzem aufgedeckt wurde, ist das Schadensausmaß noch nicht vollumfänglich bewertbar. Jedoch informieren immer mehr Software-Hersteller und Cloud Provider zum Status ihrer Produkte und Services. Darüber hinaus wurde eine inoffizielle Linksammlung betroffenen Produkte und Cloud Services ins Leben gerufen und fortgeschrieben. Diese Liste wird insbesondere aufgrund der verbreiteten Nutzung in den kommenden Tagen weiter anwachsen. Viele Software-Hersteller und Cloud Provider werden wegen des großen Prüfaufwands vermutlich noch mehrere Wochen benötigen, bis ein komplettes Lagebild vorliegt.
Woher weiß ich, ob meine Systeme betroffen sind?
Zunächst sollte man sich – optimaler Weise mit Hilfe einer vorhanden und gut gepflegten Configuration Management Database (CMDB) – einen Überblick darüber verschaffen, welche Produkte und Cloud Services innerhalb der Organisation genutzt werden. Davon ausgehend kann dann über die Seiten der Hersteller oder über die oben erwähnte inoffizielle Linksammlung überprüft werden, ob die genutzten Produkte und Cloud Services auf Log4j setzen.
Auf Grund der hohen Kritikalität, sollte auch eine direkte Anfrage beim Hersteller oder Cloud Provider in Erwägung gezogen werden, wenn andere Quellen keine Antwort liefern. Diese können vor allem eine Aussage treffen, ob für das jeweilige Produkt bereits Patches vorliegen oder andere mitigierende Maßnahmen möglich sind.
Darüber hinaus können Tools wie z. B. der Log4j-detector helfen, um die eigene Verwundbarkeit zu ermitteln und die individuelle Bedrohung zu klassifizieren.
Welche Maßnahmen kann ich ergreifen, wenn meine Systeme betroffen sind?
Ein Filtern von schädlichen Anfragen mit Hilfe von Firewalls oder anderen Intrusion Detection Systemen ist nur schwer realisierbar, da es schier unendlich viele Möglichkeiten von Mustern gibt, weshalb eine Erkennung schadhafter ausführbarer Codes in den Eingaben nahezu unmöglich ist.
Ähnlich verhält es sich mit der Filterung von IP-Adressen oder IP-Adressbereichen, da diese durch professionelle Angreifer leicht geändert werden können.
Mittlerweile gibt es ein Update 2.16.0 für Java 8 oder neuere Versionen sowie Update 2.12.2 für Java 7. Für den Betrieb der Software Verantwortliche sollten Patches so schnell wie möglich installieren. Hersteller wiederum sollten diese so schnell wie möglich bereitstellten.
Falls die Installation eines Patches nicht möglich ist, muss zunächst auf Workarounds gesetzt werden, um eine Ausnutzung der Schwachstelle schnellstmöglich zu verhindern. Der ursprünglich empfohlene Workaround seitens der Log4j-Entwickler zur Änderung der Variable „Log4j2.formatMsgNoLookups“ auf „true“ gilt inzwischen als nicht mehr wirksam. Die betroffene Klasse für den JNDI-Lookup sollte daher aus der betroffenen Installation entfernt werden. Alternativ sollte in Erwägung gezogen werden, das betroffene System vom Internet zu isolieren.
Microsoft hat einen Guide für Windows und Linux veröffentlich, der dabei unterstützen kann das Risiko zu minimieren.
Das BSI hat ebenfalls einen Übersichtskatalog mit Maßnahmen veröffentlicht, welche ergriffen werden können, solange es noch keine Updates vom Hersteller gibt, die die Schwachstelle schließen.
Weitere Quellen: Trend Micro Security Alert
