عدد الثغرات الأمنية UEFI التي تم اكتشافها في السنوات الأخيرة والفشل في تصحيحها أو إبطال الثنائيات الضعيفة خلال فترة زمنية معقولة لم يمر مرور الكرام من قبل الجهات الفاعلة في التهديد. نتيجة لذلك ، أصبحت أول مجموعة تمهيد UEFI معروفة للجمهور تتجاوز ميزة أمان النظام الأساسي الأساسية - التمهيد الآمن لـ UEFI - أصبحت الآن حقيقة واقعة. في منشور المدونة هذا ، نقدم أول تحليل عام لمجموعة التمهيد UEFI هذه ، والتي يمكنها العمل حتى على أنظمة Windows 11 المحدثة بالكامل مع تمكين UEFI Secure Boot. تؤدي وظائف مجموعة bootkit وميزاتها الفردية إلى الاعتقاد بأننا نتعامل مع مجموعة bootkit المعروفة باسم اللوتس الأسود, حزمة التمهيد UEFI التي يتم بيعها في منتديات القرصنة مقابل 5,000 دولار منذ أكتوبر 2022 على الأقل.

تعد مجموعات تمهيد UEFI تهديدات قوية للغاية ، حيث تتمتع بالتحكم الكامل في عملية تمهيد نظام التشغيل ، وبالتالي فهي قادرة على تعطيل آليات أمان نظام التشغيل المختلفة ونشر حمولات وضع kernel الخاصة بها أو وضع المستخدم في مراحل بدء تشغيل نظام التشغيل المبكرة. هذا يسمح لهم بالعمل خلسة للغاية وبامتيازات عالية. حتى الآن ، تم اكتشاف عدد قليل فقط في البرية ووصف علنًا (على سبيل المثال ، متعدد عينات EFI الخبيثة اكتشفنا في عام 2020 ، أو مجموعات التمهيد UEFI المميزة بالكامل مثل اكتشافنا العام الماضي - برنامج ESPecter bootkit - أو مجموعة التمهيد FinSpy اكتشفه باحثون من Kaspersky).

قد تفقد مجموعات إقلاع UEFI التخفي عند مقارنتها بغرسات البرامج الثابتة - مثل LoJax؛ أول عملية زرع للبرامج الثابتة UEFI ، اكتشفها فريقنا في عام 2018 - حيث توجد مجموعات التمهيد في قسم قرص FAT32 يمكن الوصول إليه بسهولة. ومع ذلك ، فإن التشغيل كمحمل إقلاع يمنحهم نفس القدرات تقريبًا مثل البرامج الثابتة المزروعة ، ولكن دون الحاجة إلى التغلب على دفاعات فلاش SPI متعددة المستويات ، مثل بت حماية BWE و BLE و PRx ، أو الحماية التي توفرها الأجهزة (مثل Intel Boot Guard ). من المؤكد أن التمهيد الآمن لـ UEFI يقف في طريق مجموعات تمهيد UEFI ، ولكن هناك عددًا لا يُستهان به من الثغرات الأمنية المعروفة التي تسمح بتجاوز آلية الأمان الأساسية هذه. وأسوأ ما في ذلك هو أن بعضها لا يزال قابلاً للاستغلال بسهولة على الأنظمة الحديثة حتى وقت كتابة هذا التقرير - بما في ذلك النظام الذي استغله BlackLotus.

بدأ تحقيقنا بعدد قليل من النتائج حول ما تبين أنه مكون وضع مستخدم BlackLotus - أداة تنزيل HTTP - في القياس عن بُعد الخاص بنا في أواخر عام 2022. بعد التقييم الأولي ، قادتنا أنماط الشفرة الموجودة في العينات إلى اكتشاف ستة BlackLotus المثبتين (على كل من VirusTotal وفي القياس عن بعد الخاص بنا). سمح لنا ذلك باستكشاف سلسلة التنفيذ بأكملها وإدراك أن ما كنا نتعامل معه هنا ليس مجرد برامج ضارة عادية.

فيما يلي النقاط الرئيسية حول BlackLotus وجدول زمني يلخص سلسلة الأحداث المتعلقة به:

• إنه قادر على العمل على أحدث أنظمة Windows 11 المصححة بالكامل مع تمكين UEFI Secure Boot.
• يستغل ثغرة عمرها أكثر من عام (CVE-2022-21894) لتجاوز التمهيد الآمن لـ UEFI وإعداد استمرارية لـ bootkit. هذه هي أول إساءة استخدام معروفة علنًا لهذه الثغرة الأمنية.
• على الرغم من إصلاح الثغرة الأمنية في تحديث Microsoft لشهر يناير 2022 ، إلا أن استغلالها لا يزال ممكناً كمتضررين ، موقعة بشكل صحيح لم تتم إضافة الثنائيات إلى ملف قائمة إبطال UEFI. تستفيد BlackLotus من ذلك ، حيث تقدم نسخها الخاصة من الثنائيات الشرعية - ولكن المعرضة للخطر - إلى النظام من أجل استغلال الثغرة الأمنية.
• إنه قادر على تعطيل آليات أمان نظام التشغيل مثل BitLocker و HVCI و Windows Defender.
• بمجرد التثبيت ، فإن الهدف الرئيسي لـ bootkit هو نشر برنامج تشغيل kernel (والذي ، من بين أشياء أخرى ، يحمي bootkit من الإزالة) ، وتنزيل HTTP مسؤول عن الاتصال بـ C&C وقادر على تحميل حمولات إضافية في وضع المستخدم أو وضع kernel .
• تم الإعلان عن BlackLotus وبيعه في المنتديات السرية منذ 6 أكتوبر على الأقل^th، 2022. في منشور المدونة هذا ، نقدم دليلًا على أن Bootkit حقيقي ، وأن الإعلان ليس مجرد عملية احتيال.
• ومن المثير للاهتمام ، أن بعض مثبتات BlackLotus التي قمنا بتحليلها لا تتابع تثبيت bootkit إذا كان المضيف المخترق يستخدم أحد المواقع التالية:
  • الرومانية (مولدوفا)، ro-MD
  • الروسية (مولدوفا)، ru-MD
  • الروسية (روسيا) ، ru-RU
  • الأوكرانية (أوكرانيا) ، uk-UA
  • البيلاروسية (بيلاروسيا) ، be-BY
  • الأرمينية (أرمينيا) ، hy-AM
  • كازاخستان (كازاخستان) ، kk-KZ

يظهر الجدول الزمني للأحداث الفردية المتعلقة بـ BlackLotus في الشكل 1.

الشكل 1. الجدول الزمني للأحداث الرئيسية المتعلقة بمجموعة التمهيد BlackLotus UEFI

كما ذكرنا سابقًا ، تم بيع Bootkit في منتديات تحت الأرض منذ 6 أكتوبر على الأقل^th، 2022. في هذه المرحلة ، لم نتمكن من تحديد قناة التوزيع الدقيقة المستخدمة لنشر مجموعة التمهيد للضحايا من خلال القياس عن بعد. العدد المنخفض من عينات BlackLotus التي تمكنا من الحصول عليها ، سواء من المصادر العامة أو من القياس عن بعد لدينا ، يقودنا إلى الاعتقاد بأنه لم يبدأ الكثير من الجهات الفاعلة في التهديد باستخدامها حتى الآن. ولكن حتى يتم إبطال محمل الإقلاع الضعيف الذي يعتمد عليه BlackLotus ، فإننا نشعر بالقلق من أن الأمور ستتغير بسرعة في حالة وصول مجموعة التمهيد هذه إلى أيدي مجموعات برامج الجريمة المعروفة ، استنادًا إلى سهولة نشر مجموعة Bootkit وإمكانيات مجموعات البرامج الإجرامية للنشر برامج ضارة باستخدام شبكات الروبوت الخاصة بهم.

هل هذا حقا بلاك لوتس؟

هناك عدة مقالات أو منشورات تلخص معلومات حول BlackLotus (هنا, هنا و هنا وغيرها الكثير ...) ، كل ذلك بناءً على المعلومات التي قدمها مطور bootkit في منتديات القرصنة تحت الأرض. حتى الآن ، لم يؤكد أو يدحض أحد هذه المزاعم.

