baton drop (CVE-2022-21894): ثغرة تجاوز ميزة أمان التمهيد الآمن

تسمح تطبيقات تمهيد Windows للإعداد truncatememory بإزالة كتل من الذاكرة تحتوي على نطاقات "مستمرة" من البيانات المسلسلة من خريطة الذاكرة، مما يؤدي إلى تجاوز التمهيد الآمن.

• سيزيل عنصر BCD truncatememory كل الذاكرة الواقعة فوق عنوان فيزيائي محدد من خريطة الذاكرة.
• يتم تنفيذ ذلك لكل تطبيق تمهيد أثناء التهيئة، قبل قراءة سياسة التمهيد الآمن المسلسلة من الذاكرة.
• لذلك، يمكن استخدام هذا العنصر لإزالة سياسة التمهيد الآمن المسلسلة من خريطة الذاكرة.
• سيسمح هذا باستخدام إعدادات خطيرة في تطبيق تمهيد (bootdebug, testsigning, nointegritychecks)، مما يكسر التمهيد الآمن.

تم إصلاح هذه المشكلة بتغييرين مختلفين:

• بعد محاولة تحميل سياسة تمهيد آمن مسلسلة، إذا لم يتم تحميل أي سياسة، وكان التمهيد الآمن مفعّلاً، ولم يتم تحميل تطبيق التمهيد مباشرةً بواسطة البرنامج الثابت UEFI، ولم يكن تطبيق التمهيد هو bootmgr، فإن تهيئة تطبيق التمهيد تفشل.
• عند تحميل تطبيق تمهيد، إذا كان يحتوي على مورد VERSIONINFO يتضمن OriginalFilename، وإذا كان هذا الاسم مضمنًا في قائمة حظر (تحتوي على bootmgr.exe و hvloader.exe؛ في Nickel، تمت إضافة hvloader.efi ولكن هذا التغيير لم يُنقل إلى الإصدارات السابقة)، يفشل التحميل.
  • في Windows 8 و Windows 8.1، لا يتم تضمين hvloader.exe في قائمة حظر winload - كان مضمنًا في الأصل، مما كسر تحميل Hyper-V!
  • منذ Windows 10 الإصدار 1809، إذا تم تعيين بت معين من الأعلام (يُستخدم مع عنصر flightedbootmgr لتحميل bootmgr من القرص)، فإن OriginalFilename مطلوب أن يكون bootmgr.exe.

الاستغلال

يحتاج المهاجم إلى ضمان أن يتم تخصيص سياسة التمهيد الآمن المسلسلة فوق عنوان فيزيائي معروف.

• افتراضيًا، يتم تخصيصها في أقل عنوان ممكن.
• في الأصل، يتم تخصيص سياسة التمهيد الآمن المسلسلة بعد تحميلها، قبل استخدام أي إعدادات محمّلة من BCD.
  • منذ RS1، يتم تخصيص سياسة التمهيد الآمن المسلسلة عند تحميل تطبيق تمهيد.
  • منذ RS2، يتم تحرير أي سياسة تمهيد آمن مسلسلة موجودة عند تسلسل سياسة تمهيد آمن.
• تتم إعادة تخصيص سياسة التمهيد الآمن المسلسلة إذا كان osdevice لإدخال BCD، عند تحميل تطبيق تمهيد، قسمًا مشفرًا بـ BitLocker حيث تم اشتقاق VMK باستخدام TPM.
  • يمكن تزييف ذلك بتعيين البت 0 من أعلام المفتاح بعد فك ختم TPM بنجاح؛ يمكن تعيين هذا البت يدويًا في بيانات BitLocker الوصفية، مع إضافة بيانات وصفية إضافية لتحديد أن التمهيد الآمن يُستخدم للتحقق من السلامة.

يمكن استخدام عنصر avoidlowmemory لضمان أن جميع تخصيصات الذاكرة الفيزيائية تكون فوق عنوان فيزيائي محدد:

• منذ Windows 10، يُحظر هذا العنصر إذا كان VBS مفعّلاً، ولكن نظرًا لأنه يُستخدم أثناء تهيئة تطبيق التمهيد، قبل قراءة سياسة التمهيد الآمن المسلسلة من الذاكرة، يمكن استخدام تحميل bootmgr وتحديد مسار BCD مخصص (باستخدام عنصر bcdfilepath المعروف أيضًا باسم custom:22000023) لتجاوز ذلك.
• إذا كان BitLocker موجودًا على وحدة تخزين نظام التشغيل، أو كان النظام المستهدف يعمل بـ TH1 أو TH2، فإن هذه الطريقة ستفشل؛ لذلك من الممكن أيضًا تشغيل الهجوم مرة واحدة باستخدام bootmgr من Windows 8.x لتعطيل VBS ثم العودة إلى أداة التمهيد الأصلية.
  • غيّر Windows 10 تهيئة تطبيق التمهيد لتثبيت جميع قيم PCR الخاصة بـ TPM مرة واحدة، لذلك سيفشل bootmgr من Windows 8.x في فك ختم VMK على نظام Windows 10+.

يمكن تحميل hvloader.efi مع عنصر nointegritychecks لتحميل mcupdate.dll موقّع ذاتيًا، حيث سيتم استدعاء نقطة الدخول الخاصة به قبل ExitBootServices.

