w5m1n9/cisco-unified-communications-manager-server-side-forgery-request-vulnerability-cve-2026-20230يحلل CVE-2026-20230 SSRF إلى كتابة ملفات عشوائية و RCE في Cisco Unified Communications Manager، مما يوفر اشتقاق PoC ومنطق الكشف وإرشادات دفاعية.
نطاق التطبيق: يُستخدم فقط في بيئات الاختبار المحلية، وبيئات إعادة الإنتاج المصرح بها، والتحقق من الثغرات وتحليل قواعد الحماية. لا تستخدمه على أهداف غير مصرح بها. تحلل هذه المقالة بشكل أساسي سلسلة استغلال CVE-2026-20230، والظواهر القابلة للتحقق، ومنطق الحكم، وأفكار الحماية، ولا تقدم رسائل هجوم قابلة للتنفيذ مباشرة، أو محتوى WebShell، أو حمولات تنفيذ الأوامر.
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، وما إذا كانت الواجهات ذات الصلة يمكن الوصول إليها في نفس الوقت.
هذه الثغرة ليست ثغرة ويب عادية من نوع "قم بزيارة عنوان URL ثابت واحصل على 200". سلسلة استغلالها تتضمن ثلاثة مستويات على الأقل:
لذلك، مجرد زيارة واجهة معينة والحصول على HTTP 200، 302، 401، 404 أو 500 لا يمكن أن يثبت بشكل مباشر وجود الثغرة أو عدم وجودها.
على سبيل المثال، الوصول إلى واجهة WebDialer WSDL يشير فقط إلى أن الهدف يعرض وظائف WebDialer ذات الصلة، ولا يمكن أن يثبت أن SSRF اللاحق سيكون قادرًا على تجاوز التصفية. الوصول إلى واجهة installClusterStatusExecute يشير فقط إلى وجود مدخل إدخال ذي صلة، ولا يمكن أن يثبت بمفرده أن كتابة الملف العشوائي قد تمت. على العكس من ذلك، إذا أعادت إحدى الخطوات استثناءً، فقد يكون ذلك بسبب إصدار الهدف، أو التصحيحات، أو تحليل اسم المضيف، أو أذونات المسار، أو أجهزة الوكيل، أو حالة الخدمة، ولا يعني بالضرورة أن سلسلة الثغرة غير موجودة بالكامل.
الحكم الأكثر سلامة يجب أن يستخدم مزيجًا من الأدلة متعددة المراحل:
فقط عندما تحدث "WebDialer مفعلة + إصدار متأثر + سلوك SSRF قائم + كتابة ملف يمكن التحكم فيه قائمة" في نفس الوقت، يجب الحكم عليها على أنها ثغرة قابلة للاستغلال بثقة عالية.
جوهر سلسلة الاستغلال العامة الحالية ليس مجرد 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، تنفيذ الأوامر، مسار رفع صلاحية الجذر
يحتاج PoC أولاً إلى الحصول على اسم المضيف الحقيقي للهدف، بدلاً من استخدام عنوان IP فقط أو اسم المجال الخارجي.
والسبب هو أن منطق تصفية SSRF لا يحدد فقط الهدف النهائي للاتصال، بل قد يتحقق أيضًا من حقل اسم المضيف، وسلسلة URL، وكلمات المفاتيح للعناوين المحلية، وما إلى ذلك. قد يتم حظر العناوين المحلية الشائعة مثل 127.0.0.1 و localhost، بينما قد يتم اعتبار اسم المضيف الحقيقي للجهاز كاسم عقدة قانوني في بعض السيناريوهات.
الواجهات التي يمكن استخدامها للمساعدة في الحكم تتعلق عادةً بمعلومات WebDialer WSDL. بعد الوصول إلى هذا النوع من WSDL، قد يحتوي الرد على عنوان الخدمة، أو حقل الموقع، أو معرفات مضيف أخرى قابلة للتحليل. سيقوم PoC باستخراج اسم المضيف من عنوان URL في نص الرد واستخدامه كهدف الوصول الداخلي لمرحلة SSRF التالية.
يجب أن يكون معيار الحكم في هذه المرحلة:
إذا فشل تحليل اسم المضيف، قد يتراجع PoC إلى عنوان IP الهدف، لكن هذا سيقلل بشكل كبير من معدل النجاح. في البيئات الحقيقية، تشمل الأسباب الشائعة لفشل تحليل اسم المضيف: WebDialer غير مفعل، واجهات مقيدة بالتحكم في الوصول، الردود المعاد كتابتها بواسطة الوكيل العكسي، تكوين الشهادة أو الخدمة غير مكتمل.
تقع نقطة تشغيل SSRF في منطق الاستعلام عن حالة تثبيت cmplatform ذي الصلة. كانت هذه الوظيفة في الأصل للاستعلام عن حالة تثبيت عقد الكتلة، حيث يقوم الخادم بتجميع طلب داخلي بناءً على معرف العقدة أو اسم المضيف الذي يقدمه المستخدم.
المشكلة الأساسية في الثغرة هي أن معلمة اسم المضيف التي يمكن للمهاجم التحكم فيها لم يتم تقييدها بشكل صارم لتكون اسم عقدة قانوني أو مضيف موثوق، مما يسمح بتكوين هذه المعلمة كمسار وصول داخلي أكثر تعقيدًا. ثم يقوم الخادم بتقديم طلبات إلى الواجهات الداخلية نيابة عن المهاجم.
المفتاح في هذه المرحلة ليس "القدرة على الوصول إلى عنوان URL خارجي"، بل "القدرة على جعل جهاز CUCM نفسه يصل إلى واجهات إدارة WebDialer / Axis الداخلية التي يمكن الوصول إليها من قبل الجهاز". لذلك، تأتي قيمة SSRF من جانبين:
في التحقق المصرح به، لا يمكن الحكم على نجاح SSRF فقط بناءً على رمز حالة HTTP. الأدلة الأكثر موثوقية تشمل:
في السلسلة العامة، يتم استخدام SSRF أيضًا للوصول إلى واجهات خدمة Axis ذات الصلة ومحاولة كتابة محتوى وصف نشر الخدمة. يقوم المهاجم بإنشاء هيكل XML/WSDD خاص، مما يجعل مكون جانب الخادم يكتب محتوى يمكن التحكم فيه إلى مسار محدد أثناء المعالجة.
جوهر هذه المرحلة ليس تحميل الملفات التقليدي، بل إساءة استخدام منطق معالجة مكون جانب الخادم:
معلمات يمكن للمستخدم التحكم فيها
↓
طلب داخلي عبر SSRF
↓
معالجة خدمة Axis / Web
↓
كتابة وصف نشر قابل للتحكم أو سجل
↓
إنشاء ملف في مسار محدد
من منظور التحليل الأمني، هناك عدة نقاط رئيسية هنا:
لذلك، فإن نقطة الخطر العالية في CVE-2026-20230 ليست فقط SSRF، بل قدرة SSRF على عبور حدود الثقة، والدخول إلى سلسلة الإدارة الداخلية/نشر الخدمة، وتشغيل كتابة ملف يمكن التحكم فيه في النهاية.
عادةً ما يستخدم تصميم PoC الكتابة على مرحلتين، بدلاً من تنفيذ الأوامر في خطوة واحدة.
تُستخدم المرحلة الأولى لإنشاء قدرة بسيطة على كتابة الملفات. هدف هذه المرحلة هو السماح للمهاجم بكتابة محتوى إلى موقع محدد على الخادم من خلال مسار يمكن الوصول إليه عبر الويب.
ثم تستخدم المرحلة الثانية قدرة الكتابة من المرحلة الأولى لكتابة برنامج نصي لتنفيذ الأوامر إلى دليل يمكن الوصول إليه عبر الويب. بعد ذلك، يمكن للمهاجم تشغيل أوامر النظام من خلال معلمات HTTP.
مزايا التصميم ذي المرحلتين هي:
ولكن من منظور الحماية، تجلب الكتابة على مرحلتين أيضًا سطح كشف أوضح:
يمكن تلخيص تدفق PoC الحالي على النحو التالي:
من منظور معدل نجاح الاستغلال، تتركز نقاط الفشل الأكثر أهمية عادةً في:
لذلك، فإن قابلية استغلال PoC هذا عالية في الإصدارات المتأثرة المحددة ومسارات التطابق الافتراضية، لكنها ليست قابلة للقتل الشامل والمستقر لجميع أصول CUCM.
لا يمكن الحكم على نجاح CVE-2026-20230 فقط من خلال ما إذا كان البرنامج النصي قد اكتمل. يجب تقسيم الحكم الأكثر منطقية إلى أربعة مستويات.
الشروط:
يمكن الوصول إلى WebDialer WSDL
أو يمكن الوصول إلى صفحة services
أو يمكن الوصول إلى الواجهات ذات الصلة بـ cmplatform
هذا يشير فقط إلى وجود سطح هجوم ذي صلة في الهدف، ولا يمكنه إثبات قابلية استغلال الثغرة.
الشروط:
إصدار الهدف ضمن النطاق المتأثر
WebDialer مفعلة
يمكن تحليل اسم المضيف
مدخل SSRF يعيد استجابة غير طبيعية ولكن معقولة من جانب الخادم
في هذه الحالة، يجب الاستمرار في التحقق باستخدام سجلات جانب الخادم أو بيئات الاختبار المصرح بها.
الشروط:
بعد SSRF، يظهر ملف يمكن التحكم فيه من جانب الخادم
أو يظهر ملف غير طبيعي تم إنشاؤه بواسطة عملية جانب الخادم في دليل الويب
أو تظهر خدمة جديدة غير طبيعية في صفحة services
أو يظهر محتوى وصف نشر يمكن التحكم فيه في السجلات
عند الوصول إلى هذا المستوى، يمكن تأكيد أن سلسلة الثغرة قد تجاوزت مرحلة SSRF العادية، ودخلت في خطر كتابة ملف عشوائي.
الشروط:
تم تحليل وتنفيذ البرنامج النصي الذي يمكن الوصول إليه عبر الويب وكتابته بنجاح
ويمكن ملاحظة نتيجة تنفيذ جانب الخادم من خلال أوامر اختبار مصرح بها
فقط هذا المستوى يمكن الحكم عليه بأن تنفيذ الأوامر عن بُعد قد تم. كتابة الملف بنجاح لا تعني بالضرورة نجاح RCE، ولكن في بيئات خدمات عالية الصلاحية مثل CUCM، فإن كتابة الملف وحدها تشكل خطرًا كبيرًا.
لا تقدم هذه المقالة أمثلة على تنفيذ exploits يمكن استخدامها مباشرة للهجوم.
في البيئات المصرح بها، يوصى باستخدام طرق "الفحص للقراءة فقط" أو "التحقق غير التدميري"، على سبيل المثال:
python3 CVE-2026-20230-check.py https://127.0.0.1 --check
تشمل العناصر الموصى بفحصها:
لا يوصى بإجراء التحقق الكامل من كتابة الملف أو تنفيذ الأوامر على أنظمة الإنتاج. حتى في حالة الاختبارات المصرح بها، يجب إعطاء الأولوية للقيام بذلك في بيئات اختبار معزولة، أو بيئات لقطات، أو وفقًا لعملية التحقق الموصى بها من قبل الشركة المصنعة.
يجب أن تكون حدود الأمان لهذا النوع من PoC واضحة.
أولاً، لا يجب تنفيذ الأوامر افتراضيًا. مرحلة تنفيذ الأوامر هي تحقق عالي المخاطر، ويمكن أن تسبب تغييرات في حالة النظام، تلوث السجلات، خلل في الخدمة، أو استجابة مرتبطة من أجهزة الأمن.
ثانيًا، لا يجب كتابة WebShell افتراضيًا. حتى إذا تم كتابة ملف اختبار، فقد يتم الحكم عليه من قبل EDR، أو برامج مكافحة WebShell، أو مراقبة سلامة الملفات، أو أنظمة تدقيق الامتثال على أنه اختراق حقيقي.
ثالثًا، لا يجب إجراء مسح جماعي لأهداف الإنترنت العامة. هذه الثغرة لا تتطلب مصادقة، والأهداف غالبًا ما تكون بنية تحتية لاتصالات المؤسسات، والمسح غير المصرح به والاستغلال يحمل مخاطر عالية جدًا.
رابعًا، يجب فصل وضع الفحص عن وضع الاستغلال. يوصى بتقسيم PoC إلى نصين: واحد فقط لتحديد الأصول والحكم على حالة الخدمة، والآخر للتحقق من كتابة الملف فقط في بيئات الاختبار المحلية أو البيئات المصرح بها بوضوح.
خامسًا، يجب تقييد نطاق الهدف. يمكن لـ PoC إضافة آليات حماية مثل العناوين المحلية، وشبكات خاصة، وأسماء نطاقات قائمة بيضاء، ومعلمات تأكيد الترخيص لمنع الضرب العرضي لأنظمة الطرف الثالث.
سادسًا، يجب تعطيل مرحلة RCE افتراضيًا. حتى إذا تم الاحتفاظ بكود البحث، يجب أن يُطلب من المستخدم تمرير معلمة تأكيد الترخيص بشكل صريح قبل السماح بدخول مرحلة كتابة الملف أو تنفيذ الأوامر.
من منظور اكتشاف حركة المرور، لا يمكن مطابقة اسم ملف ثابت واحد أو اسم خدمة ثابت أو اسم JSP ثابت فقط. يمكن تعديل اسم الخدمة واسم الملف والمسار في PoC العام، لذا فإن قواعد السلسلة الواحدة يمكن أن تؤدي بسهولة إلى إخفاقات.
نهج الكشف الأكثر منطقية هو استخراج الخصائص حول مراحل سلسلة الهجوم.
التركيز على:
/webdialer/Version.jws?wsdl
/webdialer/services
WebDialer WSDL
Axis services listing
إذا قام عميل خارجي بزيارة WSDL ثم زار واجهات حالة تثبيت cmplatform في فترة زمنية قصيرة، يجب رفع مستوى الخطر.
التركيز على:
/cmplatform/installClusterStatusExecute
action=clusterNodeInstallStatus
نمو غير طبيعي في معلمة hostname
ظهور فواصل مسار مشفرة بعناوين URL في معلمة hostname
ظهور خصائص مسار داخلي مثل webdialer و services و AdminService و platformcom و installstages في معلمة hostname
المفتاح في هذه المرحلة هو أن معلمة hostname لم تعد تشبه اسم مضيف عادي، بل تظهر خصائص تشبه المسار، وعنوان URL، والتشفير، و XML.
التركيز على:
deployment
wsdd
java:RPC
requestFlow
LogHandler
allowedMethods
className
fileName
writeToConsole
عند ظهور هذه الحقول معًا، يجب الاشتباه بقوة في أن المهاجم يحاول كتابة محتوى يمكن التحكم فيه من خلال ملف وصف نشر خدمة Axis.
التركيز على:
axis2-web
platform-services
كتابة ملف JSP
ظهور مزيج من اسم الملف ومحتوى الملف في المعلمات
تجاوز مسار دليل الويب
common/log/taos-log-a
tomcat/webapps
إذا ظهر في حركة الهجوم الكثير من ../ وتجاوز مسار مشفر بعناوين URL وامتداد JSP ومسار Tomcat WebApp، يجب الحكم عليه على أنه عالي الخطورة.
التركيز على:
زيارة JSP الجديد
ظهور معلمات أوامر مثل pwd و cmd و command و exec و i في معلمات الطلب
ظهور تنسيق إخراج أوامر النظام في الرد
إكمال نفس عنوان IP المصدر لسلسلة متصلة من الحصول على WSDL و SSRF والكتابة والتنفيذ في فترة زمنية قصيرة
من منظور تصميم القواعد، يوصى باستخدام الكشف متعدد المراحل:
أثناء التحقيق الطارئ، يُوصى بالتركيز على فحص المواقع والظواهر التالية:
installClusterStatusExecute في سجلات الوصول إلى cmplatform؟/tmp وأدلة WebApp وأدلة السجلات؟إذا كان هناك اشتباه في الاستغلال، يجب عزل الوصول إلى سطح الإدارة أولاً، والحفاظ على الأدلة من السجلات ونظام الملفات، ثم تنفيذ ترقية التصحيح، وتنظيف WebShell، وتنظيف الخدمات غير الطبيعية، وتدوير الحسابات/بيانات الاعتماد.
طريقة الإصلاح الجذرية هي الترقية إلى إصدار الإصلاح الرسمي من Cisco أو تطبيق حزمة الإصلاح المؤقتة الرسمية.
توصيات المعالجة العامة هي كما يلي:
المفتاح في CVE-2026-20230 لا يكمن في كشف واجهة واحدة، بل في تشكيل فشل حدود الثقة القابل للربط بين WebDialer في CUCM، ومنطق الاستعلام عن حالة تثبيت cmplatform، ومعالجة خدمة Axis الداخلية، وقدرة كتابة الملف.
يمكن تلخيص هذه السلسلة على النحو التالي:
طلب خارجي غير مصادق
↓
تأكيد سطح كشف WebDialer
↓
الحصول على اسم المضيف الحقيقي
↓
cmplatform SSRF
↓
الوصول إلى خدمة Axis الداخلية
↓
كتابة وصف خدمة أو سجل يمكن التحكم فيه
↓
هبوط ملف يمكن الوصول إليه عبر الويب
↓
تنفيذ الأوامر وخطر رفع صلاحية الجذر
تعتمد قابلية الاستغلال الفعلية على ما إذا كان WebDialer مفعلًا، وما إذا كان إصدار الهدف متأثرًا، وما إذا كان يمكن تجاوز تصفية اسم المضيف، وما إذا كانت نقطة هبوط المسار متطابقة، وما إذا كانت حاوية الويب تنفذ الملفات المكتوبة، وما إذا كان الهدف قد طبق التصحيح.
من منظور الدفاع، لا يمكن الاعتماد فقط على "وجود ملف JSP معين" للحكم على الهجوم. الطريقة الأكثر أمانًا هي إجراء كشف مرتبط حول سلسلة متعددة المراحل: الحصول على معلومات WSDL، واسم مضيف غير طبيعي في cmplatform، وخصائص Axis/WSDD، وكتابة تجاوز المسار، وزيارة JSP النهائي، ومعلمات الأوامر. طالما ظهرت عدة مراحل بشكل متتالٍ من نفس المصدر في فترة زمنية قصيرة، يجب التعامل معها كحادث اختراق عالي الخطورة.