فيما يلي ملخصنا للمطالبات من المنشورات المتاحة مقارنة بما اكتشفناه أثناء الهندسة العكسية لعينات مجموعة Bootkit:

• يدعي إعلان BlackLotus على منتديات القرصنة أنه يتميز بتجاوز التمهيد الآمن المتكامل. تعد إضافة برامج تشغيل ضعيفة إلى قائمة إبطال UEFI أمرًا مستحيلًا حاليًا ، حيث تؤثر الثغرة الأمنية على المئات من محمل الإقلاع التي لا تزال مستخدمة حتى اليوم. ✅
  • صحيح: إنها تستغل CVE-2022-21894 من أجل كسر التمهيد الآمن وتحقيق الثبات على الأنظمة التي تدعم UEFI-Secure-Boot. لا تزال برامج التشغيل الضعيفة التي يستخدمها لم يتم إبطالها في الأحدث DBX، في وقت كتابة هذا التقرير.
• يدعي إعلان BlackLotus على منتديات القرصنة أن bootkit يحتوي على حماية مضمنة من Ring0 / Kernel ضد الإزالة. ✅
  • صواب: يحمي برنامج تشغيل النواة الخاص به المقابض التي تنتمي إلى ملفاته الموجودة على قسم نظام EFI (ESP) من الإغلاق. كطبقة إضافية من الحماية ، تتم مراقبة هذه المقابض باستمرار ويتم تشغيل شاشة زرقاء للموت (BSOD) إذا تم إغلاق أي من هذه المقابض ، كما هو موضح في حماية ملفات bootkit على ESP من الإزالة والقسم الخاص به.
• يدعي إعلان BlackLotus على منتديات القرصنة أنه يأتي مع ميزات مكافحة الجهاز الظاهري (anti-VM) ، ومكافحة التصحيح ، والتشويش على التعليمات البرمجية لمنع محاولات تحليل البرامج الضارة. ✅
  • صواب: يحتوي على العديد من تقنيات مكافحة VM ، ومكافحة التصحيح ، والتشويش لجعل النسخ أو التحليل أكثر صعوبة. ومع ذلك ، نحن بالتأكيد لا نتحدث عن أي اختراق أو تقنيات متقدمة لمكافحة التحليل هنا ، حيث يمكن التغلب عليها بسهولة بجهد ضئيل.
• يدعي إعلان BlackLotus على منتديات القرصنة أن الغرض منه هو العمل بمثابة أداة تنزيل HTTP. ✅
  • صواب: يعمل مكونه الأخير بمثابة أداة تنزيل HTTP ، كما هو موضح في ملف تنزيل HTTP قسم
• يدعي إعلان BlackLotus على منتديات القرصنة أن أداة تنزيل HTTP يعمل تحت حساب النظام ضمن عملية شرعية. ✅
  • صواب: يعمل برنامج تنزيل HTTP الخاص به داخل ملف WINLOGON.EXE سياق العملية.
• يدعي إعلان BlackLotus على منتديات القرصنة أنه كذلك مجموعة bootkit صغيرة بحجم 80 كيلو بايت على القرص فقط. ✅
  • صحيح: العينات التي تمكنا من الحصول عليها هي في الحقيقة حوالي 80 كيلو بايت.
• يدعي إعلان BlackLotus على منتديات القرصنة أنه يمكن ذلك تعطيل حماية أمان Windows المضمنة مثل HVCI و Bitlocker و Windows Defender وتجاوز التحكم في حساب المستخدم (UAC). ✅

بناءً على هذه الحقائق ، نعتقد بثقة عالية أن مجموعة التمهيد التي اكتشفناها في البرية هي مجموعة التمهيد BlackLotus UEFI.

نظرة عامة على الهجوم

يظهر مخطط مبسط لسلسلة التسوية BlackLotus في الشكل 2. ويتكون من ثلاثة أجزاء رئيسية:

1. يبدأ بتنفيذ برنامج التثبيت (الخطوة 1 في الشكل 2) ، وهو المسؤول عن نشر ملفات bootkit إلى قسم نظام EFI ، وتعطيل HVCI و BitLocker ، ثم إعادة تشغيل الجهاز.
2. بعد إعادة التشغيل الأولى ، استغلال CVE-2022-21894 والتسجيل اللاحق للمهاجمين مفتاح مالك الجهاز (MOK) لتحقيق الثبات حتى على الأنظمة التي تم تمكين التمهيد الآمن لـ UEFI فيها. ثم يتم إعادة تشغيل الجهاز (الخطوات 2-4 في الشكل 2) مرة أخرى.
3. في جميع عمليات التمهيد اللاحقة ، يتم تنفيذ مجموعة التمهيد UEFI الموقعة ذاتيًا وتنشر كلاً من برنامج تشغيل kernel وحمولة وضع المستخدم ، أداة تنزيل HTTP. هذه المكونات معًا قادرة على تنزيل وتنفيذ مكونات إضافية في وضع المستخدم وبرنامج التشغيل من خادم القيادة والتحكم وحماية مجموعة التمهيد من الإزالة (الخطوات من 5 إلى 9 في الشكل 2).

الشكل 2. نظرة عامة على تنفيذ برنامج BlackLotus المبسط

التحف المثيرة للاهتمام

على الرغم من أننا نعتقد أن هذا هو مجموعة التمهيد BlackLotus UEFI ، إلا أننا لم نجد أي إشارة إلى هذا الاسم في العينات التي قمنا بتحليلها. بدلاً من ذلك ، فإن الكود مليء بالإشارات إلى ملف هيجوراشي عندما يبكون سلسلة animé ، على سبيل المثال في أسماء المكونات الفردية ، مثل higurashi_installer_uac_module.dll و higurashi_kernel.sys، وكذلك في الشهادة الموقعة ذاتيًا المستخدمة للتوقيع على ملف bootkit الثنائي (كما هو موضح في الشكل 3).

الشكل 3. شهادة موقعة ذاتيًا مستخدمة بواسطة مجموعة التمهيد BlackLotus

بالإضافة إلى ذلك ، يقوم الكود بفك تشفير ولكنه لا يستخدم أبدًا سلاسل مختلفة تحتوي على رسائل من مؤلف BlackLotus (كما هو موضح في الشكل 4 - لاحظ أن hasherezade هو باحث معروف ومؤلف أدوات تحليل البرامج الضارة المختلفة) ، أو مجرد بعض الاقتباسات العشوائية من الأغاني أو الألعاب أو المسلسلات المختلفة.

الشكل 4. مثال على الرسائل التي تركها مؤلف BlackLotus في الكود

عملية التثبيت

نبدأ بتحليل مثبتات BlackLotus. يبدو أن bootkit يتم توزيعه في شكل أدوات تثبيت تأتي في نسختين - دون اتصال بالإنترنت أو عبر الإنترنت. يكمن الاختلاف بين هذين النوعين في الطريقة التي يحصلون بها على ثنائيات Windows الشرعية (ولكن المعرضة للخطر) ، والتي تُستخدم لاحقًا لتجاوز التمهيد الآمن.

• في الإصدارات غير المتصلة بالإنترنت ، يتم تضمين ثنائيات Windows في المثبت
• في الإصدارات عبر الإنترنت ، يتم تنزيل ثنائيات Windows مباشرة من متجر رموز Microsoft. حتى الآن ، رأينا أنه يتم إساءة استخدام ثنائيات Windows التالية بواسطة مجموعة التمهيد BlackLotus:
  • https://msdl.microsoft.com/download/symbols/bootmgfw.efi/7144BCD31C0000/bootmgfw.efi
  • https://msdl.microsoft.com/download/symbols/bootmgr.efi/98B063A61BC000/bootmgr.efi
  • https://msdl.microsoft.com/download/symbols/hvloader.efi/559F396411D000/hvloader.efi

