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 के साथ समानता***