ज़ीरो-डे Windows exploits सार्वजनिक करने वाले सुरक्षा शोधकर्ता को GitHub ने ब्लॉक किया

 (tomshardware.com)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Nightmare-Eclipse का GitHub अकाउंट ब्लॉक कर दिया गया, और उसने अपना workspace GitLab पर शिफ्ट कर दिया, इसे Microsoft की प्रतिशोधात्मक कार्रवाई बताया
  • टकराव अप्रैल की शुरुआत में BlueHammer ज़ीरो-डे के सार्वजनिक होने से गंभीर हुआ, और Eclipse का कहना है कि Microsoft ने उसकी रिपोर्ट और bounty request को नज़रअंदाज़ किया
  • Microsoft ने ब्लॉक करने की वजह और पूरी परिस्थिति सार्वजनिक नहीं की, इसलिए यह स्पष्ट नहीं है कि मुद्दा non-standard disclosure का है या रिपोर्टिंग और bounty process की विफलता का
  • Eclipse ने BlueHammer, RedSun, UnDefend सहित Windows के 6 ज़ीरो-डे सार्वजनिक किए, जिनमें से कुछ का वास्तविक वातावरण में सक्रिय दुरुपयोग हो रहा है
  • GitHub ब्लॉक पहले से सार्वजनिक code और दुरुपयोग को रोकने के लिए पर्याप्त नहीं है, और AI से तेज़ हुई vulnerability discovery के दौर में disclosure और patch process की सीमाएँ उजागर करता है

GitHub अकाउंट ब्लॉक और GitLab पर स्थानांतरण

  • Microsoft ने सुरक्षा शोधकर्ता Nightmare-Eclipse (Chaotic Eclipse) का GitHub अकाउंट अब तक सार्वजनिक न किए गए कारणों से ब्लॉक कर दिया
  • Eclipse ने अपना workspace GitLab पर शिफ्ट कर दिया, और कहा कि bug report के लिए इस्तेमाल होने वाला उसका Microsoft अकाउंट भी पहले ही हटा दिया गया था
  • ब्लॉग पोस्ट में उसने दावा किया कि यह कार्रवाई प्रतिशोधात्मक है, Microsoft ने संवाद से इनकार किया और कोई इनाम भी नहीं दिया
  • Microsoft का MSRC bounty program शर्तों के अनुसार endpoint ज़ीरो-डे के लिए अधिकतम 30,000 से 100,000 डॉलर और Hyper-V vulnerabilities के लिए अधिकतम 250,000 डॉलर देता है
  • Eclipse पहले ही 6 ज़ीरो-डे exploits सार्वजनिक कर चुका है और उसने संकेत दिया कि 14 जुलाई को Microsoft के बारे में और खुलासे हो सकते हैं

Microsoft और Eclipse के बीच टकराव

  • टकराव अप्रैल की शुरुआत में तब गंभीर हुआ जब Eclipse ने बिना पूर्व चेतावनी BlueHammer ज़ीरो-डे सार्वजनिक कर दिया
  • Eclipse का ब्लॉग Microsoft और MSRC की कड़ी आलोचना करता है, और दावा करता है कि Microsoft ने ज़ीरो-डे रिपोर्टों को नज़रअंदाज़ किया या ठुकरा दिया और मांगी गई bounty राशि न देकर उसे आर्थिक नुकसान पहुँचाया
  • Eclipse का दावा है कि Microsoft की ओर से उससे कहा गया था कि उसकी “ज़िंदगी बर्बाद कर दी जाएगी”, और उसके अनुसार वास्तव में ऐसा हुआ; उसने यह भी कहा कि उसके पास एक तरह का deadman switch है
  • Microsoft ने विस्तृत पृष्ठभूमि सार्वजनिक नहीं की है, इसलिए यह तय करना मुश्किल है कि समस्या standard disclosure process का पालन न करने वाले शोधकर्ता की है या security reporting को कठिन बनाने वाली कंपनी की