الهدف من برنامج التثبيت واضح - فهو مسؤول عن تعطيل ميزات أمان Windows مثل تشفير قرص BitLocker و HVCI ، ونشر ملفات متعددة ، بما في ذلك مجموعة التمهيد الخبيثة ، إلى ESP. بمجرد الانتهاء ، فإنه يعيد تشغيل الجهاز المخترق للسماح للملفات المسقطة بأداء وظيفتها - للتأكد من أن مجموعة التمهيد UEFI الموقعة ذاتيًا سيتم تنفيذها بصمت عند كل بدء تشغيل للنظام ، بغض النظر عن حالة حماية UEFI Secure Boot.

الخطوة 0 - التهيئة والارتفاع (المحتمل)

عند تنفيذ المثبت ، فإنه يتحقق مما إذا كان لديه امتيازات كافية (على الأقل مطلوب من المسؤول) لنشر بقية الملفات إلى ESP وتنفيذ إجراءات أخرى تتطلب عملية مرتفعة - مثل إيقاف تشغيل HVCI أو تعطيل BitLocker. إذا لم يكن الأمر كذلك ، فإنه يحاول الارتقاء عن طريق تنفيذ المثبت مرة أخرى باستخدام طريقة تجاوز UAC الموصوفة بالتفصيل هنا: تجاوز UAC عبر مساعد توافق البرامج.

مع الامتيازات اللازمة ، يستمر ، في التحقق من حالة التمهيد الآمن لـ UEFI من خلال قراءة قيمة متغير SecureBoot UEFI باستخدام وظيفة Windows API المتاحة ، وتحديد إصدار Windows عن طريق الوصول مباشرة إلى KUSER_SHARED_DATA مجالات الهيكل NtMajorVersion و NtMinorVersion في الذاكرة. يقوم بذلك لتحديد ما إذا كان تجاوز التمهيد الآمن لـ UEFI ضروريًا لنشر مجموعة التمهيد على نظام الضحية (منذ إضافة دعم التمهيد الآمن لأول مرة في Windows 8 وقد لا يتم تمكينه على أي جهاز معين).

قبل المتابعة إلى الخطوات التالية ، يقوم بإعادة تسمية Windows Boot Manager الشرعي (bootmgfw.efi) ثنائي موجود في ESP: EFIMicrosoftBoot دليل ل winload.efi. تمت إعادة تسمية هذا bootmgfw.efi يتم استخدام النسخ الاحتياطي لاحقًا بواسطة bootkit لبدء تشغيل نظام التشغيل ، أو لاستعادة سلسلة التمهيد الأصلية إذا تم تلقي أمر "إلغاء التثبيت" من خادم القيادة والتحكم - المزيد في الاتصالات C & C والقسم الخاص به.

الخطوة 1 - نشر الملفات

إذا تم تمكين UEFI Secure Boot (التمهيد الآمن لـ UEFI) ، فسيستمر المثبِّت في إسقاط ملفات متعددة في ملف ESP: / EFI / Microsoft / Boot / و ESP: / system32 / الدلائل. في حين أن الأول هو دليل قياسي يستخدمه Windows ، فإن الأخير عبارة عن مجلد مخصص تم إنشاؤه بواسطة المثبت.

يتم توفير قائمة بالملفات التي تم إسقاطها بواسطة المثبت مع شرح موجز لدور كل ملف في سلسلة التنفيذ في الجدول 1. وسوف نشرح بالتفصيل كيفية عمل سلسلة التنفيذ لاحقًا ؛ الآن لاحظ فقط أنه يتم إسقاط العديد من الملفات الشرعية الموقعة من Microsoft مع الملفات الضارة.

الجدول 1. الملفات التي تم نشرها بواسطة مثبّت BlackLotus على الأنظمة التي تم تمكين التمهيد الآمن لـ UEFI عليها

في الحالات التي تقوم فيها الضحية بتشغيل إصدار Windows لا يدعم التمهيد الآمن UEFI ، أو في حالة تعطيله ، يكون النشر مباشرًا تمامًا. الشيء الوحيد المطلوب لنشر مجموعة التمهيد الخبيثة هو استبدال Windows Boot Manager الموجود (bootmgfw.efi) ثنائي في ESP: EFIMicrosoftBoot الدليل ، باستخدام تطبيق UEFI الخبيث الموقعة ذاتيًا الخاصة بالمهاجمين. نظرًا لتعطيل التمهيد الآمن لـ UEFI (وبالتالي لا يتم إجراء تحقق من النزاهة أثناء التمهيد) ، فإن الاستغلال ليس ضروريًا ويقوم برنامج UEFI الثابت ببساطة بتنفيذ مدير التمهيد الضار دون التسبب في أي انتهاكات أمنية.

الخطوة 2 - تعطيل تكامل التعليمات البرمجية المحمية Hypervisor (HVCI)

لتتمكن من تشغيل كود kernel المخصص غير الموقعة لاحقًا ، يجب على المثبت التأكد من ذلك HVCI معطل على النظام. كتب أحد زملائنا في ESET مدونة مفيدة للغاية حول هذا الموضوع في عام 2022 (برامج تشغيل kernel الموقعة - بوابة غير محمية إلى جوهر Windows):

يوفر الأمان المستند إلى المحاكاة الافتراضية (VBS) العديد من ميزات الحماية من أبرزها تكامل الكود المحمي بواسطة Hypervisor (HVCI) ، والذي يأتي أيضًا كميزة مستقلة. يفرض HVCI تكامل الكود في النواة ويسمح فقط بتنفيذ التعليمات البرمجية الموقعة. يمنع بشكل فعال إساءة استخدام برامج التشغيل الضعيفة لتنفيذ تعليمات برمجية kernel غير موقعة أو تحميل برامج تشغيل ضارة (بغض النظر عن طريقة الاستغلال المستخدمة) ويبدو أن البرامج الضارة التي تسيء استخدام برامج التشغيل الضعيفة لتحميل تعليمات برمجية ضارة كانت واحدة من الدوافع الرئيسية وراء تطبيق Microsoft لهذه الميزة.

كما هو موضح في الشكل 5 ، لتعطيل هذه الميزة ، يقوم المثبت بتعيين قيمة التسجيل الممكنة ضمن برنامج HypervisorEnforcedCodeIntegrity مفتاح التسجيل إلى الصفر.

الشكل 5. رمز مفكك للأشعة السداسية لوظيفة مثبت BlackLotus المسؤولة عن تعطيل HVCI

الخطوة 3 - تعطيل BitLocker

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

لتعطيل هذه الحماية ، يقوم مثبت BlackLotus بما يلي:

• يمشي من خلال جميع المجلدات تحت الجذر CIMV2SecurityMicrosoftVolumeEncryption WMI وفحص حالة الحماية الخاصة بهم عن طريق استدعاء GetProtectionStatus طريقة Win32_EncryptableVolume فئة WMI
• بالنسبة لأولئك الذين يحميهم BitLocker ، فإنه يستدعي DisableKeyProtectors الطريقة مع DisableCount تم ضبط المعلمة على صفر ، مما يعني أنه سيتم تعليق الحماية حتى يتم تمكينها يدويًا

مع تعطيل الحماية الضرورية ونشر جميع الملفات ، يسجل المثبت نفسه ليتم حذفه أثناء إعادة تشغيل النظام التالية ويعيد تشغيل الجهاز للشروع في استغلال CVE-2022-21894.

تجاوز التمهيد الآمن وإثبات الثبات

في هذا الجزء ، نلقي نظرة فاحصة على كيفية تحقيق BlackLotus للثبات على الأنظمة التي تم تمكين UEFI Secure Boot. نظرًا لأن سلسلة التنفيذ التي نحن على وشك وصفها معقدة للغاية ، فسوف نشرح أولاً المبادئ الأساسية ثم نتعمق أكثر في التفاصيل الفنية.

باختصار ، تتكون هذه العملية من خطوتين رئيسيتين:

