1 पॉइंट द्वारा GN⁺ 1 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Chaotic Eclipse का YellowKey सिर्फ USB फ़ाइलों और Windows Recovery Environment की मदद से BitLocker-लॉक्ड ड्राइव तक पहुंच संभव बनाता है
  • Tom's Hardware के टेस्ट में System Volume Information में FsTx फ़ाइलों को कॉपी करने और Shift+Restart के बाद Control key दबाने की प्रक्रिया काम करती दिखी
  • रीबूट के बाद बिना किसी सवाल या मेन्यू के elevated command line में प्रवेश मिला, और BitLocker से लॉक की गई ड्राइव पर बिना key डाले पूरा access मिल गया
  • Alice की ड्राइव को Bob की मशीन में लगाकर खोलना मुश्किल दिखता है, लेकिन अगर डिवाइस खुद चोरी हो जाए तो लक्ष्य TPM का सीधे इस्तेमाल किया जा सकता है, इसलिए जोखिम बढ़ जाता है
  • SecurityOnline के अनुसार YellowKey Windows Server 2022·2025 पर भी काम करता है, लेकिन Windows 10 पर नहीं

YellowKey की attack प्रक्रिया और देखी गई behavior

  • Chaotic Eclipse ने zero-day YellowKey जारी किया, जो BitLocker से लॉक्ड ड्राइव तक पहुंच दिला सकता है
  • Tom's Hardware ने पुष्टि की कि USB stick में कुछ फ़ाइलें कॉपी करने के बाद Windows Recovery Environment में reboot करने वाली प्रक्रिया वास्तव में काम करती है
  • इस प्रक्रिया में System Volume Information पर write access हासिल करना, उसके भीतर FsTx फ़ोल्डर और उसकी contents कॉपी करना, फिर Shift+Restart से recovery environment में जाकर Control key को लगातार दबाए रखना शामिल है
  • रीबूट के बाद बिना किसी सवाल या मेन्यू के elevated command line खुल गई, और BitLocker से लॉक्ड ड्राइव पर बिना key input के पूरा access मिल गया
  • attack में इस्तेमाल की गई फ़ाइलें एक बार उपयोग के बाद USB stick से गायब हो गईं, और Tom's Hardware ने इसे backdoor जैसा दिखने वाला behavior माना

प्रभाव का दायरा और physical theft का जोखिम

  • YellowKey उन environments के लिए तुरंत जोखिम पैदा करता है जो drive encryption के लिए BitLocker पर भरोसा करते हैं
  • BitLocker घर, enterprise और government environments में लाखों डिवाइस की सुरक्षा करता है, और खासकर Windows 11 में यह डिफ़ॉल्ट रूप से enabled है
  • Tom's Hardware की पुष्टि के अनुसार Alice डिवाइस की ड्राइव को Bob डिवाइस में लगाकर खोलना संभव नहीं दिखता, क्योंकि encryption key Alice डिवाइस के TPM में होती है
  • लेकिन अगर laptop, mini PC या desktop खुद चोरी हो जाए, तो हमलावर लक्ष्य डिवाइस के TPM का सीधे इस्तेमाल कर सकता है, जिससे physical theft का जोखिम बढ़ जाता है
  • SecurityOnline की रिपोर्ट के अनुसार YellowKey Windows Server 2022 और 2025 पर भी काम करता है, लेकिन Windows 10 पर नहीं

TPM·PIN configuration और disclosure की पृष्ठभूमि

  • Eclipse ने कहा कि पूरा TPM-and-PIN configuration इस्तेमाल करने पर भी मदद नहीं मिलती
  • उनके पास इस configuration के लिए एक variant भी है, लेकिन उसका proof-of-concept (PoC) उन्होंने जारी नहीं किया
  • Eclipse ने कहा कि यह vulnerability अच्छी तरह छिपी हुई थी और इसे बेचकर बड़ी रकम कमाई जा सकती थी, लेकिन Microsoft के प्रति अपने रुख के कारण उन्होंने इसे public किया
  • Chaotic Eclipse ने पिछले महीने भी BlueHammer और RedSun zero-days जारी किए थे, जो Windows Defender से system administrator अधिकार दिला सकते थे
  • उस समय यह disclosure Microsoft security team द्वारा vulnerability report ठुकराए जाने के दावे के बाद हुआ था