MSRC प्रक्रिया पर विवाद और disclosure policy पर दबाव

  • Tharros के William Dormann ने BlueHammer पर लेख में MSRC की आलोचना करते हुए कहा कि पहले उसके साथ सहयोग करना आसान था, लेकिन लागत कटौती के कारण अनुभवी लोगों को हटाकर केवल प्रक्रिया-तालिका मानने वाले लोग छोड़ दिए गए
  • Dormann का मानना है कि MSRC अब exploit video submission मांगता दिख रहा है, और यह भी संभव है कि रिपोर्ट करने वाले ने वीडियो जमा नहीं किया, इसलिए Microsoft ने केस बंद कर दिया
  • Microsoft की चुप्पी के कारण यह स्पष्ट नहीं हो पा रहा कि इस टकराव का मुख्य मुद्दा responsible vulnerability disclosure प्रक्रिया है या bounty program के वास्तविक संचालन का तरीका
  • AI-आधारित security research के कारण standard 90-दिन disclosure-patch window को व्यवहारिक रूप से पुराना मॉडल माना जा रहा है
  • ऐसे संदर्भ में, जहाँ exploit बनने का समय और बिना इस्तेमाल वाले exploits की अवधि दोनों लगभग शून्य की ओर जा रहे हैं, Microsoft और अन्य software कंपनियों की policy adjustments की ज़रूरत बढ़ रही है

सार्वजनिक किए गए Windows ज़ीरो-डे

  • Eclipse ने कई Windows ज़ीरो-डे exploits सार्वजनिक किए हैं
  • BlueHammer एक ऐसी vulnerability है जो Defender के ज़रिए SYSTEM privilege दिलाती है
  • RedSun भी SYSTEM user access संभव बनाता है
  • UnDefend Defender को offline कर सकता है
  • GreenPlasma CTFMon service के जरिए SYSTEM access हासिल करता है
  • MiniPlasma Windows Cloud Filter driver की खामी के जरिए समान privilege escalation संभव बनाता है
  • YellowKey एक BitLocker vulnerability है, जो हमलावर को लगभग बिना मेहनत encrypted drive खोलने देती है और BitLocker के मूल उद्देश्य को कमजोर कर देती है

