هجمات BitLocker

قائمة بالهجمات العامة على BitLocker. أي هجوم عام لديه القدرة على مهاجمة BitLocker ولكن الطريقة الدقيقة ما تزال غير عامة (مثل baton drop) خارج النطاق.

معظم الهجمات تكون للحالات التي يكون فيها VMK مغلقًا بواسطة TPM فقط، وهو الإعداد الافتراضي، وهو ما يستخدمه BitLocker التلقائي إلى جانب إيداع مفتاح الاسترداد في حساب Microsoft.

افتراضيًا، بدءًا من Windows 8، يتم استخدام التحقق من تكامل Secure Boot إذا كان Secure Boot ممكّنًا.

إذا كان يجب عليك إغلاق VMK بواسطة TPM فقط، فإن الإعداد الأكثر أمانًا لذلك هو استخدام التحقق من التكامل التقليدي مع PCRs 0 و2 و4 و7 و11 (وأيضًا إبقاء نظامك محدثًا بالكامل).
يرجى ملاحظة أن هذا يحمي فقط من الهجمات البرمجية.

المحتويات

• الهجمات على الأجهزة
• الهجمات البرمجية

الهجمات على الأجهزة

الهجمات على الأجهزة عادةً ما تكون مفيدة فقط عندما يكون لدى المهاجم وصول فعلي إلى نظام حيث يكون VMK مغلقًا بواسطة TPM فقط.

الهجمات البرمجية

الهجمات البرمجية عادةً ما تكون ثغرات في bootmgr، أو تطبيق إقلاع آخر حيث يكون الاستغلال ممكنًا مع مفاتيح BitLocker المشتقة في الذاكرة لأي وحدة تخزين.
عندما يمكن الحصول على تنفيذ كود داخل تطبيق إقلاع، قد يكون من الممكن لمهاجم "المنظف الخبيث" تثبيت bootkit يعمل نفسه مع مفاتيح مشتقة في الذاكرة (أو عندما يمكن اشتقاق المفاتيح بعد)، وبالتالي اختراق نظام يُستخدم فيه كلمة مرور أو مفتاح تشغيل بدلاً من TPM أو بالإضافة إليه.

dangerous association

النظام المعرض للخطر سيكون لديه تحديثات مايو 2022 أو يونيو 2022 مثبتة، ولكن ليس أي تحديثات لاحقة.

GUID الخيارات المرتبطة هو جزء من البيانات المجزأة، لذلك يجب وضع علامة على عنصر الجهاز المستخدم كغير مُتحقق منه.
لا توجد عناصر يمكن استخدامها على Windows 7 والإصدارات الأقدم (على الرغم من أنه عند استخدام إعدادات مخصصة غير افتراضية، قد يظل ذلك ممكنًا).
على Windows 8 والإصدارات الأحدث، لا يتم التحقق من osloader!osdevice افتراضيًا، وبالتالي يمكن استخدامه.
أسهل طريقة لاستغلال هذا هي استخدام محرر الأجهزة الخام في BCD، bcdeditmod، على الرغم من أن تحرير سجل BCD يدويًا ممكن أيضًا (اكتشف ذلك بنفسك).

يتضمن الاستغلال:

• أخذ BCD من جهازك المستهدف، وإنشاء عنصري جهاز
• نسخ osdevice من {default} إلى العنصر الأول
• تعيين GUID الخيارات المرتبطة في {default}!osdevice إلى عنصر الجهاز الأول
• تعيين GUID الخيارات المرتبطة في {first}!osdevice إلى عنصر الجهاز الثاني
• تعيين أي خيارات "خطيرة" (مثل debug) في عنصر الجهاز الثاني
• الإقلاع إلى الجهاز المستهدف باستخدام هذا BCD ونفس ملف bootmgfw الثنائي الذي كان يستخدمه

bitpixie

استمرت هذه الثغرة لأكثر من 17 عامًا، وأقدم إصدار معروف تم تقديمها فيه هو 6.0.5231.2 (winmain_idx03.051004-2120) من أكتوبر 2005.
عند استخدام التحقق من تكامل Secure Boot، سيظل هجوم خفض الإصدار يعمل لاستغلال هذه الثغرة.قم بإعداد خادم إقلاع PXE مع ملف bootmgfw.efi به ثغرة (حيث يُستخدم التحقق القديم من السلامة، يجب أن يكون هذا هو bootmgfw.efi من الجهاز الهدف) مع إعادة تسميته بشكل صحيح للإقلاع عبر EFI.

