सुरक्षा शोधकर्ता ने कहा कि Microsoft ने BitLocker में बैकडोर बनाया, exploit जारी किया
(techspot.com)- सुरक्षा शोधकर्ता 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 का उल्लेख किया गया है
2 टिप्पणियां
Lobste.rs की टिप्पणियाँ
बताया गया है कि यह backdoor तभी काम करता है जब WinRE को drive unlock करना पड़े (पिछली पोस्ट), और अगर drive password से protected है, तो संभवतः वह password दर्ज करना ही होगा
शायद असली target transparent BitLocker है, जहाँ लोग सिर्फ TPM पर भरोसा करते हैं और disk encryption password नहीं लगाते. एक बार पूरा Windows boot हो चुका हो, encryption key memory में मौजूद हो, और केवल login screen login रोक रही हो, तो यह सुनने में जितना सुरक्षित लगता है उतना है नहीं
चूँकि आप पहले से ही Windows के अंदर हैं, attack surface बहुत बड़ा हो जाता है, और OP के “bugdoor” के अलावा भी कई bugs रहे हैं जो login screen bypass करने देते थे. इसके अलावा TPM bus sniffing या cold boot attack से memory से keys निकाली जा सकती हैं
फिर भी यह चिंता की बात है, लेकिन शायद BitLocker का recommended usage यही है, और आम users को यह ठीक से नहीं बताया जाता कि disk encryption में असली password न इस्तेमाल करने का risk क्या है. फिर भी, यह vulnerability केवल उन्हीं मामलों पर लागू होती दिखती है जहाँ BitLocker पहले से ही मूल रूप से असुरक्षित तरीके से इस्तेमाल हो रहा था, और यह बस मौजूदा attacks को थोड़ा आसान बनाती है
हाँ, अगर WinRE password-encrypted drives भी जादुई तरीके से खोल सकता है, तो बात अलग होगी, लेकिन अगर ऐसा होता तो लगता है कि कोई न कोई इसे सालों पहले पकड़ चुका होता
“दूसरी बात, नहीं, TPM+PIN भी मदद नहीं करता. इस issue का exploitation अभी भी संभव है. मैंने खुद से पूछा था, ‘क्या यह TPM+PIN environment में भी काम करेगा?’ और जवाब है हाँ. लेकिन मैं PoC जारी नहीं करूँगा. जो पहले से public है वही काफ़ी बुरा है”
दूसरे शब्दों में, जिस समय Paul Le Roux को drug trafficking और contract killing के अपराधों में गिरफ्तार किया गया और उसने authorities के साथ सहयोग शुरू किया, उसी समय TrueCrypt users को backdoored software की ओर मोड़ा गया
Wikipedia के अनुसार Le Roux 2012 में गिरफ्तार हुआ था, तो यह timeline मेल नहीं खाती लगती
https://news.ycombinator.com/item?id=7812133
अगर थोड़ा बढ़ते हुए conspiracy-theory mode में जाएँ, तो cloud key request logs छोड़ सकती है और उसके लिए कानूनी मंज़ूरी भी लग सकती है
अप्रैल के आखिर में Windows update install करने के बाद मैं PIN से BitLocker volume को बिल्कुल decrypt नहीं कर पा रहा था. recovery code काम कर रहा था, लेकिन PIN कई बार reset करने पर भी वह बार-बार गलत बता रहा था
आखिरकार मैं कारण नहीं ढूँढ पाया और Windows फिर से install करना पड़ा. यह काफ़ी परेशान करने वाला bug था, और एक अजीब संयोग भी
अगर मैं कहीं लिख दूँ कि ECDSA में backdoor है, तो clickbait sites को छोड़कर कोई उसे news article नहीं बना देगा
इसे किसी हद तक जानबूझकर डाला गया backdoor मानकर शक करना बहुत बड़ी छलाँग नहीं है, लेकिन वह अब भी अटकल ही है
बिना सबूत वाला हिस्सा यह दावा है कि अलग से PIN-configured BitLocker को भी bypass किया जा सकता है. यह article में नहीं था
इस व्यक्ति का Windows vulnerabilities खोजने का काफ़ी अच्छा track record लगता है, इसलिए PoC न होने पर भी इस दावे पर ध्यान देना उचित है
साफ़ बात है, जिन चीज़ों को चोरी से बचाना ज़रूरी हो उन्हें कभी भी Windows पर नहीं रखना चाहिए. Windows पर banking, investments, taxes, email, hosting, shopping या निजी काम नहीं करने चाहिए
Windows का इस्तेमाल केवल (i) gaming और (ii) Windows builds के लिए ही करना चाहिए
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 कर पा रहे हों
यह 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 दिलचस्प है
बेहतर summary: https://infosec.exchange/@wdormann/116565129854382214
public exploit PIN इस्तेमाल करने वाले BitLocker को प्रभावित नहीं करता। PIN न हो तो BitLocker वैसे भी सुरक्षित नहीं है
मूल लेखक दावा करता है कि उसके पास ऐसा exploit भी है जो PIN होने पर भी काम करता है, लेकिन उसने अभी तक उसका कोई सबूत नहीं दिया है
मैंने किसी भी company को BitLocker पर PIN अनिवार्य करते नहीं देखा
स्रोत: 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 करना पड़ेगा? लगता है कि आगे और बहुत कुछ सामने आएगा
इसलिए यह 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 पर भी नहीं
यह BitLocker-विशेष समस्या से ज़्यादा login bypass जैसी लगती है। PIN के बिना TPM पर निर्भर होने पर decryption अपने आप हो जाता है
सामान्यतः attacker को login screen पार नहीं कर पाना चाहिए, इसलिए सब ठीक होना चाहिए, लेकिन यह exploit recovery environment में unrestricted shell पाने का तरीका दिखाता है
researcher दावा करता है कि PIN को bypass करने का तरीका भी है, लेकिन उसने अभी तक उसे public नहीं किया
security experts कब “Microsoft product security” वाली भूमिका लेना बंद करेंगे? मैं तो पहले ही उस बिंदु पर पहुँच चुका हूँ
Microsoft product security बस एक व्यस्त रखने वाला काम है, जब तक MS का पागलपन भरा tech debt और लालच की अगली लहर उसे फिर से न तोड़ दे। अब तो backdoor भी है
आपने compliance के सारे नियम पूरे कर दिए, और MS-प्रभावित “best practices” का पालन किया, तो फिर कुछ भी हो जाए, ज़िम्मेदारी आपकी नहीं मानी जाएगी
end-to-end encrypted backup के लिए ADP on किया जा सकता है, लेकिन संभव है कि जिन लोगों से आप बात करते हैं उन्होंने इसे on न किया हो, इसलिए मदद सीमित रह सकती है
Microsoft का बचाव नहीं कर रहा, बस कह रहा हूँ कि ऐसी सभी कंपनियाँ PRISM का हिस्सा रही हैं
क्या हम उस पुराने 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 द्वारा बेचा जा रहा झूठा सुरक्षा-बोध है
5 डॉलर वाले microcontroller से खास pins पर solder करके TPM key sniff करना सिर्फ dTPM पर संभव है। fTPM इस attack के लिए vulnerable नहीं है, और dTPM की तुलना में काफ़ी अधिक व्यापक रूप से इस्तेमाल होता है
boot पर passphrase टाइप करना अब तो muscle memory जैसा है, और यह भरोसेमंद, सरल security देता है
motherboard के बिना भी data recover किया जा सकता है
रोज़मर्रा के इस्तेमाल के लिए, evil maid attacks को रोकने हेतु Secure Boot+TPM+passphrase को मिलाकर एक slot और backup passphrase slot वाला hybrid setup ठीक हो सकता है
https://deadeclipse666.blogspot.com/2026/05/were-doing-silen...
यह 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 के हवाले करने वाली संरचना बनती है
किसी को “TrueCrypt का उपयोग सुरक्षित नहीं है, और इसमें unpatched security issues हो सकते हैं” वाली पंक्ति याद है? ;)