Guida di laboratorio passo-passo per sfruttare CVE-2017-10271 (RCE deserializzazione WebLogic XMLDecoder) con costruzione manuale del payload, bypass RCE cieco e tecniche post-exploitation inclusa la verifica dei privilegi e l'esfiltrazione dei dati.
AdminServer appartenente a base_domain in esecuzione in Development Mode).7001.http, t3, iiop, ldap, snmp.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).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:
/uddiexplorer:
/wls-wsat:
⇒ 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.
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.
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>"
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.