l3cr0f/dccwbypassuacتجاوز UAC في نظامي Windows 8.1 وWindows 10 عبر استغلال WinSxS في "dccw.exe".
يستغل هذا الثغرة الطريقة التي تتم بها إدارة "WinSxS" بواسطة "dccw.exe" عبر طريقة مشتقة من طريقة Leo Davidson "Bypass UAC" للحصول على شل بصلاحيات المسؤول دون المطالبة بالموافقة. وهو يدعم بنيتي "x86" و"x64". علاوة على ذلك، تم اختباره بنجاح على Windows 8.1 9600، وWindows 10 14393، وWindows 10 15031، وWindows 10 15062.
إذا كنت تريد معرفة كيفية تنفيذ السكربت، فألقِ نظرة على قسم الاستخدام. كما يمكنك تنفيذه داخل Metasploit والحصول على جلسة Meterpreter بصلاحيات المسؤول.
لتطوير طريقة جديدة لتجاوز UAC، يجب أولاً إيجاد ثغرة في النظام، وبتعبير أدق، ثغرة في عملية auto-elevate. للحصول على قائمة بهذه العمليات، استخدمنا أداة Sysinternals المسماة Strings. بعد ذلك، تمكنا من رؤية بعض عمليات auto-elevate مثل "sysprep.exe" و"cliconfig.exe" و"inetmgr.exe" و"consent.exe" أو "CompMgmtLauncher.exe" التي كانت (بعضها ما زالت) تحتوي على ثغرات تسمح بتنفيذ "bypass UAC". لذا، بدأنا في دراسة كيفية عمل عمليات auto-elevate الأخرى باستخدام تطبيق Sysinternals المسمى Process Monitor (ProcMon)، مع التركيز على عملية "dccw.exe".
ومع ذلك، قبل البدء باستخدام ProcMon، تحققنا أولاً من manifest هذه التطبيقات باستخدام تطبيق آخر من Sysinternals يسمى Sigcheck، وبالطبع، في حالتنا، "dccw.exe" هو عملية auto-elevate.
ثم، تمكنا من البدء في تتبع مسار تنفيذ "dccw.exe" باستخدام ProcMon لمعرفة ما إذا كان هناك شيء غريب يحدث، وهو ما تحققنا منه فورًا. في مرحلة معينة، إذا قمنا بتشغيل "dccw.exe" كعملية 64 بت على جهاز Windows 64 بت، فإنها تبحث عن الدليل "C:\Windows\System32\dccw.exe.Local\" لتحميل DLL معينة تسمى "GdiPlus.dll"، تمامًا كما لو تم تشغيلها على جهاز Windows 32 بت؛ بينما إذا قمنا بتشغيلها كعملية 32 بت على نفس الجهاز، ستبحث العملية عن الدليل "C:\Windows\SysWOW64\dccw.exe.Local\". وبما أن هذا الدليل غير موجود، تبحث العملية دائمًا عن مجلد في المسار "C:\Windows\WinSxS\" للحصول على DLL المطلوبة، وهذا المجلد له اسم بالتنسيق التالي:
[architecture]_microsoft.windows.gdiplus_[sequencial_code]_[Windows_version]_none_[sequencial_number]
إذا ألقينا نظرة داخل دليل "WinSxS"، يمكننا رؤية أكثر من مجلد يطابق هذا الهيكل، وهذا يعني أن "dccw.exe" يمكنه تحميل DLL المطلوبة من أي من هذه المجلدات. الشيء الوحيد المؤكد هو أنه إذا تم استدعاء التطبيق كعملية x86، فسيبدأ اسم المجلد بالسلسلة "x86"، بينما إذا قمنا بتنفيذه كعملية x64، فسيبدأ اسمه بالسلسلة "amd64".
يمكن استغلال هذا الوضع لتنفيذ اختطاف DLL ثم تشغيل كود بصلاحيات عالية (high integrity) دون المطالبة بالموافقة.
بمجرد العثور على خطأ أثناء تنفيذ عملية auto-elevate، نحتاج إلى التحقق مما إذا كان يمكن استغلاله أم لا. للقيام بذلك، قمنا بإنشاء المجلد "dccw.exe.Local" في المسار المطلوب، وداخل هذا المجلد أنشأنا المجلدات الموجودة في "WinSxS" التي يمكن أن تستدعيها العملية لتحميل "GdiPlus.dll"، ولكن دون تضمين DLL المذكورة.
الآن، إذا قمنا بتنفيذ "dccw.exe" سنلاحظ أن العملية عثرت على المجلد "dccw.exe.Local" وأحد مجلدات "WinSxS"، ولكن ليس على DLL المطلوبة، الأمر الذي يؤدي إلى ظهور خطأ. هذا ما توقعناه، لأن هذا الموقف يمكن استغلاله من قبل مهاجم كما ذكرنا سابقًا.
عند هذه النقطة، نعلم بالفعل أنه يمكننا تنفيذ bypass UAC على Windows 10 من خلال استغلال "dccw.exe"، لكن كيف؟
الطريقة الأكثر استخدامًا لتجاوز UAC هي تلك التي طورها Leo Davidson. إلا أنها تنفذ حقنًا للعملية (process injection) لاستدعاء كائن COM IFileOperation، وهو ما قد تكتشفه بعض برامج مكافحة الفيروسات، لذا فإن النهج الأفضل لاستخدامها هو ما يسمى Masquerade PEB الذي استخدمه Cn33liz في أداة bypass UAC الخاصة به.
أيضًا، يتعين علينا تعديل طريقة استدعاء IFileOperation في إصدارات Windows 10 الأحدث، لأن طريقة Leo Davidson تؤدي إلى إطلاق UAC بدءًا من البناء 15002. لذا، فإن طريقة استدعاء هذه العملية هي نفسها الأصلية، ولكن دون علامات العملية "FOF_SILENT" و"FOFX_SHOWELEVATIONPROMPT" و"FOF_NOERRORUI".
قبل تنفيذ الثغرة، من المهم التحقق من بعض الجوانب لتجنب تنفيذها دون نجاح وبالتالي إطلاق بعض الإنذارات. أول شيء نتحقق منه هو إصدار بناء Windows، لأن بعض الإصدارات غير معرضة لثغرة exploit خاصتنا (تلك التي لديها إصدار بناء أقل من 7600). بعد ذلك، نتحقق من أننا لا نملك صلاحيات المسؤول بعد؛ إذا كنا نملكها، فلا يوجد سبب لتنفيذ السكربت. ثم نتحقق من إعدادات UAC للتأكد من أنها ليست مضبوطة على "Always notify"، لأنه إذا كانت مضبوطة على هذه القيمة، ستكون ثغرة exploit عديمة الفائدة. أخيرًا، نتحقق مما إذا كان المستخدم ينتمي إلى مجموعة المسؤولين، لأنه إذا لم يكن كذلك، سيفشل الاستغلال.
عند تطوير أداة استغلال، من المهم أن تعمل على أكبر عدد ممكن من الأنظمة، بما في ذلك أنظمة Windows 32 بت. لتحقيق ذلك، نحتاج إلى تجميع الأداة لهذه الأنظمة، حيث يمكننا أيضًا تنفيذها على أنظمة 64 بت.
عند تشغيل استغلالنا المعدّ لبيئة 32 بت على جهاز Windows 64 بت، تختلف طريقة عمل "dccw.exe" قليلًا بسبب استدعاء WOW64 (النظام الفرعي لنظام Windows الذي يسمح لأجهزة 64 بت بتشغيل تطبيقات 32 بت). هذا يعني أن المجلد "dccw.exe.Local" سيتم البحث عنه في دليل "C:\Windows\SysWOW64\" بدلاً من "C:\Windows\System32\"، كما أن "GdiPlus.dll" المستهدفة ستكون DLL خاصة بـ 32 بت، مما يعني أنه سيتم البحث عنها في مجلد يطابق نمط الاسم "C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_*". ومع ذلك، إذا تم تنفيذ الأداة على نظام Windows 32 بت، ستعمل كما هو متوقع.
أخيرًا، من المهم الإشارة إلى أننا بحاجة إلى النظر في جميع المسارات التي تطابق النمط "C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_*" عند تنفيذ اختطاف DLL لضمان فعالية 100%.
لتنفيذ عملية بصلاحيات عالية (high integrity)، نحتاج إلى تطوير DLL سيتم استدعاؤها عبر اختطاف DLL. ومع ذلك، الأمر ليس ببساطة ما يبدو عليه، لأنه إذا فعلنا ذلك فقط، فلن يتم تنفيذ "dccw.exe" ولا الكود الخاص بنا. ويعود السبب إلى أن "dccw.exe" يعتمد على بعض وظائف "GdiPlus.dll"، لذا نحتاج إلى تنفيذ هذه الوظائف أو تمرير تنفيذها إلى DLL الأصلية.
الخيار الأفضل هو تمرير التنفيذ إلى DLL الأصلية، لأن ذلك يقلل من حجم DLL الخاصة بنا. للقيام بذلك، استخدمنا برنامج ExportsToC++ لنقل جميع الصادرات (exports) الخاصة بـ "GdiPlus.dll" إلى لغة C++. المشكلة الآن هي العدد الهائل من الصادرات التي تمتلكها "GdiPlus.dll"، وبالتحديد 631 تصديرًا. ومع ذلك، فإن "dccw.exe" لا يستوردها جميعًا، بل يستورد القليل منها فقط. لمعرفة الوظائف التي يستوردها "dccw.exe" من "GdiPlus.dll"، قمنا بعمل هندسة عكسية لها باستخدام "IDA Pro". في النهاية، تم استيراد 15 وظيفة فقط من "GdiPlus.dll"، لذا نحتاج فقط إلى تضمين هذه الوظائف في DLL الخاصة بنا.
الآن، يبدو أن المشكلة قد حُلّت، ولكن إذا قمنا بتمرير التنفيذ إلى "GdiPlus.dll" محددة في C:\Windows\WinSxS\"، فإن DLL ستعمل فقط على بعض الأنظمة، لأن أسماء المجلدات الداخلية لـ "WinSxS" تتغير مع كل إصدار من Windows. لتجاوز هذه المشكلة، خطرت لنا فكرة تمرير التنفيذ إلى "C:\Windows\System32\GdiPlus.dll"، نظرًا لأن المسار هو نفسه في جميع أنظمة Windows 10.
آخر شيء يتعين علينا فعله هو إيقاف تنفيذ "dccw.exe" بعد تشغيل الكود الخبيث لتجنب فتح نافذة تلك العملية.
الآن، بعد تطوير DLL الخبيثة، نحتاج إلى إسقاطها على الجهاز المستهدف. للقيام بذلك، تم ضغط DLL الخاصة بنا وتشفيرها بصيغة "base64" داخل الأداة، بحيث يمكن فك ترميزها وفك ضغطها وقت التشغيل لإسقاطها كما هو متوقع.
أخيرًا، يتم نسخ "GdiPlus.dll" المصنّعة إلى الموقع المستهدف باستخدام كائن COM IFileOperation كما ذُكر سابقًا.
عندما يخترق مهاجم نظامًا، فإنه يريد البقاء غير مكتشَف لأطول فترة ممكنة، وهذا يعني إزالة كل أثر للإجراءات التي يقوم بها. ولهذا السبب، تتم إزالة جميع الملفات المؤقتة التي يتم إنشاؤها أثناء تنفيذ الاستغلال عندما لا تكون هناك حاجة إليها بعد الآن.
أخيرًا، نحتاج إلى تحديد العملية التي نريد تنفيذها بصلاحيات عالية. في حالتنا، اخترنا تطبيق "cmd.exe" لأنه يسمح لنا بتنفيذ أكبر عدد ممكن من العمليات بصلاحيات عالية بمجرد حصولنا على صلاحيات المسؤول، ولكن في الواقع، يمكننا تنفيذ أي تطبيق نريده.
لتنفيذ الاستغلال، يجب التأكد من أن الجهاز المستهدف يستوفي المتطلبات. بعد ذلك، كل ما عليك فعله هو تنفيذ الأداة مثل أي سكربت آخر يعمل من سطر الأوامر:
C:\Users\L3cr0f> DccwBypassUAC.exe
وحدة Metasploit الخاصة بإثبات المفهوم هذا تستخدم حقن DLL بدلاً من Masquerading PEB، وهي متاحة في:
- Metasploit Framework: https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/windows/local/bypassuac_injection_winsxs.rbتم تطوير هذه الأداة الاستغلالية لإظهار كيف يمكن للمهاجم الحصول على صلاحيات داخل النظام، وليس لاستخدامها في أغراض خبيثة. وهذا يعني أنني لا أتحمل أي مسؤولية إذا استخدمها شخص ما للقيام بأنشطة إجرامية.
التحكم في حساب المستخدم (UAC) هي تقنية تم تقديمها مع Windows Vista وتوفر طريقة لفصل صلاحيات ومهام المستخدم القياسي عن تلك التي تتطلب وصول المسؤول. إذا كان المستخدم القياسي يستخدم النظام وحاول القيام بإجراء ليس لديه إذن به، تظهر نافذة من Windows تطلب كلمة مرور حساب المسؤول. إذا كان المسؤول يستخدم النظام وحاول القيام بالمهمة نفسها، فتظهر نافذة تحذير فقط. تُعرف هذه النافذة باسم "Consent Prompt" لأن المسؤول يُطلب منه فقط الموافقة على الإجراء قبل المتابعة. الضعف الذي يسمح بتجاوز "Consent Prompt" لا يُعتبر ثغرة أمنية، لأنه لا يُعتبر حدًا أمنيًا.
ومع ذلك، تذكر Microsoft أيضًا أن "التحكم في حساب المستخدم (UAC) هو مكوّن أساسي في رؤية Microsoft الأمنية الشاملة".
المصادر:
- تعريف الثغرة الأمنية.
- كيفية عمل التحكم في حساب المستخدم.