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