Schritt-für-Schritt-Laboranleitung zur Ausnutzung von CVE-2017-10271 (WebLogic XMLDecoder Deserialisierung RCE) mit manueller Payload-Konstruktion, Blind-RCE-Umgehung und Post-Exploitation-Techniken einschließlich Privilegienüberprüfung und Datenerxfilterung.
AdminServer zu base_domain gehörig, läuft im Entwicklungsmodus).7001.http, t3, iiop, ldap, snmp.t3-Protokoll auf Port 7001 bereit. Diese Standardkonfiguration birgt ein hohes Risiko, wenn die WebLogic-Version nicht gegen Schwachstellen im Zusammenhang mit der Java-Objekt-Deserialisierung über RMI (Remote Method Invocation) gepatcht ist.http-Protokoll auf Port 7001, was sie anfällig für ein Verzeichnisscanning nach sensiblen Endpunkten wie /console/login/LoginForm.jsp macht.Sobald die offenen Ports des Ziels identifiziert sind, verwenden wir nmap, um den Port zu scannen und den darauf laufenden Dienst zu bestimmen.
Das Ziel bietet also einen HTTP-Dienst mit der Version Oracle WebLogic Server 10.3.6.0 – ein bekannter Java-Enterprise-Anwendungsserver, der für eine Reihe kritischer CVEs (wie Deserialisierung, Auth Bypass) berüchtigt ist. Diese Information allein reicht jedoch nicht aus, um zu schlussfolgern, für welche spezifische Schwachstelle das System anfällig ist. Wir müssen tiefer scannen und die begleitenden Webdienstkomponenten untersuchen.
Als Nächstes identifizieren wir seine sensiblen Endpunkte mit dem Tool dirsearch. Da WebLogic auf der Java-Plattform läuft, sind .jsp- und .xml-Dateien die sensibelsten Ziele. Wir konzentrieren uns auf Endpunkte, die einen 200-Statuscode zurückgeben.
dirsearch -u http://192.168.3.137:7001/ -e jsp,xml,html
/console/login/LoginForm.jsp: Das Anmeldeportal für die WebLogic Admin Console-Weboberfläche. Dies ist ein wichtiges Ziel für Brute-Force-Angriffe auf Standard-Anmeldedaten oder Authentifizierungsumgehungs-Schwachstellen (wie CVE-2020-14882)./bea_wls_internal/: Das standardmäßige interne Webanwendungsverzeichnis von WebLogic Server. Diese Komponente ermöglicht den Zugriff auf und die Interaktion mit statischen Systemdateien./wls-wsat/CoordinatorPortType: Dies ist die kritischste Entdeckung. Das Vorhandensein dieses Pfades mit einem 200 OK-Statuscode bestätigt, dass die Komponente Web Services Atomic Transactions (wls-wsat) aktiviert und bereit ist, Daten zu empfangen./uddiexplorer und /uddi/uddilistener: Dies ist die UDDI Explorer-Komponente (Universal Description, Discovery, and Integration), die standardmäßig in WebLogic Server integriert ist, um Webdienste zu verwalten und zu registrieren. Diese Komponente ist äußerst bekannt für die SSRF (Server-Side Request Forgery) - CVE-2014-4210-Schwachstelle. Ein Angreifer kann die öffentliche Registrierungssuche-Schnittstelle von UDDI am Endpunkt /uddiexplorer/SearchPublicRegistries.jsp ausnutzen, um den WebLogic-Server zu zwingen, beliebige HTTP-Anfragen an das interne Netzwerk im Backend zu senden.⇒ Überlegung: Das gleichzeitige Vorhandensein von /wls-wsat (RCE-Risiko via XMLDecoder) und /uddiexplorer (SSRF-Risiko) deutet darauf hin, dass die Angriffsfläche dieses WebLogic-Servers extrem breit ist.
Nachdem zwei unabhängige Angriffsflächen auf dem WebLogic 10.3.6.0-Server identifiziert wurden, analysieren wir die zwei Richtungen:
/uddiexplorer:
/wls-wsat:
⇒ Entscheidung: Im Modell der Cyber-Angriffskette ist RCE immer das ultimative Ziel, da es eine direkte und vollständige Kontrolle über das System (Full System Compromise) ermöglicht. Sobald die RCE-Fähigkeit erreicht ist, wird die Ausnutzung von SSRF über die UDDI-Anwendung überflüssig. Denn von einer RCE-Shell aus können wir aktiv interne Netzwerkanfragen auf direkte, flexible und leistungsfähigere Weise stellen (mit Systembefehlen wie curl, wget), ohne durch die Parameter der UDDI-Schnittstelle eingeschränkt zu sein.
Daher entscheiden wir uns in der Logik der Exploit-Priorisierung dafür, den sekundären Pfad (SSRF bei /uddiexplorer) auszuschließen und uns vollständig auf die Erforschung der: Remote Code Execution (RCE) via der XMLDecoder-Deserialisierungsschwachstelle bei /wls-wsat/CoordinatorPortType zu konzentrieren.
Die zugrunde liegende Schwachstelle von CVE-2017-10271 tritt auf, weil die WebLogic-Klasse WorkContextXmlInputAdapter das Objekt java.beans.XMLDecoder verwendet, um Daten im Tag <work:WorkContext> zu parsen. Standardmäßig instanziiert diese XMLDecoder-Klasse automatisch jede im XML-Tag-Format definierte Java-Klasse. Von hier aus führen wir eine Überprüfung basierend auf schrittweisen systemischen Verhaltensinteraktionen durch.
Um den tatsächlichen aktiven Status dieses Servlets schnell zu überprüfen, senden Sie eine normale HTTP-GET-Sondenanfrage:
curl -i -s http://192.168.3.137:7001/wls-wsat/CoordinatorPortType
Die Antwort gibt HTTP/1.1 200 OK zusammen mit der Implementierungsklasse CoordinatorPortTypePortImpl zurück, was bestätigt, dass das Servlet erfolgreich in den JVM-Speicher geladen wurde.
Da Webdienst-Servlets dafür ausgelegt sind, SOAP-XML-Daten über die POST-Methode zu verarbeiten, führen wir vergleichende Tests mit zwei POST-Anfragen durch, um die Datenverarbeitungspipeline des Systems zu demonstrieren:
1. Standard-SOAP-POST-Anfrage
Wir senden einen Standard-SOAP-XML-Envelope (mit vollständigen Namensräumen, aber ohne Ausführungsinhalt), um die normale Parsing-Fähigkeit des Parsers zu testen.
curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" \
-d "<soapenv:Envelope xmlns:soapenv='http://schemas.xmlsoap.org/soap/envelope/'>soapenv:Header/soapenv:Body/</soapenv:Envelope>"
Cannot find dispatch method).Analyse:
Der Server verfügt über einen gut funktionierenden XML-Reader am POST-Port, der bereit ist, die gesamte vom Benutzer gesendete XML-Baumstruktur zu empfangen und zu dekodieren. Dies bestätigt, dass die Datenpipeline vom Client tief in den Speicher von WebLogic hinein vollständig betriebsbereit ist.
2. Fehlerhafte XML-POST-Anfrage
Als Nächstes brechen wir absichtlich die XML-Struktur (z. B. fehlende Namensräume), um den Ausnahmebehandlungsmechanismus des Parsers zu beobachten.