सुरक्षा शोधकर्ता ने कहा कि Microsoft ने BitLocker में बैकडोर बनाया, exploit जारी किया

• सुरक्षा शोधकर्ता Nightmare-Eclipse ने YellowKey जारी करते हुए दावा किया कि BitLocker की full-volume encryption को बिना password पूरी तरह bypass किया जा सकता है
• YellowKey को Windows-compatible file system वाले USB drive पर FsTx फ़ोल्डर कॉपी करने के बाद WinRE में एक विशेष क्रम पूरा करके दोहराया जा सकता है
• प्रक्रिया पूरी होने पर command shell खुलती है और BitLocker-सुरक्षित volume को browse, copy और file operations करना संभव बताया गया है
• Nightmare-Eclipse का कहना है कि यह bypass व्यवहार केवल official WinRE image में दिखाई देता है, जिससे जानबूझकर बनाए गए backdoor की आशंका उठती है
• प्रभाव का दायरा Windows 11, Server 2022, Server 2025 बताया गया है, जबकि Windows 10 प्रभावित नहीं है

---

YellowKey के काम करने की शर्तें

• सुरक्षा शोधकर्ता Nightmare-Eclipse ने YellowKey जारी करते हुए कहा कि BitLocker की full-volume encryption को पूरी तरह bypass किया जा सकता है
• YellowKey को साथ दिए गए FsTx फ़ोल्डर को NTFS, FAT32, exFAT जैसे Windows-compatible file system से formatted USB drive पर कॉपी करके दोहराया जा सकता है
• यह भी बताया गया है कि USB drive के बिना, FsTx फ़ाइलों को Windows EFI partition में कॉपी करके और encrypted disk को सिस्टम से अस्थायी रूप से अलग करके भी यह काम कर सकता है
• इसके बाद BitLocker से सुरक्षित सिस्टम को reboot करके Windows Recovery Environment(WinRE) में जाना होता है और फिर एक विशेष input sequence का पालन करना होता है
• प्रक्रिया सही तरह पूरी होने पर command shell दिखाई देती है, और बिना password BitLocker-सुरक्षित volume को browse, copy या अन्य file operations किए जा सकते हैं

बैकडोर संदेह के आधार

• Nightmare-Eclipse का कहना है कि YellowKey किसी पहले से अज्ञात security bug जैसा सामान्य मामला नहीं लगता, और यह संभावना उठती है कि Microsoft ने BitLocker data protection system में एक वैध backdoor डाला हो
• इसका आधार यह है कि समस्या पैदा करने वाला component केवल official WinRE image में पाया जाता है
• वही component standard Windows installation image में भी मौजूद है, लेकिन वास्तविक सिस्टम में देखा गया BitLocker bypass व्यवहार वहां नहीं दिखाई देता
• Nightmare-Eclipse ने कहा, “इसके जानबूझकर किया गया होने के अलावा मैं कोई और explanation नहीं सोच सकता,” और जोड़ा कि Windows 10 प्रभावित नहीं है, जबकि केवल Windows 11, Server 2022, Server 2025 प्रभावित हैं

बाहरी पुष्टि और अतिरिक्त खुलासा

• बताया गया है कि third-party शोधकर्ताओं ने Nightmare-Eclipse के GitHub material में दिए गए तरीके के अनुसार YellowKey के काम करने की पुष्टि की है
• Nightmare-Eclipse ने privilege escalation संभव होने का दावा किए गए दूसरे exploit GreenPlasma को भी जारी किया
• GreenPlasma के लिए SYSTEM-level access हासिल करने वाला पूरा proof-of-concept code सार्वजनिक नहीं किया गया है, लेकिन संकेत दिया गया है कि अगले महीने के Patch Tuesday से पहले अतिरिक्त details जारी की जा सकती हैं

Mitigation की दिशा

• YellowKey के कथित backdoor-जैसे व्यवहार के लिए mitigation अपेक्षाकृत सरल बताया गया है
• सुरक्षा विशेषज्ञ सलाह देते हैं कि केवल एक encryption system पर निर्भर न रहें, बल्कि अच्छी तरह परखे गए full-disk encryption alternatives का भी मूल्यांकन करें
• उदाहरण के तौर पर VeraCrypt का उल्लेख किया गया है

[GN⁺]

Hacker News टिप्पणियाँ

