Kurz- und langfristiger Schutz vor Log4j-Schwachstelle Analyse von Log4Shell-Angriffen

Anbieter zum Thema

FTAPI Software GmbH

Keysight Technologies Deutschland GmbH

Ende des letzten Jahrs kam es zu den ersten Log4Shell-Angriffen. Die Experten des Keysight ATI Research Center haben die Angriffe auf die Log4j-Schwachstelle unter die Lupe genommen und genau analysiert. Hier beschreiben sie, was sie herausgefunden haben.

Keysight betreibt ein globales Honeypot-Netzwerk, um unter der Leitung unseres ATI Research Center (Application and Threat Intelligence) Trends bei bösartigen Aktivitäten im Internet zu verfolgen. Die ersten Log4Shell-Aktivitäten wurden am Freitag, dem 10. Dezember, gegen 6:00 Uhr UTC beobachtet. Seitdem analysieren wir die Aktivitäten, um die von Angreifern verwendeten Taktiken, Techniken und Verfahren (Tactics, Techniques, and Procedures, TTPs) besser zu verstehen und unsere Kunden zu schützen.

Der Log4Shell-Angriff wird in zwei Hauptphasen durchgeführt, an denen mehrere Hosts beteiligt sind. Im ersten Schritt wird eine Verbindung zu einem Webserver hergestellt, und über die HTTP-Verbindung wird eine Zeichenfolge gesendet, die geloggt wird. Diese Zeichenfolge löst eine Schwachstelle im Log4j-Java-Logging-Code aus, die den Opfer-Webserver dazu veranlasst, eine Binärdatei von einem zweiten Server herunterzuladen, die dann auf dem Opfer-Webserver mit den Rechten der Webanwendung ausgeführt wird. Nachdem die bösartige Binärdatei auf dem Opfersystem ausgeführt wurde, sind den Möglichkeiten im Grunde keine Grenzen gesetzt – zusätzliche Software kann heruntergeladen und ausgeführt werden, sie kann sich lateral bewegen, usw. Diese Ergebnisse sind je nach Malware-Kampagne sehr unterschiedlich und liegen außerhalb des Rahmens unserer Untersuchung.

Funktionsweise

Als erstes untersuchten wir die Verbindungen der ersten Stufe – die anfänglichen HTTP-Verbindungen. Diese kamen aus der ganzen Welt und wurden mit ziemlicher Sicherheit von Botnets gesendet; die geografische Verteilung der angreifenden IPs entsprach genau der geografischen Verteilung der Botnets. Brasilien, Russland und China spielten eine zentrale Rolle. Diese Phase des Angriffs ist sehr einfach und kann leicht von arglosen Laptops, IoT-Geräten und dergleichen gestartet werden.

In der nächsten Phase unserer Analyse untersuchten wir die Befehle, die die Angreifer ursprünglich gesendet hatten. JNDI (Java Naming and Directory Interface) ist eine Java-Funktion, mit der Objekte während der Laufzeit geladen und verwendet werden können. Der Log4j/Log4Shell-Angriff nutzt diese Funktion aus, indem er eine Log-Nachricht sendet, die einen Befehl zum Herunterladen von Malware enthält, in den meisten Fällen über LDAP. Die Zeichenfolge, die geloggt wird, sieht etwa so aus:

Diese Log-Nachricht veranlasst JNDI, eine Verbindung zu evilserver herzustellen und /path/malware herunterzuladen, es als LDAP-Objekt zu interpretieren und auszuführen. Es wurden auch schon Downloads über andere Mechanismen, wie z. B. RMI (Java Remote Method Invocation), durchgeführt, aber LDAP ist bei weitem die häufigste Methode.

Das erste, was hier auffiel, war die geografische Verteilung der Malware-Server. Russland war mit zwei der drei wichtigsten Server ein Hauptherkunftsland. Danach folgt noch eine längere Liste mit Deutschland, USA und anderen Ländern. Bemerkenswert ist, dass sich der Server mit der Nummer 1 in dieser Stichprobe in Singapur befand, aber einem Unternehmen mit Sitz in Zypern gehörte. Praktischerweise wurden 60 Prozent der Top-Sites bereits in der Rap-Sheet-Datenbank von Keysight erfasst, da wir in letzter Zeit andere bösartige Aktivitäten von diesen Sites beobachtet hatten; sie waren in anderen Malware-Kampagnen verwendet worden. Das bedeutet auch, dass Kunden, die das Keysight-Produkt ThreatARMOR verwenden, automatisch vor diesen Websites geschützt sind, da wir die Verbindungen zu diesen Download-Servern in unserer Datenbank blockieren.

Als Nächstes haben wir uns die tatsächlich gesendeten JNDI-Strings angesehen. Die Angreifer betreiben einen beträchtlichen Aufwand, um die Zeichenfolge zu verschleiern und so die Erkennung durch Perimeter-Sicherheitsvorrichtungen zu umgehen. Dies wurde in erster Linie durch die Manipulation der Groß-/Kleinschreibung von „jndi“ erreicht, wobei die Häufigkeit der Treffer in der nachstehenden Tabelle angegeben ist:

