CVE-2026-20230 Cisco Unified Communications Manager SSRF ثغرة كتابة ملف عشوائي إلى RCE عملية اشتقاق PoC والتفكير

نطاق التطبيق: يُستخدم فقط في بيئات الاختبار المحلية، وبيئات إعادة الإنتاج المصرح بها، والتحقق من الثغرات وتحليل قواعد الحماية. لا تستخدمه على أهداف غير مصرح بها. تحلل هذه المقالة بشكل أساسي سلسلة استغلال CVE-2026-20230، والظواهر القابلة للتحقق، ومنطق الحكم، وأفكار الحماية، ولا تقدم رسائل هجوم قابلة للتنفيذ مباشرة، أو محتوى WebShell، أو حمولات تنفيذ الأوامر.

1. خلفية الثغرة

CVE-2026-20230 هي ثغرة تزوير طلب من جانب الخادم (SSRF) في Cisco Unified Communications Manager (Unified CM / CUCM) و Cisco Unified Communications Manager Session Management Edition (Unified CM SME). تنبع هذه الثغرة من عدم كفاية التحقق من المدخلات في عملية معالجة طلبات HTTP معينة، حيث يمكن للمهاجم إنشاء طلبات دون مصادقة، مما يجعل الجهاز المتأثر يصل إلى واجهات داخلية أو موارد محلية نيابة عن المهاجم.

لا يقتصر تأثير هذه الثغرة على مجرد استكشاف SSRF العادي. تُظهر التحليلات الفنية المنشورة أنه في ظل ظروف محددة للإصدار والخدمات النشطة، يمكن ربط SSRF بقدرة كتابة ملف عشوائي. يمكن للمهاجم كتابة محتوى يمكن التحكم فيه إلى مسارات نظام التشغيل الأساسية، ثم باستخدام أدلة يمكن الوصول إليها بواسطة حاوية الويب أو آلية تحميل مكونات جانب الخادم، تحويل كتابة الملفات إلى تنفيذ كود.

منح Cisco لهذه الثغرة درجة CVSS v3.1 تبلغ 8.6، مع متجه:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N

على الرغم من أن درجة CVSS تظهر كـ "High"، إلا أن Cisco صنفت تأثير الأمان لهذه الثغرة على أنه "Critical". والسبب هو أنه بعد الاستغلال الناجح يمكن كتابة ملفات نظام التشغيل الأساسية، وقد يتم رفعها إلى صلاحيات الجذر.

من المهم ملاحظة أن الشرط المسبق الحاسم لهذه الثغرة هو أن خدمة WebDialer يجب أن تكون مفعلة. WebDialer معطل افتراضيًا، لذلك لا يمكن الحكم على وجود الثغرة بمجرد رؤية أصول CUCM. يتطلب الحكم الحقيقي على المخاطر تأكيد إصدار المنتج، وحالة التصحيح، وحالة خدمة WebDialer، وما إذا كانت الواجهات ذات الصلة يمكن الوصول إليها في نفس الوقت.

2. لماذا لا يكفي مجرد رؤية ما إذا كانت واجهة ما تعيد 200؟

هذه الثغرة ليست ثغرة ويب عادية من نوع "قم بزيارة عنوان URL ثابت واحصل على 200". سلسلة استغلالها تتضمن ثلاثة مستويات على الأقل:

1. واجهات خارجية يمكن الوصول إليها مرتبطة بـ WebDialer أو cmplatform.
2. منطق الوصول الداخلي الذي يمكن أن يتأثر بـ SSRF.
3. سلوك كتابة ملف أو نشر خدمة يمكن تشغيله بواسطة الطلبات الداخلية.

لذلك، مجرد زيارة واجهة معينة والحصول على HTTP 200، 302، 401، 404 أو 500 لا يمكن أن يثبت بشكل مباشر وجود الثغرة أو عدم وجودها.

