
دليل مختبر خطوة بخطوة لاستغلال CVE-2017-10271 (إلغاء تسلسل XMLDecoder في WebLogic يؤدي إلى RCE) مع بناء حمولة يدوي، وتجاوز RCE الأعمى، وتقنيات ما بعد الاستغلال بما في ذلك التحقق من الامتيازات واستخراج البيانات.

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، نقوم بتحليل الاتجاهين:
/uddiexplorer:
/wls-wsat:
⇒ القرار: في نموذج سلسلة الهجوم السيبراني، تُعد 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.
بما أن Servlets خدمات الويب مصممة لمعالجة بيانات SOAP XML عبر طريقة POST، فإننا نجري اختبارًا مقارنًا باستخدام طلبي POST لعرض مسار معالجة البيانات في النظام:
1. طلب SOAP POST القياسي
نرسل مغلف SOAP XML قياسيًا (بمساحات أسماء كاملة ولكن بدون محتوى تنفيذي) لاختبار قدرة المحلّل على التحليل بشكل طبيعي.
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 (مثل حذف مساحات الأسماء) لملاحظة آلية معالجة الاستثناءات في المحلّل.
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".التحليل:
com.ctc.wstx) للتحليل.الجمع بين النتائج العملية للتجارب وتحليل بنية النظام — بدءًا من استقبال Servlet الخاص بـ wls-wsat للحزم الخام عبر منفذ POST، وغياب WAF/مرشح الفحص في طبقة المحلّل، وصولاً إلى إلقاء أخطاء Java XML Reader الخام مباشرةً — يؤكد أن الخادم يشغّل بنية خدمة شديدة الحساسية تقع مباشرةً ضمن نطاق CVE-2017-10271 (إلغاء تسلسل XMLDecoder).
ونظرًا لأن آلية التحليل الافتراضية لـ XMLDecoder لا تحتوي على أي مرشحات للتحكم في الفئات، فإن استلام الخادم لبيانات POST الخام دون تعقيم يُعد البوابة المثالية التي تسمح لنا بتصميم حمولات تستدعي كائنات تنفيذ نظام Java مباشرةً في الخطوة التالية.
نظرًا لأن خادم WebLogic 10.3.6.0 يعمل على بيئة Java قديمة ولا يطبّق مرشحات صارمة للتحكم في الفئات على XMLDecoder، يمكن للمهاجم حقن كائنات Java قابلة للتنفيذ مباشرةً.