themalwareguardian/cve-2022-34303يوضح تجاوز Secure Boot الخاص بـ CVE-2022-34303 عبر UEFI Shell الموقّع من CryptoPro، باستخدام الأمر mm لإبطال gSecurity2 وتحميل تطبيقات UEFI غير الموقّعة.
CryptoPro Secure Disk UEFI Shell - Bring Your Own Vulnerable UEFI Application (BYOVUA) - تجاوز Secure Boot عبر UEFI Shell موقّع وإفساد gSecurity2.
يوضّح هذا المستودع تقنية BYOVUA (Bring Your Own Vulnerable UEFI Application) من خلال استغلال CVE-2022-34303، وهي ثغرة تجاوز Secure Boot في بيئة الإقلاع CryptoPro Secure Disk UEFI.
في هذه الحالة، المكوّن الموثوق به من قِبل Secure Boot هو shim مخصّص موقّع من قِبل Microsoft's UEFI Third Party Certificate Authority. بمجرد تنفيذه، يقوم هذا الـ shim بتحميل UEFI Shell كمرحلة ثانية، مما يتيح الأمر mm (تعديل الذاكرة) وبالتالي يوفّر قدرات قراءة وكتابة عشوائية للذاكرة خلال مرحلة الإقلاع قبل نظام التشغيل.
يمكن بعد ذلك استخدام هذه القدرة لتحديد موقع وإبطال المؤشر العام gSecurity2 في نواة DXE. ونتيجة لذلك، يتم تعطيل التحقق من صور UEFI اللاحقة، مما يسمح بتحميل تطبيقات UEFI غير الموقّعة، مثل bootkits، على الرغم من تمكين Secure Boot.
BYOVUA هو المكافئ في UEFI لتقنية BYOVD (Bring Your Own Vulnerable Driver) المستخدمة على مستوى النواة. فبدلاً من جلب برنامج تشغيل نواة موقّع يحتوي على ثغرة أمنية، يجلب المهاجم تطبيق UEFI موقّعًا - في هذه الحالة، UEFI Shell كامل - يحتوي على وظائف قادرة على تقويض Secure Boot.
ولأن التطبيق - في هذه الحالة، الـ shim المخصّص الذي يحمّل UEFI Shell كمرحلة ثانية - موقّع بشهادة موثوقة من Microsoft، فإنه يُقبل من قِبل Secure Boot دون تساؤل، مما يجعله موثوقًا على أي نظام يتضمّن هذه الشهادة في قاعدة بيانات Secure Boot الخاصة به (db) - وهو عمليًا كل حاسوب قادر على UEFI تم شحنه خلال العقد الماضي. وبمجرد تشغيله، توفّر أوامره المدمجة للمهاجم وصولاً مباشرًا إلى العتاد والذاكرة يعمل قبل تحميل نظام التشغيل، في بيئة لا توجد فيها ضوابط الأمان الحديثة (ASLR، DEP، حمايات النواة) ببساطة.
Shell_Full.efi هو UEFI Shell يتم توزيعه كجزء من CryptoPro Secure Disk، وهو منتج للمصادقة قبل الإقلاع وتشفير الأقراص.
| الخاصية | القيمة |
|---|---|
| الملف | Shell_Full.efi = EFI/Boot/BootX64.efi (SHIM) -> EFI/CPSD/Bootxsa.efi (Shell) |
| المورّد | CryptoPro Secure Disk |
| CVE | CVE-2022-34303 |
| التوقيع | 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 (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) │
└──────────────────────────────────────────────────────────────┘
كلا الهجومين يستغلان نفس الخلل الجوهري: مكوّن موقّع تثق به آلية أمنية يوفّر البدائية اللازمة لتعطيل تلك الآلية ذاتها.