بالنسبة إلى BCD، أعدّ إدخالًا افتراضيًا واحدًا حيث يكون device هو osdevice المشفّر عبر BitLocker؛ وpath هو "\"؛ وتسلسل استرداد.

يجب أن يشير تسلسل الاسترداد إلى إدخال startup واحد، حيث يكون device هو boot، وpath يشير إلى تطبيق EFI لتشغيله (من خادم PXE)؛ ويكون pxesoftreboot مفعّلًا.

عند تعطيل Secure Boot، يمكن أن يكون تطبيق EFI هذا مجرد تطبيق لفحص الذاكرة الفعلية بحثًا عن جدول مفاتيح BitLocker لتفريغه.

عند تمكين Secure Boot، يمكن لتطبيق EFI هذا استخدام تجاوز معروف لـ Secure Boot (حيث يكون الوصول الفعلي مطلوبًا إذا لزم الأمر).
لاستغلال تطبيق إقلاع من Windows بهذه الطريقة، ستحتاج إلى استبدال BCD بملفك الثاني على خادم PXE.
وهذا يعني الضغط على مفتاح سهم أثناء بدء تشغيل bootmgr لإجبار قائمة الإقلاع على الظهور؛ ثم استبدال BCD على خادم PXE في تلك اللحظة.

فك التشفير بضغطة زر

يتضمن الاستغلال ما يلي:

• قم بتفريغ osvolume المحمي عبر BitLocker إلى صورة قرص. تؤدي هذه الطريقة للحصول على FVEK إلى فقدان بيانات فعلي!
• أقلع إلى WinRE بأي وسيلة (افرض ذلك عبر إصلاح بدء التشغيل إذا لزم الأمر، أو ببساطة عيّن عنصر bootsequence في BCD، إلخ).
• ابدأ إعادة تعيين (استكشاف الأخطاء وإصلاحها -> إعادة تعيين هذا الكمبيوتر -> إزالة كل شيء). من الأسرع اختيار "إعادة التثبيت المحلية". تأكد من اختيار "إزالة ملفاتي فقط".
  • سيطلب اختيار "الاحتفاظ بالملفات" مفتاح الاسترداد.
  • إذا لم تكن بيئة WinRE في النظام قابلة للاستغلال، فسيطلب أيضًا مفتاح استرداد.
• عندما تصل عملية إعادة التعيين إلى ~98%، قم بإيقاف تشغيل النظام بالقوة (بالضغط مع الاستمرار على زر الطاقة لمدة 7 ثوانٍ / إلخ).
• أعد تشغيل النظام، يجب أن يقلع إلى WinRE مرة أخرى ويعرض خطأً. يجب أن يؤدي تجاهل الخطأ إلى إعادة التشغيل.
• عندما ترى شاشة "التحديث" الزرقاء، اضغط Shift+F10 للوصول إلى شل.
• نفّذ manage-bde -pause C: متبوعًا بـ manage-bde -protectors -delete C:
• أوقف تشغيل النظام بالقوة (مرة أخرى).

عند هذه النقطة، ستحتوي بيانات BitLocker الوصفية على القرص على VMK بنص واضح.
قم بتفريغه، واستخدم VMK هذا لفك تشفير FVEK.
يمكن استخدام FVEK الذي تم فك تشفيره على صورة القرص التي أُنشئت مسبقًا لفك تشفير القسم.

يرجى ملاحظة: نجحت فقط في استغلال هذه المشكلة على Windows 10 في ظروف محددة جدًا (BitLocker عبر TPM فقط بدون مفتاح استرداد). ومع ذلك، نجح آخرون في استغلال هذه المشكلة باستخدام WinRE قابلة للاستغلال على Windows 11 (Nickel).

تسريب الرام

على حد علمي، وُجدت هذه الثغرة منذ وجود مدير الإقلاع نفسه - يبدو أنها موجودة منذ وقت مبكر يصل إلى 6.0.5098.0 (winmain_beta1.050628-1740) من يونيو 2005، على الرغم من أن ذلك يسبق BCD وبالتالي سيكون الاستغلال مختلفًا في الإصدارات المبكرة جدًا. يبدو أن الكود ذي الصلة موجود أيضًا في وقت سابق (يبدو أن الكود المتعلق بالقرص الرامي (ramdisk) هو نفسه في الإصدار 5048 من أبريل 2005)، لكن الإصدار 5098 هو أقدم إصدار تم تفريغه يحتوي على BitLocker بشكل ما.

