Log4Shell
Vectra AI analysiert Log4Shell - Die Entwicklung eines Exploits
Die JNDI-Exploits am vorletzten Wochenende waren spektakulär. Viele Sicherheitsteams auf der ganzen Welt sind auf ihre Posten geeilt und haben viele Stunden mit der Identifizierung, dem Blockieren, dem Patchen und wahrscheinlich auch dem Kampf mit den Infrastrukturteams verbracht, um Änderungen vorzunehmen, damit dieser Zero-Day, der jetzt CVE-2021-44228 heißt, gepatcht werden kann.
Entwicklung des Exploits anhand von Netzwerk-Metadaten
Über das Wochenende und bis in diese Woche hinein hat Vectra aktiv die Versuche von Angreifern beobachtet, diese Schwachstelle in freier Wildbahn auszunutzen. Die meisten dieser ursprünglichen Versuche kamen aus dem Tor-Netzwerk und versuchten, Hosts dazu zu bringen, die Domain zurückzurufen: bingsearchlib[.]com. Obwohl es einige Spekulationen darüber gibt, was diese Domain abwarf, wurden von Vectra keine Nutzdaten von dieser Domain abgerufen. Private Analysen deuten darauf hin, dass die Nutzlast mit dem Coin Mining zusammenhängt. Möglicherweise gibt es jedoch noch andere Faktoren, die das Wasser trüben, wenn es um ToR-Verbindungen geht, worauf wir in Kürze eingehen werden. Vectra hat die verschiedenen Domains 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). 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. Vectra hat IPs mit dieser Kodierung mehrfach in seinen Metadaten beobachtet.
Eine weitere Entwicklung, die Vectra in freier Wildbahn beobachtet hat, 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:
Während Vectra diese Entwicklung bereits vor zehn Tagen feststellte, ist die Nutzung seitdem tatsächlich zurückgegangen. Doch warum ist das so?
Leider treiben die Verteidiger die Entwicklung von Exploits voran
Während die Verteidiger versuchen, sich gegen neue Exploits zu schützen, versuchen die Angreifer, sich weiterzuentwickeln. Der Rückgang der zweiten Stufe kann speziell mit diesem Repository auf GitHub 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 Tools entwickeln, mit denen sie einige dieser neuartigen Versuche erkennen können (siehe oben). Es ist jedoch unbestreitbar, dass Angreifer ihre Taktiken auf der Grundlage von Sicherheitsforschern ändern, und man kann nur bis zu einem gewissen Grad spezifische Signaturen für Angriffe entwickeln. 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.
Das kollektive Stöhnen von Systemadministratoren, SOC-Analysten, Blue Teams auf der ganzen Welt ist fast zu hören. Während einer aktiven Phase eines Exploits, beobachtet in freier Wildbahn, kann ein abschwächender Faktor den Unterschied zwischen einem Update und einer vollständigen Rootkit-Installation bedeuten, wenn jemand diesen abschwächenden Faktor umgeht. Untersuchungen wie diese sind wertvoll und fördern die Diskussion und die Sicherheitspraktiken insgesamt, aber während eines aktiven globalen Ereignisses können sie auch Öl ins Feuer gießen. Ebenso könnte die Suche nach Schwachstellen während des besagten globalen Ereignisses als kontraproduktiv angesehen werden.
Das Geschäft ankurbeln oder die Erkennung nur schwer sichtbar machen?
Einer der am häufigsten beobachteten Angriffsversuche ging nicht von böswilligen Akteuren oder Einzelpersonen aus, die den Exploit testeten, sondern von Sicherheitsunternehmen, die mehrere Hosts im Internet scannten, um anfällige Ziele zu identifizieren. Vectra hat mindestens zwei Sicherheitsunternehmen, eines in den USA und ein weiteres in der DACH-Region, beobachtet, die 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 die eigenen Dienste anzukurbeln. In jedem Fall wurden viele der anfänglichen Scanversuche mit eigenen Scanversuchen der Unternehmen gefüllt, was die Erkennung von echtem bösartigem Verhalten erheblich erschwert.
Fazit
Log4shell ist nicht der erste Exploit, der die Welt erschüttert, und es lässt sich mit Sicherheit sagen, dass es nicht der letzte sein wird. Die Angreifer werden sich weiter entwickeln und die Verteidiger an ihre Grenzen bringen, um zu versuchen, sie am Eindringen zu hindern. Log4shell ist wieder einmal ein Weckruf für die gesamte Branche, dass Sicherheitsprobleme nicht verschwinden werden. Egal wie viel wir in die Prävention investieren, Angreifer finden einen Weg.
Informationen zu früheren Entwicklungen finden sich hier im Beitrag über Log4Shell.