عندما يخرج SOAP عن السيطرة: ثغرة في .NET ترفض مايكروسوفت إصلاحها

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

داخل الثغرة

في قلب المشكلة توجد SoapHttpClientProtocol، وهي فئة مصممة لجعل التواصل مع خدمات الويب المعتمدة على SOAP بسيطاً وآمناً. في الواقع، هي قنبلة موقوتة. إذا تمكن مهاجم من التأثير على عنوان URL الوجهة لطلب SOAP، يمكنه خداع التطبيق لكتابة بيانات إلى ملفات عشوائية - أو ما هو أسوأ، تنفيذ تعليمات برمجية خبيثة على الخادم.

أظهر الباحث الأمني بيوتر بازيدلو من watchTowr كيف أن هذه الفئة، المصممة للعمل عبر HTTP أو HTTPS، تقبل بروتوكولات أخرى بسعادة، بما في ذلك FTP وFILE. هذا يعني أن طلب SOAP قد ينتهي به المطاف مكتوباً في ملف محلي، وهو أمر لا يتوقعه أي مطور من "عميل ويب".

في إحدى الحالات، اكتشف الباحثون أن واجهة برمجة تطبيقات SOAP في Barracuda Service Center يمكن الوصول إليها بدون مصادقة. من خلال تزويد ملف WSDL (لغة وصف خدمات الويب) مصمم خصيصاً، يمكن للمهاجمين إنشاء عميل وكيل خاص بهم وحقن web shell - مما يمنحهم السيطرة على الخادم. والأسوأ من ذلك، أن نفس الطريقة نجحت مع منتجات مؤسسية أخرى مثل Ivanti Endpoint Manager وUmbraco 8 CMS.

رد مايكروسوفت: "ليست مشكلتنا"

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

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