1. استغلال CVE-2022-21894 لتجاوز ميزة التمهيد الآمن وتثبيت مجموعة التمهيد. يسمح هذا بتنفيذ التعليمات البرمجية التعسفية في مراحل التمهيد المبكرة ، حيث لا تزال النظام الأساسي مملوكًا للبرامج الثابتة ولا تزال وظائف UEFI Boot Services متاحة. يسمح هذا للمهاجمين بالقيام بالعديد من الأشياء التي لا ينبغي أن يكونوا قادرين على القيام بها على جهاز تم تمكين التمهيد الآمن لـ UEFI بدون الوصول الفعلي إليه ، مثل تعديل متغيرات NVRAM لخدمات التمهيد فقط. وهذا ما يستفيد منه المهاجمون لإعداد المثابرة لـ bootkit في الخطوة التالية. يمكن العثور على مزيد من المعلومات حول الاستغلال في استغلال CVE-2022-21894 والقسم الخاص به.
2. تعيين المثابرة عن طريق كتابة MOK الخاص به إلى MokList، متغير NVRAM لخدمات التمهيد فقط. من خلال القيام بذلك ، يمكنه استخدام ملف الرقائق لتحميله موقعًا ذاتيًا (موقّعًا بواسطة المفتاح الخاص الذي ينتمي إلى المفتاح المكتوب إلى MokList) UEFI bootkit بدلاً من استغلال الثغرة الأمنية في كل تمهيد. المزيد حول هذا في ثبات Bootkit والقسم الخاص به.

لتسهيل التحليل التفصيلي في القسمين التاليين ، سنتبع الخطوات الموضحة في الرسم التخطيطي للتنفيذ ، الشكل 6.

الشكل 6. تجاوز التمهيد الآمن وإعداد المثابرة باستخدام MOK

استغلال CVE-2022-21894

لتجاوز التمهيد الآمن ، يستخدم BlackLotus امتداد baton drop (CVE-2022-21894): ميزة أمان التمهيد الآمن تجاوز الثغرات الأمنية. على الرغم من تأثيرها الكبير على أمن النظام ، لم تحظ هذه الثغرة الأمنية بالقدر الذي تستحقه من اهتمام الجمهور. على الرغم من إصلاح الثغرة الأمنية في تحديث Microsoft لشهر يناير 2022 ، إلا أن استغلالها لا يزال ممكنًا لأن الثنائيات المتأثرة لم تتم إضافتها إلى قائمة إبطال UEFI. نتيجة لذلك ، يمكن للمهاجمين إحضار نسخهم الخاصة من الثنائيات الضعيفة إلى أجهزة ضحاياهم لاستغلال هذه الثغرة الأمنية وتجاوز التمهيد الآمن على أنظمة UEFI المحدثة.

علاوة على ذلك ، أصبح إثبات المفهوم (PoC) لاستغلال هذه الثغرة الأمنية متاحًا للجمهور منذ أغسطس 2022. وبالنظر إلى تاريخ تقديم BlackLotus VirusTotal الأول (انظر الشكل 1) ، فمن المحتمل أن يكون مطور البرامج الضارة قد قام للتو بتكييف PoC المتاح مع احتياجاته دون أي حاجة لفهم عميق لكيفية عمل هذا الاستغلال.

لنبدأ بمقدمة موجزة عن الثغرة الأمنية ، تلخص في الغالب النقاط الرئيسية من الكتابة المنشورة جنبًا إلى جنب مع PoC على جيثب:

• تطبيقات تمهيد Windows المتأثرة (مثل bootmgr.efi, hvloader.efi, winload.efi…) بإزالة نهج التمهيد الآمن المتسلسل من الذاكرة - قبل تحميله بواسطة التطبيق - باستخدام ملف مقتطفات من الذاكرة خيار التمهيد BCD.
• يسمح هذا للمهاجمين باستخدام خيارات BCD الخطيرة الأخرى مثل com.bootdebug, الاختباراتالطرق أو nointegritychecks، وبالتالي كسر Secure Boot.
• هناك طرق مختلفة لاستغلال هذه الثغرة الأمنية - ثلاثة منها منشورة في مستودع إثبات الهوية.
• على سبيل المثال ، يوضح أحد نقاط إثبات الملكية كيف يمكن استغلاله لإضفاء الشرعية hvloader.efi تحميل تعسفي موقعة ذاتيا mcupdate_ .dll ثنائي (أين يمكن أن يكون اصلية انتل or أصيلة AMD، على أساس وحدة المعالجة المركزية للجهاز.).

الآن ، نواصل وصف كيفية استغلال BlackLotus لهذه الثغرة الأمنية (الأرقام الواردة في القائمة أدناه تصف الخطوات المقابلة في الشكل 6):

1. بعد أن يقوم المثبت بإعادة تشغيل الجهاز ، يستمر برنامج UEFI الثابت في تحميل خيار التمهيد الأول. بالنسبة لأنظمة Windows ، يكون خيار التمهيد الأول افتراضيًا bootmgfw.efi وتقع في ESP: / EFI / Microsoft / Boot مجلد على ESP. هذه المرة ، بدلاً من إعدام الضحية الأصلية bootmgfw.efi (التي تمت إعادة تسميتها سابقًا winload.efi بواسطة المثبت) ، ينفذ البرنامج الثابت البرنامج الضعيف - الذي ينشره المثبت.
2. بعد bootmgfw.efi يتم تنفيذه ، يقوم بتحميل خيارات التمهيد BCD ، والتي تم تعديلها مسبقًا بواسطة المثبت. يوضح الشكل 7 مقارنة BCD الشرعية والمعدلة.
3. كما ترى في الشكل 7 (المسار تحته خط باللون الأخضر) ، فإن Windows Boot Manager الشرعي يقوم عادةً بتحميل برنامج تحميل نظام التشغيل Windows (WINDOWSsystem32winload.efi) كتطبيق تمهيد افتراضي. لكن هذه المرة ، مع BCD المعدل ، يستمر في تحميل الضعفاء ESP: system32bootmgr.efi، مع تجنب الذاكرة تم تعيين عنصر BCD على القيمة 0x10000000 و مخصص: 22000023 عنصر BCD يشير إلى BCD لمهاجمين آخرين تم تخزينه في ESP: system32bcd. يمكن الاطلاع على شرح استخدام هذه العناصر في المنشور اضغط لتتحدث:

يحتاج المهاجم إلى التأكد من تخصيص سياسة التمهيد الآمن المتسلسلة فوق عنوان مادي معروف.
[...]
• تجنب الذاكرة يمكن استخدام عنصر للتأكد من أن جميع عمليات تخصيص الذاكرة الفعلية أعلى من العنوان الفعلي المحدد.
 • منذ Windows 10 ، لا يُسمح بهذا العنصر إذا تم تمكين VBS ، ولكن نظرًا لاستخدامه أثناء تهيئة تطبيق التمهيد ، قبل قراءة نهج التمهيد الآمن المتسلسل من الذاكرة ، يتم التحميل Dice: الزهر: وتحديد مسار BCD مخصص (باستخدام bcdfilepath عنصر الملقب مخصص: 22000023) لتجاوز هذا.

الشكل 7. مخزن BCD الشرعي (قبل) مقابل المخزن المستخدم بواسطة مثبّت BlackLotus (بعد)

4. في الخطوة التالية ، أعدم ESP: system32bootmgr.efi تحميل ذلك BCD الإضافي الموجود في ESP: system32bcd. يظهر المحتوى الذي تم تحليله من هذا BCD الإضافي في الشكل 8.

الشكل 8. BCD الثاني الذي تم إسقاطه بواسطة مثبت BlackLotus - يستخدم لاستغلال CVE-2022-21894

5. بسبب الخيارات التي تم تحميلها من ملف BCD الموضح في الشكل 8 ، bootmgr.efi يستمر في تحميل تطبيق تمهيد Windows ضعيف آخر تم نشره بواسطة المثبت - ESP: system32hvloader.efi - وهو Windows Hypervisor Loader. الأهم من ذلك ، تم تحديد خيارات BCD الإضافية في نفس ملف BCD (انظر الشكل 8):
   1. مقتطفات من الذاكرة بقيمة 0x10000000
   2. nointegritychecks اضبط على "نعم"
   3. و الاختبارات، واضبط أيضًا على "نعم"

