YellowKey: BitLocker एन्क्रिप्शन को बायपास करने वाला नया Windows Zero‑Day

महत्वपूर्ण बात यह है कि यह remote exploit नहीं है। इसे इस्तेमाल करने के लिए हमलावर को डिवाइस तक भौतिक पहुंच (physical access) चाहिए—जैसे मशीन को रीबूट करना और उसके boot या recovery environment से इंटरैक्ट करना।

फिर भी यह खतरनाक इसलिए माना जा रहा है क्योंकि कई सुरक्षा मॉडल यह मानकर चलते हैं कि BitLocker एन्क्रिप्शन चोरी या कब्ज़े में आए डिवाइस के डेटा को सुरक्षित रखेगा।

YellowKey हमला कैसे काम करता है

प्रकाशित proof‑of‑concept (PoC) में दिखाया गया है कि यह हमला Windows Recovery Environment (WinRE) के व्यवहार का फायदा उठाता है। WinRE वह बिल्ट‑इन वातावरण है जिसका उपयोग Windows सिस्टम की मरम्मत या ट्रबलशूटिंग के लिए किया जाता है।

सरल शब्दों में हमला इस तरह चलता है:

• हमलावर USB ड्राइव या EFI पार्टिशन पर विशेष रूप से तैयार FsTx (Transactional NTFS) फाइलें रखता है।
• लक्ष्य सिस्टम को Windows Recovery Environment (WinRE) में रीबूट किया जाता है।
• जब WinRE recovery प्रक्रिया के दौरान इन FsTx फाइलों को प्रोसेस करता है, तो exploit सक्रिय हो सकता है और एक command shell खुल सकती है।
• इस shell के माध्यम से हमलावर को सिस्टम की स्टोरेज ड्राइव तक पहुंच मिल सकती है—भले ही वह BitLocker से एन्क्रिप्टेड क्यों न हो।

रिपोर्टों के अनुसार, recovery प्रक्रिया के दौरान फाइल सिस्टम की स्थिति को संभालने के तरीके की वजह से BitLocker‑सुरक्षित वॉल्यूम उस समय एक्सेसिबल हो सकता है।

Physical‑Access हमले अभी भी क्यों महत्वपूर्ण हैं

कई लोग सोचते हैं कि अगर हमला remote नहीं है तो जोखिम कम है। लेकिन वास्तविक दुनिया में ऐसे परिदृश्य आम हैं जहाँ किसी को डिवाइस तक अस्थायी या स्थायी भौतिक पहुंच मिल जाती है। उदाहरण:

• चोरी हुए या खोए हुए लैपटॉप
• यात्रा या जांच के दौरान जब्त किए गए डिवाइस
• unattended ऑफिस वर्कस्टेशन
• शाखा कार्यालय या कियोस्क सिस्टम

विशेष रूप से वे सिस्टम अधिक जोखिम में हो सकते हैं जहाँ BitLocker केवल TPM‑based automatic unlock के साथ कॉन्फ़िगर है। ऐसे मामलों में सिस्टम बूट होते समय डिस्क स्वतः अनलॉक हो सकती है।

Microsoft द्वारा सुझाए गए अस्थायी Mitigations

जब यह कमजोरी सार्वजनिक हुई तब तक Microsoft ने इसका पूर्ण सुरक्षा पैच जारी नहीं किया था। इसलिए कंपनी ने कुछ workaround‑based mitigation steps सुझाए हैं।

1. WinRE में autofstx.exe BootExecute एंट्री हटाना

Microsoft ने सुझाव दिया है कि एडमिन WinRE इमेज के BootExecute registry value से autofstx.exe एंट्री हटा दें। इससे Transactional NTFS replay मैकेनिज़्म निष्क्रिय हो जाता है, जिसका इस्तेमाल exploit करता है।

2. BitLocker में TPM + PIN सक्षम करना

केवल TPM‑based unlock के बजाय TPM + PIN authentication उपयोग करना अधिक सुरक्षित है। इससे सिस्टम स्टार्ट होते समय उपयोगकर्ता को PIN दर्ज करना पड़ता है, जिससे भौतिक हमलावर के लिए ड्राइव तक पहुंच कठिन हो जाती है।

3. Boot और recovery सुरक्षा मजबूत करना

संगठनों को अतिरिक्त सुरक्षा उपाय भी लागू करने की सलाह दी गई है:

• USB या external boot को सीमित या बंद करना
• UEFI/BIOS settings को मजबूत एडमिन पासवर्ड से सुरक्षित करना
• Secure Boot सक्षम रखना
• WinRE या boot configuration में बदलाव की निगरानी करना

ये उपाय हमलावर के लिए उस recovery environment तक पहुंचना कठिन बनाते हैं जिसका इस्तेमाल exploit करता है।

YellowKey का खुलासा किसने किया

इस vulnerability का सार्वजनिक खुलासा एक सुरक्षा शोधकर्ता ने किया, जो ऑनलाइन Chaotic Eclipse और Nightmare‑Eclipse नामों से जाने जाते हैं। उन्होंने इस तकनीक का proof‑of‑concept कोड भी जारी किया।

रिपोर्टों के अनुसार यह शोधकर्ता Microsoft से जुड़े अन्य zero‑day मुद्दों—जैसे GreenPlasma—का भी खुलासा कर चुके हैं, जिससे Windows सुरक्षा से जुड़ी व्यापक चर्चा शुरू हुई।

सुरक्षा विशेषज्ञ अक्सर चेतावनी देते हैं कि जब PoC कोड सार्वजनिक हो जाता है तो exploit बनाना आसान हो जाता है, खासकर तब जब आधिकारिक पैच अभी उपलब्ध न हो।

संगठनों को क्या मॉनिटर करना चाहिए

जब तक स्थायी पैच जारी नहीं होता, सुरक्षा टीमों को कुछ संकेतों पर विशेष ध्यान देना चाहिए:

• अचानक Windows Recovery Environment में बूट होना
• WinRE images या BootExecute registry में बदलाव
• boot order, EFI partitions या Secure Boot settings में परिवर्तन
• अनधिकृत USB boot प्रयास
• BitLocker protector या TPM configuration में अप्रत्याशित बदलाव

इन संकेतों की निगरानी से recovery या boot प्रक्रिया के साथ छेड़छाड़ का पता लगाया जा सकता है।

Disk Encryption सुरक्षा के लिए बड़ा सबक

YellowKey एक महत्वपूर्ण सुरक्षा सिद्धांत को उजागर करता है: सिर्फ full‑disk encryption पर्याप्त नहीं है यदि हमलावर boot या recovery chain को नियंत्रित कर सके।

Boot loader, recovery environment और firmware settings—all उसी भरोसे की सीमा का हिस्सा हैं जिस पर encryption आधारित है। इनमें से किसी भी हिस्से की कमजोरी पूरी सुरक्षा को प्रभावित कर सकती है।

इसलिए BitLocker पर निर्भर संगठनों के लिए encryption के साथ‑साथ pre‑boot authentication, firmware security और कड़े boot नियंत्रण लागू करना बेहद जरूरी है—कम से कम तब तक जब तक Microsoft CVE‑2026‑45585 के लिए पूर्ण समाधान जारी नहीं कर देता।