تحليل تقني خطوة بخطوة وتطوير استغلال لـ CVE-2017-9822، وهو ثغرة RCE حرجة في DotNetNuke عبر إلغاء تسلسل XML غير آمن في ملف تعريف الارتباط DNNPersonalization. يتضمن إعداد البيئة، تكوين التصحيح باستخدام dnSpy، بناء سلسلة الأدوات (ObjectDataProvider, ResourceDictionary)، ورفع webshell.
DNN (المعروف أيضًا باسم DotNetNuke) قبل الإصدار 9.1.1 لديه القدرة على تنفيذ التعليمات البرمجية عن بُعد عبر ملفات تعريف الارتباط، والمعروف أيضًا باسم "2017-08 (مهم) إمكانية تنفيذ تعليمات برمجية عن بُعد على مواقع DNN".
ما هو DotNetNuke؟ DotNetNuke هو نظام إدارة محتوى ويب مجاني ومفتوح المصدر مكتوب بلغة C# ويعتمد على منصة .NET. DotNetNuke شائع جدًا ويستخدم على نطاق واسع على الإنترنت لأنه يمكنك نشر إصدار ويب من DNN في دقائق دون الحاجة إلى الكثير من المعرفة التقنية. وظيفة مهمة أخرى لـ DotNetNuke هي القدرة على إنشاء أو استيراد وحدات مخصصة من طرف ثالث مبنية باستخدام VB.NET أو C#. يمكن تثبيت DNN على مجموعة تتضمن Windows Server وIIS وASP.NET وSQL Server لنظام Windows. كما يدعم DNN التحقق من التسجيل للمستخدمين الجدد عبر البريد الإلكتروني، ولكنك تحتاج إلى تكوين خادم SMTP صالح لكي تعمل هذه الميزة الأمنية. الميزات الرئيسية لـ DNN • الهندسة المعيارية: يسمح DNN بالتوسع بسهولة عن طريق تثبيت وحدات إضافية (وحدات وظيفية) مطورة من قبل المجتمع. يمكن للمسؤولين تحميل وحدة جديدة عبر واجهة الإدارة (رفع حزمة .zip) أو فك الضغط مباشرة في مجلد على الخادم. • إدارة المستخدمين: يوفر النظام وظائف أمان وتفويض مفصلة (أدوار/صلاحيات) للبوابات والوحدات. تتم إدارة حسابات المستخدمين والأدوار والصلاحيات بشكل مركزي في DNN. • إدارة المحتوى: يدعم محرر WYSIWYG، وإدارة المقالات والصور والمستندات... يوجد نظام سير عمل/نشر (نشر المقالات وفق عملية مراجعة) وتحديد إصدارات المحتوى. يتم تخزين المحتوى في قاعدة بيانات مشتركة (SQL Server). • API والتكامل القابل للتوسع: يوفر DNN API .NET للمطورين لتطوير وحدات مخصصة (WebForms، MVC، Razor) ودمج الخدمات الخارجية. تتوفر مجموعة واسعة من المكتبات الخارجية (قوالب الواجهة، وحدات التجارة الإلكترونية، المنتديات، إلخ) لتوسيع الوظائف. • الواجهة والقوالب: نظام القوالب (الجلود) يفصل المحتوى عن الواجهة مما يسمح بتصميم ويب مرن. يمكن لمواقع الويب التي تم إنشاؤها بواسطة DNN تغيير الواجهة عن طريق تغيير القوالب. • آلية تثبيت الوحدات: يتم تغليف وحدات DNN في ملفات ZIP، ويمكن تثبيتها عبر واجهة الإدارة أو عن طريق فك الضغط يدويًا. يدعم DNN كلاً من الوحدات المترجمة (.NET DLL) ووحدات Razor الديناميكية؛ يمكن منح أو إلغاء الوصول لأي وحدة من خلال إعدادات التفويض على كل صفحة.
أنظمة التشغيل: Windows 10 .NET Framework: 4.5.1+ خادم الويب: Microsoft IIS 10 خادم قاعدة البيانات: Microsoft® SQL Server® 2019 Express، SQL Server Management Studio إصدار Dotnetnuke 9.1.0 يمكن استخدام Google dorks التالية للعثور على إصدارات Dotnetnuke المنتشرة على الإنترنت واختبارها بناءً على الموقع: inurl:dnn.js inurl:dnn.modalpopup.js inurl:dnn.servicesframework.js inurl:dnn.xml.js inurl:dnncore.js inurl:/Portals/0/ inurl:/DesktopModules/ inurl:/DNNCorp/ inurl:/DotNetNuke inurl:/tabid//Default.aspx inurl:/tabid//language/*/Default.aspx intext:"by DNN Corp " يمكن اتباع هذا المقال لبناء البيئة
قم بتعديل خصائص التجميع إلى خصائص "قابلة للتصحيح"، وهذا ضروري جدًا لأنه في وقت التشغيل، سيتم تطبيق بعض التحسينات التي قد تعيق عملية التصحيح، وقد لا يتم الوصول إلى بعض نقاط التوقف أو قد لا تكون بعض المتغيرات موجودة. قم بتحميل DotNetNuke.dll إلى dnSpy (32 بت) ثم اختر Edit Assembly Attributes (C#)
قم بتغيير السطر من
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]
إلى
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.Default | DebuggableAttribute.DebuggingModes.DisableOptimizations | DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | DebuggableAttribute.DebuggingModes.EnableEditAndContinue)]
ثم اختر Compile واحفظ هذه الوحدة في مكانها الأصلي. بعد ذلك، قم بتشغيل dnSpy بصلاحيات المسؤول واختر Debug -> Attach to Process
اختر العملية w3wp.exe
سبب إرفاق هذه العملية هو أن تطبيقات الويب على IIS تستخدم عادةً عمليات العامل. وهي مسؤولة عن معالجة طلبات الويب المرسلة إلى خادم IIS لكل مجموعة تطبيقات، وقد تكون هناك عدة عمليات عامل على جهاز واحد وكلها تحمل نفس الاسم w3wp.exe. ملاحظة صغيرة: قد لا تكون هناك عملية w3wp قيد التشغيل في بعض الأوقات، حيث لن يبدأ IIS عمليات العامل حتى يستقبل أول طلب ويب.
بالعودة إلى التصحيح، بعد إرفاق العملية، اختر: Debug -> Windows -> Modules
انقر على وحدة واختر Open All Modules
في هذه المرحلة، في نافذة Assembly يمكننا رؤية جميع الوحدات ذات الصلة
إلغاء التسلسل هو عملية تفسير تدفقات البايت وتحويلها إلى بيانات يمكن للتطبيق تنفيذها. المشكلة الرئيسية في إلغاء التسلسل هي أنه في معظم الأوقات يمكنه استخدام بيانات إدخال المستخدم. وهذا يعني أنه يمكنك إدراج حمولات ضارة في التنسيق المطلوب للتطبيق ويمكن التلاعب بالمنطق، أو الكشف عن البيانات، أو حتى تنفيذ التعليمات البرمجية عن بُعد. يستخدم DotNetNuke ملف تعريف الارتباط DNNPersonalization لتخزين خيارات التخصيص للمستخدمين المجهولين (يتم تخزين خيارات المستخدمين الموثقين عبر صفحة ملفهم الشخصي). وفقًا للتقرير، تحدث الثغرة في معالجة ملف تعريف الارتباط DNNPersonalization، حيث يُستخدم هذا الملف لتحميل ملف المستخدم الشخصي ولكن لا يزال من الممكن تشغيله دون مصادقة عند الوصول إلى صفحة غير موجودة (خطأ 404). نقطة الدخول لهذه الثغرة تقع في دالة LoadProfile التابعة لوحدة DotNetNuke.dll، سنقوم بفك ترجمة هذه الوحدة باستخدام dnSpy وتحليلها بالتفصيل: في PersonalizationController#LoadProfile(int, int)
إذا كان userId مختلفًا عن null، فسيتم تعيين قيمة المتغير text إلى قيمة ملف تعريف الارتباط DNNPersonalization من الطلب ثم يتم استدعاء Globals#DeserializeHashTableXml
Globals#DeserializeHashTableXml يستدعي XmlUtils#DeSerializeHashtable
عملية المعالجة كالتالي:
استخدم burp لإرسال طلب يؤدي إلى حالة 404 + ملف تعريف الارتباط DNNPersonalization
هنا يمكننا رؤية أن الدالة المستدعاة لمعالجة 404 هي Handler404OrException التي قامت بتشغيل سلسلة استدعاءات وأدت إلى Personalization.LoadProfile(int,int).
الجدير بالملاحظة في الكود أعلاه هو الشرط if الذي يتحقق مما إذا كان الطلب الحالي قد تم توثيقه (IsAuthenticated) أم لا، ومن الواضح أن الطلب الذي قمنا به هو غير موثق إلى نقطة دخول غير موجودة. فلماذا يتم تنفيذ الطلب الحالي كمستخدم موثق؟ نواصل التصحيح، بالعودة إلى نهاية المكدس تقريبًا نجد في AdvancedUrlRewriter#Handle404OrException حلقة else if كما يلي:
هنا يقوم بالتحقق مما إذا كان طلب context.User الحالي هو null، وإذا كان الأمر كذلك، يقوم بتعيين context.User كمستخدم الخيط الحالي، وعند تعيين نقطة توقف يمكننا رؤية النتيجة التالية:
المتغير IsAuthenticated أصبح الآن قيمته true ويتم تعيين المستخدم إلى المستخدم الذي يقوم بتشغيل الخيط الحالي والذي ينتمي إلى مجموعة IIS APPPOOL الخاصة بخادم IIS، وبالتالي يتم تنفيذ الطلب كمستخدم موثق. سبب وجود هذا المنطق هو أن معالج 404 يتم استدعاؤه قبل تعيين HttpContext.User، ويستمر تدفق المعالجة بناءً على User.IsAuthenticated، لذلك لتجنب أخطاء المرجع الفارغ، قام المطورون بتعيين كائن User إلى كائن WindowsPrinicipal الخاص بالخيط الحالي.
XmlSerializer هي فئة تسلسل خاصة من Microsoft، تُستخدم للتحويل بين السلاسل النصية وكائنات XML. اسم المساحة الخاص بها هو: System.Xml.Serialization. مثال على استخدام XmlSerializer:
شرط هجوم RCE عبر XmlSerializer هو أنه يجب التحكم في نوع البيانات المرسلة إلى منشئ XmlSerializer. أي أن أنواع البيانات المؤدية إلى الأداة يجب أن تُمرر إلى الخاصية XmlSerializer.mapping
الأداة الأكثر شيوعًا لهجمات إلغاء تسلسل XML هي ObjectDataProvider. يمكن إنشاء هذه الأداة باستخدام أداة ysoserrial .net
بشكل أساسي، عند استخدام هذه الفئة، يمكننا استدعاء أي أسلوب من أي فئة.
على سبيل المثال، يمكننا استدعاء Process.Start مع المعاملات التالية:
ObjectDataProvider o = new ObjectDataProvider(); o.MethodParameters.Add("cmd.exe"); o.MethodParameters.Add("/c calc"); o.MethodName = "Start"; o.ObjectInstance = new Process(); Console.ReadKey();
بناء حمولة إلغاء تسلسل XML مع الكود أعلاه:
يُستخدم ResourceDictionary لتطوير WPF، وبما أنه WPF، يجب عليه استخدام لغة XAML. أولاً، دعنا نلقي نظرة على حمولة تستخدم ResourceDictionary لتنفيذ الأوامر.
<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:d="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:b="clr-namespace:System;assembly=mscorlib" xmlns:c="clr-namespace:System.Diagnostics;assembly=system"> <ObjectDataProvider d:Key="" ObjectType="{d:Type c:Process}" MethodName="Start"> <ObjectDataProvider.MethodParameters> <b:String>cmd</b:String> <b:String>/c calc</b:String> </ObjectDataProvider.MethodParameters> </ObjectDataProvider> </ResourceDictionary>
شرح XAML هذا:
تنفيذ الكود أعلاه يكافئ ObjectDataProvider -> Person.Evil(). إذا تم تنفيذ هجوم RCE عبر XmlSerializer، فسيبدو التدفق هكذا ObjectDataProvider -> XamlReader.Parse() -> ObjectDataProvider -> System.Diagnostics.Process.Start("cmd.exe","/c calc")
الهدف الآن هو إيجاد كائن يمكنه تنفيذ كود عند إجراء إلغاء التسلسل. في الـ POC، يتم استخدام دالة PullFile الخاصة بـ DotNetNuke.Common.Utilities.FileSystemUtils لاستغلال "رفع ملف تعسفي"
نحصل على obj.xml:
إرسال الحمولة
بعد أن يقوم DNN بإلغاء تسلسل ملفات تعريف الارتباط، على خادم http سيكون هناك طلب إلى /cmd.aspx أي أن إلغاء التسلسل نجح، وتم رفع الـ webshell إلى DNN
وبالمثل، استغلال دالة WriteFile الخاصة بـ DotNetNuke.Common.Utilities.FileSystemUtils لقراءة الملف
