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 الخاصة بنا.
