wack0/bitlocker-attacksबिटलॉकर पर सार्वजनिक हमलों की एक सूची
बिटलॉकर पर सार्वजनिक हमलों की एक सूची। कोई भी सार्वजनिक हमला जिसमें बिटलॉकर पर हमला करने की क्षमता हो, लेकिन जिसकी सटीक विधि अभी भी सार्वजनिक नहीं है (जैसे baton drop), दायरे से बाहर है।
अधिकांश हमले उन स्थितियों के लिए हैं जहाँ VMK केवल TPM द्वारा सील किया जाता है, जो डिफ़ॉल्ट सेटिंग है, और यही स्वचालित BitLocker Microsoft खाते में रिकवरी कुंजी एस्क्रो के साथ उपयोग करता है।
डिफ़ॉल्ट रूप से, Windows 8 से शुरू करके, यदि सिक्योर बूट सक्षम है तो सिक्योर बूट अखंडता सत्यापन का उपयोग किया जाता है।
यदि आपको VMK को केवल TPM द्वारा सील करना ही है, तो इसके लिए सबसे सुरक्षित कॉन्फ़िगरेशन PCR 0, 2, 4, 7, 11 के साथ लीगेसी अखंडता सत्यापन का उपयोग करना है (और अपने सिस्टम को पूरी तरह से अपडेट रखना भी)।
कृपया ध्यान दें कि यह केवल सॉफ़्टवेयर हमलों से सुरक्षा करेगा।
हार्डवेयर हमले आम तौर पर तभी उपयोगी होते हैं जब हमलावर के पास ऐसे सिस्टम तक भौतिक पहुंच हो जहाँ VMK केवल TPM द्वारा सील किया गया हो।
| सारांश | विवरण | फिक्स | सार्वजनिक सूचना समयावधि | खोजकर्ता |
|---|---|---|---|---|
| TPM स्निफिंग: bootmgr TPM के साथ स्पष्ट रूप से संवाद करता है | Windows Boot Manager TPM के साथ स्पष्ट रूप से संवाद करता है, इसलिए यदि LPC बस पर एक अलग TPM चिप उपयोग की जाती है (अर्थात, fTPM या "Pluton"/HSP नहीं), तो उस बस पर एक लॉजिक विश्लेषक का उपयोग VMK को डंप करने के लिए किया जा सकता है। यह भी देखें पल्स सिक्योरिटी से ब्लॉग पोस्ट, LPC स्निफर Verilog कोड. | कोई नहीं, लेकिन फर्मवेयर TPM वैसे भी असुरक्षित नहीं थे | जनवरी 2019 | marcan |
| हार्डवेयर डिबगर: कुछ सिस्टम हार्डवेयर डिबगर सक्षम करने से पहले PCR7 में मापन नहीं करते हैं | TPM के लिए TCG EFI प्लेटफ़ॉर्म विनिर्देश (खंड 6.4) में निम्नलिखित शामिल है: "यदि प्लेटफ़ॉर्म एक फर्मवेयर डिबगर मोड प्रदान करता है जिसका उपयोग UEFI पर्यावरण से पहले किया जा सकता है या यदि प्लेटफ़ॉर्म UEFI पर्यावरण के लिए एक डिबगर प्रदान करता है, तो प्लेटफ़ॉर्म को डिबगर के उपयोग की अनुमति देने से पहले PCR[7] में एक EV_EFI_ACTION घटना का विस्तार करना अनिवार्य है।" कुछ सिस्टम कुछ हार्डवेयर डिबगर (जैसे Intel DCI) को सक्षम करने से पहले यह मापन नहीं करते हैं। इसलिए ऐसे असुरक्षित सिस्टम पर, एक सिक्योर बूट बायपास (भौतिक पहुंच सिक्योर बूट सक्षम रहते हुए कम से कम दो की अनुमति देगी) या हार्डवेयर हमला (सीधे SPI फ्लैश में लिखना) का उपयोग हार्डवेयर डिबगर को सक्षम करने के लिए किया जा सकता है; bootmgr!FvebUnsealCallback के अंदर एक ब्रेकपॉइंट सेट करना (उदाहरण के लिए) फिर VMK को डंप करने की अनुमति दे सकता है। यह भी देखें यूरोप 2023 डिजिटल फोरेंसिक्स रिसर्च कॉन्फ्रेंस से यह लेख। | कोई नहीं, असुरक्षित सिस्टम के लिए। असुरक्षित सिस्टम की सटीक सूची अज्ञात है। | मार्च 2023 | ब्राज़ीलियाई संघीय पुलिस |
| fTPM ग्लिचिंग: ग्लिचिंग के माध्यम से कोड निष्पादन जो fTPM स्थिति से पूरी तरह समझौता करता है | यदि एक on-SoC प्रोसेसर/माइक्रोकंट्रोलर जो fTPM लागू करता है, ग्लिचिंग के प्रति असुरक्षित है, जिससे बूट के शुरुआती चरण में कोड निष्पादन प्राप्त किया जा सकता है, तो पूरी fTPM स्थिति से समझौता किया जा सकता है, जिससे VMK डंपिंग (आदि) हो सकती है। यह भी देखें शोध लेख, AMD PSP के लिए पेलोड/आदि | IntelME: नवंबर 2021 / एल्डर लेकAMD: अज्ञात, कोई नहीं?अन्य (ARM64, ARMv7, आदि): अज्ञात |
सॉफ़्टवेयर हमले आम तौर पर bootmgr, या किसी अन्य बूट एप्लिकेशन में कमजोरियाँ होती हैं, जहाँ किसी भी वॉल्यूम के लिए मेमोरी में व्युत्पन्न BitLocker कुंजियों के साथ शोषण संभव होता है।
जहाँ बूट एप्लिकेशन के अंदर कोड निष्पादन प्राप्त किया जा सकता है, वहाँ एक "ईविल क्लीनर" हमलावर के लिए बूटकिट स्थापित करना संभव हो सकता है जो स्वयं मेमोरी में व्युत्पन्न कुंजियों के साथ चलेगा (या जब कुंजियाँ अभी भी व्युत्पन्न की जा सकती हैं), और इस प्रकार एक सिस्टम से समझौता करेगा जहाँ पासवर्ड या स्टार्टअप कुंजी का उपयोग TPM के बजाय या उसके अतिरिक्त किया जाता है।
एक असुरक्षित सिस्टम में मई 2022 या जून 2022 के अपडेट स्थापित होंगे, लेकिन उसके बाद के कोई भी अपडेट नहीं होंगे।
संबद्ध विकल्प GUID हैश किए गए डेटा का हिस्सा है, इसलिए उपयोग किए गए डिवाइस तत्व को सत्यापित नहीं के रूप में चिह्नित किया जाना चाहिए।
Windows 7 और उससे नीचे पर उपयोग किए जा सकने वाले कोई तत्व नहीं हैं (हालाँकि जब कस्टम गैर-डिफ़ॉल्ट सेटिंग्स का उपयोग किया जाता है, तो यह अभी भी संभव हो सकता है)।
Windows 8 और उससे ऊपर पर, osloader!osdevice डिफ़ॉल्ट रूप से सत्यापित नहीं होता है, और इस प्रकार इसका उपयोग किया जा सकता है।
इसका शोषण करने का सबसे आसान तरीका BCD कच्चे डिवाइस संपादक, bcdeditmod का उपयोग करना है, हालाँकि BCD रजिस्ट्री हाइव को मैन्युअल रूप से संपादित करना भी संभव है (खुद पता लगाएँ)।
शोषण में निम्नलिखित शामिल है:
{default} से osdevice की प्रतिलिपि पहले वाले में बनाएँ{default}!osdevice में संबद्ध विकल्प GUID को पहले डिवाइस तत्व पर सेट करें{first}!osdevice में संबद्ध विकल्प GUID को दूसरे डिवाइस तत्व पर सेट करेंdebug) सेट करेंbootmgfw बाइनरी का उपयोग करके बूट करें जिसका वह उपयोग कर रहा थायह कमजोरी 17 वर्षों से अधिक समय से मौजूद थी, जिसका सबसे पुराना ज्ञात बिल्ड जिसमें इसे पेश किया गया था, वह अक्टूबर 2005 का 6.0.5231.2 (winmain_idx03.051004-2120) है।
जहाँ सिक्योर बूट अखंडता सत्यापन उपयोग किया जाता है, वहाँ इस कमजोरी का शोषण करने के लिए एक डाउनग्रेड हमला अभी भी काम करेगा।Set up a PXE boot server with a vulnerable bootmgfw.efi (where legacy integrity validation is used, this must be the bootmgfw.efi from the target device) renamed correctly for EFI booting.
For the BCD, set up one default entry where device is the BitLocker encrypted osdevice; path is "\"; and a recovery sequence.
The recovery sequence should point to a single startup entry, where device is boot, path points to an EFI application to run (from the PXE server); and pxesoftreboot is enabled.
When Secure Boot is disabled, that EFI application can just be an application to scan physical memory looking for a BitLocker keytable to dump.
When Secure Boot is enabled, that EFI application can use a known Secure Boot bypass (where physical access is required if needed).
For exploiting a Windows boot application in this way, you will need to replace the BCD with your second one on the PXE server.
This means pressing an arrow key during bootmgr startup to force the boot menu to show; and then replacing the BCD on the PXE server at that point.
Exploitation involves:
manage-bde -pause C: निष्पादित करें और उसके बाद manage-bde -protectors -delete C: चलाएं।इस बिंदु पर, डिस्क पर मौजूद BitLocker मेटाडेटा में एक प्लेनटेक्स्ट VMK होगा।
इसे डंप करें, और उस VMK का उपयोग FVEK को डिक्रिप्ट करने के लिए करें।
डिक्रिप्ट किया गया FVEK पहले बनाई गई डिस्क इमेज पर पार्टीशन को डिक्रिप्ट करने के लिए उपयोग किया जा सकता है।
कृपया ध्यान दें: मैंने इस मुद्दे का शोषण केवल विंडोज 10 पर बहुत विशिष्ट परिस्थितियों में सफलतापूर्वक किया (बिना रिकवरी कुंजी के TPM-केवल BitLocker)।
हालाँकि, अन्य लोगों ने विंडोज 11 पर एक कमजोर WinRE का उपयोग करके इस मुद्दे का सफलतापूर्वक शोषण किया है (Nickel)।
जहाँ तक मुझे ज्ञात है, यह कमजोरी उतनी ही पुरानी है जितना बूट मैनेजर है - यह जून 2005 से 6.0.5098.0 (winmain_beta1.050628-1740) जितनी पुरानी बिल्ड में मौजूद प्रतीत होती है, हालाँकि वह BCD से पहले की है इसलिए उतने पुराने बिल्ड में शोषण अलग होता। प्रासंगिक कोड पहले भी मौजूद प्रतीत होता है (ramdisk-संबंधित कोड अप्रैल 2005 की बिल्ड 5048 में समान प्रतीत होता है), लेकिन बिल्ड 5098 सबसे पुरानी डंप की गई बिल्ड है जिसमें BitLocker किसी रूप में मौजूद है।
इसका शोषण करने के लिए, आपको bitpixie की तरह एक डिफ़ॉल्ट प्रविष्टि और एक रिकवरी अनुक्रम सेट करना होगा। ऐसा इसलिए है ताकि फ़ाइल लोड होने पर OS डिवाइस के लिए कुंजियाँ व्युत्पन्न की जा सकें।
रिकवरी अनुक्रम में रैमडिस्क सेट करने के लिए एक अतिरिक्त डिवाइस प्रविष्टि होनी चाहिए। इसके लिए bcdeditmod का उपयोग करें। यहाँ custom:21100000 जैसे कस्टम तत्व का उपयोग करें। यहाँ उपयोग करने के लिए डिवाइस प्रविष्टि का एक उदाहरण !raw:block[ram[part2[hd[gpt[{D2E23617-2338-4685-A2D7-F3133312E12E}]],gptsig[{1B85332B-AD73-4D9A-BFC3-B39443D3DFE4}]],:\hiberfil.sys:]] होगा - आप यहाँ part2 ब्लॉक डिवाइस को अपने लक्षित सिस्टम के BCD वाले डिवाइस से बदलना चाहेंगे।
फिर फ़ाइल को मेमोरी से किसी भी ऐसी विधि से डंप किया जा सकता है जो आपके लिए काम करती है। मैं उन्नत विकल्प मेनू के माध्यम से पुराने winload को सेल्फ-साइन्ड mcupdate में उपयोग करना पसंद करता हूँ, लेकिन अन्य विकल्प भी उपलब्ध हैं (उदाहरण के लिए PXE सॉफ्ट रीबूट करके किसी तृतीय-पक्ष ऑपरेटिंग सिस्टम में; बगचेक या किसी ज्ञात कमजोर ड्राइवर का उपयोग करके WinPE से मेमोरी डंप करना संभव है, लेकिन winload मेमोरी क्षेत्र को NT मेमोरी मैप में मुक्त के रूप में चिह्नित कर देगा, इसलिए winload में उस मेमोरी को खराब/आदि के रूप में चिह्नित करने के लिए कुछ अन्य सेटिंग्स के बिना इसे अधिलेखित किया जा सकता है)।
मेरी पसंदीदा विधि का एक प्रूफ ऑफ कॉन्सेप्ट कार्यान्वयन इस रिपॉजिटरी में ramleak.zip के रूप में शामिल है। उपयोग निर्देशों के लिए शामिल readme पढ़ें।
मैक्सिम सुहानोव को धन्यवाद, यह CrashXTS राइटअप पढ़ने और hiberfil.sys को डंप करने का कोई अन्य तरीका निकालने से प्रेरित था।
और अब इस बग और yellowkey के बारे में मेरे अपने विचार:
MSRC को सबमिट करने में यह पहली बार था जब मुझे वास्तविक समस्या हुई, और यह मुख्य रूप से उनकी ओर से Secure Boot से संबंधित एक गलतफहमी थी। यह देखते हुए कि अन्य bitlocker 0day ड्रॉप किया जा रहा है, मैंने इसे अभी जारी करने का फैसला किया, मैं लगभग एक साल से इस पर बैठा हूँ कि इसके साथ क्या करना है।
yellowkey के विपरीत, मैं इसे "बैकडोर" बताने जैसी अतिरंजित बातें नहीं करूँगा, मेरी राय में मुझे नहीं लगता कि yellowkey एक बैकडोर है, संबंधित घटक WinPE से संबंधित है (WinRE-विशिष्ट नहीं), और वहाँ मुख्य "vuln" उस कोडपाथ तक पहुँचने के लिए winpeshl.ini को हटवाना है, मैं पूरी तरह समझ सकता हूँ कि MS ने क्यों सोचा कि WinRE+bitlocker परिदृश्य में इसे हटाना संभव नहीं था।
चूँकि bitlocker-एन्क्रिप्टेड पार्टीशन से रैमडिस्क लोड करना वास्तव में बूट एनवायरनमेंट की एक विशेषता है, हालाँकि मुझे इसे वास्तव में काम करने के लिए एक मौजूदा ट्रिक का उपयोग करना पड़ा, अन्य लोग भी चाहें तो इसे बैकडोर कह सकते हैं, लेकिन मैं इतनी दूर नहीं जाऊँगा। बूट एनवायरनमेंट जटिल है (और बड़ा होता जा रहा है, नवीनतम bootmgfw_ex.efi अब 2.88MB इमेज में नहीं समाता - एक युग का अंत), कई vulns इस कारण खोजे गए हैं कि कुछ विशेषताएँ एक-दूसरे के साथ कैसे इंटरैक्ट करती हैं।
| अप्रैल 2023 |
| Hans Niklas Jacob, Christian Werling, Robert Buhren, Jean-Pierre Seifert of Technische Universit ät Berlin - SecT |
| बूट-समय IOMMU अक्षम करना: फ्लैश डंप/रीराइट के साथ UEFI गैर-वाष्पशील चर भंडारण को संशोधित करना बूट पर IOMMU को अक्षम कर सकता है | कुछ UEFI फर्मवेयर चर डेटा के आधार पर बूट पर IOMMU सक्षम नहीं करेंगे। फ्लैश डंप करके, उन चरों को संशोधित करके और पुनः लिखकर, IOMMU बूट पर अक्षम हो जाएगा और TPM गैर-वाष्पशील स्थिति अभी भी मान्य रहेगी। उस बिंदु पर, एक हमलावर bootmgr लॉन्च होने से पहले PCI DMA का उपयोग करके DMAR ACPI तालिका को अधिलेखित कर सकता है, सेफ मोड में बूट कर सकता है और फिर SYSTEM शेल पाने के लिए फिर से PCI DMA का उपयोग कर सकता है। लेख देखें। यह अज्ञात है कि यह किस घटक में है; लेख एक Intel सिस्टम का उपयोग करता है, वहाँ प्रासंगिक कोड Intel फर्मवेयर सपोर्ट पैकेज द्वारा प्रदान किया गया है। यह अज्ञात है कि AMD समकक्ष (AGESA/CBS) भी प्रभावित है या नहीं। | Intel फर्मवेयर सपोर्ट पैकेज: अज्ञात AMD AGESA/CBS: अज्ञात | मार्च 2026 | Craig S. Blackie of MDSec |
| सारांश | विवरण | फिक्स | सार्वजनिक सूचना समयावधि | खोजकर्ता |
|---|
| बूट वातावरण नई कुंजी तालिका बनाते समय पिछली कुंजी तालिका को मिटाता नहीं है | बूट लाइब्रेरी इनिशियलाइज़ेशन फ़ंक्शन में उसे पारित किए गए फ़्लैग्स का एक सेट होता है। यदि बिट 7 सेट है (जो कम से कम bootmgr के लिए मामला है), किसी भी मौजूदा कुंजी तालिका को अनदेखा कर दिया जाता है, और एक नई बनाई जाती है। मौजूदा कुंजी तालिका मिटाई नहीं जाती है, और मेमोरी में बनी रहती है। यह एक हमलावर को मनमाने osdevice के साथ bootmgr लोड करने की अनुमति देता है, फिर या तो कोड निष्पादन पाने के लिए bootmgr का शोषण करता है, या WinPE लोड करने के लिए RS2+ bootmgr का उपयोग करता है (यह सुनिश्चित करने के लिए कि केवल एक सिक्योर बूट नीति मौजूद है) और एक ज्ञात असुरक्षित ड्राइवर का उपयोग करके कुंजी तालिका को ढूंढता है और डंप करता है।लीगेसी अखंडता सत्यापन का उपयोग इस हमले को काम करने से रोकता है, BitLocker विभाजन मेटाडेटा में बूट एप्लिकेशन अनुमत सूची के कारण। | जनवरी 2022 में शमन किया गया (अधिकांश मामलों में bootmgr लोड करने से रोककर)। मार्च 2023 में बिल्ड 25330 के साथ ठीक किया गया (नई बनाने से पहले मौजूदा कुंजी तालिका मैप और मिटा दी जाएगी)। इस कमजोरी का शोषण करने के लिए एक डाउनग्रेड हमला अभी भी काम करेगा। | अगस्त 2022 (बैटन ड्रॉप के साथ); जनवरी 2022 में खोजा गया। | Rairii |
| लीगेसी अखंडता सत्यापन ने संबद्ध विकल्पों को गलत तरीके से लागू किया | लीगेसी अखंडता सत्यापन प्रभावित (जहाँ असुरक्षित bootmgr उपयोग किया जाता है), सिक्योर बूट अखंडता सत्यापन बिल्कुल भी प्रभावित नहीं BitLocker लीगेसी अखंडता सत्यापन सभी बूट विकल्पों से गुजरता है, और या तो सुनिश्चित करता है कि वे मौजूद हैं, सुनिश्चित करता है कि कोई भी अज्ञात विकल्प मौजूद नहीं है, या उन्हें हैश करके सुनिश्चित करता है कि वे अपरिवर्तित हैं। मूल कार्यान्वयन ने संबद्ध विकल्पों से गुजरने का भी प्रयास किया, लेकिन ऐसा करने के लिए गलत ऑफ़सेट का उपयोग किया। यह एक ऐसा BCD बनाने की अनुमति देगा जिसमें BitLocker लीगेसी अखंडता सत्यापन के लिए अदृश्य बूट विकल्प शामिल हों। यहाँ कई खतरनाक विकल्प, विशेष रूप से debug, BitLocker कुंजी तालिका डंपिंग का कारण बन सकते हैं।संबद्ध विकल्पों से गुजरते समय सही ऑफ़सेट का उपयोग करके ठीक किया गया। यह बग CVE-2022-29127 है। | मई 2022 | जून 2022 (emfcamp पर, bindiffing के लिए धन्यवाद) | Matt Wesemann of Microsoft (WDG) |
| dangerous association: लीगेसी अखंडता सत्यापन ने संबद्ध विकल्पों को गलत तरीके से लागू किया (भाग 2) | लीगेसी अखंडता सत्यापन प्रभावित (जहाँ असुरक्षित bootmgr उपयोग किया जाता है), सिक्योर बूट अखंडता सत्यापन बिल्कुल भी प्रभावित नहीं पिछली कमजोरी का समाधान गलत था और केवल संबद्ध विकल्पों के एक स्तर की जाँच करता था, जबकि बूट विकल्पों का उपयोग करने वाला कोड पुनरावृत्त करता था। यह एक ऐसा BCD बनाने की अनुमति देगा जिसमें BitLocker लीगेसी अखंडता सत्यापन के लिए अदृश्य बूट विकल्प शामिल हों। यह भी देखें सार्वजनिक सूचना। अन्य कोड की तरह संबद्ध विकल्पों में पुनरावृति करके ठीक किया गया। यह बग CVE-2022-22048 है। | जुलाई 2022 | दिसंबर 2022; मई 2022 में पिछले पैच की bindiffing करते समय खोजा गया | Rairii |
| bitpixie: PXE सॉफ्ट रीबूट मेमोरी से व्युत्पन्न बिटलॉकर कुंजियों को मिटाता नहीं है | केवल UEFI सिस्टम पर शोषण योग्य (लीगेसी BIOS, या CSM नहीं)। लीगेसी अखंडता सत्यापन प्रभावित (जहाँ असुरक्षित bootmgr उपयोग किया जाता है), सिक्योर बूट अखंडता सत्यापन प्रभावित PXE सॉफ्ट रीबूट नेटवर्क से बूट करते समय अनुमत है, और केवल BS->LoadImage() और BS->StartImage() करता है।BS->StartImage कॉल किए जाने के समय व्युत्पन्न BitLocker कुंजियाँ अभी भी मेमोरी में होती हैं।फिर उन्हें मेमोरी से डंप किया जा सकता है। इसके अतिरिक्त: BitLocker कुंजियाँ बूट एप्लिकेशन लोड करने में बहुत पहले व्युत्पन्न होती हैं। यदि डिस्क से PE लोड करना विफल रहा, तो अखंडता सत्यापन नहीं किया जाता है और व्युत्पन्न कुंजियाँ मेमोरी में रहती हैं। फिर एक PXE सॉफ्ट रीबूट किया जा सकता है, इस प्रकार यह लीगेसी अखंडता सत्यापन को भी बायपास करता है। यह भी देखें सार्वजनिक सूचना। bootmgr!BlNetSoftReboot को कॉल करने से पहले bootmgr!PxeSoftReboot में बिटलॉकर कुंजी तालिकाओं को मिटाकर ठीक किया गया। यह बग CVE-2023-21563 है। | नवंबर 2022 (बिल्ड 25236); जनवरी 2023 (बैकपोर्ट) जहाँ सिक्योर बूट अखंडता सत्यापन उपयोग किया जाता है, इस कमजोरी का शोषण करने के लिए एक डाउनग्रेड हमला अभी भी काम करेगा। | फरवरी 2023, अगस्त 2022 में खोजा गया | Rairii |
| push button decrypt: WinRE में रीसेट डिक्रिप्ट के दौरान बाधित किया जा सकता है, जिससे हमलावर को कुंजी सुरक्षा अक्षम करने के लिए शेल मिल सकता है | Windows Server इस कमजोरी के प्रति संवेदनशील नहीं है क्योंकि यह रीसेट सुविधा का समर्थन नहीं करता है। लीगेसी अखंडता सत्यापन और सिक्योर बूट अखंडता सत्यापन प्रभावित, जहाँ असुरक्षित winre छवि उपयोग की जाती है किसी सिस्टम के WinRE में बूट करते समय, संबद्ध osvolume के लिए कुंजियाँ व्युत्पन्न होती हैं। इन कुंजियों को पुश बटन रीसेट (डेटा हटाने के साथ) करते समय मेमोरी में रहने की अनुमति होती है। "केवल मेरी फ़ाइलें हटाएँ" रीसेट शुरू करने से ~98% पूर्णता पर ड्राइव डिक्रिप्ट होना शुरू हो जाएगा। इस बिंदु पर रीबूट करने से winre में रीबूट होगा जो एक त्रुटि और एक बटन दिखाएगा जो रीबूट करता है। रीबूट करने के बाद, विंडोज़ सेटअप एक अपग्रेड स्क्रीन पर लॉन्च होता है। शेल पाने के लिए Shift+F10 यहाँ काम करता है।यहाँ एक शेल डिक्रिप्शन को रोकने और सभी कुंजी सुरक्षा हटाने के लिए पर्याप्त है, फिर प्लेनटेक्स्ट VMK का उपयोग FVEK को डिक्रिप्ट करने के लिए किया जा सकता है जिसे पहले बनाई गई डिस्क छवि के साथ उपयोग किया जा सकता है। रीसेट से पहले BitLocker रिकवरी कुंजी की आवश्यकता के द्वारा ठीक किया गया। यह बग CVE-2022-41099 है। | नवंबर 2022 (winre छवि को मैन्युअल रूप से पैच किया जाना चाहिए) | मई 2023 | अज्ञात |
| dubious disk: बूट वातावरण के संदर्भ में मनमाना कोड निष्पादन | इस बग या इसके वेरिएंट का शोषण बूट वातावरण के संदर्भ में मनमाना कोड निष्पादन प्राप्त करता है, इसलिए या तो बिटलॉकर कुंजियों की व्युत्पत्ति (bootmgr में मनमाना कोड निष्पादन के साथ) या बिटलॉकर कुंजी तालिका की डंपिंग (किसी अन्य बूट एप्लिकेशन में मनमाना कोड निष्पादन के साथ) की अनुमति देता है। यह बग और इसके वेरिएंट CVE-2022-30203, CVE-2023-21560, CVE-2023-28269, CVE-2023-28249, (अज्ञात), और CVE-2024-38065 हैं। | जुलाई 2022 और जुलाई 2024 के बीच विभिन्न सुधार। इन कमजोरियों का शोषण करने के लिए एक डाउनग्रेड हमला अभी भी काम करेगा। | जून 2024 (सार्वजनिक राइटअप, जुलाई 2024 में ठीक किए गए वेरिएंट को छोड़कर); मूल रूप से अगस्त 2021 में खोजा गया और जनवरी से मार्च 2022 के बीच शोषित किया गया | Rairii |
| CrashXTS: क्रिप्टोग्राफ़िक हमला, SYSTEM हाइव के सटीक भ्रष्टाचार की अनुमति देता है, जिससे hiberfile स्पष्ट रूप में लिखा जाता है | BitLocker AES-XTS का उपयोग करता है। क्रिप्टेड विभाजन की कई छवियाँ लेकर, SYSTEM हाइव का ऑफ़सेट खोजना संभव है, और इसलिए SYSTEM\ControlSet001\Control\CrashControl कुंजी का ऑफ़सेट, और हाइव को इस तरह से भ्रष्ट करना कि hiberfile को डिस्क पर लिखते समय एन्क्रिप्ट करने के लिए उपयोग की जाने वाली फ़िल्टर ड्राइवर लोड न हो। इसलिए, कोई व्यक्ति सिस्टम को हाइबरनेट कर सकता है, विभाजन को फिर से डंप कर सकता है, और वॉल्यूम कुंजियों सहित एक पूर्ण प्लेनटेक्स्ट (संपीड़ित) RAM डंप प्राप्त कर सकता है।यह भी देखें सार्वजनिक राइटअप। यदि आवश्यकता होने पर लोड करने के लिए वह फ़िल्टर ड्राइवर मौजूद नहीं है, तो बगचेक करके ठीक किया गया। यह बग CVE-2025-21210 है। | जनवरी 2025 | जनवरी 2025 | Maxim Suhanov |
| break out in hives: systemdatadevice तत्व winload को हमलावर द्वारा निर्दिष्ट SYSTEM हाइव का उपयोग करने का कारण बनता है | Windows 10 (th1) से शुरू करके, systemdatadevice तत्व के लिए समर्थन winload में जोड़ा गया था। यदि मौजूद है, तो winload osdevice के बजाय इस डिवाइस से SYSTEM हाइव पढ़ता है।इस प्रकार, हमलावर WinPE से SYSTEM हाइव ले सकता है, Setup!CmdLine को cmd.exe में संशोधित कर सकता है, और WinRE बूट करते समय winload को इस हाइव का उपयोग करने का कारण बना सकता है। इसके बाद WinRE बूट करने पर, osvolume के लिए बिटलॉकर कुंजियाँ मेमोरी में व्युत्पन्न होने पर एक SYSTEM शेल खुलेगी; इस प्रकार, बिटलॉकर बायपास। systemdatadevice से SYSTEM हाइव लोड करने की क्षमता हटाकर ठीक किया गया। यह बग CVE-2024-20666 है। | जनवरी 2024 (winre छवि को मैन्युअल रूप से पैच किया जाना चाहिए) | फरवरी 2025; मार्च 2023 में खोजा गया | Rairii |
| break out in hives 2: systemdatadevice तत्व का शोषण करने की वैकल्पिक विधि, डाउनग्रेड हमले के साथ उपयोग योग्य | break out in hives के लिए सुधार ने winload को अपडेट किया। हालाँकि, winload के पहले (अनफिक्स्ड) संशोधन संभावित रूप से अभी भी Windows के अपने प्रमुख संस्करण को बूट करने के लिए चल सकते हैं (हर संस्करण के लिए व्यवहार में काम नहीं कर सकते)। इस प्रकार, हमलावर एक पुराना winload ला सकता है, उससे बूट करने के लिए BCD को संशोधित कर सकता है, और हमले को दोहरा सकता है, हालाँकि एक अलग शोषण विधि का उपयोग किया जाना चाहिए। winpe तत्व BCD में सेट होना चाहिए (यदि नहीं, तो बिटलॉकर एन्क्रिप्टेड osvolume में SYSTEM हाइव भ्रष्ट हो जाएगा!)यहाँ काम करने वाला SYSTEM हाइव Windows के उसी प्रमुख संस्करण की install.wim छवि से आएगा (WinPE/WinRE नहीं)। Win32 सबसिस्टम पूरी तरह से प्रारंभ नहीं कर पाएगा, लेकिन smss को ControlSet001\Control\Session Manager!SetupExecute में कॉन्फ़िगर किया जा सकता है ताकि मेमोरी में व्युत्पन्न कुंजियों के साथ SYSTEM के रूप में मनमाना नेटिव सबसिस्टम कोड निष्पादन प्राप्त किया जा सके।यदि सिक्योर बूट सक्षम है, तो bootmgr में systemdatadevice तत्व को मिटाकर ठीक किया गया, लेकिन सुधार केवल PCA 2023-हस्ताक्षरित bootmgr_ex पर लागू किया गया था, इसलिए KB5025885 शमन सक्षम किए बिना, यह कमजोरी अभी भी मौजूद है और अनफिक्स्ड बनी हुई है। यह बग CVE-2025-21213 है। | जनवरी 2025, केवल PCA2023-हस्ताक्षरित bootmgr_ex में | फरवरी 2025; जनवरी 2024 में खोजा गया (मूल सुधार के बाद) | Rairii |
| बूट वातावरण रैमडिस्क लोड करते समय SDI की जाँच नहीं करता है, जिसमें उपयोग किए गए WIM का ऑफ़सेट होता है | रैमडिस्क लोड करते समय, बूट वातावरण (और NT wimfsf.sys) SDI फ़ाइल से उपयोग किए गए WIM का ऑफ़सेट प्राप्त करता है यदि वह मौजूद है, और उपयोग की गई SDI फ़ाइल का कोई सत्यापन नहीं होता है। इसलिए एक क्राफ्टेड SDI फ़ाइल का उपयोग रिकवरी अनुक्रम में osdevice बिटलॉकर कुंजियों के व्युत्पन्न होने पर एक मनमाना WinPE WIM बूट करने के लिए किया जा सकता है।यह जाँच करके ठीक किया गया कि गणना किया गया WIM ऑफ़सेट WIM के वास्तविक लोड ऑफ़सेट के बराबर है, और नहीं होने पर STATUS_INVALID_IMAGE_FORMAT लौटाता है। यह बग CVE-2025-48804 है। | जुलाई 2025 | अगस्त 2025 (ब्लैक हैट पर) | Alon Leviev and Netanel Ben Simon of Microsoft (MORSE) |
YellowKey उर्फ trans writes (मिरर, पासवर्ड: bitlocker): एक वॉल्यूम पर स्थित फाइल सिस्टम ट्रांजैक्शन फ़ाइलें दूसरे वॉल्यूम पर फ़ाइलों को प्रभावित कर सकती हैं | Germanium ने एक नई फाइल सिस्टम ट्रांजैक्शन सुविधा पेश की (NTFS ट्रांज़ैक्शन से असंबंधित)। इसके लॉग डिस्क पर होते हैं और fstx.dll (सर्विसिंग स्टैक का हिस्सा) द्वारा पार्स किए जाते हैं, और केवल WinPE में इसे नए नेटिव निष्पादन योग्य autofstx.exe ("बूट-टाइम FsTx अपडेट रिकवरी यूटिलिटी" - "यह उपयोगिता बूट-टाइम पर विफल FsTx अपडेट को पुनर्प्राप्त करती है।") द्वारा लोड किया जाता है, जिसे smss रजिस्ट्री प्रविष्टि के कारण चलाता है।इन लॉग्स में पूर्ण NT पथ होते हैं, और इस प्रकार दूसरे वॉल्यूम पर फ़ाइलों को प्रभावित कर सकते हैं। इसका उपयोग एक हटाने योग्य ड्राइव (NTFS स्वरूपित) संलग्न के साथ WinRE बूट करते समय रैमडिस्क पर winpeshl.ini को हटाने के लिए किया जा सकता है। इस फ़ाइल के हटाए जाने पर, यदि Ctrl कुंजी दबाई जाती है तो winpeshl.exe मेमोरी में व्युत्पन्न osdevice बिटलॉकर कुंजियों के साथ एक SYSTEM शेल लॉन्च करेगा।यह भी देखें विल डोरमैन द्वारा अतिरिक्त राइटअप। यह बग CVE-2026-45585 है। | जून 2026 | मई 2026 | Nightmare-Eclipse |
| ram leak: बूट वातावरण में रैमडिस्क निर्माण डिवाइस पर कोई प्रतिबंध नहीं है | जब रैमडिस्क बनाने के लिए कॉन्फ़िगर किया जाता है, तो लोड करने के लिए फ़ाइल और उसे लोड करने के लिए डिवाइस BCD में प्रदान किया जाता है। बूट वातावरण पारित डिवाइस पर कोई जाँच नहीं करता है, और इस प्रकार, BitLocker-एन्क्रिप्टेड विभाजन की अनुमति दी जाती है, बशर्ते कि कुंजियाँ व्युत्पन्न की जा सकें। इसलिए, एक हमलावर BitLocker-एन्क्रिप्टेड विभाजन से एक मनमानी फ़ाइल के साथ एक रैमडिस्क स्थापित कर सकता है, और फ़ाइल सामग्री RAM में रहेगी भले ही व्युत्पन्न BitLocker कुंजियाँ मिटा दी जाएँ, और बाद में डंप की जा सकती हैं। इसके अतिरिक्त, एक हमलावर इसका उपयोग यह निर्धारित करने के लिए कर सकता है कि कोई फ़ाइल BitLocker-एन्क्रिप्टेड OS विभाजन पर मौजूद है या नहीं। दिलचस्प लक्ष्यों में शामिल हैं: हाइबरनेशन फ़ाइल (व्युत्पन्न बिटलॉकर कुंजियाँ शामिल हैं, और संपीड़ित है, इसलिए इसे पूरी तरह से RAM में फिट होना चाहिए, विशेष रूप से यदि लॉगऑन स्क्रीन से "शट डाउन" अर्थात लॉगऑफ-फिर-हाइबरनेट किया जाता है), पेजफ़ाइल, SYSTEM और SAM हाइव्स, कमजोरियों की जाँच के लिए कोई भी तृतीय-पक्ष सेवा या ड्राइवर (SYSTEM हाइव से पहचाना गया)। | कोई नहीं। MSRC ने गलतफहमी के कारण इसे कम प्राथमिकता के रूप में बंद कर दिया। | मई 2026, मूल रूप से मार्च 2025 में खोजा गया। | Rairii |
| bitskrieg: WinRE बूट आपातकालीन प्रबंधन सेवाओं को प्रतिबंधित नहीं करता है | आपातकालीन प्रबंधन सेवाएँ विशेष प्रशासन कंसोल का उपयोग करके सीरियल पोर्ट से एक चालू Windows सिस्टम को नियंत्रित करने की अनुमति देती हैं, जिसमें SYSTEM शेल चलाने की क्षमता शामिल है। यह WinRE में अनुमत है, और इस प्रकार मेमोरी में व्युत्पन्न osdevice बिटलॉकर कुंजियों के साथ एक SYSTEM शेल खोलने के लिए उपयोग किया जा सकता है। | कोई नहीं, 0day के रूप में छोड़ दिया गया। | जून 2026 | Jonas Lyk |