baton drop (CVE-2022-21894): सिक्योर बूट सुरक्षा सुविधा बाईपास भेद्यता

Windows बूट अनुप्रयोग truncatememory सेटिंग को मेमोरी मैप से सीरियलाइज़्ड डेटा के "persistent" रेंज वाले मेमोरी ब्लॉक को हटाने की अनुमति देते हैं, जिससे सिक्योर बूट बाईपास होता है।

• truncatememory BCD तत्व मेमोरी मैप से एक निर्दिष्ट भौतिक पते के ऊपर की सभी मेमोरी को हटा देगा।
• यह प्रत्येक बूट अनुप्रयोग के लिए आरंभीकरण के दौरान किया जाता है, इससे पहले कि सीरियलाइज़्ड सिक्योर बूट नीति मेमोरी से पढ़ी जाए।
• इसलिए, ऐसे तत्व का उपयोग सीरियलाइज़्ड सिक्योर बूट नीति को मेमोरी मैप से हटाने के लिए किया जा सकता है।
• यह बूट अनुप्रयोग में खतरनाक सेटिंग्स (bootdebug, testsigning, nointegritychecks) के उपयोग की अनुमति देगा, जिससे सिक्योर बूट टूट जाएगा।

इस समस्या को दो अलग-अलग परिवर्तनों द्वारा ठीक किया गया था:

1. सीरियलाइज़्ड सिक्योर बूट नीति को लोड करने का प्रयास करने के बाद, यदि कोई नीति लोड नहीं हुई, और सिक्योर बूट सक्षम है, और बूट अनुप्रयोग सीधे UEFI फर्मवेयर द्वारा लोड नहीं किया गया था, और बूट अनुप्रयोग bootmgr नहीं है, तो बूट अनुप्रयोग आरंभीकरण विफल हो जाता है।
2. बूट अनुप्रयोग लोड करते समय, यदि इसमें VERSIONINFO संसाधन है जिसमें OriginalFilename है, और यदि वह फ़ाइलनाम एक ब्लॉकलिस्ट में शामिल है (जिसमें bootmgr.exe और hvloader.exe शामिल हैं; Nickel में, hvloader.efi जोड़ा गया था लेकिन यह बैकपोर्ट नहीं किया गया), तो लोड विफल हो जाता है।
   • Windows 8 और Windows 8.1 में, hvloader.exe winload की ब्लॉकलिस्ट में शामिल नहीं है - मूल रूप से यह शामिल था, जिसने Hyper-V लोडिंग को तोड़ दिया!
   • Windows 10 संस्करण 1809 से, यदि एक निश्चित फ़्लैग्स बिट सेट है (डिस्क से bootmgr लोड करने के लिए flightedbootmgr तत्व के साथ उपयोग किया जाता है), तो OriginalFilename का bootmgr.exe होना आवश्यक है।

शोषण

हमलावर को यह सुनिश्चित करना होगा कि सीरियलाइज़्ड सिक्योर बूट नीति एक ज्ञात भौतिक पते के ऊपर आवंटित हो।

• डिफ़ॉल्ट रूप से, यह सबसे कम संभव पते पर आवंटित किया जाता है।
• मूल रूप से, सीरियलाइज़्ड सिक्योर बूट नीति लोड होने के बाद, BCD से लोड किए गए किसी भी कॉन्फ़िगरेशन का उपयोग करने से पहले आवंटित होती है।
  • RS1 से, सीरियलाइज़्ड सिक्योर बूट नीति बूट अनुप्रयोग लोड करते समय आवंटित होती है।
  • RS2 से, किसी भी मौजूदा सीरियलाइज़्ड सिक्योर बूट नीति को सीरियलाइज़िंग सिक्योर बूट नीति के दौरान मुक्त कर दिया जाता है।
• सीरियलाइज़्ड सिक्योर बूट नीति पुनः आवंटित हो जाती है यदि, बूट अनुप्रयोग लोड करते समय, BCD प्रविष्टि का osdevice एक BitLocker-एन्क्रिप्टेड विभाजन है जहाँ VMK TPM का उपयोग करके प्राप्त किया गया था।
  • इसे सफल TPM अनसीलिंग के बाद कुंजी फ़्लैग्स के बिट 0 को सेट करके नकली किया जा सकता है; इस बिट को BitLocker मेटाडेटा में मैन्युअल रूप से सेट किया जा सकता है, जिसमें अखंडता सत्यापन के लिए सिक्योर बूट के उपयोग को निर्दिष्ट करने के लिए अतिरिक्त मेटाडेटा जोड़ा जाता है।