• इस vulnerability को खोजने वाले researcher Nightmare-Eclipse की पोस्ट देखें तो लगता है कि यह लगभग एक हफ्ते से चल रहा था
  मंगलवार, 12 मई 2026 को उसने लिखा, “इस बार दो vulnerabilities हैं [YellowKey] [GreenPlasma] [...] अगले Patch Tuesday पर Microsoft के लिए बड़ा surprise होगा”, और बुधवार, 13 मई को लिखा, “जब मैं पूरी कहानी बता पाऊँगा तो लोगों को लगेगा कि मेरा भड़कना काफी हद तक जायज़ था, और Microsoft के लिए भी यह बिल्कुल अच्छा नहीं दिखेगा”
  लेखक का ब्लॉग: https://deadeclipse666.blogspot.com/
  मार्च 2026 की पहली पोस्ट में कुछ ऐसा भी है: “किसी ने हमारा agreement तोड़ा, और मैं कंगाल होकर घर भी खो बैठा। उन्हें पता था कि ऐसा होगा, फिर भी उन्होंने मेरी पीठ में छुरा घोंपा। यह मेरा फैसला नहीं, उनका फैसला है”
  इसे कैसे देखा जाए, समझ नहीं आता, लेकिन यह कुछ हद तक ऐसे लगता है जैसे कोई insider असल में “leak” कर रहा हो, और दूसरे लोग भी नतीजों को reproduce कर पा रहे हों

  • insider से ज़्यादा यह ऐसा लगता है कि Microsoft के साथ vulnerability disclosure process चल रहा था और किसी वजह से गुस्से में आकर उसने इसे public कर दिया
  • इस पर HN में पहले भी कई बार चर्चा हो चुकी है, उदाहरण के लिए यहाँ: https://news.ycombinator.com/item?id=48130519
    यह backdoor है या नहीं, आखिरकार इस बात पर निर्भर करता है कि आप सामान्य तौर पर “bug या backdoor” को कैसे देखते हैं, और यह वैसी आसान कहानी नहीं है जैसी tech media को पसंद आती है, जैसे “Microsoft 1, BitLocker hacked”
    असल बात Windows Recovery Environment WinRE की NTFS transaction log replay feature में एक bug है, जिससे external volume के NTFS transaction logs पढ़कर उन्हें mounted filesystem पर apply किया जा सकता है। इससे attacker WinRE authentication को bypass कर सकता है
    जिन BitLocker setups में PIN या password नहीं है, वहाँ कोई भी authentication bypass असल में disk encryption bypass बन जाता है। क्योंकि bootloader पहले ही disk को unseal कर चुका होता है, और ऐसी structural “खामी” उसी configuration वाले Linux में भी है। उदाहरण के लिए, Ubuntu installer में अपेक्षाकृत हाल में जोड़ा गया Hardware Disk Encryption checkbox इस्तेमाल करने पर भी यही बात लागू होती है
    अगर अतिरिक्त सबूत न हों, तो NTFS transaction log की यह समस्या जानबूझकर डाला गया backdoor है या सिर्फ एक enumeration bug, यह exploit development में आम conspiracy theory के स्तर पर ही निर्भर करता है। मुझे व्यक्तिगत रूप से यह एक plausible bug लगता है, और boot-time unsealing की कमजोरी जानी-पहचानी और साफ़ है, इसलिए मैं इसे दुनिया हिला देने वाला खुलासा नहीं मानता, लेकिन bug दिलचस्प है
  • मैं जल्दी से blog post पढ़ना चाहता हूँ कि असल में क्या हुआ और यह व्यक्ति M$ को बेनकाब करने तक क्यों पहुँचा

• बेहतर summary: https://infosec.exchange/@wdormann/116565129854382214
  public exploit PIN इस्तेमाल करने वाले BitLocker को प्रभावित नहीं करता। PIN न हो तो BitLocker वैसे भी सुरक्षित नहीं है
  मूल लेखक दावा करता है कि उसके पास ऐसा exploit भी है जो PIN होने पर भी काम करता है, लेकिन उसने अभी तक उसका कोई सबूत नहीं दिया है

  • क्या आपकी company PIN अनिवार्य करती है? और उससे भी ज़्यादा अहम, क्या आपकी company जिस cyber insurance के लिए पैसे देती है, वह PIN मांगती है?
    मैंने किसी भी company को BitLocker पर PIN अनिवार्य करते नहीं देखा
  • BitLocker में PIN से एक स्तर ऊपर भी विकल्प है: boot के समय इस्तेमाल होने वाली key रखने के लिए USB stick। क्योंकि data device पर stored नहीं होता, इसलिए यह attack उससे सुरक्षित होना चाहिए
  • अगर PIN version वाला दावा सही मानें, तो यह दिलचस्प है कि उसने PIN version के बजाय कमजोर और लगभग बेकार version को क्यों release किया। कुछ अंदाज़े हैं, लेकिन किसी के पास ठोस आधार नहीं

