Guide de laboratoire étape par étape pour exploiter CVE-2017-10271 (RCE par désérialisation XMLDecoder de WebLogic) avec construction manuelle de charge utile, bypass aveugle de RCE et techniques de post-exploitation incluant la vérification des privilèges et l'exfiltration de données.
dungsocool/cve-2017-10271
AdminServer appartenant à base_domain s'exécutant en mode développement).7001.http, t3, iiop, ldap, snmp.t3 sur le port 7001. Cette configuration par défaut présente un risque élevé si la version de WebLogic n'est pas corrigée contre les vulnérabilités liées à la désérialisation d'objets Java via RMI (Remote Method Invocation).http sur le port 7001, ce qui la rend sensible au scan de répertoires pour les points d'accès sensibles tels que /console/login/LoginForm.jsp.Une fois les ports ouverts de la cible identifiés, nous utiliserons nmap pour scanner le port afin de déterminer son service en cours.
Ainsi, la cible exécute un service HTTP avec la version Oracle WebLogic Server 10.3.6.0 - un serveur d'applications Java d'entreprise bien connu, célèbre pour une série de CVE critiques (telles que désérialisation, contournement d'authentification). Cependant, cette information seule ne suffit pas pour conclure à quelle vulnérabilité spécifique le système est vulnérable. Nous devons scanner plus profondément les composants du service web associés.
Nous allons procéder à identifier ses points d'accès sensibles à l'aide de l'outil dirsearch. Comme WebLogic fonctionne sur la plateforme Java, les fichiers .jsp et .xml sont les cibles les plus sensibles. Nous nous concentrerons sur les points d'accès renvoyant un code d'état 200.
dirsearch -u http://192.168.3.137:7001/ -e jsp,xml,html
/console/login/LoginForm.jsp : Le portail de connexion pour l'interface web de la console d'administration WebLogic. C'est une cible importante pour les scénarios de force brute d'identifiants par défaut ou les vulnérabilités de contournement d'authentification (comme CVE-2020-14882)./bea_wls_internal/ : Le répertoire d'application web interne par défaut de WebLogic Server. Ce composant permet d'accéder aux fichiers système statiques et d'interagir avec eux./wls-wsat/CoordinatorPortType : C'est la découverte la plus critique. La présence de ce chemin avec un code d'état 200 OK confirme que le composant Web Services Atomic Transactions (wls-wsat) est activé et prêt à recevoir des données./uddiexplorer et /uddi/uddilistener : Il s'agit du composant UDDI Explorer (Universal Description, Discovery, and Integration) intégré par défaut dans WebLogic Server pour la gestion et l'enregistrement des services web. Ce composant est extrêmement célèbre pour la vulnérabilité SSRF (Server-Side Request Forgery) - CVE-2014-4210. Un attaquant peut exploiter l'interface de recherche de registres publics d'UDDI au point d'accès /uddiexplorer/SearchPublicRegistries.jsp pour forcer le serveur WebLogic à envoyer des requêtes HTTP arbitraires vers le réseau interne backend.⇒ Réflexion : La coexistence de /wls-wsat (risque d'exécution de code à distance via XMLDecoder) et /uddiexplorer (risque SSRF) indique que la surface d'attaque de ce serveur WebLogic est extrêmement large.
Après avoir identifié deux surfaces d'attaque indépendantes coexistantes sur le serveur WebLogic 10.3.6.0, nous analysons les deux directions :
/uddiexplorer :
/wls-wsat :
⇒ Décision : Dans le modèle de la chaîne d'attaque cybernétique, l'exécution de code à distance (RCE) est toujours l'objectif ultime car elle fournit un contrôle direct et complet du système (compromission totale du système). Une fois la capacité d'exécution de code à distance acquise, l'exploitation de la SSRF via l'application UDDI devient redondante. En effet, à partir d'un shell RCE, nous pouvons effectuer activement des requêtes sur le réseau interne de manière directe, flexible et plus puissante (en utilisant des commandes système comme curl, wget) sans être restreints par les paramètres de l'interface UDDI.
Par conséquent, en termes de logique de priorisation de l'exploitation, nous décidons d'exclure la voie secondaire (SSRF au niveau de /uddiexplorer) et de nous concentrer entièrement sur la recherche : l'exécution de code à distance (RCE) via la vulnérabilité de désérialisation XMLDecoder au niveau de /wls-wsat/CoordinatorPortType.
La vulnérabilité racine de CVE-2017-10271 se produit car la classe WorkContextXmlInputAdapter de WebLogic utilise l'objet java.beans.XMLDecoder pour analyser les données dans la balise <work:WorkContext>. Par défaut, cette classe XMLDecoder instancie automatiquement toute classe Java définie sous forme de balise XML. À partir de là, nous effectuons la vérification basée sur une interaction comportementale système étape par étape.
Pour vérifier rapidement l'état actif réel de ce servlet, envoyez une requête de sonde HTTP GET standard :
curl -i -s http://192.168.3.137:7001/wls-wsat/CoordinatorPortType
La réponse renvoie HTTP/1.1 200 OK ainsi que la classe d'implémentation CoordinatorPortTypePortImpl, confirmant que le servlet a été chargé avec succès dans la mémoire JVM.
Étant donné que les servlets de services web sont conçus pour traiter les données SOAP XML via la méthode POST, nous procédons à des tests comparatifs avec deux requêtes POST pour démontrer le pipeline de traitement des données du système :
1. Requête POST SOAP standard
Nous envoyons une enveloppe SOAP XML standard (avec des espaces de noms complets mais sans contenu d'exécution) pour tester la capacité d'analyse normale de l'analyseur.
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 :
Le serveur possède un lecteur XML fonctionnel sur le port POST, prêt à recevoir et décoder toute la structure d'arbre XML envoyée par l'utilisateur. Cela confirme que le pipeline de données allant du client jusqu'à la mémoire de WebLogic est entièrement opérationnel.