Threat Spotlight: Angriffe auf Log4Shell-Sicherheitslücken

Der Log4Shell-Komplex von Schwachstellen in der Log4J-Software ist nun schon seit mehr als zwei Monaten öffentlich bekannt. Das Forscherteam von Barracuda hat die von unseren Systemen seit dem 10. Dezember 221 erkannten Angriffe und Payloads analysiert und festgestellt, dass das Volumen der Angriffe, die diese Schwachstellen auszunutzen versuchen, mit einigen Einbrüchen und Spitzen in den letzten zwei Monaten relativ konstant geblieben ist. In Anbetracht der Beliebtheit der Software, der Ausnutzbarkeit der Schwachstelle und des Gewinns im Falle einer Kompromittierung erwarten wir, dass sich dieses Angriffsmuster zumindest kurzfristig fortsetzen wird.

Obwohl die Anzahl der Angriffe auf diese Schwachstellen konstant bleibt, hat unser Forscherteam einige interessante Erkenntnisse darüber gewonnen, wo die Angriffe herkamen. Die Mehrheit der Angriffe kam von IP-Adressen in den USA, wobei die Hälfte dieser IP-Adressen mit AWS-, Azure- und anderen Rechenzentren verbunden war. Angriffe wurden auch aus Japan, Deutschland, den Niederlanden und Russland gesendet. Beachten Sie, dass es sich hierbei um die IP-Adressen handelt, die Scans und Eindringversuche durchgeführt haben. Die tatsächlichen Payloads wurden von anderen kompromittierten Websites oder VPS-Hosts bereitgestellt, wenn der Angriff durchgekommen war. Diese IP-Adressen, die die Payloads enthalten, werden in der Regel mit der in den folgenden Beispielen beschriebenen Base64-Kodierung verschleiert.

Bedrohung im Fokus

Log4Shell-Schwachstellen — Log4j ist ein Java-basiertes Logging-Audit-Framework innerhalb von Apache. Apache Log4j <=2.14.1 JNDI-Funktionen, die in der Konfiguration, in Protokollnachrichten und in Parametern verwendet werden, schützen nicht vor LDAP und anderen JNDI-bezogenen Endpunkten, die von Angreifern kontrolliert werden. Ein Angreifer, der die Kontrolle über die Protokollnachrichten oder die Parameter der Protokollnachrichten hat, kann beliebigen Code ausführen, der von LDAP-Servern geladen wird, wenn die Lookup-Substitution für Nachrichten aktiviert ist. Die Schwachstelle betrifft die Standardkonfigurationen mehrerer Apache-Frameworks, darunter Apache Struts2, Apache Solr, Apache Druid und Apache Flink, die von zahlreichen Unternehmen wie Apple, Amazon, Cloudflare, Twitter und Steam genutzt werden.

Die Schwachstelle wird durch das Senden eines bestimmten Strings an die Log4j-Software ausgelöst, was bedeutet, dass sie einfach auszunutzen ist. Außerdem gibt es wegen der breiten Nutzung dieser Software mehrere Angriffsvektoren.

Die Details

Sehen wir uns einige Beispiele für die Payloads an, die in den letzten Monaten für die Ausnutzung dieser Schwachstellen verwendet wurden.

Im ersten Fall handelt es sich um eine relativ harmlose (oder, je nach Sichtweise, sehr lästige) Payload:



Nach einigen Recherchen haben wir diese Java-Payload gefunden:

Wie erwartet, spielt das YouTube-Video in dieser Payload Rick Astleys „Never Gonna Give You Up“. Ich frage mich, ob das irgendjemanden überrascht hat. Wie bereits erwähnt, handelt es sich meiner Meinung nach um eine harmlose Payload, die Sie aber sehr schnell zum Patchen bringt!

Cryptomining-Payloads

Das zweite Beispiel ist etwas, von dem wir in den frühen Tagen nach dem ersten Auftreten der Schwachstellen viel gesehen haben — eine Monero Miner-Payload. Sie ging von mehreren verschiedenen IP-Adressen aus, wobei die Befehle in der Regel mit Base64 verschleiert wurden:

Die Dekodierung des Base64-Strings ergab:

Die eigentliche Payload auf dieser URL war dieses Skript, das den Miner eingerichtet hat:

Angriffe auf VMware-Installationen

Im Laufe der Zeit wurden Berichte bekannt, dass die Ransomware-Gruppe Conti versucht, VMware-Installationen mithilfe von Log4Shell-Schwachstellen zu kompromittieren. Unseres Wissens handelt es sich dabei meist um laterale Bewegungen innerhalb eines Netzwerks. Wir haben nicht viele Beispiele für Ransomware-Angriffe auf VMware-Installationen gesehen und gehen davon aus, dass es sich hierbei eher um eine Insider-Bedrohung handelt. Allerdings haben wir in unseren Protokollen noch einige andere Versuche festgestellt, diese Installationen zu infizieren. Zum Beispiel:

Die Entschlüsselung ergab:

Die Payload wurde entfernt, seit wir den Datenverkehr zum ersten Mal gesehen haben. URLhaus identifiziert sie jedoch als eine Art der Mirai DDoS Botnet Malware. Eine andere Version dieses bösartigen Downloads ist immer noch aktiv und wird in ähnlicher Weise auf VMware-Installationen verübt.

DDoS-Malware

In unserem letzten Beispiel betrachten wir eine andere Art von DDoS-Malware:

Die Entschlüsselung ergibt:

Hierbei handelt es sich um eine Variante der BillGates-Malware. Diese Malware wurde um 2016 entwickelt und zielte ursprünglich nur auf Linux-Systeme ab. Dieses Beispiel ist seit einiger Zeit offline.

Neben diesen Payloads haben wir auch viele andere Versuche gesehen — eine Menge Kinsing, XMRig und Varianten von Mirai und Mushtik waren in den Protokollen zu finden —, basierend auf der Analyse der Base64-kodierten Befehle, die in die JNDI-Verbindungszeichenfolgen eingebettet waren, und der Annahme, dass die LDAP-Server, mit denen eine Verbindung hergestellt wurde, bösartige Klassen-Payloads zurücksenden, die diese Base64-kodierten Befehle implementieren. Die häufigste Payload war Mirai in verschiedenen Formen und aus unterschiedlichen Quellen. Die Verbreitung der DDoS-Botnet-Malware scheint darauf hinzudeuten, dass die Bedrohungsakteure darauf hinarbeiten, ein großes Botnet zur zukünftigen Verwendung aufzubauen, und dass in naher Zukunft mit großen DDoS-Angriffen zu rechnen ist.

So schützen Sie sich vor dieser Art von Payloads

Der beste Weg, sich speziell gegen Log4Shell zu schützen, ist ein Upgrade auf die neueste Version von Log4j. Aktuelle Software und Bibliotheken zu verwenden, trägt dazu bei, dass Schwachstellen zeitnah gepatcht werden.

Aufgrund der wachsenden Anzahl von Schwachstellen in Web-Applikationen wird es immer aufwändiger, sich vor Angriffen zu schützen. Inzwischen gibt es jedoch Komplettlösungen, die Ihre Web-Applikationen davor schützen, dass diese Schwachstellen ausgenutzt werden. WAF/WAF-as-a-Service-Lösungen, auch bekannt als WAAP-Services (Web Application and API-Protection), können zum Schutz Ihrer Web-Applikationen beitragen, indem sie alle aktuellen Sicherheitslösungen in einem einfach zu bedienenden Produkt bereitstellen.

Bericht: Application Security 2021 - Ein Überblick