Eine sehr umfassende Beschreibung der Verschleierungs­techniken hat Cloudflare in diesem Blog-Beitrag zusammengestellt. Vermutlich werden immer mehr Verschleierungs­techniken eingesetzt, um Schutzmechanismen zu umgehen.

Als nächstes haben wir einige der in den LDAP-Download-Befehlen angegebenen Schadprogramme heruntergeladen und analysiert. Als Beispiel nehmen wir den Befehl

der auf einen zweiten Server (überprüft durch ldapsearch) –137.184.174.180 – verweist, bei dem es sich um einen Wordpress-Server handelt, der von einem ISP (DigitalOcean) gehostet wird. Höchstwahrscheinlich weiß der Eigentümer dieses Servers nichts von dem Exploit, der unter h__p://137.184.174.180:8082/Exploit.class gehostet wird.

Wenn wir auf diese Exploit.class zugreifen und sie mit Hilfe von Strings untersuchen, sehen wir Folgendes:

Dadurch wird unser Opferserver angewiesen, noch einen weiteren Abruf durchzuführen nach h__p://60.183.165.105/.l/log der eine Reihe von „ptyX“-Dateien enthält (es handelt sich um ELF-Binärdateien):

Interessanterweise enthalten die ptyX-Binärdateien einige japanische Wörter:

Das heißt übersetzt: Ich weiß nichts, nur was du weißt. Dieser Satz taucht häufig in Code auf, der aus der Mirai-Codebasis für Linux- und IOT-Botnets stammt, und ist eine Anspielung auf japanische Anime.