وهذا هو المكان الذي يحدث فيه السحر. نظرًا لأنه يجب تحميل سياسة التمهيد الآمن المتسلسلة في العناوين الفعلية أعلاه 0x10000000 (بسبب تجنب الذاكرة المستخدمة في الخطوات السابقة) ، مع تحديد مقتطفات من الذاكرة سيقوم عنصر بإزالته بشكل فعال - وبالتالي ، كسر التمهيد الآمن والسماح باستخدام خيارات BCD الخطيرة مثل nointegritychecks or الاختبارات. باستخدام هذه الخيارات ، يمكن للمهاجمين إنشاء ملف hvloader.efi تنفيذ التعليمات البرمجية الخاصة بهم والموقعة ذاتيًا. 

6. للقيام بذلك ، نفس الحيلة كما هو موضح في ملف اضغط لتتحدث يستخدم: أثناء تنفيذه ، شرعي hvloader.efi تحميل وتنفيذ mcupdate_ {GenuineIntel | أصيلة AMD} .dll ثنائي أصلي من : نظام 32 الدليل. علق Hex-Rays رمز فك من الوظيفة من hvloader.efi مسؤول عن تحميل ملف mcupdate * .dll الثنائي يظهر في الشكل 9. لاحظ ذلك hvloader.efi عادة تحميل هذا الشرعي mcupdate * .dll ثنائي من: Windowssystem32، ولكن هذه المرة قام المهاجمون الأشرار بالتوقيع ذاتيًا mcupdate * .dll يتم تنفيذه من دليل ESP مخصص تم إنشاؤه مسبقًا بواسطة المثبت (ESP: system32). إنه ناتج عن خيارات BCD جهاز و جذر النظام المستخدمة في BCD من الشكل 8 مع تحديد الجهاز الحالي كـ حذاء - يعني ESP - وكذلك تحديد SystemRoot ليكون الجذر () الدليل على هذا الجهاز.

الشكل 9. تفكيك الأشعة السداسية من BtLoadUpdateDll وظيفة من الشرعي hvloader.efi، مسؤول عن التحميل mcupdate _ *. dll

7. الآن ، كما وقع المهاجمون أنفسهم mcupdate * .dll يتم تحميله وتنفيذه ، ويستمر في تنفيذ المكون الأخير في هذه السلسلة - MokInstaller مضمن (تطبيق UEFI) - انظر الشكل 10 للحصول على تفاصيل حول كيفية القيام بذلك.

الشكل 10. تحليل الشفرة السداسية للأشعة السداسية للشفرة الخبيثة الموقعة ذاتيًا mcupdate * .dll ثنائي

ثبات Bootkit

الآن ، يمكن لـ MokInstaller المضي قدمًا في إعداد الاستمرارية عن طريق تسجيل MOK للمهاجمين في متغير NVRAM وإعداد البرنامج الشرعي الموقع من Microsoft الرقائق ثنائي كمحمل إقلاع افتراضي. قبل الشروع في التفاصيل ، القليل من النظرية حول الرقائق وموك.

الرقائق هو محمل إقلاع UEFI للمرحلة الأولى تم تطويره بواسطة مطوري Linux لجعل توزيعات Linux المختلفة تعمل مع UEFI Secure Boot. إنه تطبيق بسيط والغرض منه هو تحميل تطبيق آخر والتحقق منه وتنفيذه - في حالة أنظمة Linux ، يكون عادةً محمل الإقلاع GRUB. إنه يعمل بطريقة تجعل Microsoft توقع فقط ملف الرقائق، و الرقائق يعتني بالباقي - يمكنه التحقق من سلامة محمل إقلاع المرحلة الثانية باستخدام مفاتيح من db متغير UEFI ، ويقوم أيضًا بتضمين قائمته الخاصة من المفاتيح أو التجزئات "المسموح بها" أو "الملغاة" للتأكد من أنه يُسمح بتنفيذ المكونات الموثوقة من قِبل كل من مطور النظام الأساسي والرقائق (مثل Canonical و RedHat وما إلى ذلك). بالإضافة إلى هذه القوائم ، الرقائق يسمح أيضًا باستخدام قاعدة بيانات المفاتيح الخارجية التي يديرها المستخدم ، والمعروفة باسم قائمة MOK. يوضح الشكل 11 بشكل جيد كيفية عمل UEFI Secure Boot مع MOK.

يتم تخزين قاعدة بيانات MOK هذه في متغير NVRAM للتشغيل فقط يسمى MokList. بدون استغلال ثغرة أمنية مثل تلك الموضحة أعلاه ، يلزم الوصول المادي لتعديلها على نظام تم تمكين التمهيد الآمن لـ UEFI (يتوفر فقط أثناء التمهيد ، قبل أن يستدعي مُحمل نظام التشغيل وظيفة خدمات التمهيد UEFI ExitBootServices). ومع ذلك ، من خلال استغلال هذه الثغرة الأمنية ، يمكن للمهاجمين تجاوز التمهيد الآمن لـ UEFI وتنفيذ التعليمات البرمجية الموقعة ذاتيًا قبل الاتصال بـ ExitBootServices، حتى يتمكنوا من تسجيل مفتاحهم بسهولة (عن طريق تعديل MokList متغير NVRAM) لجعل الرقاقة تنفذ أي تطبيق - موقع بواسطة هذا المفتاح المسجل - دون التسبب في انتهاك أمني.

الشكل 11. نظرة عامة على عملية التمهيد MOK (مصدر الصورة)

8. الاستمرار في وصف التدفق من الشكل 6 - الخطوة 8 ... يستمر تطبيق MokInstaller UEFI في إعداد الثبات لمجموعة التمهيد BlackLotus UEFI وتغطية مسارات الاستغلال من خلال:
   1. استعادة مخزن BCD الأصلي للضحية من النسخة الاحتياطية التي أنشأها المثبت واستبدال efi بالرقاقة الشرعية الموقعة من Microsoft ، والتي سبق إسقاطها إلى ESP: system32bootload.efi بواسطة المثبت.
   2. خلق MokList متغير NVRAM يحتوي على شهادة المفتاح العام الموقعة ذاتيًا للمهاجمين. لاحظ أن هذا المتغير يتم تنسيقه بنفس طريقة تنسيق أي متغيرات أخرى لقاعدة بيانات توقيع UEFI (مثل db أو dbx) ويمكن أن يتكون من صفر أو أكثر من قوائم التوقيع من النوع EFI_SIGNATURE_LIST - على النحو المحدد في مواصفات UEFI.
   3. حذف جميع الملفات المتورطة في الاستغلال من المهاجمين. ESP: system32 المجلد.
9. في النهاية ، يقوم بإعادة تشغيل الجهاز لجعل الرقاقة التي تم نشرها تنفذ مجموعة التمهيد ذات التوقيع الذاتي التي تم إسقاطها EFIMicrosoftBootgrubx64.efi بواسطة المثبت (grubx64.efi هو عادةً محمل إقلاع المرحلة الثانية الافتراضي الذي ينفذه ملف الرقائق على أنظمة x86-64).

يظهر الرمز الذي يؤدي الإجراءات الموضحة في الخطوتين الأخيرتين في الشكل 12.

الشكل 12. كود Hex-Rays الذي تم فك تشفيره - يقوم تطبيق MokInstaller UEFI بإعداد استمرارية لـ BlackLotus bootkit

مجموعة التمهيد BlackLotus UEFI

بمجرد تكوين الاستمرارية ، يتم تنفيذ مجموعة التمهيد BlackLotus عند كل بدء تشغيل للنظام. هدف bootkit هو نشر برنامج تشغيل kernel ومكون وضع المستخدم النهائي - أداة تنزيل HTTP. أثناء تنفيذه ، يحاول تعطيل ميزات أمان Windows الإضافية - الأمان المستند إلى الظاهرية (VBS) و Windows Defender - لزيادة فرصة النشر الناجح والتشغيل الخفي. قبل القفز إلى التفاصيل حول كيفية القيام بذلك ، دعنا نلخص الأساسيات حول برنامج تشغيل kernel وبرنامج تنزيل HTTP:

• سائق النواة هو المسؤول عن
  • نشر المكون التالي من السلسلة - أداة تنزيل HTTP.
  • إبقاء اللودر على قيد الحياة في حالة الإنهاء.
  • حماية ملفات bootkit من الإزالة من ESP.
  • تنفيذ حمولات kernel إضافية ، إذا طلب ذلك من أداة تنزيل HTTP.
  • إلغاء تثبيت bootkit ، إذا طلب ذلك من أداة تنزيل HTTP.