على سبيل المثال، الوصول إلى واجهة WebDialer WSDL يشير فقط إلى أن الهدف يعرض وظائف WebDialer ذات الصلة، ولا يمكن أن يثبت أن SSRF اللاحق سيكون قادرًا على تجاوز التصفية. الوصول إلى واجهة installClusterStatusExecute يشير فقط إلى وجود مدخل إدخال ذي صلة، ولا يمكن أن يثبت بمفرده أن كتابة الملف العشوائي قد تمت. على العكس من ذلك، إذا أعادت إحدى الخطوات استثناءً، فقد يكون ذلك بسبب إصدار الهدف، أو التصحيحات، أو تحليل اسم المضيف، أو أذونات المسار، أو أجهزة الوكيل، أو حالة الخدمة، ولا يعني بالضرورة أن سلسلة الثغرة غير موجودة بالكامل.

الحكم الأكثر سلامة يجب أن يستخدم مزيجًا من الأدلة متعددة المراحل:

1. تأكيد أن الهدف هو Cisco Unified CM / Unified CM SME.
2. تأكيد أن خدمة WebDialer مفعلة.
3. تأكيد القدرة على الحصول على اسم المضيف الحقيقي للهدف أو معرف الخدمة الداخلي.
4. تأكيد أن مدخل SSRF يمكن الوصول إليه، وأن هناك علامات على قيام الخادم بتقديم طلبات داخلية.
5. في بيئات الاختبار المصرح بها، تأكيد ما إذا كان يمكن إنتاج دليل على كتابة ملفات يمكن التحكم فيها.
6. الجمع بين سجلات جانب الخادم، وتغييرات نظام الملفات، وسجلات حاوية الويب، وبيانات التنبيه لتحديد ما إذا كان قد تم تشغيل الثغرة حقًا.

فقط عندما تحدث "WebDialer مفعلة + إصدار متأثر + سلوك SSRF قائم + كتابة ملف يمكن التحكم فيه قائمة" في نفس الوقت، يجب الحكم عليها على أنها ثغرة قابلة للاستغلال بثقة عالية.

3. فكرة بناء PoC

جوهر سلسلة الاستغلال العامة الحالية ليس مجرد SSRF، بل هو مزيج من SSRF مع آليات خدمة Axis/Java Web، أو كتابة السجلات، أو منطق معالجة ملفات وصف النشر.

يمكن تلخيص الفكرة العامة على النحو التالي:

الحصول على معلومات WebDialer
    ↓
الحصول على اسم المضيف الحقيقي للهدف
    ↓
تشغيل SSRF عبر الواجهات ذات الصلة بـ cmplatform
    ↓
الوصول إلى مسار إدارة WebDialer / Axis الداخلي
    ↓
كتابة أو نشر محتوى وصف خدمة يمكن التحكم فيه
    ↓
إنشاء خدمة جديدة قابلة للاستدعاء أو قدرة كتابة ملف
    ↓
تحويل قدرة كتابة الملف إلى برنامج نصي يمكن الوصول إليه عبر الويب
    ↓
في بيئة معينة، تحقيق تنفيذ الأوامر

من منظور تصميم السلسلة، اسم المضيف هو نقطة رئيسية. بعض منطق التصفية قد يعترض 127.0.0.1 و localhost وعناوين محلية شائعة أخرى، ولكن قد يُسمح لاسم المضيف الحقيقي للهدف بالدخول إلى عملية الطلب اللاحقة. لذلك، سيبدأ PoC باستخراج اسم المضيف الحقيقي من معلومات WSDL الخاصة بـ WebDialer، ثم استخدامه كبادئة للوصول الداخلي في سلسلة SSRF.

النقطة الرئيسية الثانية هي المنطق المتعلق بخدمة Axis. لا يقوم PoC بتحميل الملفات مباشرة إلى دليل الويب، بل من خلال سلسلة معالجة الخدمة الداخلية، يجعل مكون جانب الخادم يكتب محتوى يمكن للمهاجم التحكم فيه إلى مسار محدد. هذه العملية هي في الأساس مزيج من "طلب داخلي من جانب الخادم + سلوك تكوين/كتابة سجل للمكون + تجاوز المسار/التحكم في المسار".

النقطة الرئيسية الثالثة هي الكتابة على مرحلتين. تُستخدم المرحلة الأولى عادةً لإنشاء مدخل كتابة ملف أكثر استقرارًا، وتقوم المرحلة الثانية بكتابة برنامج نصي لتنفيذ الأوامر إلى دليل يمكن الوصول إليه عبر الويب. السبب في ذلك هو أن كتابة منطق تنفيذ الأوامر الكامل مباشرة عبر SSRF في خطوة واحدة قد تتأثر بالتشفير، والطول، وهيكل XML، وأذونات المسار، وسلوك تحليل الخادم، بينما يسهل الأسلوب ذو المرحلتين تقسيم الحمولة المعقدة.