Der letzte Payload (h__p://159.89.182.117/wp-content/themes/twentyseventeen/ldm) ist ein Bash-Skript mit mehreren Verweisen auf TOR.

Base64-Kodierung wurde in großem Umfang als einfache Verschleierungstechnik verwendet, gefolgt von verschiedenen fragwürdigen Befehlen. Schauen wir uns einige konkrete Beispiele an.

1. Download und Ausführung von Binärdateien.

Wir beobachteten, dass Befehle an Log4j gesendet wurden, die etwa so aussahen:

Nach der Dekodierung der Base64-Nutzdaten finden wir

Wir konnten diesen speziellen Code nicht herunterladen, da der Server möglicherweise offline genommen wurde. Aber es ist leicht zu erkennen, wie der Exploit vorging: Er lud offensiven Code in das Verzeichnis /tmp/x86 herunter, den er dann ausführbar machte und ausführte.

2. Diebstahl von AWS-Zugangsdaten

Hinweis: In einigen Beispielen wie diesem entfernen oder verschleiern wir einige Hosts oder Domänen, die an einer Angriffskette beteiligt waren, von denen wir aber annehmen, dass sie unwissentliche Opfer waren.

Die base64-Nutzdaten werden dekodiert als

3. Sleep-Befehl

Vermutlich hat hier jemand ein Skript getestet, indem er etwas Unschädliches ausgeführt hat. Die an Log4j gesendete Zeichenfolge war:

Das bedeutet übersetzt so viel wie "Sleep 20". Wenn man schon von einem Log4Shell-Angriff betroffen sein muss, wäre dies die beste Möglichkeit.

4. Download und Ausführung von Binärdateien.

Diese Base64-Nutzdaten werden in eine relativ einfache Befehlssequenz übersetzt, die den heruntergeladenen Inhalt in eine Bash-Shell leitet:

5. Download und Ausführung von Binärdateien

Wir haben die folgende Zeichenfolge beobachtet:

Daraus ergibt sich die folgende Base64-Nutzlast, die sich als (Bill)Gates Linux-Malware für DDoS entpuppt.

6. Und was wäre eine Angriffswelle ohne den gelegentlichen Powershell-Aufruf zum Herunterladen und Ausführen von Angriffen auf anfällige Windows-Systeme?

Entschlüsselt bedeutet dies

Wir waren nicht in der Lage, dieses PHP herunterzuladen, aber es ist bemerkenswert, dass Nicht-Linux-Systeme gezielt angegriffen werden.

Beobachtungen

Bei den bösartigen Binärdateien, die wir herunterladen konnten, war Cryptojacking wenig überraschend sehr verbreitet. Wir haben viele der üblichen Tricks und Taktiken beobachtet, die Kryptojacker anwenden, um mehr Systemressourcen für das Cryptomining bereitzustellen, z. B. das Abschalten von unkritischen Systemdiensten (und Diensten mit PID > 301) und die gezielte Suche nach konkurrierenden Cryptominern und deren Abschaltung. Es gibt keine Ehre unter Dieben!

Obwohl die Ausnutzung der Log4j-Schwachstelle fast trivial einfach ist, sehen wir ziemlich ausgereifte Malware-Modelle– wie z. B. Proxy-Kompatibilität, Einfügen von SSH-Schlüsseln und Verwendung von Cron-Jobs zur Planung von Befehlen und Netzwerkverbindungen nach der ersten Infektion, um eine Entdeckung zu vermeiden.

Was bedeutet das für die Unternehmens-IT? Die Nutzung von Log4j ist weit verbreitet, es gibt Milliarden von Java-fähigen Systemen. Es ist trivial einfach auszunutzen, und wir sahen eine sofortige und zunehmende Aktivität, sobald der Proof of Concept Code veröffentlicht wurde.

Hier sind die wichtigsten Strategien, um Unternehmen sowohl kurz- als auch langfristig besser zu schützen.

• 1. Aktualisieren Sie Ihre Web Application Firewalls (WAFs) und andere Perimeter-Geräte sofort, um sowohl eingehende als auch ausgehende Log4j-Angriffe zu stoppen; eingehende, um Ihre Server zu schützen, und ausgehende, für den Fall, dass Sie Systeme haben, die unwissentlich zu einem Botnet gehören. Dies kann kurzfristig einen gewissen Schutz bieten, bis Sie in der Lage sind, alle Ihre Systeme zu aktualisieren. Seien Sie sich jedoch bewusst, dass es einen Wettlauf zwischen bösen Akteuren und Sicherheitsanbietern geben wird, um die Verschleierung zu verbessern und zu überwinden, so dass dies wahrscheinlich nur eine teilweise und vorübergehende Lösung ist. Verwenden Sie ein Tool zur Simulation von Sicherheitsverletzungen und Angriffen wie den Threat Simulator von Keysight, um Ihren WAF/NGFW-Schutz vor Log4j-Angriffen zu bewerten.

• 2. Aktualisieren Sie sowohl die externen als auch die internen Systeme, und zwar in dieser Reihenfolge. Jede exponierte IP-Adresse wird derzeit mit Log4Shell-Verbindungsversuchen bombardiert. Sobald ein Angreifer jedoch Fuß gefasst hat, sei es durch einen Log4Shell-Angriff auf einen externen Server oder einen anderen Mechanismus, wird er sich auf interne Systeme stürzen.

• 3. Überprüfen Sie jedes Gerät in Ihrem Netzwerk auf den Aktualisierungsstatus. Das heißt, jeder Server, Drucker und alles andere, das eine eingehende TCP-Verbindung akzeptiert (insbesondere eine Webverbindung) – und wenden Sie sich an den Hersteller, um nach Updates für Log4j zu suchen. Java ist auf Geräten wie Mobiltelefonen, Blu-ray-Playern, Druckern, Netzwerkgeräten und allem anderen weit verbreitet. Wenn Sie ein paar Tage ohne etwas leben können, schalten Sie es aus, bis Sie Informationen von Ihrem Hersteller erhalten.

• 4. Überwachen Sie Ihre Netzwerkaktivitäten. Achten Sie auf unerwartete ausgehende Verbindungen, insbesondere von Geräten, die über das Internet zugänglich sind. Zero-Trust wäre in dieser Situation natürlich ideal, aber wenn Sie keine vollständige Zero-Trust-Implementierung durchführen können, deaktivieren Sie alle ausgehenden Verbindungen von Geräten, die mit dem Internet verbunden und nicht kritisch sind. Selbst wenn Sie ein anfälliges System haben, an das jemand einen bösartigen JNDI-Befehl weiterleiten kann, der Abruf der Malware aber blockiert ist, bietet dies einen gewissen Schutz.

• 5. Ziehen Sie Geoblocking in Betracht, um Ihr Risiko zu minimieren. Wenn Sie über ein Gerät wie eine NGFW oder ein Threat Intelligence Gateway (wie den ThreatARMOR von Keysight) verfügen, das Geoblocking implementieren kann, sollten Sie dies tun. Blockieren Sie sowohl eingehende als auch ausgehende Verbindungen in Länder, die für Ihr Unternehmen nicht von Bedeutung sind. Wenn Sie feststellen, dass Verbindungen blockiert werden, können Sie diese untersuchen und nach und nach auf eine Whitelist setzen, aber jetzt sollten Sie das Risiko minimieren.

• 6. Aktualisieren Sie alle Ihre Server auf Log4j 2.15.0. Und zwar alle. Denn wenn Sie nur einen verwundbaren Server haben, wird er gefunden werden.

Über den Autor: Scott Register hat mehr als 15 Jahre Erfahrung in der Leitung von Produktmanagement-Aktivitäten für globale Technologieunternehmen und ist derzeit Vice President des Bereichs Security Solutions bei Keysight. Er hat einen B.S.- und einen M.S.-Abschluss in Informatik vom Georgia Institute of Technology und war auch Mitglied einer Forschungsabteilung des Instituts.

(ID:47978032)