• स्रोत: https://infosec.exchange/@wdormann/116565129854382214
  “एक सामान्य WinRE session में X:\Windows\System32 directory होती है और उसके भीतर winpeshl.ini file होती है”
  “लेकिन YellowKey exploit में ऐसा लगता है कि USB drive के Transactional NTFS fragments दूसरी drive की winpeshl.ini file delete कर सकते हैं”
  दिलचस्प। मैं इस environment से ज़्यादा परिचित नहीं हूँ, लेकिन क्या यह किसी naive file handle creation या passing की समस्या हो सकती है? अगर ऐसा है, तो WinRE reboot के दौरान key input की ज़रूरत क्यों पड़ती है?
  यह भी जानना दिलचस्प होगा कि patch कितना संभव है। असंख्य WinRE USB drives को छेड़ा नहीं जा सकेगा, तो क्या BitLocker side पर access permissions update की जा सकती हैं? क्या decrypt/re-encrypt करना पड़ेगा? लगता है कि आगे और बहुत कुछ सामने आएगा

  • छूटा हुआ हिस्सा यह है कि WinRE के पास access क्यों है। Windows TPM में decryption key store करता है, ताकि WinRE recovery key के बिना भी disk को decrypt कर सके
    इसलिए यह attack Ubuntu live CD जैसी किसी चीज़ से boot करने का नहीं, बल्कि WinRE की ज़रूरत वाला attack है
    और मौजूदा WinRE USB drives को पूरी तरह patch करने की भी ज़रूरत नहीं होगी। Secure Boot signatures revoke कर दिए जाएँ तो वे TPM verification pass नहीं कर पाएँगे, और इसलिए कोई भी disk decrypt नहीं कर सकेंगे

• “Security experts आम तौर पर सलाह देते हैं कि केवल एक encryption system पर निर्भर न रहें और VeraCrypt जैसे अच्छी तरह review किए गए full disk encryption alternatives का मूल्यांकन करें”
  अगर उन्होंने FDE में backdoor डाला है, तो लोगों से Windows छोड़कर Linux इस्तेमाल करने को कहना ज़्यादा तर्कसंगत होगा
  अगर FDE में backdoor डाला गया है, तो मानना चाहिए कि operating system में भी सिर्फ एक backdoor नहीं होगा। Proprietary software पर बिल्कुल भरोसा नहीं करना चाहिए, और ठीक से audited न किए गए open source पर भी नहीं

  • मैं आम तौर पर Microsoft products इस्तेमाल नहीं करता, लेकिन आपके computer पर भी VeraCrypt नहीं चलाऊँगा
  • या फिर VeraCrypt जैसा open source इस्तेमाल कर सकते हैं

• यह BitLocker-विशेष समस्या से ज़्यादा login bypass जैसी लगती है। PIN के बिना TPM पर निर्भर होने पर decryption अपने आप हो जाता है
  सामान्यतः attacker को login screen पार नहीं कर पाना चाहिए, इसलिए सब ठीक होना चाहिए, लेकिन यह exploit recovery environment में unrestricted shell पाने का तरीका दिखाता है
  researcher दावा करता है कि PIN को bypass करने का तरीका भी है, लेकिन उसने अभी तक उसे public नहीं किया

  • हो सकता है disclosure process में reward न मिलने पर उसने सोचा हो कि किसी पैसे देने वाले को बेच देना बेहतर होगा

• security experts कब “Microsoft product security” वाली भूमिका लेना बंद करेंगे? मैं तो पहले ही उस बिंदु पर पहुँच चुका हूँ
  Microsoft product security बस एक व्यस्त रखने वाला काम है, जब तक MS का पागलपन भरा tech debt और लालच की अगली लहर उसे फिर से न तोड़ दे। अब तो backdoor भी है

  • वह “security” role नहीं, compliance role है। ज़्यादातर enterprise customers असल में सिर्फ उसी की परवाह करते हैं
    आपने compliance के सारे नियम पूरे कर दिए, और MS-प्रभावित “best practices” का पालन किया, तो फिर कुछ भी हो जाए, ज़िम्मेदारी आपकी नहीं मानी जाएगी
  • iOS भी डिफ़ॉल्ट रूप से end-to-end encrypted नहीं होने वाले iCloud backups बनाता है, इसलिए law enforcement chats, browser history वगैरह माँग सकती है। Signal इससे एक उल्लेखनीय अपवाद है
    end-to-end encrypted backup के लिए ADP on किया जा सकता है, लेकिन संभव है कि जिन लोगों से आप बात करते हैं उन्होंने इसे on न किया हो, इसलिए मदद सीमित रह सकती है
    Microsoft का बचाव नहीं कर रहा, बस कह रहा हूँ कि ऐसी सभी कंपनियाँ PRISM का हिस्सा रही हैं
  • enterprise market में इससे बहुत पैसा बनता है, इसलिए सिर्फ झंझट समझकर लोग यह काम ठुकराना शुरू करेंगे, ऐसा नहीं लगता
  • “अब तो backdoor भी है”? “अब”?
    क्या हम उस पुराने Windows NT version की बात करें जो गलती से debug symbols enabled के साथ release हो गया था, और तब Microsoft जिस “secondary key” की बात करता था उसका नाम आखिर ..._NSAKEY क्यों था
    सिर्फ एक बार, बस सचमुच एक बार, Windows debug symbols enabled के साथ release हुआ, और संयोग से encryption key का नाम “NSAKEY” निकला
    बेशक, जो लोग राज्य की गलतियों पर लगातार आँख मूँद लेते हैं, वे कहेंगे कि यह पूरी तरह सामान्य था, और उस समय Microsoft ने जो मेहनत से तैयार किया हुआ “यह backdoor नहीं है” वाला बचाव दिया था, उसे ही दोहराएँगे