avoidlowmemory तत्व का उपयोग यह सुनिश्चित करने के लिए किया जा सकता है कि भौतिक मेमोरी के सभी आवंटन एक निर्दिष्ट भौतिक पते से ऊपर हों:

• Windows 10 से, यह तत्व VBS सक्षम होने पर अनुमत नहीं है, लेकिन चूँकि इसका उपयोग बूट अनुप्रयोग आरंभीकरण के दौरान किया जाता है, इससे पहले कि सीरियलाइज़्ड सिक्योर बूट नीति मेमोरी से पढ़ी जाए, bootmgr लोड करना और एक कस्टम BCD पथ निर्दिष्ट करना (bcdfilepath तत्व उर्फ custom:22000023 का उपयोग करके) इससे बचने के लिए किया जा सकता है।
• यदि OS वॉल्यूम पर BitLocker मौजूद है, या लक्ष्य सिस्टम TH1 या TH2 चला रहा है, तो यह विधि विफल हो जाएगी; इसलिए VBS को अक्षम करने के लिए Windows 8.x bootmgr के साथ एक बार हमला चलाना और फिर मूल बूटलोडर पर वापस स्विच करना भी संभव है।
  • Windows 10 ने बूट अनुप्रयोग आरंभीकरण को सभी TPM PCR को एक बार कैप करने के लिए बदल दिया, इसलिए Windows 8.x bootmgr Windows 10+ सिस्टम पर VMK को अनसील करने में विफल हो जाएगा।

hvloader.efi को nointegritychecks तत्व के साथ लोड किया जा सकता है ताकि एक स्व-हस्ताक्षरित mcupdate.dll लोड किया जा सके, जिसका प्रवेश बिंदु ExitBootServices से पहले कॉल किया जाएगा।

वैकल्पिक रूप से, गैर-AMD64 सिस्टम पर, TH2 से पहले के winload.efi का उपयोग testsigning तत्व के साथ किया जा सकता है; यह प्रमाणपत्र में szOID_NT5_CRYPTO EKU वाले स्व-हस्ताक्षरित बाइनरी की अनुमति देता है।

ARMv7 सिस्टम पर, कोड निष्पादन प्राप्त करने के लिए mcupdate.dll के आयात के साथ एक पैच किए गए स्व-हस्ताक्षरित hal.dll को लोड करना आवश्यक होगा।

x86 और AMD64 सिस्टम पर, mcupdate.dll के रूप में लोड की गई फ़ाइल का नाम mcupdate_*.dll होना चाहिए, जहाँ * CPUID निर्माता स्ट्रिंग है (GenuineIntel, AuthenticAMD आदि)।

ARM64 सिस्टम पर, इस तकनीक का उपयोग नहीं किया जा सकता क्योंकि उपलब्ध सबसे पुराना प्रोडक्शन हस्ताक्षरित बिल्ड RS2 का WinPE है; इस प्रकार वर्तमान में केवल टेदर्ड कोड निष्पादन किया जा सकता है (bootdebug का उपयोग करके)।

शामिल फ़ाइलें

इस रिपॉजिटरी में निम्नलिखित फ़ाइलें शामिल हैं:

• एक सरल पेलोड का स्रोत कोड प्रदान किया गया है। यह पेलोड अनंत रूप से एक इंटरप्ट की प्रतीक्षा करता है, क्योंकि कॉल करने वाले बूट अनुप्रयोग में दिलचस्प फ़ंक्शन और वेरिएबल खोजने के बिना, कुछ और करना असंभव है।
  • क्योंकि mcupdate.dll पेजिंग सक्षम के साथ एक वर्चुअल पते पर चलता है, EFI फ़ंक्शन को सीधे कॉल करना असंभव है (EFI फ़ंक्शन को कॉल करने के लिए पेजिंग को अक्षम करने की आवश्यकता है, पेजिंग बंद होने पर वर्चुअल पते पर लौटना अच्छा नहीं होता)।
  • EFI फ़ंक्शन को कॉल करने के लिए, एक पेलोड को फ़्लैग्स में बिट 0 सेट करके BlImgLoadPEImageEx या BlImgLoadPEImageFromSourceBuffer को कॉल करना होगा ताकि एक 1:1 भौतिक पता-वर्चुअल पता मैपिंग पर एक अतिरिक्त पेलोड लोड किया जा सके।
    • वैकल्पिक रूप से, यह उसी बिट सेट के साथ BlImgAllocateImageBuffer को कॉल कर सकता है ताकि 1:1 भौतिक पता-वर्चुअल पता मैपिंग पर मेमोरी आवंटित हो; फिर स्वयं एक पेलोड लोड कर सकता है (या वहाँ स्वयं को रीमैप कर सकता है)।
• एक ISO जो Windows 8 RTM के bootmgfw और TH1 RTM के hvloader का उपयोग करके AMD64 पर इस समस्या का शोषण करता है।
  • यहाँ उपयोग किया गया पेलोड ऑफ़सेट द्वारा प्राप्त hvloader के एक फ़ंक्शन का उपयोग करके स्क्रीन पर एक संदेश प्रिंट करता है और फिर अनंत लूप करता है।
• एक ISO जो RS1 के bootmgr और TH1 RTM के hvloader का उपयोग करके AMD64 पर इस समस्या का शोषण करता है।

उपसंहार

इस समस्या का उपयोग BitLocker कुंजियों को डंप करने के लिए किया जा सकता है (जहाँ अखंडता सत्यापन के लिए सिक्योर बूट का उपयोग किया जाता है)।

• हालाँकि यह संभव है, मेमोरी में एक मनमाने वॉल्यूम के लिए व्युत्पन्न BitLocker कुंजियों के साथ कोड निष्पादन प्राप्त करने की सटीक विधि का खुलासा नहीं किया जाएगा।

इस समस्या के लिए फिक्स ने एक और समस्या को भी ठीक किया जिसका कोई CVE नहीं है।

• bootmgr मेमोरी में पहले से मौजूद किसी भी BitLocker कीटेबल को अनदेखा करता है और एक नया आवंटित करता है, पुराने को मिटाए बिना।
  • इसलिए, एक हमलावर bootmgr से RS2+ bootmgr लोड कर सकता है (एक मनमाना osdevice निर्दिष्ट करके जहाँ अखंडता सत्यापन के लिए सिक्योर बूट का उपयोग किया जाता है), WinPE में बूट कर सकता है, एक ज्ञात असुरक्षित ड्राइवर लोड कर सकता है, और इसका उपयोग भौतिक मेमोरी में मौजूदा BitLocker कीटेबल को खोजने और डंप करने के लिए कर सकता है।

अभी तक किसी भी ज्ञात असुरक्षित बूट अनुप्रयोग को रद्द नहीं किया गया है।

• जब तक रद्दीकरण नहीं होता, एक हमलावर अपना स्वयं का असुरक्षित बूटलोडर ला सकता है।
• रद्दीकरण के कारण सभी मौजूदा Windows इंस्टॉलेशन/रिकवरी मीडिया और पुराने बैकअप बूट करने में विफल हो जाएंगे।
  • बूट विफलता सिक्योर बूट अक्षम होने पर भी होगी क्योंकि bootmgr अपने स्वयं के हस्ताक्षर की जाँच करता है।

अद्यतन (2023-05-10)

एक अपूर्ण रद्दीकरण हुआ, और एक और CVE (CVE-2023-24932) आया। अभी भी असुरक्षित bootmgfw हैं जिन्हें रद्द नहीं किया गया, साथ ही अतिरिक्त पैच केवल उस मामले को ठीक करते हैं जहाँ bootmgr bootmgr लोड करता है। MS को कार्रवाई करने के लिए केवल एक पेस्ट किए गए बूटकिट की आवश्यकता थी ;)
यदि आप पर्याप्त रचनात्मक हैं तो आपको 2000 से अधिक bootmgfw फ़ाइलों के रद्दीकरण को बायपास करने का एक तरीका मिल जाएगा ;)