• برنامج تنزيل HTTP مسؤول عن:
  • التواصل مع C & C.
  • تنفيذ الأوامر الواردة من C&C.
  • تنزيل وتنفيذ الحمولات المستلمة من C&C (يدعم كل من حمولات kernel وحمولات وضع المستخدم).

يظهر تدفق التنفيذ الكامل (المبسط) ، من المثبت إلى أداة تنزيل HTTP ، في الشكل 13. سنوضح هذه الخطوات الفردية بمزيد من التفصيل في القسم التالي.

الشكل 13. رسم تخطيطي يوضح تنفيذ مجموعة التمهيد BlackLotus UEFI

تدفق تنفيذ BlackLotus

خطوات التنفيذ هي كما يلي (هذه الخطوات موضحة في الشكل 13):

1. كخطوة أولى ، تنفذ البرامج الثابتة UEFI خيار التمهيد الافتراضي لنظام التشغيل Windows ، وهو الملف الذي يتم تخزينه عادةً EFIMicrosoftBootbootmgfw.efi. كما وصفنا سابقًا (قسم ثبات Bootkit ، 8.a) ، استبدل ثنائي MokInstaller هذا الملف بملف الرقائق.
2. عندما الرقائق يتم تنفيذه ، يقرأ MokList متغير NVRAM ، ويستخدم الشهادة التي تم تخزينها مسبقًا بالداخل بواسطة المهاجمين للتحقق من أداة تحميل التشغيل في المرحلة الثانية - مجموعة التمهيد BlackLotus UEFI الموقعة ذاتيًا والموجودة في EFIMicrosoftBootgrubx64.efi.
3. عند التحقق من الرقائق ينفذ bootkit.
4. يبدأ bootkit بإنشاء Boot-only VbsPolicyDisable متغير NVRAM. كما وصفت هنا، يتم تقييم هذا المتغير بواسطة مُحمل نظام التشغيل Windows أثناء التمهيد ، وإذا تم تحديده ، فلن تتم تهيئة ميزات VBS الأساسية ، مثل HVCI و Credential Guard.
5. في الخطوات التالية (5. a – e) ، يستمر bootkit بنمط شائع تستخدمه مجموعات تمهيد UEFI. إنه يعترض تنفيذ المكونات المضمنة في تدفق تمهيد Windows النموذجي ، مثل Windows Boot Manager ، ومحمل نظام التشغيل Windows OS ، و Windows OS kernel ، ويربط بعض وظائفها في الذاكرة. على سبيل المكافأة ، يحاول أيضًا تعطيل Windows Defender عن طريق تصحيح بعض برامج التشغيل الخاصة به. كل هذا لتحقيق تنفيذ الحمولة في المراحل الأولى من عملية بدء تشغيل نظام التشغيل ولتجنب الاكتشاف. يتم ربط الوظائف التالية أو تصحيحها:
   1. ImgArchStartBootApplication in bootmgfw.efi or bootmgr.efi:
      عادة ما يتم ربط هذه الوظيفة بواسطة مجموعات التشغيل لالتقاط اللحظة التي يتم فيها تحميل نظام التشغيل Windows (winload.efi) في الذاكرة ولكن لم يتم تنفيذه بعد - وهي اللحظة المناسبة لإجراء المزيد من عمليات التصحيح في الذاكرة.
   2. BlImgAllocateImageBuffer in winload.efi:
      تُستخدم لتخصيص مخزن ذاكرة مؤقت إضافي لبرنامج تشغيل kernel الضار.
   3. OslArchTransferToKernel in winload.efi:
      مدمن مخدرات لالتقاط اللحظة التي يتم فيها تحميل نواة نظام التشغيل وبعض برامج تشغيل النظام بالفعل في الذاكرة ، ولكن لم يتم تنفيذها بعد - وهي لحظة مثالية لإجراء المزيد من عمليات التصحيح في الذاكرة. يتم تصحيح برامج التشغيل المذكورة أدناه في هذا الخطاف. يظهر الرمز من هذا الخطاف المسؤول عن إيجاد برامج التشغيل المناسبة في الذاكرة في الشكل 14.
   4. WdBoot.sys و WdFilter.sys:
      BlackLotus تصحيحات نقطة دخول WdBoot.sys و WdFilter.sys - برنامج تشغيل Windows Defender ELAM وبرنامج تشغيل عامل تصفية نظام ملفات Windows Defender ، على التوالي - للعودة على الفور.
   5. disk.sys:
      يربط Bootkit نقطة دخول ملف disk.sys سائق لتنفيذ برنامج تشغيل BlackLotus kernel في المراحل الأولى من تهيئة النظام.

الشكل 14. رمز تفكيك الأشعة السداسية OslArchTransferToKernel الخطاف - تصحيح برامج تشغيل Windows Defender والبحث عن ملف disk.sys نقطة الدخول

6. بعد ذلك ، عندما ينفذ نظام التشغيل kernel ملف disk.sys نقطة دخول برنامج التشغيل ، يقفز الخطاف المثبت إلى نقطة دخول برنامج تشغيل النواة الخبيثة. الشيفرة الخبيثة بدورها تستعيد الأصل disk.sys للسماح للنظام بالعمل بشكل صحيح وينتظر حتى WINLOGON.EXE تبدأ العملية.
7. عندما يكتشف السائق الخبيث أن ملف WINLOGON.EXE بدأت العملية ، تقوم بحقن وتنفيذ مكون وضع المستخدم النهائي - أداة تنزيل HTTP - فيه.

سائق نواة

سائق النواة مسؤول عن أربع مهام رئيسية:

• إدخال أداة تنزيل HTTP في ملف WINLOGON.EXE وإعادة حقنه في حالة إنهاء الخيط.
• حماية ملفات bootkit التي تم نشرها على ESP من إزالتها.
• نزع سلاح عملية Windows Defender في وضع المستخدم MsMpEngine.exe.
• التواصل مع أداة تنزيل HTTP وتنفيذ أي أوامر إذا لزم الأمر.

دعونا ننظر إليهم واحدة تلو الأخرى.

استمرار تنزيل HTTP

برنامج تشغيل kernel مسؤول عن نشر أداة تنزيل HTTP. عندما يبدأ السائق ، فإنه ينتظر حتى العملية المسماة WINLOGON.EXE يبدأ ، قبل اتخاذ أي إجراءات أخرى. بمجرد بدء العملية ، يقوم برنامج التشغيل بفك تشفير برنامج تنزيل HTTP الثنائي ، ويحقنه في WINLOGON.EXEمساحة العنوان الخاصة بـ ، وينفذها في سلسلة محادثات جديدة. بعد ذلك ، يواصل السائق التحقق بشكل دوري مما إذا كان الخيط لا يزال قيد التشغيل ، ويكرر الحقن إذا لزم الأمر. لن يتم نشر أداة تنزيل HTTP إذا اكتشف برنامج التشغيل مصحح أخطاء kernel.

حماية ملفات bootkit على ESP من الإزالة

لحماية ملفات bootkit الموجودة على ESP ، يستخدم برنامج تشغيل kernel خدعة بسيطة. يفتح جميع الملفات التي يريد حمايتها ويكررها ويحفظ مقابضها ويستخدم ملف ObSetHandleAttributes وظيفة kernel التي تحدد ملف حماية من إغلاق العلم في الداخل HandFlags (OBJECT_HANDLE_FLAG_INFORMATION) إلى 1 - وبالتالي حماية المقابض من أن يتم إغلاقها بواسطة أي عمليات أخرى. سيؤدي ذلك إلى إحباط أي محاولات لإزالة أو تعديل الملفات المحمية. الملفات التالية محمية:

• ESP: EFIMicrosoftBootwinload.efi
• ESP: EFIMicrosoftBootbootmgfw.efi
• ESP: EFIMicrosoftBootgrubx64.efi

إذا حاول المستخدم حذف هذه الملفات المحمية ، فسيحدث شيء مثل ما يظهر في الشكل 15.