• exploit को थोड़ा और देखने पर पता चलता है कि यह TPM-only mode के BitLocker को निशाना बनाता है। यानी इसमें pre-boot authentication जैसी कोई चीज़ नहीं है
  अगर Secure Boot boot chain verify कर दे, तो TPM खुद encryption key दे देता है। Physical access हो तो फ़र्क बहुत बड़ा नहीं रह जाता
  exploit वाले USB से boot करके emergency shell लेना हो, या 5 डॉलर का microcontroller खरीदकर motherboard के खास pins पर solder करके TPM key sniff करनी हो, दोनों संभव हैं
  Microsoft कुल मिलाकर कुछ असुरक्षित चीज़ बेच रहा है और उसे full disk encryption कह रहा है। जो व्यक्ति flash drive में exploit डालकर shell पा सकता है और files देख-समझकर copy कर सकता है, वह microcontroller खरीदकर YouTube पर soldering videos देखकर वैसा करना भी सीख सकता है
  इसलिए समस्या “exploit” खुद नहीं, बल्कि Microsoft द्वारा बेचा जा रहा झूठा सुरक्षा-बोध है

  • “bootable stick से emergency shell में जाना” वाला तरीका काम नहीं करता। TPM केवल “approved” operating system पर boot होने पर ही key देता है, खास तौर पर तब जब encryption key से bind की गई PCR state मेल खाए
    5 डॉलर वाले microcontroller से खास pins पर solder करके TPM key sniff करना सिर्फ dTPM पर संभव है। fTPM इस attack के लिए vulnerable नहीं है, और dTPM की तुलना में काफ़ी अधिक व्यापक रूप से इस्तेमाल होता है
  • Ubuntu ने भी कुछ versions पहले TPM-based FDE दिया था। तब भी मुझे यही लगा था, इसलिए मैंने उसे इस्तेमाल न करने का फैसला किया
    boot पर passphrase टाइप करना अब तो muscle memory जैसा है, और यह भरोसेमंद, सरल security देता है
    motherboard के बिना भी data recover किया जा सकता है
    रोज़मर्रा के इस्तेमाल के लिए, evil maid attacks को रोकने हेतु Secure Boot+TPM+passphrase को मिलाकर एक slot और backup passphrase slot वाला hybrid setup ठीक हो सकता है
  • वह TPM+PIN exploit होने का दावा भी करता है, लेकिन उस पर भरोसा किया जा सकता है या नहीं, यह अभी देखना बाकी है
    https://deadeclipse666.blogspot.com/2026/05/were-doing-silen...
  • Linux LUKS को भी बिल्कुल इसी तरह configure किया जा सकता है
    यह BitLocker पर attack से ज़्यादा Secure Boot chain पर attack लगता है
    PIN के बिना unlock का मूल्य तभी है जब threat model disk disposal, disk removal, या TPM और disk के अलग हो जाने तक सीमित हो
    अगर device नियमित रूप से कई users इस्तेमाल करते हैं, तो PIN डालना असुविधाजनक या असंभव हो सकता है। इसलिए access verification control को trusted operating system components के हवाले करने वाली संरचना बनती है
  • यह बहुत गंभीर bug है, लेकिन BitLocker full disk encryption ही है। बस authentication bypass संभव हो जाता है

• किसी को “TrueCrypt का उपयोग सुरक्षित नहीं है, और इसमें unpatched security issues हो सकते हैं” वाली पंक्ति याद है? ;)

  • TrueCrypt/VeraCrypt याद आता है। शायद यह कहीं ज़्यादा सुरक्षित encryption solution हो सकता है। इस घटना के बाद तो यह निश्चित रूप से ज़्यादा सुरक्षित लगता है