साथ में जारी किया गया GreenPlasma

  • Chaotic Eclipse द्वारा साथ में जारी GreenPlasma के लिए पूरा PoC नहीं है, लेकिन उनका कहना है कि यह local privilege escalation के जरिए system-level access दिला सकता है
  • GreenPlasma CTFMon process को manipulate करके tampered memory section object को Windows Object Manager की एक specific section में रखता है
  • कहा गया है कि यह section ऐसी जगह है जहां SYSTEM user के पास write permission होती है, और यह सामान्य access control को bypass करता है
  • इसके बाद exploit code ऐसे memory region तक पहुंच सकता है जहां उसे नहीं पहुंचना चाहिए, और इससे पूरे system पर access हासिल किया जा सकता है
  • desktop पर कोई भी arbitrary program पूरा access पा सकता है, और server पर सामान्य user server और दूसरे users के data तक control हासिल कर सकता है, इसलिए मामला और गंभीर हो जाता है

Microsoft की response स्थिति

  • लेख लिखे जाने के समय तक Microsoft ने YellowKey या GreenPlasma पर कोई आधिकारिक बयान नहीं दिया था
  • BlueHammer पहले ही patch किया जा चुका है
  • Chaotic Eclipse का दावा है कि Microsoft ने RedSun को चुपचाप patch कर दिया, लेकिन इस पर भी कोई आधिकारिक बयान नहीं है