वास्तविक दुरुपयोग और सुरक्षा प्रभाव

  • BlueHammer, RedSun, UnDefend के वास्तविक वातावरण में सक्रिय रूप से दुरुपयोग होने की पुष्टि हुई है
  • बाकी vulnerabilities के लिए भी पूरा या आंशिक proof-of-concept code सार्वजनिक है, जिससे इच्छुक हमलावरों के लिए उनका इस्तेमाल करना आसान हो गया है
  • GitHub अकाउंट ब्लॉक सार्वजनिक code हटाने या दुरुपयोग रोकने के लिए पर्याप्त नहीं है, और शोधकर्ता तथा platform के मालिक कंपनी के बीच टकराव को और बढ़ाता है
  • ज़ीरो-डे disclosure, bounty विवाद, अकाउंट ब्लॉक, और AI से तेज़ हुई vulnerability discovery एक साथ मिलकर मौजूदा security reporting, validation, और patching process की सीमाओं को और स्पष्ट कर रहे हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • अगर वेब ऐप में कोई security bug मिल भी जाए, तो अब मैं उसे report नहीं करूँगा। पहली बार report करने पर मुझे लगभग पुलिस द्वारा गिरफ्तार किया गया था, और दूसरी बार उन्होंने मुझे जवाब भी नहीं दिया, सीधे मेरे employer से संपर्क किया और कहा कि यह report उन्हें नागवार गुज़री और fix होने के बाद मैं इस पर लिखना चाहता था
    उसके बाद मैंने तय किया कि यह झंझट उठाने लायक नहीं है, और अगर इसे ऐसे ही छोड़ दूँ तो मेरा दिन भी शांति से गुज़र सकता है

    • अगर चाहें, तो vulnerability को Finnish Cyber Security Centre में report कर सकते हैं, और वहाँ से प्रभावित पक्षों के साथ report और mediation की प्रक्रिया संभाल ली जाती है
      यह पूरी तरह anonymous तरीके से भी संभव है, इसलिए इस बात की चिंता नहीं करनी पड़ती कि कोई अतिसंवेदनशील कंपनी आपकी ज़िंदगी खराब कर देगी। Traficom का FCSC white-hat security researchers को public interest में योगदान जारी रखने देने वाली एक अच्छी व्यवस्था है
    • एक बार किसी railway route ने social media पर “किसी के लिए अच्छा काम किया” जैसी एक photo पोस्ट की, और office की photo में दीवार पर कई systems के username और login details लिखी हुई A4 शीट लगी हुई थी
      मैंने मिल सकने वाले तीन contacts पर इसकी report की, लेकिन सिर्फ़ एक ने जवाब दिया और पूछा कि वे systems क्या करते हैं और risk क्या है। मुझे बिल्कुल नहीं पता था, और मैं किसी अज्ञात system में login करके जाँच करने का इरादा कभी नहीं रखता, इसलिए मैंने जवाब दिया कि इसे internal IT को भेजें ताकि वे credentials बदलें या system बदलें
      अंत में उन्होंने मेरी सजगता के लिए धन्यवाद दिया और कहा कि photo हटा दी गई है, इसलिए मामला सुलझ गया। उम्मीद है कि किसी समझदार व्यक्ति ने वास्तव में इसकी समीक्षा की होगी, लेकिन मैंने इसमें आगे शामिल न होने का फैसला किया
    • ध्यान न देना ही बेहतर है
      कुछ समय तक मैंने पेशेवर रूप से white-hat का काम किया, लेकिन मैं सहमत हूँ कि ईमानदार और मददगार बनने की कोशिश अब जोखिम भरी हो गई है। अगर कोई vulnerabilities बेचने का फैसला करे, तो अब वह भी समझ में आता है
    • कुछ लोग regulation की आलोचना करेंगे, लेकिन EU द्वारा अनिवार्य किया गया Cyber Resilience Act (CRA) कंपनियों को vulnerability reports प्राप्त करने के लिए स्पष्ट contact point रखने और वास्तव में जवाब देने के लिए बाध्य करता है
    • anonymous तरीके से किसी सरकारी एजेंसी को exploit report करने की कोशिश भी की जा सकती है

  • यहाँ क्या चल रहा है, यह मुझे नहीं पता, लेकिन बड़े bug bounty programs का पहला सिद्धांत यह है कि vendor की तरफ़ के संबंधित लोगों को payment करने के लिए मज़बूत incentives दिए जाते हैं
    कई मामलों में internal metrics payment amounts से जुड़े होते हैं, और ऐसे programs में payment होना जश्न की बात मानी जाती है। यह मानना लगभग निश्चित रूप से मुश्किल है कि Microsoft bounty claimants को परेशान करके पैसे बचाने की कोशिश कर रहा होगा
    यह छोटी कंपनियों पर लागू न हो, और यही वजह भी है कि छोटी कंपनियों को bug bounty चलाना नहीं चाहिए, लेकिन FAANG/MAG7 स्तर की कंपनियों पर यह बात निश्चित रूप से लागू होती है। इसका मतलब यह नहीं कि ऐसे programs हमेशा payment के मामले में उदार होते हैं या कभी लोगों को नाराज़ करने वाले फ़ैसले नहीं लेते। बस इतना है कि द्वेष के कारण payment रोके जाने का दावा इससे मेल नहीं खाता
    हालाँकि, Microsoft की तरफ़ के लोगों से बात किए हुए काफ़ी समय हो गया है, इसलिए मैं थोड़ी सावधानी बरत रहा हूँ

    • YellowKey पोस्ट पढ़ने पर लगता है कि कम से कम कुछ मामलों में यह Microsoft के ऐसे आधिकारिक backdoor को उजागर करता है, जिसका उपयोग अमेरिकी intelligence agencies वगैरह करती हैं। यानी BitLocker सुरक्षित नहीं है और उसमें backdoor है
      TrueCrypt के अचानक बंद हो जाने, सभी downloads हटाने और सबको Microsoft BitLocker पर जाने की सलाह देने के बाद यह कोई बिल्कुल अप्रत्याशित बात नहीं थी
      [1] - https://www.tomshardware.com/tech-industry/cyber-security/mi...
    • यह मामला तब शुरू हुआ जब bureaucracy ने Bluehammer की समीक्षा तक करने से इनकार कर दिया, क्योंकि वे reporter को video जारी न करने के लिए मना नहीं पाए
      और bureaucracy को ठीक करने के बजाय account ban करके बात को और बढ़ाना सच में बहुत खराब दिखता है। मुझे समझ नहीं आता कि Microsoft को इसमें good faith में क्यों देखा जाए
    • इस व्यक्ति द्वारा उठाया गया bug एक बेहद स्पष्ट BitLocker backdoor जैसा दिखता है, और यह Microsoft encryption में क्या कर रहा है, इस पर बहुत गंभीर सवाल उठाता है
      ऐसा काफ़ी संभव लगता है कि user key के बिना भी volume decrypt किया जा सकता है, जो बेहद चिंताजनक है। ऐसा लगता है कि वे इसे दबाने की कोशिश कर रहे हैं, लेकिन यह पहले ही सार्वजनिक हो चुका है
    • अगर वे समझदार होते, तो ban के बाद उसे बहुत पैसे देकर hire कर लेते। ऐसी बड़ी कंपनियाँ तनाव में ज़रूर आती हैं, लेकिन अगर मूर्ख न हों तो payment करती हैं
      Microsoft होने के नाते यह ज़रूरी नहीं कि वह इस तरह की चीज़ों में सबसे progressive कंपनी हो, इसलिए पता नहीं उन्हें यह समझ आया भी या नहीं
    • bug bounty review पर काम करते समय मैंने payment से बचने की कोशिश का कोई सबूत नहीं देखा। कंपनी की तरफ़ से मैंने सबसे खराब जो देखा, वह यह था कि proof of concept में “कृपया X से बचें” कहा गया, और उस निर्देश को न मानने वाले researcher को उल्टा ज़्यादा payment दिया गया
      आखिरकार, सिद्ध किया गया risk ज़्यादा बड़ा था। इसके उलट, एक बड़े program में एक researcher ने बहुत पहले यह मनवा लिया था कि साधारण XSS exploit से ऊँचे payment tier के लायक प्रभाव हासिल किया जा सकता है, और उसके बाद वह जब भी XSS ढूँढता, उसी प्रभाव वाला proof of concept जोड़कर बार-बार अनुचित रूप से ऊँचे tier पर payment ले लेता। दूसरे researchers की XSS findings को table में दिए गए XSS tier के हिसाब से payment मिलता था
      हालाँकि, एक अपवाद सच में याद आता है। किसी ने कंपनी के server पर webshell install करने जैसा पवित्र-कप उपलब्धि वाला काम कर दिखाया, और आज के हिसाब से उसकी कीमत 10,000 डॉलर से ज़्यादा होती। लेकिन उसने webshell हटाए बिना सिर्फ़ report submit कर दी और उसे वहीं छोड़ दिया। program owner इतना गुस्सा हुआ कि उसने साफ़ कहा कि इसी वजह से वह bounty देना नहीं चाहता। आख़िरकार payment हुई या नहीं, यह मुझे याद नहीं

  • लगता है Microsoft को इस बात का पछतावा होगा
    कोई zero-day ढूँढे और बदले में reward न मिले, सिर्फ़ account ban हो जाए। फिर वह उस zero-day को कहीं और बेच देगा

    • लेकिन क्या यह कहानी zero-day exploit बेचने की नहीं, बल्कि उसे public करने की नहीं है? शीर्षक में भी यही लिखा है
      और Microsoft से असंबंधित GitLab पर भी ban लगा था
    • दूसरे zero-day खोजने वाले लोग भी हैं। प्रतिष्ठा बहुत मायने रखती है
    • अगर कोई zero-day कहीं और बेच दे, तो भी शायद कोई समस्या नहीं होगी। CIA सिर्फ़ किसी senior official के अनुरोध पर लाखों डॉलर के gold bars दे सकती है, इसलिए exploits खरीदने के लिए शायद purchase order की भी ज़रूरत नहीं पड़ती होगी

  • पिछले कुछ महीनों में कई संबंधित मामलों में बहुत अजीब digital प्रतिक्रियाएँ झेलीं, और यह ठीक-ठीक समझ नहीं पा रहा था कि मैं क्या गलत कर रहा हूँ, इसलिए काफी झुंझलाहट थी। फिर लेख में यह पंक्ति पढ़ी
    “लेकिन लागत बचाने के लिए Microsoft ने अनुभवी लोगों को निकाल दिया, और सिर्फ flowchart followers ही छोड़ दिए।”
    flowchart followers वाली अभिव्यक्ति याद रखने लायक है। ये वे लोग हैं जिन्हें सोचने के लिए नहीं, बल्कि पहले से तय प्रक्रिया का पालन करने के लिए पैसे दिए जाते हैं। लगता है कि निकट भविष्य में, चाहे digital सिस्टम हों या असली इंसान, हमें ऐसे flowchart followers का बहुत ज़्यादा सामना करना पड़ेगा

    • जिन ज़्यादातर corporate security consulting कंपनियों से पहले निपटना पड़ा, वे checklist से चलती थीं
    • मैकेनिक, इलेक्ट्रीशियन, बिल्डर जैसे कई blue-collar पेशों में flowchart का पालन करना लगभग कानून जैसा है, और प्रक्रियाएँ खून और जवाबदेही से लिखी गई हैं
      वहीं IT, operations, और developers खुद को कारीगर-सुलभ और स्वतंत्र सोच वाले knowledge workers मानते हैं। वे मानते हैं कि प्रक्रिया का पालन करने से अधिक shortcuts, hacking, और out-of-the-box thinking ही असली कौशल से जुड़ी होती है

  • क्या Microsoft में क्या चल रहा है इस पर कोई सार्वजनिक रुख है? Microsoft और GitLab दोनों ने उस user को ban क्यों किया होगा?
    मुझे तो लगा था कि दोनों platforms exploit और security research hosting की अनुमति देते हैं, अगर शुरू से साफ़ लेबल किया गया हो, लेकिन शायद उसने कोई नियम तोड़ा होगा

    • अगर यह ऐसा full-disk encryption exploit है जिसके लिए अब भी hardware access चाहिए, तो शायद यह किसी तीन-अक्षरी सरकारी agency जैसी जगह के लिए बनाया गया होगा

  • दूत को ही मार दो, समस्या हल हो जाएगी

    • हो सकता है वे vulnerability patch करने के बजाय उसे राज्य एजेंसियों को बेचने की ओर धकेलना चाहते हों

  • क्या Microsoft ने GitHub पर zero-day हटाने की editorial जिम्मेदारी खुद अपने ऊपर ले ली है?
    अगर मेरे software का zero-day GitHub पर चढ़ जाए, तो क्या Microsoft उस account को भी उड़ा देगा?

    • मुझे समझ नहीं आता कि यह कार्रवाई आगे चलकर दूसरे accounts पर भी कार्रवाई करने की जिम्मेदारी क्यों बना देगी

  • यह स्थिति अच्छी तरह दिखाती है कि GitHub का Microsoft के स्वामित्व में होना एक संरचनात्मक हित-संघर्ष है
    GitHub के पास सक्रिय weaponized exploits host करने पर स्पष्ट terms of service हैं, लेकिन Windows को target करने वाले researcher को ban करना, चाहे उसके लिए वैध कारण हों, हमेशा प्रतिशोध जैसा ही दिखेगा

  • बहुत महत्वपूर्ण जानकारी:
    https://www.theregister.com/security/2026/05/28/microsoft-0-...
    linked Microsoft blog post में यह कहा गया है
    “इन vulnerabilities का विवरण public disclosure से पहले Microsoft के साथ साझा नहीं किया गया था, और उस disclosure ने customers को अनावश्यक जोखिम में डाल दिया।”
    तो क्या Microsoft झूठ बोल रहा है? अगर नहीं, तो Nightmare-Eclipse ने रिपोर्ट क्यों नहीं किया? स्थिति काफी अजीब लगती है

    • “उस disclosure ने customers को अनावश्यक जोखिम में डाल दिया” वाली बात खटकती है
      चाहे disclosure जिम्मेदार तरीके से हुआ हो या नहीं, customers को जोखिम में डालने वाला researcher नहीं बल्कि Microsoft खुद है
    • Nightmare-Eclipse ने रिपोर्ट नहीं किया, क्योंकि हो सकता है वह नाराज़ researcher होने का नाटक करने वाला किसी विदेशी खुफिया एजेंसी का छद्म संगठन हो
    • यहाँ customer से मतलब license खरीदने वाले व्यक्ति या कंपनी नहीं, बल्कि वह पक्ष हो सकता है जिसने इस backdoor की मांग की हो