optiv/dentإطار عمل لإنشاء تجاوزات قائمة على COM باستخدام ثغرات في مستشعرات WDAPT من Microsoft.
لعرض أحدث إصدار من Dent أو لتقديم مشكلة، راجع https://github.com/Tylous/Dent.
Dent
إذا كنت ترغب في معرفة المزيد عن التقنيات المستخدمة في هذا الإطار، يرجى إلقاء نظرة على هذا المقال.
يُولد هذا الإطار كودًا لاستغلال الثغرات الأمنية في قواعد تقليل سطح الهجوم (ASR) الخاصة بـ Microsoft Defender Advanced Threat Protection لتنفيذ shellcode دون اكتشاف أو منع. تم تصميم ASR ليكون خط الدفاع الأول، حيث يكتشف الأحداث بناءً على إجراءات تنتهك مجموعة من القواعد. تركز هذه القواعد على مؤشرات سلوكية محددة على نقطة النهاية والتي غالبًا ما ترتبط بتكتيكات أو تقنيات أو إجراءات المهاجم (TTPs). تركز هذه القواعد بشكل كبير على مجموعة Microsoft Office، لأنها ناقل هجوم شائع لإنشاء موطئ قدم عن بُعد على نقطة النهاية. يركز الكثير من الضوابط المستندة إلى القواعد على مؤشرات السلوك المستندة إلى الشبكة أو العملية التي تبرز عن العمليات التجارية العادية. تركز هذه القواعد إما على الاختراق الأولي لنظام أو تقنية يمكن أن تؤثر بشدة على مؤسسة (مثل الكشف عن بيانات الاعتماد أو برامج الفدية). وهي تغطي جزءًا كبيرًا من سطح الهجوم الشائع وتركز على إعاقة التقنيات المعروفة المستخدمة لاختراق الأصول.
يستغل Dent العديد من الثغرات الأمنية لتجاوز هذه الضوابط التقييدية لتنفيذ حمولات على نقطة النهاية دون أن يتم حظرها أو اكتشافها بشكل فعال بواسطة مستشعرات Microsoft Defender Advanced Threat Protection. يوضح المقال أعلاه هذه الثغرات الأمنية التي لا تزال موجودة في Microsoft Defender Advanced Threat Protection حتى بعد الإفصاح.
الخطوة الأولى كالعادة هي استنساخ المستودع، ثم بناؤه
go build Dent.go
./Dent -h
________ __
\______ \ ____ _____/ |_
| | \_/ __ \ / \ __\
| | \ ___/| | \ |
/_______ /\___ >___| /__|
\/ \/ \/
(@Tyl0us)
"Call someone a hero long enough, and they'll believe it. They'll become it.
They have no choice. Let them call you a monster, and you become a monster."
Usage of ./Dent:
-C string
Name of the COM object.
-N string
Name of the XLL playload when it's writen to disk.
-O string
Name of the output file. (default "output.txt")
-P string
Path of the DLL for your COM object. (Either use \\ or '' around the path)
-U string
URL where the base64 encoded XLL payload is hosted.
-show
Display the script in the terminal.
هذا الإطار مصمم لاستغلال الثغرات الأمنية والقصور في Microsoft Defender Advanced Threat Protection، ولهذا السبب لا يقوم فعليًا بتوليد أي حمولات/غرسات. لتوليد تلك، يمكنك استخدام عدد كبير من الأدوات المتاحة للجمهور، ومع ذلك، تم إجراء جميع الأبحاث والتطوير والاختبار باستخدام ScareCrow. لا تعتمد Microsoft Defender Advanced Threat Protection على خطافات مساحة المستخدم (userland hooking) للتتبع عن بُعد، بل تستخدم آليات أخرى متنوعة مثل استدعاءات النواة (kernel callbacks). من الاختبارات، يعمل هذا الإطار بشكل ممتاز لتجاوز Microsoft Defender Advanced Threat Protection لتنفيذ shellcode.
في وقت الإصدار، هناك حاليًا تقنيتان. سأقوم بإضافة تقنيات مختلفة تستخدم هذه الثغرات بطرق مختلفة بشكل دوري، لذا يرجى البقاء على اطلاع للمزيد.
غالبًا ما يتم إنشاء كائنات COM عند تثبيت تطبيق على نظام. بمجرد إنشائها، يمكن لأي تطبيق أو برنامج نصي استدعائها، ولكن هذه ليست الطريقة الوحيدة لإنشائها. عن طريق تعديل/إنشاء مفاتيح التسجيل في قسم HKEY_CLASSES_ROOT في سجل ويندوز، يمكننا إنشاء كائن COM يشير إلى shellcode الخاص بنا على النظام. وهذا يعني أن أي تطبيق أو برنامج نصي يمكنه استخدام COM يمكنه استدعاؤه، لتنفيذ الـ shellcode.
يعمل هذا بسبب كيفية عمل دالة CoCreateInstance. تُستخدم CoCreateInstance لإنشاء وتهيئة كائنات COM استنادًا إلى CLSID (معرف فريد عالميًا يُستخدم لتحديد فئة كائن COM محددة). تقوم هذه الدالة بسحب المعلومات لتنفيذ الاستدعاء باستخدام القيم المخزنة في مفاتيح التسجيل. يمكن العثور على قيم CLSID هذه في مسار HKEY_CLASSES_ROOT\CLSID\ في السجل. ومع ذلك، قبل أن تتمكن عملية من استدعاء CLSID، يجب أن تعرف قيمة CLSID ذلك. يتم ذلك عن طريق إجراء استعلام تسجيل أولاً للبحث عن كائن COM في HKEY_CLASSES_ROOT\<اسم كائن COM>، وإذا كان موجودًا، سيتم إجراء استعلام تسجيل ثانٍ للحصول على قيمة CLSID المخزنة في المجلد الفرعي.
يُظهر الفحص الإضافي للمجلدات الفرعية للسجل أن أذونات قيم CLSID ليست متسقة. تسمح الغالبية العظمى من كائنات COM المخزنة هنا بإذن "التحكم الكامل" فقط للمثبت الموثوق (Trusted Installer). المثبت الموثوق هو حساب خدمة يمتلك الموارد لحمايتها، حتى من المسؤولين. يهدف هذا إلى ضمان أنه حتى إذا حصل المهاجم على امتيازات إدارية، لا يمكن التلاعب بالموارد بشكل ضار. لسوء الحظ، تسمح الكثير من كائنات COM لأي شخص في مجموعة المسؤولين بإذن "التحكم الكامل". بالإضافة إلى ذلك، يسمح مفتاح CLSID الجذر لمجموعة المسؤولين بأذونات "التحكم الكامل" بدلاً من NT AUTHORITY\System أو المثبت الموثوق. لهذا السبب، في سياق مرتفع (elevated context)، يمكننا إنشاء أو حتى تعديل قيم كائنات COM محددة.
مهم
إنشاء مفاتيح التسجيل هذه يعمل فقط إذا قمت بتشغيلها في سياق مرتفع. النقر المزدوج على هذا من خلال واجهة المستخدم الرسومية لن ينفذ ملف .VBS في سياق مرتفع حتى لو كنت مسؤولاً. يُوصى بتشغيله من شل إداري أو موجه أوامر. ومع ذلك، بمجرد إنشاء المفاتيح، يمكن لأي تطبيق استدعاء كائن COM هذا تحت أي سياق.
لاستخدام حمولة ScareCrow مع هذا النوع من التجاوز، يمكنك تشغيل الأمر التالي:
./ScareCrow -I <path to your raw stageless shellcode> -domain <domain name> -Loader dll
بمجرد أن يكون لديك الحمولة، استخدم العلم -N لاسم الحمولة عند كتابتها على القرص، والعلم -C لاسم كائن COM، والعلم -I للموقع الذي سيتم الكتابة إليه، وأخيرًا العلم -O لملف الإخراج لتخزين المحتوى.
يولد هذا الخيار كتلة من الكود لتجاوز عدة قواعد ASR لتنزيل shellcode وكتابته على القرص وتحميله وتنفيذه، متجاوزًا ضوابط الوقاية الخاصة بـ ASR. يتم ذلك باستخدام كائن COM الخاص بـ Excel.Application الذي يمثل تطبيق Excel بأكمله، ولكن في شكل آلي، ويسمح بالتفاعل البرمجي معه. نظرًا لأن هذا لا يزال Excel، فإنه لا يؤدي إلى تشغيل قاعدة ASR. وذلك لأنه عندما نستدعي Excel.Application، نرى أنه ينشأ تحت عملية مضيف الخدمة (Svchost.exe) وليس عملية WinWord.exe. بينما Svchost.exe هي عملية على مستوى النظام تُستخدم لاستضافة خدمات ويندوز متعددة، فإن العملية الفرعية المنشأة (Excel.exe) لم تكتسب امتيازات على مستوى النظام.
نظرًا لأننا أنشأنا كائن COM كان تطبيقًا كاملاً، فقد تم إنشاء عملية Excel تحت Svchost.exe بحيث يمكن التعامل معها بشكل صحيح لمنع أي عدم استقرار في عملية WinWord.exe. على الرغم من أن هذه العملية تحت Svchost.exe، هناك تحدٍ آخر يجب مواجهته: تنفيذ shellcode. نظرًا لأن التنفيذ الثنائي أو استخدام WinAPI داخل ماكرو سيؤدي إلى تشغيل قواعد ASR أخرى، فإن هذا يحد مما يمكننا فعله دون تشغيل قاعدة ASR أو الوقوع في مكون EDR الخاص بـ WDAPT. هنا تتألق ملفات DLL. إذا تم تجميع حمولة قائمة على DLL مع وظائف التصدير الصحيحة، فيمكن استخدامها كإضافة Office والتي عند تحميلها، ستقوم تلقائيًا بتشغيل shellcode. للقيام بذلك، يمكننا استخدام وظيفة RegisterXLL الخاصة بـ Excel. تقوم وظيفة RegisterXLL بتحميل إضافة XLL إلى الذاكرة، وتسجيلها وتنفيذها تلقائيًا. ملفات XLL هي في الأساس ملفات DLL تعتمد على Excel.
للحصول على المحتوى على النظام، يمكننا استخدام كائن COM آخر (Microsoft.XMLHTTP)، للحصول على القدرة على تنفيذ طلب HTTP، في هذه الحالة، طلب GET HTTP إلى عنوان URL. يوفر كائن COM الثاني (ADODB.stream) القدرة على قراءة/كتابة بايتات من تيار البيانات. من خلال الجمع بين كائني COM، يمكن للمهاجم طلب مورد بعيد عبر طلب GET HTTP وكتابة الاستجابة (في هذه الحالة، الملف نفسه) على القرص. يتم ذلك باستخدام كائن COM (ADODB.stream) مرة أخرى للتعامل مع قراءة/كتابة بايتات تيار البيانات. يسمح كائن COM الثاني (Microsoft.XMLDOM) بقراءة البيانات المخزنة في ملف. يسمح كائن XMLDOM بتعيين نوع البيانات (في هذه الحالة، base64) وبمجرد فتحها وتخزينها في سلسلة نصية بنوع البيانات المناسب، يمكن لكائن ADODB.stream كتابة سلسلة الكود على القرص باستخدام نوع بيانات مختلف (في هذه الحالة، BinaryStreamType)، محولاً سلسلة base64 مرة أخرى إلى شكل ثنائي.
لاستخدام حمولة ScareCrow مع هذا النوع من التجاوز، يمكنك تشغيل الأمر التالي:
./ScareCrow -I <path to your raw stageless shellcode> -domain <domain name> -Loader excel -O <Output filename>
بمجرد الإنشاء، انسخ السطرين 13 و14 من الملف المُخرَج، وادمجهما معًا، مع التأكد من إزالة:
var <اسم المتغير>; في نهاية كل سطر
بمجرد أن يكون لديك الحمولة المشفرة، استخدم العلم -N لاسم الحمولة عند كتابتها على القرص، والعلم -U لعنوان URL الذي سيتم استضافة الحمولة المشفرة عليه (مثل https:///)، والعلم -F لاسم الملف الذي يستضيفه الموقع. الكود المُخرج مصمم للعمل في مستند ماكرو .
من خلال التحقيق الإضافي، لوحظ أن الأمر ليس فجوة في مستشعرات WDATP، بل أن WDATP لديه بالفعل رؤية لهذا النشاط، ولكن يتم تجاهله. من خلال الجدول الزمني لأحداث نقطة النهاية لـ WDATP بحثًا عن أي إشارة إلى Appwiz.xll، لاحظنا أن WDATP سجل حدث "إنشاء ملف" عندما أنشأ Word الملف AppWiz.xll. من المهم ملاحظة أن ملفات .XLL قابلة للتنفيذ.
11/20/2020 - تطوير البحث وكتابة المقال.
03/14/2021 - تقديم مستند إفصاح أولي لـ Microsoft يوضح المشكلات المحددة.
03/31/2021 - اعترفت Microsoft وأقرت بأن الثغرات المتعلقة بإنشاء عملية Office فرعية وكتابة الملفات على القرص كانت ثغرات حقيقية وبدأت العمل على المعالجة. ومع ذلك، اعتُبرت التناقضات في أذونات السجل ليست ثغرة بسبب اشتراط الامتيازات المرتفعة.
04/21/2021 - أبلغت Microsoft المؤلف أن بناء التوقيع 1.333.1055.0 الذي صدر في 03/22/2021 و 1.335.1321.0 الذي صدر في 04/21/2021 يحتوي على الكشف عن الثغرات المستندة إلى تطبيقات Office وأغلقت القضية.
04/22/2021 - قام المؤلف بإعادة اختبار نفس التقنيات ووجد أن الثغرات لا تزال موجودة.