1 टिप्पणियां

 
GN⁺ 1 시간 전
Hacker News की राय
  • मूल स्रोत https://deadeclipse666.blogspot.com/2026/05/two-more-public-... है
    दूसरे लिंक: https://github.com/Nightmare-Eclipse/YellowKey, https://github.com/Nightmare-Eclipse/GreenPlasma

  • BitLocker भेद्यता साधारण होने के बावजूद बेहद खतरनाक लगती है
    कंपनियाँ और व्यक्तिगत उपयोगकर्ता डिवाइस खो जाने पर डेटा की सुरक्षा के लिए BitLocker पर निर्भर रहे हैं, लेकिन Microsoft शायद अपने वादों के बावजूद सुरक्षा को गंभीरता से नहीं लेता
    और कितनी घटनाएँ लगेंगी ताकि ज़्यादा कंपनियाँ Windows और Microsoft प्लेटफ़ॉर्म पर निर्भरता के जोखिम को ठीक से समझें?

    • Microsoft पहले से ही BitLocker को गंभीरता से लेता हुआ नहीं दिखता था
      Windows 7 के दौर में Windows install CD डालकर Shift+F7 जैसी कोई key दबाने पर drive unlocked स्थिति में system command prompt मिल जाता था
      अगर वे installer को BitLocker unlock करने देने वाले थे, तो तुरंत यह सोचना चाहिए था कि “तो पूरा installer login screen जितना सुरक्षित होना चाहिए”, लेकिन लगता है ऐसा नहीं हुआ
    • RedSun और Bluehammer को देखना चाहिए, जिन्हें Microsoft ने CVE का जवाब दिए बिना और शोधकर्ता को श्रेय दिए बिना चुपचाप patch कर दिया
      यह Microsoft की खराब security practices को जारी रखते हुए बात को टालने की कोशिश का नतीजा है
      शोधकर्ता का दावा है कि इसी तरह का एक और version तैयार है जो TPM+PIN को भी bypass कर सकता है, और यह भरोसेमंद लगता है
      तीन महीनों में एक ही व्यक्ति द्वारा ring 0 zero-day की 5 खोजें सांख्यिकीय रूप से बहुत असंभव लगती हैं, और यह व्यक्ति exploits में सचमुच बहुत निपुण लगता है, Juan Sacco के स्तर का
    • ज़्यादातर Linux distributions full disk encryption को default से enable भी नहीं करते, और अगर करते हैं तो अक्सर BitLocker की ही तरह TPM PCR-sealed auto-unlock का इस्तेमाल करते हैं
      उस स्थिति में signed OS image से boot होने के बाद अगर auth bypass किया जा सके या system memory की स्थिति देखी जा सके, तो disk contents हासिल किए जा सकते हैं; यानी वही भेद्यता रहती है
      यह किसी भी platform पर चुना जाने वाला एक architectural trade-off है, “lock-in” से इसका लेना-देना नहीं
      BitLocker disk encryption को ज़्यादा सुरक्षित तरीके से configure करना आसान है, लेकिन इससे admins पर बड़ा operational burden पड़ता है, इसलिए आम तौर पर ऐसा नहीं किया जाता
      मुझे लगता है Apple के FileVault defaults बेहतर हैं, क्योंकि FileVault को “enable” करना मौजूदा hardware UID-tangled key को user password से भी wrap करने जैसा है
      हालांकि यह strategy remote password rotation या Active Directory जैसी delegated authentication में बड़ी समस्याएँ पैदा कर सकती है, इसलिए शायद Microsoft इसे default नहीं चुनता
    • समझ नहीं आता कि एक bug से सीधे यह कैसे निष्कर्ष निकलता है कि “वे security को गंभीरता से नहीं लेते”
    • लेख का तीसरा paragraph पढ़ें तो यह जानबूझकर डाला गया backdoor जैसा लगता है
  • Crikey, इतनी बड़ी backdoor ख़बर दब-सी गई लगती है
    ये सब पूरी तरह तैयार नहीं तो भी ज़्यादातर काफी mature और बहुत high-value exploits लगते हैं
    बाज़ार में इनकी कीमत खगोलीय होती, और ये उन law enforcement agencies के लिए सबसे उपयुक्त होते जो unlock-as-a-service देने वाली कंपनियों का इस्तेमाल करती हैं
    इसलिए इनके public disclosure की सराहना करता हूँ

    • मुझे पूरा यक़ीन है कि यह bug नहीं बल्कि जानबूझकर बनाया गया backdoor है, लेकिन यह भी देखना चाहिए कि सरकारी एजेंसियों के पास पहले से ही access के दूसरे साधन थे: https://news.ycombinator.com/item?id=46735545
  • BitLocker मूल रूप से तब तक बहुत काम का नहीं है जब तक hardware सुरक्षित न हो
    कई Boot Guard implementations में certificates hardware में fuse किए जाते हैं ताकि OEM केवल वही firmware बना सके जिससे boot हो, लेकिन ऐसे certificates कम-से-कम दो बार leak हो चुके हैं, जिससे उस signature वाले सारे hardware exposed हो गए, और दूसरे bypasses भी मौजूद हैं
    कुछ Boot Guard केवल “flash guard” होते हैं जो signed firmware ही flash होने देते हैं, इसलिए वे सीधे SPI BIOS chip पर लिखने से नहीं रोकते
    किसी ने firmware के SMM module को patch करके PCR values बनाए रखते हुए BitLocker lock को बिलकुल trigger न होने देने का demo भी दिखाया था
    यानी अगर किसी के पास laptop या desktop खोलने और firmware flash करने के लिए लगभग 2 मिनट हों, तो वह बाहर से SMM module वाला BIOS लिख सकता है
    PIN authentication न होने पर यह सबसे घातक है, क्योंकि सिर्फ laptop चुराकर भी data निकाला जा सकता है
    अगर PIN हो, तो user से boot करवाने के बाद network के ज़रिए data exfiltrate करने वाला payload गिराया जा सकता है, या decryption key को unencrypted partition में दोबारा लिखवाया जा सकता है, या disk के आखिर के कुछ sectors खराब करके वहाँ लिखवाया जा सकता है, फिर बाद में दोबारा चोरी की जा सकती है
    SMM को modify करके boot process patch किया जा सकता है ताकि malicious payload hypervisor या kernel में load हो

    • यह केवल तभी बेकार है जब आप पूरी तरह सक्षम attacker मान लें
      हर attacker nation-state स्तर का नहीं होता, और वास्तविक दुनिया में काफ़ी amateur attackers भी होते हैं
      यह मान लेना मददगार नहीं कि अगर सबसे ताकतवर attackers को नहीं रोक सकते तो सब कुछ बेकार है, इसलिए परवाह ही न करें
      मुझे पता है कि मेरी cycle lock भी पर्याप्त कुशल और जिद्दी व्यक्ति कुछ सेकंड में काट सकता है, फिर भी मैं cycle lock करूँगा
    • “अगर hardware सुरक्षित न हो” वाले आधार पर देखें, तो HDD/SSD controller पर चलने वाली ज़्यादातर hardware disk encryption BitLocker से खुद 100 गुना ज़्यादा खराब है
      वह bugs और security vulnerabilities से भरी होती है, और उसका इस्तेमाल करना समझदारी नहीं है
  • https://infosec.exchange/@wdormann/116565129854382214

    • वहाँ mitigation के रूप में PIN के साथ BitLocker इस्तेमाल करने की बात कही गई है
      हालांकि YellowKey के लेखक का कहना है कि वे PIN को सुरक्षा उपाय मानने से सहमत नहीं हैं
  • हैरानी की बात है। क्या backdoor की वजह से Microsoft की साख को बड़ा झटका लगेगा, या वह ज़्यादातर संगठनों के लिए इतना अनिवार्य है कि कुछ ख़ास नहीं होगा?

    • लगता है EU ऐसी घटनाओं की वजह से de-coupling को और तेज़ी से आगे बढ़ाएगा
    • कम-से-कम 20 साल से इस विषय पर नज़र रखने वाले लोग तो पहले से ही मानते आए हैं कि Microsoft products में किसी-न-किसी रूप में backdoor हैं
      सिर्फ Snowden leaks के मूल दस्तावेज़ ही देख लें, अगर उससे पहले यह साफ़ नहीं था तो उसके बाद काफ़ी साफ़ हो गया
      कंपनियाँ Microsoft इसलिए इस्तेमाल करती हैं क्योंकि उन्हें लगता है कि backdoor होने पर भी उससे उनका कुछ नहीं बिगड़ेगा
      वे न तो terrorist हैं, न child porn से जुड़े अपराधी, और उनका मानना है कि BitLocker में backdoor हो या न हो, subpoena आने पर वे मान ही लेंगे
      जो व्यक्ति security और privacy की परवाह करते हैं, वे अपना data किसी VeraCrypt drive में रखते हैं
    • वास्तव में इसे जानबूझकर बनाया गया “backdoor” साबित करने वाला कोई ठोस सबूत नहीं दिखता
    • यह असली backdoor नहीं है
      attacker ने recovery mode में boot करने के बाद Windows को exploit करने का तरीका ढूँढा है
      डिवाइस फ़ाइलों की सुरक्षा इस बात पर निर्भर करती है कि user के unlock करने से पहले सामने आने वाली किसी भी attack surface पर attacker Windows पर क़ब्ज़ा न कर सके
      इसी वजह से GrapheneOS जैसे operating systems शुरुआती boot में USB ports disable कर देते हैं ताकि attacker की पहुँच वाली attack surface कम हो
    • privacy की वजह से Windows इस्तेमाल करने वाला शायद कोई नहीं, इसलिए शायद किसी को फ़र्क़ नहीं पड़ेगा
  • system unlock होने के बाद key copy कर लेना backdoor कहलाना चाहिए या नहीं, यह तय नहीं कर पा रहा हूँ
    अगर operating system ने key access को lock रखने का वादा किया था और उसमें नाकाम रहा, तो लोग इसे backdoor कहें, यह तर्क समझ आता है
    लेकिन यह key bypass या pre-shared key जैसी चीज़ नहीं है, जबकि लेख का लहजा वैसा संकेत देता है
    वैसे भी अच्छा है कि मैं Windows इस्तेमाल नहीं करता

    • सही है। यह BitLocker enable होने की स्थिति में काम करने वाला Windows auth bypass है
      केवल TPM वाले BitLocker में boot के बाद होने वाले auth bypass या memory contents extraction जैसी सभी तकनीकों का जोखिम पहले से रहता है, और यह मामला खास तौर पर एक बहुत ही बेवकूफ़ाना और अजीब auth bypass technique है जिसे लेखक और media ने ज़रूरत से ज़्यादा पेश किया है
      कोई भी operating system जो सिर्फ hardware identity के आधार पर disk encryption unlock करता है, उसी तरह के attack के लिए vulnerable होता है
      Linux full disk encryption setups में भी recovery shell में पहुँचने लायक misconfiguration या exploit के कई रास्ते होते हैं
      फिर भी यह “कोई disk protection नहीं” होने से बहुत बेहतर है, और खास तौर पर उन सभी scenarios को रोकता है जहाँ disk को hardware से अलग कर लिया जाता है
      लेकिन boot के बाद की attack surface बहुत बड़ी होती है, और गंभीर attackers के सामने इस protection layer को speed bump से ज़्यादा नहीं समझना चाहिए
  • Reddit पर मैंने लोगों को यह पूछते देखा कि patch हो जाने के बाद भी क्या किसी known-vulnerable WinRE version को उसी drive या किसी दूसरी drive पर लिखा जा सकता है
    मुझे BitLocker या TPM की ज़्यादा समझ नहीं है, तो क्या ये चीज़ें उसे भी रोकती हैं?

  • समझ नहीं आता कि हर ऐसे thread में इसे छोटा दिखाने वाली replies इतनी ज़्यादा क्यों होती हैं
    और यह भी अजीब है कि अक्सर नए accounts से ही ऐसी बातें आती हैं
    “यह BitLocker exploit नहीं बल्कि auth/privilege-escalation bug है”, “attacker ने साफ़ लिखा कि TPM+PIN bypass हो सकता है लेकिन असल में ऐसा नहीं है या उसका मतलब वह नहीं था”, “इसे backdoor मानने में जल्दबाज़ी नहीं करनी चाहिए”, “TPM-only BitLocker के सुरक्षित न होने की बात तो पहले से मालूम थी” — ऐसे कई रूप बार-बार दिखते हैं
    आख़िरी बात खास तौर पर इसलिए अजीब लगती है क्योंकि बहुत-सी organizations उसी पर निर्भर हैं

    • ये systems auto-decrypt होने के लिए configured होते हैं
      unlock और user login के बीच Windows पर सफल हमला हो जाए तो files तक पहुँचा जा सकेगा, यह तो बिल्कुल साफ़ बात है
      अगर यह उसी तरह का attack है, तो यह BitLocker की अपनी खामी नहीं है
      TPM+PIN bypass के दावे पर “दिखाइए” कहना अनुचित नहीं है
      यह कहना भी सही है कि इसे backdoor घोषित करने में जल्दबाज़ी नहीं करनी चाहिए
      और TPM-only BitLocker को किसी ज्ञात असुरक्षित चीज़ से ज़्यादा एक ज्ञात बहुत बड़ी attack surface कहना बेहतर होगा
    • बड़ी tech companies की आलोचना वाले पोस्टों पर आम तौर पर ऐसी replies आ ही जाती हैं
      यहाँ यह हमेशा होता है, और 100% असली लगने वाली ऐसी replies को रोकने का कोई तरीका नहीं दिखता, इसलिए बस उन्हें छोड़कर आगे बढ़ना पड़ता है
  • यह इतना ज़्यादा जानबूझकर बनाए गए backdoor जैसा दिखता है कि 2014 में TrueCrypt का अचानक सबको BitLocker पर जाने की सलाह देना और भी संदिग्ध लगता है
    यह खास backdoor तब नहीं रहा होगा, क्योंकि यह शायद Windows 11-विशेष है, लेकिन दूसरे backdoors की संभावना तब और विश्वसनीय लगती है
    हालांकि अगर TrueCrypt को इसलिए खत्म किया गया कि लोग backdoor-सक्षम encryption पर जाएँ, तो फिर VeraCrypt को क्यों रहने दिया गया, यह सवाल उठता है
    VeraCrypt open source है और उसका independent audit भी हुआ है, इसलिए उसमें backdoor नहीं होना चाहिए