dungsocool/cve-2017-11610شرح تفصيلي خطوة بخطوة لاستغلال الثغرة CVE-2017-11610 (Supervisord XML-RPC RCE) مع تحليل سطح الهجوم، اكتشاف اجتياز مساحة الأسماء، وتقنيات ما بعد الاستغلال في بيئة مختبر Docker.
البدء بما يعمل في البيئة. أقوم بإدراج جميع الحاويات النشطة:``` docker ps-a
**الضحية يعرض منفذًا واحدًا: `9001`**.
المنفذ 9001 ليس تطبيق ويب قياسي. البحث في **قاعدة بيانات المنافذ** يظهر أن هذا المنفذ قد يكون مرتبطًا بـ **Supervisord** (مدير خدمة ETL وفقًا لـ IANA)، أو وكيل Tor، أو بعض الخدمات الداخلية الأخرى. ومع ذلك، لا يمكننا استخلاص استنتاج بناءً على رقم المنفذ فقط.
⇒ أستخدم الأمر curl مباشرة لقراءة الاستجابة وكذلك الوصول إلى واجهة المستخدم الرسومية لجمع المزيد من المعلومات.```
curl -i http://192.168.3.137:9001/
تحليل الاستجابة:
Server: Medusa/1.12 والعنوان Supervisor Status→ تم التأكيد على أن هذا هو Supervisord، وليس Tor أو أي خدمة أخرى.
REFRESH، RESTART ALL، STOP ALLSupervisord هو مدير عمليات على Linux. إذا كان المنفذ 9001 مكشوفًا على الشبكة بدون كلمة مرور، فهذا تكوين خطير. يمكن للمهاجم عرض الخدمات، إعادة تشغيل/إيقاف العمليات، وتحت تكوينات معينة، استغلاله لتنفيذ أوامر إذا كان لديه صلاحيات لتعديل أو التحكم في البرامج المُدارة.
خلاصة التحليل: يمكننا التأكيد على أن الهدف يعرض واجهة إدارة Supervisord على الشبكة على المنفذ 9001. هذه ليست خدمة ويب قياسية، بل واجهة إدارة تُستخدم لمراقبة العمليات والتحكم بها. القدرة على الوصول إلى هذه الواجهة بدون مصادقة تُشكّل خطرًا يتمثل في تمكن المهاجم من عرض حالة الخدمات المُدارة أو التفاعل معها.
ومع ذلك، يجب أن نفرق بين واجهة المستخدم المرئية وآلية التحكم الأساسية. الأزرار مثل REFRESH و RESTART ALL و STOP ALL لا تعالج الطلبات بشكل مستقل على الواجهة الأمامية؛ بل يجب أن تستدعي واجهة/خلفية Supervisord لاسترداد الحالة أو إرسال أوامر التحكم في العمليات. لذلك، بعد التأكيد على كشف واجهة الويب، الخطوة التالية في التحليل هي تحديد ما إذا كانت واجهة التحكم الأساسية موجودة خلف واجهة الويب وما إذا كانت تتطلب مصادقة.
⇒ تفكير: نحتاج للتحقق مما إذا كانت واجهة التحكم خلف واجهة الويب موجودة وما إذا كانت تتطلب مصادقة.
وفقًا لوثائق Supervisor، [inet_http_server] هو خادم HTTP يستمع على مقبس TCP. هذه الواجهة غير مفعلة افتراضيًا، ويجب استخدامها فقط في البيئات الموثوقة، ولا تدعم التشفير، ولا توجد مصادقة افتراضية ما لم يتم تكوين username/password.
كما تشير الوثائق إلى أن منفذ [inet_http_server] يُستخدم لاستقبال طلبات HTTP/XML-RPC؛ يستخدم supervisorctl XML-RPC للتواصل مع supervisord عبر هذا المنفذ. هذا يتوافق مع ملاحظتنا في المختبر: الحاوية تعرض 0.0.0.0:9001->9001/tcp، واجهة الويب متاحة بدون مصادقة، والإصدار المعروض هو Supervisor 3.3.2.
وبالتالي، بعد التأكيد على وجود واجهة الويب على المنفذ 9001، الخطوة التالية هي فحص نقطة نهاية XML-RPC /RPC2. بناءً على الآلية الرسمية لـ Supervisord، نحتاج للتحقق من هذه الأهداف:
/RPC2 موجودًا.supervisor.getState أو system.listMethods.تحقق مما إذا كانت نقطة النهاية حية:```
curl -i -s -X POST -H "Content-Type: text/xml"
-d 'supervisor.getState'
http://192.168.3.137:9001/RPC2
النتيجة تعيد `HTTP/1.1 200 OK`، وليس `401 Unauthorized` أو `403 Forbidden`، مما يُظهر أن الطلب تم قبوله من قبل الخادم بدون بيانات اعتماد. الاستجابة تكون بتنسيق XML-RPC `<methodResponse>` وتحتوي على `statename=RUNNING` و `statecode=1`، مما يثبت أن نقطة النهاية `/RPC2` نشطة وأن أسلوب `supervisor.getState` تم تنفيذه بنجاح.
**⇒ التفكير:** لم يعد سطح الهجوم مقتصرًا على واجهة الويب فحسب، بل توسع ليشمل واجهة برمجة تطبيقات XML-RPC، حيث يتم التعامل مع أوامر التحكم في البرنامج الخفي/العمليات. من هنا، يكون اتجاه التحليل التالي هو **التحقق من كيفية تعامل Supervisor** مع `methodName` في **XML-RPC**، لتحديد ما إذا كان الهدف الحالي **يظهر سلوك CVE-2017-11610**، الذي يكمن في آلية الإرسال/البحث لهذا الأسلوب. نحتاج إلى التحقق من ذلك لنستنتج ما إذا كان هو **CVE-2017-11610**.
### **تحليل معالجة اسم الأسلوب في XML-RPC**
في الخطوة السابقة، قمنا بنجاح باستدعاء أسلوب `supervisor.getState` عبر نقطة النهاية `/RPC2`. وهذا يثير السؤال التالي: عند استلام `methodName` مبني على سلسلة نصية، كيف يقوم Supervisord بتعيين هذه السلسلة إلى وظيفة بايثون الداخلية؟
في XML-RPC، تستخدم الأساليب عادةً مساحات الأسماء، على سبيل المثال:
- `supervisor.getState`
- `supervisor.stopProcess`
- `supervisor.getAllProcessInfo`
من الناحية المنطقية، يتلقى الخادم سلسلة `methodName`، ويقسمها بناءً على النقطة `.`، ويبحث عن الكائن/الوظيفة المقابلة داخل المعالج المسجل.
يمكن فهم الكود الزائف على النحو التالي:```python
# Pseudo-code simulating the dispatch method concept in XML-RPC
def dispatch(method_name, params):
parts = method_name.split(".") # ["supervisor", "getState"]
obj = registered_handlers[parts[0]] # get namespace "supervisor"
for attr in parts[1:]:
obj = getattr(obj, attr) # lookup the next attribute
return obj(*params) # call the final function
بالنسبة للطرق القياسية مثل supervisor.getState، تعمل هذه الآلية بشكل طبيعي: يسترد الخادم معالج supervisor، ثم يستدعي الدالة getState. ومع ذلك، فإن المشكلة الأساسية لـ CVE-2017-11610 هي أن آلية البحث هذه لا تقيد بشكل كافٍ السمات المسموح بالوصول إليها. إذا تحكم المهاجم في methodName، يمكنه ليس فقط استدعاء الطرق العامة مثل getState، بل أيضًا التنقل أعمق داخل الكائنات/الوحدات القابلة للوصول من معالج supervisor.
بعبارة أخرى، النقطة . في methodName لا تُستخدم فقط لاستدعاء الطرق الصالحة، بل يمكن إساءة استخدامها للتنقل عبر سمات الكائن.
وهذا يؤسس لمسار الاستغلال لدينا:
supervisor → supervisord → options → warnings → linecache → os → system
الفكرة هي البدء من معالج supervisor، واتباع السمات إلى الكائنات الداخلية للخفي، ثم استغلال وحدات Python المستوردة مسبقًا للوصول إلى os.system. إذا كان يمكن استدعاء os.system، يمكن للمهاجم تنفيذ أوامر النظام بصلاحيات عملية supervisord.
وبالتالي، فإن سلسلة الهجوم تتبع هذا المنطق:
/RPC2 يقبل استدعاءات الطرق غير المصادق عليها → فحص كيفية توزيع XML-RPC لـ methodName → اكتشاف أن methodName يمكنه التنقل عبر سمات الكائن → يؤدي إلى استدعاء os.system.
أولاً، أحتاج إلى التحقق مما إذا كان الخادم يسمح بالفعل بالتنقل عبر السمات الداخلية. سأحاول استدعاء اسم طريقة أطول من المعتاد. إذا أعاد الخادم خطأ "method not found"، فهذا يعني وجود عامل تصفية؛ إذا أعاد خطأ مختلفًا (أو نجح)، فإن التنقل يعمل.
التفكير: أعرف بالفعل أن supervisor.getState يعمل. إذا جربت supervisor.supervisord—الذي يذهب إلى طبقة أعمق—ولم يُرجع الخادم خطأ unknown method، فهذا يعني أنه يستخدم بالفعل getattr التكراري بدون قائمة بيضاء.