لا تقدم هذه المقالة رسائل استغلال كاملة ومحتوى WebShell. للحماية والتحقق، يكفي فهم الخصائص الأساسية التالية:

مدخل الطلب الخارجي: واجهات متعلقة بحالة تثبيت cmplatform
مدخل الحصول على المعلومات: واجهات WebDialer WSDL / services ذات الصلة
هدف التوجيه الداخلي: المسارات المتعلقة بـ WebDialer / Axis / AdminService
السلوكيات الرئيسية: SSRF، طلب داخلي من جانب الخادم، كتابة ملف يمكن التحكم فيه، وصول ملف إلى الويب
المخاطر النهائية: كتابة ملف عشوائي، وصول WebShell، تنفيذ الأوامر، مسار رفع صلاحية الجذر

4. منطق الحصول على اسم المضيف

يحتاج PoC أولاً إلى الحصول على اسم المضيف الحقيقي للهدف، بدلاً من استخدام عنوان IP فقط أو اسم المجال الخارجي.

والسبب هو أن منطق تصفية SSRF لا يحدد فقط الهدف النهائي للاتصال، بل قد يتحقق أيضًا من حقل اسم المضيف، وسلسلة URL، وكلمات المفاتيح للعناوين المحلية، وما إلى ذلك. قد يتم حظر العناوين المحلية الشائعة مثل 127.0.0.1 و localhost، بينما قد يتم اعتبار اسم المضيف الحقيقي للجهاز كاسم عقدة قانوني في بعض السيناريوهات.

الواجهات التي يمكن استخدامها للمساعدة في الحكم تتعلق عادةً بمعلومات WebDialer WSDL. بعد الوصول إلى هذا النوع من WSDL، قد يحتوي الرد على عنوان الخدمة، أو حقل الموقع، أو معرفات مضيف أخرى قابلة للتحليل. سيقوم PoC باستخراج اسم المضيف من عنوان URL في نص الرد واستخدامه كهدف الوصول الداخلي لمرحلة SSRF التالية.

يجب أن يكون معيار الحكم في هذه المرحلة:

1. هل واجهة WSDL يمكن الوصول إليها؟
2. هل محتوى الرد يتوافق مع خصائص خدمة WebDialer / Axis؟
3. هل يمكن استخراج اسم المضيف الحقيقي من الرد؟
4. هل يختلف اسم المضيف المستخرج عن عنوان IP الخارجي أو اسم المجال؟
5. هل يمكن قبول اسم المضيف هذا بواسطة مدخل SSRF اللاحق؟

إذا فشل تحليل اسم المضيف، قد يتراجع PoC إلى عنوان IP الهدف، لكن هذا سيقلل بشكل كبير من معدل النجاح. في البيئات الحقيقية، تشمل الأسباب الشائعة لفشل تحليل اسم المضيف: WebDialer غير مفعل، واجهات مقيدة بالتحكم في الوصول، الردود المعاد كتابتها بواسطة الوكيل العكسي، تكوين الشهادة أو الخدمة غير مكتمل.

5. مرحلة تشغيل SSRF

تقع نقطة تشغيل SSRF في منطق الاستعلام عن حالة تثبيت cmplatform ذي الصلة. كانت هذه الوظيفة في الأصل للاستعلام عن حالة تثبيت عقد الكتلة، حيث يقوم الخادم بتجميع طلب داخلي بناءً على معرف العقدة أو اسم المضيف الذي يقدمه المستخدم.

المشكلة الأساسية في الثغرة هي أن معلمة اسم المضيف التي يمكن للمهاجم التحكم فيها لم يتم تقييدها بشكل صارم لتكون اسم عقدة قانوني أو مضيف موثوق، مما يسمح بتكوين هذه المعلمة كمسار وصول داخلي أكثر تعقيدًا. ثم يقوم الخادم بتقديم طلبات إلى الواجهات الداخلية نيابة عن المهاجم.