لاستغلال ذلك، تحتاج إلى إعداد إدخال افتراضي وتسلسل استرداد كما في bitpixie. والغرض من ذلك هو اشتقاق المفاتيح لجهاز نظام التشغيل عند تحميل الملف.

يجب أن يحتوي تسلسل الاسترداد على إدخال جهاز إضافي لإعداد القرص الرامي. استخدم bcdeditmod لذلك. استخدم عنصرًا مخصصًا هنا مثل custom:21100000. مثال على إدخال جهاز يمكن استخدامه هنا هو !raw:block[ram[part2[hd[gpt[{D2E23617-2338-4685-A2D7-F3133312E12E}]],gptsig[{1B85332B-AD73-4D9A-BFC3-B39443D3DFE4}]],:\hiberfil.sys:]] - ستحتاج إلى استبدال جهاز الكتلة part2 هنا بالجهاز الموجود في BCD لنظامك الهدف.

يمكن بعد ذلك تفريغ الملف من الذاكرة باستخدام أي طريقة تناسبك. أفضّل استخدام winload الأقدم للوصول إلى mcupdate الموقّع ذاتيًا عبر قائمة الخيارات المتقدمة، لكن هناك خيارات أخرى متاحة (على سبيل المثال، إعادة تشغيل ناعمة عبر PXE إلى نظام تشغيل تابع لجهة خارجية؛ يمكن تفريغ الذاكرة من WinPE باستخدام bugcheck أو برنامج تشغيل معروف بوجود ثغرة فيه، لكن winload سيضع علامة على منطقة الذاكرة على أنها خالية في خريطة ذاكرة NT لذلك قد يتم استبدالها دون إعدادات أخرى لتحديد تلك الذاكرة على أنها تالفة/إلخ في winload).

تم تضمين تنفيذ لإثبات المفهوم لأسلوبي المفضل في هذا المستودع باسم ramleak.zip. اقرأ ملف readme المرفق لتعليمات الاستخدام.

تحية إلى Maxim Suhanov، فقد كان هذا مستوحىً من قراءة شرح CrashXTS ومعرفة طريقة أخرى ربما لتفريغ hiberfil.sys.

والآن أفكاري الخاصة حول هذه الثغرة وحول yellowkey:

كانت هذه هي المرة الأولى التي أواجه فيها مشكلة حقيقية مع التقديم إلى MSRC، وكانت في الأساس سوء فهم من جانبهم يتعلق بـ Secure Boot. ونظرًا لأن ثغرة bitlocker أخرى من نوع 0day تم كشفها، قررت إصدار هذا الآن، لقد احتفظت به لما يقارب عامًا وأنا أتساءل ماذا أفعل به.

على عكس yellowkey، لن أطلق تصريحات مبالغًا فيها حول اعتبار ذلك "بابًا خلفيًا"، ففي رأيي لا أعتقد أن yellowkey باب خلفي، فالمكوّن ذو الصلة يتعلق بـ WinPE (ليس خاصًا بـ WinRE)، والثغرة الرئيسية هناك هي حذف winpeshl.ini للوصول إلى مسار الكود هذا، ويمكنني أن أفهم تمامًا لماذا اعتقدت Microsoft أن حذفه في سيناريو WinRE + bitlocker لم يكن ممكنًا.

وبما أن تحميل قرص رامي من قسم مشفّر عبر BitLocker هو في الواقع ميزة في بيئة الإقلاع، وعلى الرغم من أنني اضطررت إلى استخدام حيلة موجودة مسبقًا لجعلها تعمل فعليًا، يمكن لأشخاص آخرين أيضًا أن يقولوا إن هذا باب خلفي إذا أرادوا، لكنني لن أذهب إلى هذا الحد. بيئة الإقلاع معقدة (وتستمر في النمو، فلم يعد أحدث bootmgfw_ex.efi يتسع لصورة بحجم 2.88MB - نهاية حقبة)، وقد تم اكتشاف العديد من الثغرات بسبب كيفية تفاعل ميزات معينة مع بعضها البعض.