themalwareguardian/cve-2022-34302CVE-2022-34302 को प्रदर्शित करता है, जो New Horizon Datasys द्वारा हस्ताक्षरित बूटलोडर के माध्यम से Secure Boot बायपास है, जिसका अंतर्निहित कस्टम PE/COFF लोडर अहस्ताक्षरित UEFI एप्लिकेशन निष्पादित करता है।
न्यू होराइज़न डेटासिस रीबूट रिस्टोर बूट लोडर - ब्रिंग योर ओन वल्नरेबल UEFI एप्लिकेशन (BYOVUA) - अहस्ताक्षरित UEFI एप्लिकेशन लोड करने वाले अंतर्निहित कस्टम PE/COFF लोडर के साथ हस्ताक्षरित बूटलोडर के माध्यम से सिक्योर बूट बायपास।
यह रिपॉज़िटरी CVE-2022-34302 का शोषण करके BYOVUA (ब्रिंग योर ओन वल्नरेबल UEFI एप्लिकेशन) तकनीक का प्रदर्शन करती है, जो न्यू होराइज़न डेटासिस बूट लोडर में एक सिक्योर बूट बायपास भेद्यता है।
UEFI Shell-आधारित भेद्यताओं (CVE-2022-34301 और CVE-2022-34303) के विपरीत, यह बूटलोडर UEFI Shell को उजागर नहीं करता है। इसके बजाय, shdloader.efi अपना स्वयं का कस्टम PE/COFF लोडर लागू करता है जो दूसरे चरण की बाइनरी (shdmgr.ef_) को फर्मवेयर के LoadImage() फ़ंक्शन का उपयोग किए बिना और किसी भी हस्ताक्षर सत्यापन को किए बिना लोड करता है। हमलावर को सिक्योर बूट सक्षम होने पर मनमाना कोड निष्पादन प्राप्त करने के लिए केवल shdmgr.ef_ को किसी भी संगत UEFI एप्लिकेशन से बदलना होता है।
यह "One Bootloader to Load Them All" शोध में प्रकट की गई तीन भेद्यताओं में से सबसे खतरनाक है। जैसा कि Eclypsium ने उल्लेख किया: बायपास अंतर्निहित है, पूरी तरह से मौन है, और स्क्रीन पर कोई दृश्य संकेत नहीं छोड़ता है - जिससे यह मॉनिटर वाले सिस्टम पर भी अदृश्य रहता है और सर्वर या औद्योगिक उपकरण जैसे हेडलेस सिस्टम पर अप्राप्य रहता है।
BYOVUA, कर्नेल स्तर पर उपयोग की जाने वाली BYOVD (ब्रिंग योर ओन वल्नरेबल ड्राइवर) तकनीक का UEFI समकक्ष है। एक भेद्यता वाले हस्ताक्षरित कर्नेल ड्राइवर लाने के बजाय, हमलावर एक हस्ताक्षरित UEFI एप्लिकेशन लाता है जिसमें सिक्योर बूट को कमजोर करने में सक्षम कार्यक्षमता होती है।
चूंकि shdloader.efi Microsoft-विश्वसनीय प्रमाणपत्र के साथ हस्ताक्षरित है, इसे सिक्योर बूट द्वारा बिना किसी प्रश्न के स्वीकार किया जाता है, जिससे यह किसी भी सिस्टम पर विश्वसनीय हो जाता है जो इस प्रमाणपत्र को अपने सिक्योर बूट डेटाबेस (db) में शामिल करता है - जो पिछले दशक में भेजे गए लगभग हर UEFI-सक्षम PC में होता है। एक बार चलने पर, इसका अंतर्निहित कस्टम PE लोडर हमलावर को ऑपरेटिंग सिस्टम लोड होने से पहले मनमाना अहस्ताक्षरित कोड लोड और निष्पादित करने की क्षमता प्रदान करता है, ऐसे वातावरण में जहाँ आधुनिक सुरक्षा नियंत्रण (ASLR, DEP, कर्नेल सुरक्षा) बस मौजूद नहीं हैं।
shdloader.efi न्यू होराइज़न डेटासिस के सिस्टम रिस्टोर और रिकवरी उत्पादों (Reboot Restore Rx, RollBack Rx) के हिस्से के रूप में वितरित एक UEFI बूट लोडर है। वैध बूट श्रृंखला में इसकी भूमिका ऑपरेटिंग सिस्टम शुरू होने से पहले स्नैपशॉट और रिस्टोर संचालन को संभालने वाले प्री-OS प्रबंधन घटक (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" |
| निरसन | Microsoft KB5012170 (अगस्त 2022) के माध्यम से DBX में जोड़ा गया |
भेद्यता बूट लोडर की संरचना में एक डिज़ाइन दोष है। फर्मवेयर के LoadImage() और StartImage() बूट सेवाओं का उपयोग करने के बजाय - जो सिक्योर बूट हस्ताक्षर सत्यापन लागू करते हैं - shdloader.efi अपना स्वयं का कस्टम PE/COFF लोडर लागू करता है जो shdmgr.ef_ को सीधे कच्चे डिस्क बाइट्स से पढ़ता, स्थानांतरित करता और निष्पादित करता है, फर्मवेयर की सुरक्षा जाँचों को पूरी तरह से बायपास करता है।
मूल समस्या: एक हस्ताक्षरित बाइनरी जो सिक्योर बूट द्वारा विश्वसनीय है, उसमें अपना स्वयं का इमेज लोडर होता है जो हस्ताक्षरों को सत्यापित नहीं करता है। फर्मवेयर shdloader.efi को हस्ताक्षरित के रूप में मान्य करता है, लेकिन एक बार चलने पर, यह shdmgr.ef_ को बिना किसी सत्यापन के लोड करता है। shdmgr.ef_ को किसी भी मनमाने UEFI एप्लिकेशन से बदलने पर वह एप्लिकेशन पूर्ण हार्डवेयर पहुँच के साथ चलता है, जबकि सिक्योर बूट सक्षम के रूप में रिपोर्ट करता है।
यह CVE-2022-34301 और CVE-2022-34303 से मौलिक रूप से भिन्न है, जहाँ हमलावर को UEFI Shell के साथ इंटरैक्ट करने और सत्यापन को अक्षम करने के लिए मैन्युअल रूप से को भ्रष्ट करने की आवश्यकता होती है। यहाँ, बायपास है - कोई उपयोगकर्ता इंटरैक्शन नहीं, कोई दृश्य आउटपुट नहीं, कोई शेल प्रॉम्प्ट नहीं।
gSecurity2हस्ताक्षरित shdloader.efi में PE/COFF इमेज लोडर का अपना कार्यान्वयन है। फर्मवेयर की LoadImage() बूट सेवा को कॉल करने के बजाय, जो Security Architectural Protocols को लागू करेगी और सिक्योर बूट डेटाबेस के विरुद्ध इमेज के हस्ताक्षर को सत्यापित करेगी, बूटलोडर:
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL का उपयोग करके \EFI\Boot\shdmgr.ef_ खोलता है.reloc सेक्शन को संसाधित करता है और बेस रीलोकेशन लागू करता हैइस प्रक्रिया में किसी भी बिंदु पर लोडर इमेज के Authenticode हस्ताक्षर को सत्यापित नहीं करता, सिक्योर बूट डेटाबेस (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 बनाम Custom Loader***
फर्मवेयर के `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 section* | `.reloc` मान्य बेस रीलोकेशन प्रविष्टियों के साथ मौजूद होना चाहिए | लोडर अपना स्वयं का इमेज रीलोकेशन करता है। .reloc के बिना, यह "Reloc table overflows binary" के साथ विफल हो जाता है |
| *Relocation Directory* | `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 System Partition (ESP) पर डिफ़ॉल्ट बूट लोडर के रूप में रखा जाता है। चूँकि यह Microsoft के UEFI Driver Publisher प्रमाणपत्र द्वारा हस्ताक्षरित है, 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
जब सिस्टम बूट होता है, तो फर्मवेयर:
1. ESP से `bootx64.efi` पढ़ता है
2. `LoadImage()` को कॉल करता है जो Secure Boot डेटाबेस के विरुद्ध Authenticode हस्ताक्षर को सत्यापित करता है
3. हस्ताक्षर `db` में Microsoft UEFI CA 2011 प्रमाणपत्र से मेल खाता है → इमेज स्वीकार कर ली जाती है
4. निष्पादन को `shdloader.efi` को स्थानांतरित करने के लिए `StartImage()` को कॉल करता है
---
<div id='Phase2'/>
### ***चरण 2 - कस्टम PE लोडर सक्रिय होता है***
एक बार `shdloader.efi` का नियंत्रण हो जाने पर, यह एक डायग्नोस्टिक संदेश प्रिंट करता है और तुरंत अपने कस्टम PE/COFF लोडर को सक्रिय करता है:```
Booting in insecure mode
बूटलोडर फिर:
\EFI\Boot\shdmgr.ef_ खोलता है.text, .data, .reloc, आदि) को आवंटित मेमोरी में कॉपी करता हैLoadAddress - ImageBase) की गणना करता है और .reloc सेक्शन से सभी बेस रीलोकेशन लागू करता हैLoadAddress + 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 एप्लिकेशन अब निम्नलिखित के साथ चलता है:
- पूर्ण हार्डवेयर एक्सेस (प्रत्यक्ष मेमोरी, I/O पोर्ट, PCI, MMIO)
- अभी तक कोई ऑपरेटिंग सिस्टम लोड नहीं हुआ
- कोई ASLR, DEP, या कर्नेल सुरक्षा नहीं
- कोई EDR या एंडपॉइंट सुरक्षा निगरानी नहीं
- किसी भी बाद की OS क्वेरी के लिए Secure Boot **सक्षम** के रूप में रिपोर्टिंग
हमला पूरी तरह से मौन है। CVE-2022-34301 और CVE-2022-34303 के विपरीत, जो एक दृश्यमान UEFI Shell प्रॉम्प्ट प्रदर्शित करते हैं, यह एक्सप्लॉइट "Booting in insecure mode" संदेश के अलावा कोई दृश्य आउटपुट उत्पन्न नहीं करता है (जो, एक वैध सिस्टम पर, संक्षेप में प्रकट होता है और जल्दी से OS बूट स्क्रीन द्वारा प्रतिस्थापित हो जाता है)। हेडलेस सिस्टम (सर्वर, IoT, औद्योगिक उपकरण) पर, कोई संकेत नहीं होता है।
---
<div id='Phase4'/>
### ***चरण 4 - दृढ़ता***
हमला डिफ़ॉल्ट रूप से दृढ़ है। जब तक `shdloader.efi` `\EFI\Boot\bootx64.efi` पर बना रहता है और हमलावर का पेलोड ESP पर `\EFI\Boot\shdmgr.ef_` पर बना रहता है, अहस्ताक्षरित पेलोड प्रत्येक बूट पर निष्पादित होता है।
किसी `startup.nsh` स्क्रिप्ट की आवश्यकता नहीं है। फर्मवेयर अपडेट में किसी gSecurity2 पते को पुनर्गणना करने की आवश्यकता नहीं है। कस्टम PE लोडर जो भी `shdmgr.ef_` पाता है, उसे बिना शर्त लोड करता है।
सिस्टम Secure Boot को "सक्षम" के रूप में रिपोर्ट करना जारी रखता है - केवल ट्रस्ट चेन बूटलोडर स्तर पर टूट गई है। यह हमले को OS-स्तरीय 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
हस्ताक्षरित बूटलोडर को KB5012170 (अगस्त 2022) के माध्यम से Microsoft की DBX निरसन सूची में जोड़ा गया है। अद्यतन किए गए सिस्टम पर, कस्टम PE लोडर के सक्रिय होने से पहले ही Secure Boot द्वारा बूटलोडर को अस्वीकार कर दिया जाएगा।
लैब वातावरण के लिए, आपको एक ऐसे सिस्टम की आवश्यकता है जहाँ:
QEMU UEFI Research Environment इसके लिए एक स्वचालित सेटअप प्रदान करता है।
CVE-2022-34302, CVE-2022-34301 और CVE-2022-34303 की तुलना में शोषण करने के लिए सरल है:
| पहलू | CVE-2022-34302 (कस्टम लोडर) | CVE-2022-34301/34303 (Shell) |
|---|
| तकनीक | shdmgr.ef_ को payload से बदलें | mm कमांड के माध्यम से gSecurity2 को भ्रष्ट करें |
| इंटरैक्शन | कोई नहीं (पूरी तरह से स्वचालित) | मैन्युअल shell कमांड या startup.nsh |
| दृश्यता | मौन ("Booting in insecure mode") | दृश्यमान UEFI Shell प्रॉम्प्ट |
| फर्मवेयर निर्भरता | कोई नहीं (payload स्व-निहित है) | gSecurity2 पता प्रति फर्मवेयर बिल्ड बदलता है |
| जटिलता | कम (फ़ाइल प्रतिस्थापन) | मध्यम (मेमोरी स्कैनिंग और पैचिंग) |
| स्टेल्थ | उच्च (हेडलेस पर कोई दृश्य आउटपुट नहीं) | कम (स्क्रीन पर shell दृश्यमान) |