الشكل 15. محاولة حذف الملفات المحمية بواسطة برنامج تشغيل BlackLotus

كطبقة أخرى من الحماية ، في حالة تمكن المستخدم أو برنامج الأمان من إلغاء ضبط علامة الحماية وإغلاق المقابض ، يقوم برنامج تشغيل kernel بمراقبتها باستمرار ، ويتسبب في حدوث الموت الزرقاء عن طريق استدعاء KeBugCheck (INVALID_KERNEL_HANDLE) تعمل إذا لم يعد أي من المقابض موجودًا.

نزع سلاح عملية Windows Defender الرئيسية

يحاول برنامج تشغيل kernel أيضًا تعطيل عملية Windows Defender الرئيسية - MsMpEng.exe. يقوم بذلك عن طريق إزالة جميع امتيازات الرمز المميز للعملية عن طريق تعيين SE_PRIVILEGE_REMOVED السمة لكل منهم. نتيجة لذلك ، يجب ألا تكون عملية Defender قادرة على أداء وظيفتها - مثل فحص الملفات - بشكل صحيح. ومع ذلك ، نظرًا لسوء تنفيذ هذه الوظيفة ، يمكن جعلها غير فعالة عن طريق إعادة تشغيل MsMpEng.exe .

التواصل مع أداة تنزيل HTTP

برنامج تشغيل kernel قادر على الاتصال بأداة تنزيل HTTP باستخدام حدث وقسم مسمى. يتم إنشاء أسماء الكائنات المسماة المستخدمة بناءً على عنوان MAC لمحول الشبكة الخاص بالضحية (إيثرنت). إذا كانت قيمة ثماني بتات أقل من 16 ، فسيتم إضافة 16 إليها. قد يختلف تنسيق أسماء الكائنات التي تم إنشاؤها في عينات مختلفة. على سبيل المثال ، في إحدى العينات التي قمنا بتحليلها ، لعنوان MAC 00-1c-0b-cd-ef-34، ستكون الأسماء التي تم إنشاؤها:

• BaseNamedObjects101c1b: للقسم المحدد (يتم استخدام أول ثلاث بتات فقط من MAC)
• BaseNamedObjectsZ01c1b: للحدث المحدد - كما هو الحال بالنسبة للقسم ، ولكن يتم استبدال الرقم الأول من عنوان MAC بالرقم Z

في حالة رغبة برنامج تنزيل HTTP في تمرير بعض الأوامر إلى برنامج تشغيل kernel ، فإنه يقوم ببساطة بإنشاء قسم مسمى ، ويكتب أمرًا مع البيانات المرتبطة بالداخل ، وينتظر الأمر ليتم معالجته بواسطة برنامج التشغيل عن طريق إنشاء حدث مسمى والانتظار حتى يقوم السائق بتشغيله (أو إشاراته).

يدعم برنامج التشغيل الأوامر التالية التي لا تحتاج إلى شرح:

• قم بتثبيت برنامج تشغيل kernel
• قم بإلغاء تثبيت BlackLotus

قد يلاحظ القارئ الدقيق نقطة ضعف BlackLotus هنا - على الرغم من أن bootkit يحمي مكوناته من الإزالة ، يمكن خداع برنامج تشغيل kernel لإلغاء تثبيت bootkit تمامًا عن طريق إنشاء الكائنات المذكورة أعلاه وإرسال أمر إلغاء التثبيت إليها.

تنزيل HTTP

المكون الأخير مسؤول عن الاتصال بخادم القيادة والتحكم وتنفيذ أي أوامر قيادة وتحكم مستلمة منه. جميع الحمولات التي تمكنا من اكتشافها تحتوي على ثلاثة أوامر. هذه الأوامر مباشرة للغاية وكما يوحي اسم القسم ، فهي في الغالب تتعلق بتنزيل وتنفيذ حمولات إضافية باستخدام تقنيات مختلفة.

الاتصالات C & C

للتواصل مع C&C الخاص به ، يستخدم مُحمل HTTP بروتوكول HTTPS. يتم تضمين جميع المعلومات اللازمة للاتصال مباشرة في ثنائي أداة التنزيل - بما في ذلك مجالات C&C ومسارات موارد HTTP المستخدمة. يتم تعيين الفاصل الزمني الافتراضي للاتصال بخادم القيادة والتحكم على دقيقة واحدة ، ولكن يمكن تغييرها بناءً على البيانات الواردة من C&C. تبدأ كل جلسة اتصال مع C&C بإرسال رسالة منارة HTTP POST إليها. في العينات التي قمنا بتحليلها ، يمكن تحديد مسارات موارد HTTP التالية في رؤوس HTTP POST:

• /network/API/hpb_gate[.]php
• /API/hpb_gate[.]php
• /gate [.] [فب]
• /hpb_gate[.]php

يتم تقديم بيانات رسالة المرشد مسبقًا بامتداد الإيداع= سلسلة تحتوي على معلومات أساسية حول الجهاز المخترق - بما في ذلك معرف الجهاز المخصص (يُشار إليه باسم HWID) ، وحالة التمهيد الآمن لـ UEFI ، ومعلومات الأجهزة المختلفة ، والقيمة التي يبدو أنها رقم إصدار BlackLotus. HWID يتم إنشاؤه من عنوان MAC الخاص بالجهاز (إيثرنت) والرقم التسلسلي لوحدة تخزين النظام. تنسيق الرسالة قبل التشفير كما هو موضح في الشكل 16

الشكل 16. تنسيق رسالة المرشد

قبل إرسال الرسالة إلى C&C ، يتم تشفير البيانات أولاً باستخدام مفتاح RSA مضمن ، ثم تشفير base64 الآمن لعنوان URL. أثناء التحليل ، وجدنا مفتاحين مختلفين RSA مستخدمين في العينات. يظهر مثال لطلب إشارة HTTP في الشكل 17.

الشكل 17. مثال على رسالة منارة HTTP POST (تم إنشاؤها بواسطة عينة من VirusTotal - الرسالة التي تحتوي على عناوين IP محلية بدلاً من عناوين C&C الحقيقية)

يجب أن تبدأ البيانات الواردة من C&C كاستجابة لرسالة المرشد بالقيمة السحرية ثنائية البايت HP ؛ خلاف ذلك ، لا تتم معالجة الاستجابة بشكل أكبر. إذا كانت القيمة السحرية صحيحة ، يتم فك تشفير البيانات التالية للقيمة السحرية باستخدام 256 بت AES في وضع CBC مع استخدام سلسلة HWID المذكورة أعلاه كمفتاح.

بعد فك التشفير ، تكون الرسالة مشابهة للمنارة ، وهي سلسلة بتنسيق JSON ، وتحدد معرف الأمر (يشار إليه باسم النوع) والعديد من المعلمات الإضافية مثل:

• الفاصل الزمني للاتصال C & C
• طريقة التنفيذ للاستخدام
• اسم ملف الحمولة
• نوع الحمولة على أساس امتداد الملف (.sys, .إملف تنفيذىالطرق أو . دلل أيد)
• رمز المصادقة المفترض استخدامه لطلب تنزيل بيانات الحمولة
• مفتاح AES المستخدم لفك تشفير بيانات الحمولة

يتم سرد جميع الأوامر المدعومة وأوصافها في الجدول 2.

الجدول 2. أوامر C & C

في هذه الأوامر ، يمكن أن تحدد القيادة والتحكم ، ما إذا كان يجب إسقاط الحمولة أولاً على القرص قبل تنفيذها ، أو تنفيذها مباشرة في الذاكرة. في الحالات التي تنطوي على إسقاط الملف على القرص ، فإن ملف ProgramData يتم استخدام المجلد الموجود على وحدة تخزين نظام التشغيل حيث يتم تحديد المجلد الوجهة واسم الملف والامتداد بواسطة خادم القيادة والتحكم. في حالة تنفيذ الملفات مباشرة في الذاكرة ، ملف Svchost.exe يستخدم كهدف حقن. عندما ترسل C&C أمرًا يتطلب تعاون برنامج تشغيل kernel ، أو عندما يريد عامل تشغيل التعليمات البرمجية في وضع kernel ، فإن الآلية الموضحة في التواصل مع أداة تنزيل HTTP يستخدم القسم.

