themalwareguardian/cve-2022-34301يوضح تجاوز Secure Boot عبر CVE-2022-34301 من خلال UEFI Shell الموقّع من Eurosoft (esdiags.efi)، باستخدام الأمر mm لإبطال gSecurity2 وتحميل تطبيقات UEFI غير الموقّعة.
Eurosoft Pc-Check UEFI Diagnostics Shell - Bring Your Own Vulnerable UEFI Application (BYOVUA) - تجاوز Secure Boot عبر UEFI Shell موقّع وفساد gSecurity2.
يوضح هذا المستودع تقنية BYOVUA (Bring Your Own Vulnerable UEFI Application) من خلال استغلال CVE-2022-34301، وهي ثغرة تجاوز Secure Boot في بيئة التشخيص Eurosoft Pc-Check UEFI.
في هذه الحالة، المكوّن الموثوق من قِبل Secure Boot هو esdiags.efi، وهو UEFI Shell يُوزَّع كجزء من منتج التشخيص العتادي Eurosoft Pc-Check UEFI، وموقّع بسلسلة شهادات موثوقة من قِبل Microsoft UEFI Third Party Certificate Authority. عند تنفيذه، يكشف هذا الـ Shell عن أمر mm (تعديل الذاكرة) وبالتالي يوفر قدرات قراءة وكتابة عشوائية للذاكرة خلال مرحلة الإقلاع قبل نظام التشغيل.
يمكن بعد ذلك استخدام هذه القدرة لتحديد موقع وإبطال المؤشر العام gSecurity2 في نواة DXE. ونتيجة لذلك، يتم تعطيل التحقق من صور UEFI اللاحقة، مما يسمح بتحميل تطبيقات UEFI غير الموقّعة، والـ bootkits، على الرغم من تمكين Secure Boot.
BYOVUA هو المكافئ في UEFI لتقنية BYOVD (Bring Your Own Vulnerable Driver) المستخدمة على مستوى النواة. فبدلاً من جلب برنامج تشغيل نواة موقّع يحتوي على ثغرة، يجلب المهاجم تطبيق UEFI موقّعاً - في هذه الحالة، UEFI Shell كامل - يحتوي على وظائف قادرة على تقويض Secure Boot.
ولأن التطبيق موقّع بسلسلة شهادات موثوقة من قِبل Secure Boot، فإنه يُقبل دون سؤال، مما يجعله موثوقاً على أي نظام يتضمن Microsoft UEFI Third Party Certificate Authority في قاعدة بيانات Secure Boot الخاصة به (db) - وهو ما ينطبق على كل حاسوب قادر على UEFI تقريباً تم شحنه خلال العقد الماضي. وبمجرد تشغيله، تمنح أوامره المدمجة المهاجم وصولاً مباشراً إلى العتاد والذاكرة يعمل قبل تحميل نظام التشغيل، في بيئة لا توجد فيها ضوابط الأمان الحديثة (ASLR، DEP، حمايات النواة) ببساطة.
esdiags.efi هو UEFI Shell يُوزَّع كجزء من Eurosoft Pc-Check UEFI، وهو منتج تشخيص عتادي قبل الإقلاع تستخدمه شركات تصنيع الحواسيب ومؤسسات الخدمة وفرق تقنية المعلومات لاختبار الأنظمة العارية.
| الخاصية | القيمة |
|---|---|
| الملف | EFI/Boot/Bootx64.efi (Microsoft) -> EFI/Boot/esdiags.efi (Shell) |
| المورّد | Eurosoft (UK) Ltd |
| CVE | CVE-2022-34301 |
| التوقيع | Microsoft Corporation UEFI CA 2011 (Third Party) |
| الاكتشاف | Eclypsium (Mickey Shkatov, Jesse Michael) - أغسطس 2022 |
| العرض التقديمي | DEF CON 30 - "One Bootloader to Load Them All" |
| الإبطال | أُضيف إلى DBX عبر Microsoft KB5012170 (أغسطس 2022) |
الثغرة ليست خطأً برمجياً - بل هي عيب في التصميم. فـ UEFI Shells هي أدوات تشخيصية مشروعة لم يُقصد بها أبداً العمل في بيئات Secure Boot. ومع ذلك، من خلال توقيعها بشهادة موثوقة من Microsoft وتوزيعها كجزء من منتجات تجارية، أنشأ المورّدون دون قصد تجاوزاً موقّعاً لـ Secure Boot.
المشكلة الجوهرية: ملف ثنائي موقّع موثوق من قِبل Secure Boot يوفر قدرات قراءة/كتابة غير مقيّدة للذاكرة عبر أوامره المدمجة. هذه التركيبة تكسر نموذج الثقة الكامل لـ Secure Boot.
أمر mm (تعديل الذاكرة) هو أمر مدمج قياسي في UEFI Shell يوفر وصولاً مباشراً للقراءة والكتابة إلى ذاكرة النظام. وهو موثّق في UEFI Shell Specification (القسم 5.3).```
MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
| المعامل | الوصف |
|-----------|-------------|
| `Address` | عنوان الذاكرة الهدف |
| `Value` | القيمة المراد كتابتها (تُحذف للقراءة فقط) |
| `-w` | العرض: 1 أو 2 أو 4 أو 8 بايت |
| `-MEM` | الوصول إلى ذاكرة النظام |
| `-MMIO` | الإدخال/الإخراج المعيّن للذاكرة |
| `-IO` | الوصول إلى منفذ الإدخال/الإخراج |
| `-n` | غير تفاعلي (بدون مطالبة بالعنوان التالي) |
---
<div id='gsecurity2'/>
### ***gSecurity2 وبروتوكول البنية الأمنية***
يُفرض التحقق من صورة Secure Boot في UEFI من خلال [بروتوكولات البنية الأمنية](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols)، المعرّفة في مواصفة UEFI Platform Initialization (PI).
يحتفظ نواة DXE (DxeMain) بمؤشر عام يُسمى [`gSecurity2`](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252)، والذي يشير إلى بنية `EFI_SECURITY2_ARCH_PROTOCOL`. يحتوي هذا البروتوكول على مؤشر دالة واحد - `FileAuthenticationState` - والذي يُستدعى بواسطة `LoadImage()` في كل مرة يتم فيها تحميل صورة UEFI:```c
// EFI_SECURITY2_ARCH_PROTOCOL structure (PI Specification)
typedef struct _EFI_SECURITY2_ARCH_PROTOCOL {
EFI_SECURITY_FILE_AUTHENTICATION_STATE FileAuthenticationState;
} EFI_SECURITY2_ARCH_PROTOCOL;
// GUID: 94AB2F58-1438-4EF1-9152-18941A3A0E68
عند استدعاء LoadImage()، يتحقق نواة DXE من:```c
if (gSecurity2 != NULL)
{
Status = gSecurity2->FileAuthenticationState(gSecurity2, DevicePath, FileBuffer, FileSize, BootPolicy
);
if (EFI_ERROR(Status))
{
// Image rejected - signature verification failed
}
}
من خلال تعيين `gSecurity2 = NULL`، يفشل فحص `if` ولا يتم استدعاء `FileAuthenticationState` أبدًا. يتم تخطي التحقق من الصورة بالكامل - **يبقى Secure Boot "مُمكّنًا" لكنه لم يعد مفروضًا**. يمكن بعد ذلك تحميل تطبيقات UEFI غير الموقّعة بحرية.
لفهم تقني عميق لهذه التقنية، بما في ذلك تطبيق UEFI مُصمم خصيصًا يحدد ويُرقّع gSecurity2 تلقائيًا، راجع المشروع المرافق: [Exploitation Technique - UEFI Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption).
---
<div id='BYOVD'/>
### ***التوازي مع Kernel BYOVD***
التوازي البنيوي بين UEFI BYOVUA و kernel BYOVD دقيق تمامًا:```
┌──────────────────────────────────────────────────────────────┐
│ UEFI BYOVUA (Secure Boot Bypass) │
│ │
│ Signed Shell ─ mm ─> gSecurity2 = NULL ─> Load unsigned │
│ (trusted by (Security2 Protocol) UEFI apps │
│ Secure Boot) │
├──────────────────────────────────────────────────────────────┤
│ Kernel BYOVD (DSE Bypass) │
│ │
│ Signed Driver ─ IOCTL ─> g_CiOptions = 0 ─> Load unsigned │
│ (trusted by (CI.dll) kernel drivers │
│ DSE / CI) │
└──────────────────────────────────────────────────────────────┘
كلا الهجومين يستغلان نفس الخلل الجوهري: مكوّن موقّع تثق به آلية أمنية يوفّر البدائية اللازمة لتعطيل تلك الآلية ذاتها.