themalwareguardian/cve-2022-34302يوضح CVE-2022-34302، وهو تجاوز لـ Secure Boot عبر محمّل الإقلاع الموقّع من New Horizon Datasys الذي ينفّذ محمّل PE/COFF المخصص المدمج فيه تطبيقات UEFI غير موقّعة.
محمّل الإقلاع Reboot Restore من New Horizon Datasys - أحضر تطبيق UEFI الضعيف الخاص بك (BYOVUA) - تجاوز Secure Boot عبر محمّل إقلاع موقّع يحتوي على محمّل PE/COFF مخصص مدمج يقوم بتحميل تطبيقات UEFI غير الموقّعة.
يوضّح هذا المستودع تقنية BYOVUA (أحضر تطبيق UEFI الضعيف الخاص بك) من خلال استغلال CVE-2022-34302، وهي ثغرة تجاوز Secure Boot في محمّل الإقلاع New Horizon Datasys.
على عكس الثغرات القائمة على UEFI Shell (CVE-2022-34301 وCVE-2022-34303)، لا يوفّر محمّل الإقلاع هذا واجهة UEFI Shell. بدلاً من ذلك، يطبّق shdloader.efi محمّل PE/COFF مخصصًا خاصًا به يقوم بتحميل ملف ثنائي من المرحلة الثانية (shdmgr.ef_) دون استخدام دالة LoadImage() الخاصة بالبرنامج الثابت ودون إجراء أي تحقق من التوقيع. يحتاج المهاجم فقط إلى استبدال shdmgr.ef_ بأي تطبيق UEFI متوافق لتحقيق تنفيذ كود عشوائي مع تمكين Secure Boot.
تُعدّ هذه أخطر الثغرات الثلاث المُفصح عنها في بحث "One Bootloader to Load Them All". وكما أشارت Eclypsium: فإن التجاوز مدمج، وصامت تمامًا، ولا يترك أي مؤشر مرئي على الشاشة - مما يجعله غير مرئي حتى على الأنظمة المزوّدة بشاشة، وغير قابل للاكتشاف على الأنظمة التي تعمل بدون شاشة مثل الخوادم أو المعدات الصناعية.
BYOVUA هو المكافئ لتقنية BYOVD (أحضر برنامج التشغيل الضعيف الخاص بك) المستخدمة على مستوى النواة، ولكن في سياق UEFI. فبدلاً من إحضار برنامج تشغيل نواة موقّع يحتوي على ثغرة، يُحضر المهاجم تطبيق UEFI موقّعًا يحتوي على وظائف قادرة على تقويض Secure Boot.
ولأن shdloader.efi موقّع بشهادة موثوقة من Microsoft، فإن Secure Boot يقبله دون سؤال، مما يجعله موثوقًا على أي نظام يتضمّن هذه الشهادة في قاعدة بيانات Secure Boot الخاصة به (db) - وهو عمليًا كل جهاز حاسوب يدعم UEFI تم شحنه خلال العقد الماضي. وبمجرد تشغيله، يمنح محمّل PE المخصص المدمج المهاجم القدرة على تحميل وتنفيذ كود عشوائي غير موقّع قبل تحميل نظام التشغيل، في بيئة لا توجد فيها ضوابط الأمان الحديثة (ASLR، DEP، حمايات النواة) ببساطة.
shdloader.efi هو محمّل إقلاع UEFI يُوزَّع كجزء من منتجات استعادة النظام والاسترداد من New Horizon Datasys (Reboot Restore Rx، RollBack Rx). ويتمثل دوره في سلسلة الإقلاع المشروعة في تحميل مكوّن إدارة ما قبل نظام التشغيل (shdmgr.ef_) الذي يتعامل مع عمليات اللقطات والاستعادة قبل بدء نظام التشغيل.
| الخاصية | القيمة |
|---|---|
| الملف | shdloader.efi = EFI/Boot/bootx64.efi |
| المورّد | New Horizon Datasys Inc |
| المنتج | Reboot Restore Rx / RollBack Rx |
| CVE | CVE-2022-34302 |
| التوقيع | Microsoft Windows UEFI Driver Publisher → Microsoft Corporation UEFI CA 2011 |
| الاكتشاف | Eclypsium (Mickey Shkatov، Jesse Michael) - أغسطس 2022 |
| العرض التقديمي | DEF CON 30 - "One Bootloader to Load Them All" |
| الإبطال | أُضيف إلى DBX عبر Microsoft KB5012170 (أغسطس 2022) |
الثغرة هي خلل في التصميم في بنية محمّل الإقلاع. فبدلاً من استخدام خدمات الإقلاع LoadImage() وStartImage() الخاصة بالبرنامج الثابت - التي تفرض التحقق من توقيع Secure Boot - يطبّق shdloader.efi محمّل PE/COFF مخصصًا خاصًا به يقرأ shdmgr.ef_ ويعيد تحديد موقعه وينفّذه مباشرة من بايتات القرص الخام، متجاوزًا بذلك فحوصات الأمان الخاصة بالبرنامج الثابت بالكامل.
المشكلة الجوهرية: ملف ثنائي موقّع موثوق من Secure Boot يحتوي على محمّل صور خاص به لا يتحقق من التوقيعات. يتحقق البرنامج الثابت من أن shdloader.efi موقّع، ولكن بمجرد تشغيله، يقوم بتحميل shdmgr.ef_ دون أي تحقق على الإطلاق. ويؤدي استبدال shdmgr.ef_ بتطبيق UEFI عشوائي إلى تشغيل ذلك التطبيق بوصول كامل إلى العتاد، بينما يُبلّغ Secure Boot عن أنه مُفعّل.
يختلف هذا اختلافًا جوهريًا عن CVE-2022-34301 وCVE-2022-34303، حيث يحتاج المهاجم إلى التفاعل مع UEFI Shell وإفساد gSecurity2 يدويًا لتعطيل التحقق. أما هنا، فالتجاوز - لا تفاعل من المستخدم، ولا مخرجات مرئية، ولا موجّه أوامر.
يحتوي shdloader.efi الموقّع على تطبيق خاص به لمحمّل صور PE/COFF. فبدلاً من استدعاء خدمة الإقلاع LoadImage() الخاصة بالبرنامج الثابت، التي كانت ستستدعي بروتوكولات البنية الأمنية وتتحقق من توقيع الصورة مقابل قاعدة بيانات Secure Boot، يقوم محمّل الإقلاع بما يلي:
\EFI\Boot\shdmgr.ef_ باستخدام EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.reloc ويطبّق إعادة تحديد الموقع الأساسيفي أي مرحلة من هذه العملية، لا يتحقق المحمّل من توقيع Authenticode للصورة، ولا يفحص قاعدة بيانات Secure Boot (db/dbx)، ولا يستدعي EFI_SECURITY2_ARCH_PROTOCOL. يتم تحميل الصورة بناءً فقط على صلاحيتها البنيوية لـ PE/COFF.```c
// Pseudocode of what shdloader.efi does internally
//
// NOTE: This is a simplified representation. The actual
// implementation was derived from reverse engineering.
EFI_STATUS LoadShdmgr(VOID) { // Step 1: Open the file File = OpenFile(L"\EFI\Boot\shdmgr.ef_");
// Step 2: Read raw bytes (no signature check)
ReadFile(File, &Buffer, &Size);
// Step 3: Parse PE/COFF headers
DosHeader = (EFI_IMAGE_DOS_HEADER *)Buffer;
PeHeader = (EFI_IMAGE_NT_HEADERS *)(Buffer + DosHeader->e_lfanew);
// Step 4: Allocate memory and copy sections
ImageBase = AllocatePages(...);
CopySections(ImageBase, Buffer, PeHeader);
// Step 5: Apply base relocations from .reloc
Delta = ImageBase - PeHeader->OptionalHeader.ImageBase;
ApplyRelocations(ImageBase, PeHeader, Delta);
// Step 6: Jump to entry point
// NO SIGNATURE VERIFICATION ANYWHERE
EntryPoint = ImageBase + PeHeader->OptionalHeader.AddressOfEntryPoint;
((EFI_IMAGE_ENTRY_POINT)EntryPoint)(ImageHandle, SystemTable);
}
---
<div id='LoadImageVsCustomLoader'/>
### ***LoadImage مقابل محمّل مخصص***
الفرق بين `LoadImage()` الخاص بالبرنامج الثابت والمحمّل المخصص هو الثغرة الأمنية الحرجة:```
┌─────────────────────────────────────────────────────────────────────────┐
│ Firmware LoadImage() - How legitimate boot chains work │
│ │
│ bootx64.efi ──> LoadImage("shdmgr.ef_") │
│ │ │
│ ├── Parse PE/COFF headers │
│ ├── Verify Authenticode signature │
│ ├── Check signature against db (allowed) │
│ ├── Check hash against dbx (revoked) │
│ ├── Call gSecurity2->FileAuthenticationState() │
│ │ │ │
│ │ ├── Signature valid? ── YES ──> Load image │
│ │ └── Signature invalid? ── NO ──> REJECT │
│ └── StartImage() │
│ │
├─────────────────────────────────────────────────────────────────────────┤
│ Custom PE Loader - What shdloader.efi does │
│ │
│ shdloader.efi ──> OpenFile("shdmgr.ef_") │
│ │ │
│ ├── ReadFile() into buffer │
│ ├── Parse PE/COFF headers │
│ ├── Allocate memory │
│ ├── Copy sections │
│ ├── Apply .reloc relocations │
│ ├── *** NO SIGNATURE CHECK *** │
│ └── Jump to EntryPoint │
│ │
│ Result: ANY valid PE/COFF EFI application runs, signed or not │
└─────────────────────────────────────────────────────────────────────────┘
مُحمِّل PE المخصص هو تطبيق مبسّط ويتوقع تخطيطًا محددًا لـ PE/COFF. يتم رفض الملفات الثنائية غير المتوافقة مع أخطاء:``` Reloc table overflows binary Relocation failed Invalid entry point
أي ملف ثنائي يفتقد أي من هذه سيتم رفضه بواسطة المُحمِّل المخصص.
| الحقل | القيمة المطلوبة | السبب |
|-------|---------------|--------|
| *Machine* | `0x8664` (x64) | المُحمِّل يدعم فقط صور x86-64 |
| *Subsystem* | `10` (EFI Application) | يجب أن يكون EFI Application |
| *قسم .reloc* | يجب أن يوجد `.reloc` مع إدخالات إعادة تحديد أساس صالحة | يقوم المُحمِّل بإعادة تحديد الصورة بنفسه. بدون .reloc، يفشل مع "Reloc table overflows binary" |
| *دليل إعادة التحديد* | `VirtualAddress` != 0، Size != 0 (DATA_DIRECTORY[5]) | يجب أن يشير إدخال الدليل إلى بيانات إعادة تحديد صالحة |
يتم توفير سكربت تحقق (Scripts/VerifyPE.py) للتحقق من التوافق قبل النشر.
---
<div id='BYOVD'/>
### ***التوازي مع Kernel BYOVD***
التوازي البنيوي بين UEFI BYOVUA و kernel BYOVD دقيق، على الرغم من أن CVE-2022-34302 يمثل الشكل الأكثر مباشرة - المكوّن الموقّع **نفسه** يحمّل كودًا غير موقّع، بدلاً من توفير بدائية لتعطيل التحقق:```
┌──────────────────────────────────────────────────────────────┐
│ UEFI BYOVUA - CVE-2022-34302 (Custom PE Loader) │
│ │
│ Signed Bootloader ──> Custom PE Loader ──> Load unsigned │
│ (trusted by (no sig check) UEFI apps │
│ Secure Boot) │
├──────────────────────────────────────────────────────────────┤
│ UEFI BYOVUA - CVE-2022-34301/34303 (Shell + gSecurity2) │
│ │
│ 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) │
└──────────────────────────────────────────────────────────────┘
CVE-2022-34302 هو أخطر متغير لأن التجاوز متأصل في تصميم محمّل الإقلاع - لا توجد خطوة وسيطة يحتاج فيها المهاجم إلى إفساد آلية أمنية. يقوم المكوّن الموقّع بتحميل تعليمات برمجية غير موقّعة مباشرةً كعملية عادية له.
يتم وضع shdloader.efi الموقّع على قسم نظام EFI (ESP) كمحمّل الإقلاع الافتراضي. ولأنه موقّع بشهادة UEFI Driver Publisher من Microsoft، يتحقق Secure Boot منه ويحمّله دون مشاكل.```
EFI System Partition (ESP)
└── EFI/
└── Boot/
└── bootx64.efi (shdloader.efi) ← Signed by Microsoft Windows UEFI Driver Publisher
└── shdmgr.ef_ (PAYLOAD) ← Unsigned, loaded by shdloader's custom PE loader
عند إقلاع النظام، تقوم البرامج الثابتة (firmware) بما يلي:
1. تقرأ `bootx64.efi` من ESP
2. تستدعي `LoadImage()` التي تتحقق من توقيع Authenticode مقابل قاعدة بيانات Secure Boot
3. التوقيع يطابق شهادة Microsoft UEFI CA 2011 في `db` → يتم قبول الصورة
4. تستدعي `StartImage()` لنقل التنفيذ إلى `shdloader.efi`
---
<div id='Phase2'/>
### ***المرحلة 2 - مُحمِّل PE المخصص يُفعَّل***
بمجرد أن يسيطر `shdloader.efi`، يطبع رسالة تشخيصية ويُفعِّل فورًا مُحمِّل PE/COFF المخصص الخاص به:```
Booting in insecure mode
يقوم محمّل الإقلاع بعد ذلك بما يلي:
\EFI\Boot\shdmgr.ef_ باستخدام بروتوكول نظام الملفات.text، .data، .reloc، إلخ) إلى الذاكرة المخصّصةLoadAddress - ImageBase) ويطبّق جميع عمليات إعادة التموضع الأساسية من قسم .relocLoadAddress + AddressOfEntryPoint كهدف التنفيذلا يحدث أي تحقق من التوقيع في أي مرحلة من هذه العملية. لا يستدعي المحمّل LoadImage()، ولا يستدعي gSecurity2->FileAuthenticationState()، ولا يتحقق من قاعدتي بيانات db أو dbx. يتم تحميل الملف بناءً على الصلاحية البنيوية فقط.
إذا لم يتم العثور على الملف، يبلّغ محمّل الإقلاع بما يلي:``` Failed to open \EFI\Boot\shdmgr.ef_ - 800000000000000E Failed to load image
---
<div id='Phase3'/>
### ***المرحلة 3 - تنفيذ تعليمات برمجية غير موقّعة***
يقفز المُحمِّل المخصص إلى نقطة الدخول الخاصة بـ `shdmgr.ef_`. يعمل تطبيق UEFI غير الموقّع الآن مع:
- وصول كامل إلى العتاد (الذاكرة المباشرة، منافذ الإدخال/الإخراج، PCI، MMIO)
- لم يتم تحميل أي نظام تشغيل بعد
- لا يوجد ASLR أو DEP أو حمايات النواة
- لا توجد مراقبة من EDR أو أمان نقاط النهاية
- الإبلاغ عن Secure Boot كـ **مُفعَّل** لأي استعلام لاحق من نظام التشغيل
الهجوم صامت تمامًا. على عكس CVE-2022-34301 و CVE-2022-34303، اللذين يعرضان موجه UEFI Shell مرئيًا، لا ينتج هذا الاستغلال أي مخرجات مرئية تتجاوز رسالة "Booting in insecure mode" (والتي تظهر على نظام شرعي لفترة وجيزة ثم تُستبدل سريعًا بشاشة إقلاع نظام التشغيل). على الأنظمة بدون شاشة (الخوادم، إنترنت الأشياء، المعدات الصناعية)، لا يوجد أي مؤشر على الإطلاق.
---
<div id='Phase4'/>
### ***المرحلة 4 - الاستمرارية***
الهجوم مستمر بشكل افتراضي. طالما بقي `shdloader.efi` في `\EFI\Boot\bootx64.efi` وبقي الحمولة الخاصة بالمهاجم في `\EFI\Boot\shdmgr.ef_` على ESP، تُنفَّذ الحمولة غير الموقّعة عند كل إقلاع.
لا حاجة إلى سكربت `startup.nsh`. ولا حاجة إلى إعادة حساب عنوان gSecurity2 عبر تحديثات البرامج الثابتة. يقوم مُحمِّل PE المخصص بتحميل أي `shdmgr.ef_` يجده، دون أي شرط.
يواصل النظام الإبلاغ عن Secure Boot كـ "مُفعَّل" - فقط سلسلة الثقة قد كُسرت على مستوى مُحمِّل الإقلاع. هذا يجعل الهجوم غير مرئي لاستعلامات حالة Secure Boot على مستوى نظام التشغيل ولأي برنامج أمني يعتمد على إثبات Secure Boot.
> **مهم:** لا تنكسر الاستمرارية إلا إذا تم تحديث DBX بإدخال الإبطال الخاص بـ `shdloader.efi` (KB5012170)، مما يجعل البرنامج الثابت يرفض `shdloader.efi` نفسه قبل أن يُنشَّط المُحمِّل المخصص أصلًا.
---
---
---
<div id='Exploit'/>
## ***الاستغلال***
يحتوي دليل `Exploit/` على كل ما يلزم لبناء `shdmgr.ef_` متوافق:```
Exploit/
|
├── README.md ← Build guide and PE/COFF requirements
|
├── PayloadShdmgr/
| |
│ ├── ForceReloc.nasm ← Force .reloc section generation
│ ├── shdmgr.ef_.c ← UEFI application source (EDK2)
│ ├── shdmgr.ef_.inf ← EDK2 module definition
│ ├── shdmgr.ef_.dsc ← EDK2 platform build configuration
│ └── shdmgr.ef_.dec ← EDK2 package declaration
|
└── Scripts/
└── VerifyPE.py ← PE/COFF compatibility verifier
تمت إضافة محمّل الإقلاع الموقّع إلى قائمة إلغاء DBX الخاصة بـ Microsoft عبر KB5012170 (أغسطس 2022). على الأنظمة المحدّثة، سيرفض Secure Boot محمّل الإقلاع قبل أن يتمكن محمّل PE المخصص من التنشيط أصلاً.
بالنسبة لبيئة المختبر، تحتاج إلى نظام حيث:
توفّر بيئة أبحاث QEMU UEFI إعداداً آلياً لهذا الغرض.
من الأسهل استغلال CVE-2022-34302 مقارنةً بـ CVE-2022-34301 و CVE-2022-34303:
| الجانب | CVE-2022-34302 (محمّل مخصص) | CVE-2022-34301/34303 (Shell) |
|---|
| التقنية | استبدال shdmgr.ef_ بالحمولة | إفساد gSecurity2 عبر أمر mm |
| التفاعل | لا يوجد (تلقائي بالكامل) | أوامر shell يدوية أو startup.nsh |
| الظهور | صامت ("Booting in insecure mode") | موجه UEFI Shell مرئي |
| الاعتماد على البرنامج الثابت | لا يوجد (الحمولة مكتفية ذاتياً) | عنوان gSecurity2 يتغير حسب إصدار البرنامج الثابت |
| التعقيد | منخفض (استبدال ملف) | متوسط (فحص الذاكرة وترقيعها) |
| التخفي | عالٍ (لا مخرجات مرئية على الأنظمة بدون شاشة) | منخفض (shell مرئي على الشاشة) |