بدلاً من ذلك، على الأنظمة غير AMD64، يمكن استخدام winload.efi قبل TH2 مع عنصر testsigning؛ وهذا يسمح بالملفات الثنائية الموقعة ذاتيًا التي تحتوي على EKU szOID_NT5_CRYPTO في الشهادة.

على أنظمة ARMv7، سيكون من الضروري تحميل hal.dll موقّع ذاتيًا ومصححًا مع استيراد إلى mcupdate.dll للحصول على تنفيذ التعليمات البرمجية.

على أنظمة x86 و AMD64، يجب أن يكون اسم الملف الذي يُحمَّل كـ mcupdate.dll هو mcupdate_*.dll، حيث * هي سلسلة الشركة المصنعة CPUID (GenuineIntel, AuthenticAMD إلخ).

على أنظمة ARM64، لا يمكن استخدام هذه التقنية لأن أقدم إصدار إنتاج موقّع متاح هو WinPE من RS2؛ وبالتالي، لا يمكن حاليًا سوى تنفيذ تعليمات برمجية مقيد (tethered) باستخدام bootdebug.

الملفات المرفقة

يتضمن هذا المستودع الملفات التالية:

• يتم توفير الكود المصدري لحمولة بسيطة. تنتظر هذه الحمولة حدوث مقاطعة إلى ما لا نهاية، لأنه بدون العثور على دوال ومتغيرات مثيرة للاهتمام في تطبيق التمهيد المستدعي، يستحيل فعل أي شيء آخر.
  • نظرًا لأن mcupdate.dll يعمل على عنوان افتراضي مع تمكين الترحيل (paging)، يستحيل استدعاء دوال EFI مباشرةً (يجب تعطيل الترحيل لاستدعاء دوال EFI، والعودة إلى عنوان افتراضي مع تعطيل الترحيل لا تؤدي إلى نتيجة جيدة).
  • لاستدعاء دوال EFI، ستحتاج الحمولة إلى استدعاء BlImgLoadPEImageEx أو BlImgLoadPEImageFromSourceBuffer مع تعيين البت 0 في الأعلام لتحميل حمولة إضافية على تعيين 1:1 بين العنوان الفيزيائي والعنوان الافتراضي.
    • بدلاً من ذلك، يمكنها استدعاء BlImgAllocateImageBuffer مع تعيين نفس البت لتخصيص ذاكرة على تعيين 1:1 بين العنوان الفيزيائي والعنوان الافتراضي؛ ثم تحميل حمولة بنفسها (أو إعادة تعيين نفسها هناك).
• ملف ISO يستغل هذه المشكلة على AMD64 باستخدام bootmgfw من Windows 8 RTM و hvloader من TH1 RTM.
  • الحمولة المستخدمة هنا تطبع رسالة على الشاشة باستخدام دالة من hvloader تم الحصول عليها عبر إزاحة ثم تدخل في حلقة لا نهائية.
• ملف ISO يستغل هذه المشكلة على AMD64 باستخدام bootmgr من RS1 و hvloader من TH1 RTM.
• ملف ISO يستغل هذه المشكلة على AMD64 باستخدام bootmgr الإصدار 19041.1081 و hvloader من TH1 RTM.

خاتمة

يمكن استخدام هذه المشكلة لتفريغ مفاتيح BitLocker (حيث يُستخدم التمهيد الآمن للتحقق من السلامة).

• على الرغم من أن ذلك ممكن، لن يتم الكشف عن الطريقة الدقيقة للحصول على تنفيذ التعليمات البرمجية باستخدام مفاتيح BitLocker المشتقة لوحدة تخزين عشوائية في الذاكرة.

إصلاح هذه المشكلة أصلح أيضًا مشكلة أخرى ليس لها CVE.

• يتجاهل bootmgr أي جدول مفاتيح BitLocker موجود بالفعل في الذاكرة ويخصص جدولًا جديدًا، دون مسح القديم.
  • لذلك، يمكن للمهاجم تحميل نسخة bootmgr من RS2+ من bootmgr (تحديد osdevice عشوائي حيث يُستخدم التمهيد الآمن للتحقق من السلامة)، ثم التمهيد إلى WinPE، وتحميل برنامج تشغيل معروف بثغراته، واستخدامه للبحث عن جدول مفاتيح BitLocker الموجود في الذاكرة الفيزيائية وتفريغه.

لم يتم إبطال أي تطبيق تمهيد معروف بثغراته حتى الآن.

• حتى يحدث الإبطال، يمكن للمهاجم ببساطة إحضار أدوات التمهيد المعرضة للخطر الخاصة به.
• سيؤدي الإبطال إلى فشل جميع وسائط تثبيت/استرداد Windows الموجودة، والنسخ الاحتياطية القديمة، في التمهيد.
  • سيحدث فشل التمهيد حتى مع تعطيل التمهيد الآمن بسبب قيام bootmgr بالتحقق من توقيعه الخاص.

تحديث (2023-05-10)

حدث إبطال غير مكتمل، وCVE أخرى (CVE-2023-24932). لا تزال هناك ملفات bootmgfw معرضة للخطر لم يتم إبطالها، بالإضافة إلى تصحيحات إضافية تعالج فقط الحالة التي يقوم فيها bootmgr بتحميل bootmgr. لم يتطلب الأمر سوى bootkit مُجمَّع بالنسخ واللصق لدفع MS إلى التحرك ;)
إذا كنت مبدعًا بما يكفي، فستجد طريقة للالتفاف حول إبطال أكثر من 2000 ملف bootmgfw ;)