dungsocool/cve-2017-18349Schritt-für-Schritt-Anleitung zur Ausnutzung der Fastjson-Deserialisierungs-RCE (CVE-2017-18349), einschließlich Identifizierung der Angriffsfläche, Fingerprinting, JNDI-Injection und Erlangung einer Reverse Shell in einer Docker-Lab-Umgebung.
Beginnen wir mit dem, was in der Umgebung läuft. Ich liste alle aktiven Container auf:
docker ps
Das Opfer gibt nur einen einzigen Port frei: 8090
Derzeit ist mir das Ziel noch nicht vollständig klar. Aus den docker-ps-Ergebnissen geht hervor, dass das System extern nur einen nennenswerten Dienst auf Port 8090 veröffentlicht, der auf den internen Dienst des Containers abgebildet ist. Dies ist die Hauptangriffsfläche, die analysiert werden muss.
⇒ Ich führe direkt einen Curl-Befehl aus, um weitere Informationen zu sammeln
curl -i 192.168.3.137:8090/
Antwortanalyse:
Content-Type: application/json;charset=UTF-8.{"age": 25, "name": "Bob"}.⇒ Überlegung: Beim Zugriff auf Port 8090 gibt der Server JSON-Daten zurück. Dies deutet darauf hin, dass der Endpunkt nicht nur eine statische Webseite ausliefert, sondern über ein Backend verfügt, das Anfragen verarbeitet und Daten in JSON serialisiert, um sie an den Client zurückzugeben. Aus den docker-ps-Ergebnissen geht hervor, dass es sich bei dem im Container laufenden Befehl um eine Java-Anwendung handelt. Die nächste Untersuchungsrichtung ist daher das Fingerprinting gängiger JSON-Parser in Java.
In Java verhalten sich bekannte JSON-Bibliotheken wie Jackson, Gson und Fastjson bei ungewöhnlichen Eingaben unterschiedlich. Daher können wir die Technik des fehlerbasierten Fingerprintings (Error-based Fingerprinting) nutzen. Der zurückgegebene Fehler verrät manchmal direkt die Bibliothek oder den internen Verarbeitungsmechanismus. Unter ihnen ist Fastjson ein Ziel, das frühzeitig überprüft werden muss, da alte Versionen mehrere kritische Schwachstellen im Zusammenhang mit der AutoType-Deserialisierung aufwiesen.
Hier behaupte ich nicht sofort, dass das Backend Fastjson verwendet. Ich wähle Fastjson nur als erste Überprüfungsrichtung, weil es durch den @type-Schlüssel einen eindeutigen Fingerprint besitzt. Sollte es sich tatsächlich um eine alte Fastjson-Version handeln, reicht die Ausnutzbarkeit weit über einen standardmäßigen Parsing-Fehler hinaus und kann möglicherweise sogar bis zur RCE führen.
Fastjson hat eine für das Fingerprinting sehr nützliche Eigenschaft: Es erkennt den speziellen @type-Schlüssel. Wenn das Backend Fastjson verwendet und der in den Deserialisierungsprozess gesendete Anfragetext AutoType unterstützt, versucht der Parser möglicherweise, den @type-Wert als Java-Klassennamen zu interpretieren.
Daher sende ich einen Payload, der @type mit Verweis auf eine nicht existierende Klasse enthält. Das Ziel dieses Schritts ist nicht die sofortige Ausnutzung, sondern die Beobachtung, ob das Backend auf @type reagiert.
curl -i -X POST -H "Content-Type: application/json" \
-d '{"@type":"com.non.existent.Class"}' \
http://192.168.3.137:8090/
Wenn das Backend einen standardmäßigen JSON-Parser verwenden würde und @type ignorieren würde, könnte dieses Feld einfach ignoriert oder als normaler Schlüssel im JSON behandelt werden. Hier reagiert das Backend jedoch mit typbezogenem Verhalten (type not match), was bedeutet, dass die Anfrage in den Verarbeitungsablauf für Klassen-/Typ-Zuordnung gelangt ist.
Die Meldung „type not match“ ist eine charakteristische Signatur, die häufig auftritt, wenn Fastjson @type verarbeitet, die angegebene Klasse jedoch nicht dem vom Endpunkt erwarteten Datentyp entspricht oder die Klasse nicht existiert bzw. nicht deserialisiert werden darf.
⇒ Überlegung: Das Backend parst den JSON-Body der POST-Anfrage tatsächlich, das @type-Feld wird nicht ignoriert, der Parser verfügt über einen Mechanismus zur Verarbeitung von Typmetadaten, und der zurückgegebene Fehler entspricht dem Verhalten von Alibaba Fastjson. Daher können wir mit hoher Zuversicht schlussfolgern, dass das Backend Alibaba Fastjson verwendet.**
Nach dem Fingerprinting-Schritt kann ich nicht sofort schlussfolgern, dass das System ausnutzbar ist. Dass das Backend Fastjson verwendet, beweist nur, dass die JSON-Anfrage in den @type-Verarbeitungsablauf gelangt.
Um einen RCE-Exploit auszuführen, müssen die folgenden Punkte überprüft werden:
⇒ Überlegung: Der Fehler „type not match“ zeigt, dass das Backend auf @type reagiert, aber der aktuelle Payload verwendet nur eine Fake-Klasse, um einen Fehler auszulösen. Für die tatsächliche Ausnutzung müssen wir diese Fake-Klasse durch eine echte, in Java/JDK vorhandene Klasse ersetzen, die in der Lage ist, ausgehende Verhaltensweisen wie einen JNDI-Lookup zu erzeugen.
Um die Version zu bestimmen, prüfe ich direkt im Container/in der Anwendung.
Nachdem ich festgestellt habe, dass die Anwendung als Datei /usr/src/fastjsondemo.jar verpackt ist, analysiere ich die Paketstruktur eingehend, um nach der JSON-Verarbeitungsbibliothek zu suchen. Die Prüfung der Verzeichnisstruktur BOOT-INF/lib/ zeigt die Datei fastjson-1.2.24.jar (Abbildung X).
Die Verwendung von genau Version 1.2.24 – der ersten und bekanntesten Version, die von der Deserialisierungsschwachstelle ohne jegliche AutoType-Verteidigungsmechanismen betroffen ist – erlaubt uns zu bestätigen, dass das System anfällig für CVE-2017-18349 ist.
Das Auffinden von fastjson-1.2.24.jar bestätigt, dass die Anwendung eine sehr alte Version von Fastjson verwendet, die zu der von der AutoType-Deserialisierungsschwachstelle betroffenen Gruppe gehört. In dieser Version wurde der Kontrollmechanismus über AutoType nicht wie in späteren Versionen verschärft. Hinsichtlich der Bibliotheksbedingungen ist das System daher anfällig für die Ausnutzung durch Gadget-Klassen wie JdbcRowSetImpl.
Die tatsächliche Ausnutzbarkeit hängt jedoch weiterhin davon ab, wie der Endpunkt Fastjson aufruft. Wenn die Anwendung JSON in eine feste Klasse parst, kann das Setzen des @type-Payloads auf der Root-Ebene zum Fehler „type not match“ führen. Daher müssen wir nach der Identifizierung der Version die JVM, die Gadget-Klasse und das LDAP-Callback-Verhalten weiter analysieren, um zu bestätigen, ob die Exploit-Kette tatsächlich den JNDI-Lookup erreicht.
1. Analyse der JVM-Barrieren
Neben der Fastjson-Version ist auch die Java-Version ein entscheidender Faktor. Ich prüfe die JVM im Container:
java -version
Dies sind kritische Informationen, da Fastjson-Exploit-Ketten typischerweise auf JNDI-Injection basieren. Neuere Java-Versionen blockieren standardmäßig das Laden von Klassen aus externen Codebases über LDAP/RMI. Java 8u102 ist jedoch eine alte Version, die diese Blockierungsmechanismen noch nicht besitzt.