الحيل المضادة للتحليل

لجعل اكتشاف هذا الجزء من البرنامج الضار وتحليله أكثر صعوبة ، حاول مؤلفه تقييد رؤية عناصر الملفات القياسية ، مثل السلاسل النصية أو الواردات أو البيانات المضمنة الأخرى غير المشفرة إلى الحد الأدنى. فيما يلي ملخص للتقنيات المستخدمة.

• تشفير السلسلة والبيانات
  • يتم تشفير جميع السلاسل المستخدمة في العينات باستخدام تشفير بسيط.
  • يتم تشفير جميع الملفات المضمنة باستخدام 256 بت AES في وضع CBC.
  • يمكن أن تختلف مفاتيح التشفير للملفات الفردية من نموذج إلى آخر.
  • بالإضافة إلى تشفير AES ، يتم أيضًا ضغط بعض الملفات باستخدام LZMS.
• دقة واجهة برمجة التطبيقات في وقت التشغيل فقط
  • في جميع العينات (عند الاقتضاء) ، يتم دائمًا حل واجهات برمجة تطبيقات Windows بشكل حصري أثناء وقت التشغيل ويتم استخدام تجزئات الوظائف بدلاً من أسماء الوظائف للعثور على عناوين وظائف API المطلوبة في الذاكرة.
  • في بعض الحالات ، يكون ملف تعليق يتم استخدام استدعاء التعليمات لاستدعاء وظيفة النظام المطلوبة.
• شبكة التواصل
  • التواصل باستخدام HTTPS.
  • يتم تشفير جميع الرسائل المرسلة إلى C&C بواسطة أداة تنزيل HTTP باستخدام مفتاح عمومي مضمن RSA.
  • يتم تشفير جميع الرسائل المرسلة من C&C إلى أداة تنزيل HTTP باستخدام مفتاح مشتق من بيئة جهاز الضحية أو باستخدام مفتاح AES المقدم من C&C.
• حيل مكافحة التصحيح ومقاومة الجهاز الظاهري - في حالة استخدامها ، يتم وضعها عادةً في بداية نقطة الدخول مباشرةً. يتم استخدام حيل كشف الحماية أو المصحح فقط.

التخفيف والمعالجة

• بادئ ذي بدء ، بالطبع ، يعد الحفاظ على تحديث نظامك ومنتج الأمان الخاص به أمرًا ضروريًا - لزيادة فرصة إيقاف التهديد في البداية ، قبل أن يتمكن من تحقيق استمرارية ما قبل نظام التشغيل.
• بعد ذلك ، فإن الخطوة الأساسية التي يجب اتخاذها لمنع استخدام ثنائيات UEFI المعروفة المعرضة للخطر لتجاوز التمهيد الآمن لـ UEFI هي إبطالها في قاعدة بيانات إبطال UEFI (DBX) - على أنظمة Windows ، DBX يجب توزيع التحديثات باستخدام تحديثات Windows.
• تكمن المشكلة في أن إبطال ثنائيات Windows UEFI المستخدمة على نطاق واسع يمكن أن يؤدي إلى جعل الآلاف من الأنظمة القديمة أو صور الاسترداد أو النسخ الاحتياطية غير قابلة للتمهيد - وبالتالي ، غالبًا ما يستغرق الإلغاء وقتًا طويلاً.
• لاحظ أن إلغاء تطبيقات Windows التي تستخدمها BlackLotus من شأنه أن يمنع تثبيت bootkit ، ولكن نظرًا لأن المثبت سيحل محل محمل إقلاع الضحية بأحد محمل الإقلاع الذي تم إلغاؤه ، فقد يجعل النظام غير قابل للتمهيد. للتعافي في هذه الحالة ، من شأن إعادة تثبيت نظام التشغيل أو استرداد ESP فقط حل المشكلة.
• إذا حدث الإلغاء بعد تعيين استمرارية BlackLotus ، فستظل مجموعة bootkit تعمل ، لأنها تستخدم رقاقة شرعية مع مفتاح MOK المخصص للاستمرار. في هذه الحالة ، سيكون حل التخفيف الأكثر أمانًا هو إعادة تثبيت Windows وإزالة مفتاح MOK المسجل لدى المهاجمين باستخدام موكوتيل الأداة المساعدة (التواجد المادي مطلوب لإجراء هذه العملية بسبب تفاعل المستخدم الضروري مع MOK Manager أثناء التمهيد).

الوجبات السريعة

تم اكتشاف العديد من نقاط الضعف الحرجة التي تؤثر على أمان أنظمة UEFI في السنوات القليلة الماضية. لسوء الحظ ، نظرًا لتعقيد النظام البيئي UEFI بأكمله ومشاكل سلسلة التوريد ذات الصلة ، فقد ترك العديد من هذه الثغرات العديد من الأنظمة عرضة للخطر حتى بعد وقت طويل من إصلاحها - أو على الأقل بعد إخبارنا بأنها تم إصلاحها. للحصول على صورة أفضل ، فيما يلي بعض الأمثلة على فشل التصحيح أو الإلغاء الذي يسمح بتجاوز UEFI Secure Boot منذ العام الماضي:

• بادئ ذي بدء ، بالطبع ، CVE-2022-21894 - الثغرة الأمنية التي استغلتها BlackLotus. بعد مرور عام على إصلاح الثغرة الأمنية ، لم يتم إبطال ثنائيات UEFI الضعيفة ، مما يسمح للتهديدات مثل BlackLotus بالعمل خلسة على أنظمة تم تمكين UEFI Secure Boot ، مما يوفر للضحايا إحساسًا زائفًا بالأمان.
• في أوائل عام 2022 ، كشفنا عن العديد من ثغرات UEFI التي تسمح ، من بين أمور أخرى ، بتعطيل التمهيد الآمن لـ UEFI. العديد من الأجهزة المتأثرة لم تعد مدعومة من قبل الشركة المصنعة للمعدات الأصلية ، وبالتالي لم يتم إصلاحها (على الرغم من أن هذه الأجهزة لم تكن قديمة جدًا - مثل 3-5 سنوات في وقت الكشف عن الثغرات الأمنية). اقرأ المزيد في مدونتنا: عندما لا يكون "آمن" آمنًا على الإطلاق: تم اكتشاف ثغرات أمنية عالية التأثير في UEFI في أجهزة الكمبيوتر المحمولة للمستهلكين من Lenovo
• في وقت لاحق من عام 2022 ، اكتشفنا أ بعض نقاط ضعف UEFI الأخرى، والذي سيسمح استغلاله للمهاجمين بتعطيل التمهيد الآمن لـ UEFI بسهولة شديدة. كما أشار زملائه الباحثين من ثنائي، العديد من الأجهزة المدرجة في استشاري لم يتم إصلاحها ، أو لم يتم تصحيحها بشكل صحيح ، حتى بعد أشهر قليلة من التنبيه - مما ترك الأجهزة عرضة للخطر. وغني عن القول ، على غرار الحالة السابقة ، أن بعض الأجهزة ستبقى عرضة للخطر إلى الأبد ، حيث وصلت إلى تاريخ انتهاء الدعم.

لقد كانت مجرد مسألة وقت قبل أن يستفيد شخص ما من هذه الإخفاقات وإنشاء مجموعة تمهيد UEFI قادرة على العمل على أنظمة تم تمكين UEFI Secure Boot. كما اقترحنا العام الماضي في موقعنا عرض RSA، كل هذا يجعل الانتقال إلى ESP أكثر جدوى للمهاجمين وطريقة محتملة للمضي قدمًا لتهديدات UEFI - وجود BlackLotus يؤكد ذلك.

شركات النفط العالمية

ملفات

الشهادات

شبكة

تقنيات MITER ATT & CK

تم بناء هذا الجدول باستخدام إصدار 12 من إطار MITER ATT & CK.

• محتوى مدعوم من تحسين محركات البحث وتوزيع العلاقات العامة. تضخيم اليوم.
• بلاتوبلوكشين. Web3 Metaverse Intelligence. تضخيم المعرفة. الوصول هنا.
• المصدر https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/