Storm-0558 द्वारा key हासिल करने पर प्रमुख तकनीकी जांच के निष्कर्ष

 (msrc.microsoft.com)
1 पॉइंट द्वारा GN⁺ 2023-09-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • China-आधारित threat actor Storm-0558 ने चोरी की गई MSA consumer signing key से token forge करके OWA और Outlook.com तक पहुंच बनाई—इस घटना की तकनीकी जांच के निष्कर्ष
  • अप्रैल 2021 में consumer signing system crash से बने crash dump में race condition के कारण key शामिल हो गई, और system इसे detect नहीं कर सका
  • key शामिल crash dump एक isolated production network से internet-connected corporate network के debugging environment में ले जाया गया, और credential scan भी इसे पकड़ नहीं सका
  • enterprise mail तक consumer key से पहुंच संभव होने का कारण यह था कि mail system developer ने library के scope validation को गलत मान लिया और issuer/scope validation नहीं जोड़ा
  • सभी खामियां ठीक कर दी गई हैं, और key scope validation automation जैसी multi-layer defense strengthening को follow-up action के रूप में लागू किया गया है

key हासिल होने का क्रम

  • Microsoft background check, dedicated account, secure access workstation, और hardware token-आधारित multi-factor authentication वाले isolated और restricted production environment का संचालन करता है
    • इस environment में email, meetings, web research जैसे collaboration tools के उपयोग को रोका जाता है, ताकि malware infection और phishing जैसी account compromise की राहें रोकी जा सकें
    • Just in Time / Just Enough Access policies के जरिए system और data access सीमित किया जाता है
  • corporate environment में security certification और secure devices जरूरी हैं, लेकिन email, meetings, और collaboration tools की अनुमति होने से यह spear phishing, token-stealing malware आदि के प्रति अधिक vulnerable है
    • Zero-Trust और "assume breach" सिद्धांतों के अनुसार key material को production environment से बाहर नहीं जाना चाहिए
  • अप्रैल 2021 में consumer signing system crash होने पर crash dump (crashed process snapshot) बना
    • crash dump में sensitive information को mask किया जाता है, इसलिए उसमें signing key नहीं होनी चाहिए थी, लेकिन race condition के कारण key शामिल हो गई (इसे ठीक कर दिया गया है)
    • system crash dump के भीतर key की मौजूदगी detect नहीं कर सका (इसे ठीक कर दिया गया है)
  • crash dump को, जिसे उस समय key शामिल न करने वाला माना गया था, isolated production network से debugging environment में ले जाया गया
    • यह standard debugging procedure के अनुरूप था, और credential scan key की मौजूदगी detect नहीं कर सका (इसे ठीक कर दिया गया है)
  • key leak होने के बाद Storm-0558 actor ने Microsoft engineer के corporate account को compromise किया
    • उस account के पास उस debugging environment तक access था जहां key वाला crash dump मौजूद था
    • log retention policy के कारण specific exfiltration evidence logs नहीं हैं, लेकिन key हासिल करने का यह सबसे संभावित रास्ता है

consumer key से enterprise mail तक पहुंच संभव क्यों हुई

  • consumer और enterprise applications दोनों को support करने की customer demand के जवाब में सितंबर 2018 में common key metadata publishing endpoint पेश किया गया
    • integrated offering के हिस्से के रूप में enterprise और consumer account के लिए key scope validation requirements को स्पष्ट करने हेतु documentation update की गई
  • cryptographically signature validate करने वाली API उपलब्ध थी, लेकिन library को scope validation अपने-आप करने के लिए update नहीं किया गया (इसे ठीक कर दिया गया है)
  • 2022 में mail system को common metadata endpoint इस्तेमाल करने के लिए update किया गया
    • mail system developer ने गलत मान लिया कि library पूरी validation करती है और जरूरी issuer/scope validation नहीं जोड़ा
    • परिणामस्वरूप, mail system ने consumer key से signed security token के साथ enterprise mail requests स्वीकार कर लीं (updated library से इसे ठीक कर दिया गया है)

postmortem review और सुधारात्मक कदम

  • signing key के crash dump में शामिल होने का कारण बनी race condition की पहचान कर उसे हल किया गया
  • crash dump में गलती से key material शामिल होने की स्थिति के लिए prevention, detection, और response को मजबूत किया गया
  • debugging environment में signing key की मौजूदगी बेहतर ढंग से detect करने के लिए credential scanning को मजबूत किया गया
  • authentication library में key scope validation को automate करने वाली improved library deploy की गई और संबंधित documentation को स्पष्ट किया गया

12 मार्च 2024 का अतिरिक्त update

  • operational error के कारण key material security token signing environment से बाहर गया और compromised engineer account के जरिए debugging environment में access हुआ—यह core hypothesis बरकरार है; customer और Microsoft impact या actor activity में कोई बदलाव नहीं है
  • पहले कहा गया था कि 2021 crash dump actor access का कारण हो सकता है, लेकिन प्रभावित key material वाला crash dump नहीं मिला है
  • बताई गई race condition का असर इस बात पर नहीं था कि key crash dump में मौजूद थी या नहीं, बल्कि इस पर था कि crash dump को secure signing environment से बाहर ले जाया जा सकता था या नहीं
  • यह कहना कि crash dump का बाहर ले जाना standard debugging procedure के अनुरूप था, इसका मतलब केवल यह था कि पहले इसे प्रतिबंधित नहीं किया गया था; अब Microsoft standard debugging procedure production environment से ऐसे material के export पर रोक लगाती है
  • जारी जांच में credential scanning technology की सीमाएं सामने आई हैं, और जैसे-जैसे वे मिलेंगी, उन्हें दूर किया जाएगा

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

1 टिप्पणियां

 
GN⁺ 2023-09-07
Hacker News की राय

  • यहां कोई missing link दिखता है: concurrency bug या memory safety bug की वजह से private key का debugging output में गलती से आ जाना आसानी से समझ आता है, लेकिन लगता है कि हमलावर को crash होने की बात, crash dump का structure पता था और उसे Microsoft के internal network के अंदर इंतज़ार कर रहा होना पड़ा होगा
    breach मानकर defense करना अच्छी network security strategy है, लेकिन यह धारणा यूं ही स्वीकार नहीं कर लेनी चाहिए कि वाकई breach हो चुका था

    • अगर मैं चीन की तरफ़ का advanced persistent threat (APT) attacker होता और employee credentials से Microsoft के internal network में घुस गया होता, तो सबसे पहले crash logs की storage location ढूंढकर debug symbols के साथ चुपचाप निकाल लेता
      ऐसे data को अक्सर उसकी वास्तविक value की तुलना में पर्याप्त सुरक्षित तरीके से नहीं रखा जाता। FAANG में काम करके देखा है कि finance या enterprise regulation का अनुभव न रखने वाले लगभग हर नए व्यक्ति को लगता है कि crash data को bug tracker में attach करना ठीक है। इसलिए crash dump जैसी चीज़ों को ऐसे vault में डालने की आदत बदलनी होगी जो इतना आसान हो कि लोग उसे bypass करना न चाहें
      अगर compromised engineer account है, तो कम से कम bug tracker access तो होगा ही, और शायद binary के debug symbols हासिल या बना भी सकता है, ऐसा मानना चाहिए। बाकी बस इतना है कि किसी engineer के लापरवाही से crash dump को bug attachment के रूप में upload करने का इंतज़ार किया जाए, और किसी के notice करके delete करने से पहले उसे उठा लिया जाए
    • लेख के अनुसार employee account compromise, crash dump के internal network में ले जाए जाने के बाद हुआ था। Microsoft कहता है कि exfiltration का evidence नहीं है, लेकिन account compromise के evidence कुछ हद तक हैं, ऐसा पढ़ने में आता है
      साथ ही Microsoft के credential scanning tool ने key नहीं पकड़ी, और कहा गया है कि वह issue ठीक कर दिया गया, इसलिए लगता है key scan से detect हो सकने वाले form में थी
      कुल मिलाकर स्थिति ऐसी लगती है कि engineer ने key वाला dump अपने account में ले जाकर कुछ समय तक छोड़ दिया, बाद में attacker ने account compromise किया, usable files सब उठा ले गया, फिर Microsoft से बेहतर tools से keys scan करते हुए jackpot पा गया
    • उद्धृत बात के हिसाब से, अप्रैल 2021 के बाद key crash dump के जरिए internal environment में leak हुई, फिर Storm-0558 ने Microsoft engineer का internal account compromise किया, और उस account के पास उस debugging environment तक access था जहां गलत तरीके से key शामिल वाला crash dump मौजूद था
      यानी attacker पहले से network के अंदर था और undetected scanning के दौरान संयोग से dump मिल गया, या उसने शुरू से इसी specific account को target किया था
    • Cold boot attacks के समय से ही memory dumps में cryptographic material खोजने के standard tools रहे हैं, ऐसा मुझे पता है। attacker के ऐसे नजरिए से opportunistically crash dumps खोजने की कल्पना भी की जा सकती है
      फिर भी attacker के नजरिए से घटनाओं की chain कुछ ज्यादा ही किस्मत वाली लगती है
    • अगर system में घुसपैठ कर ली और filesystem में sshd.core दिख जाए, तो जाहिर है उसे ले जाओगे ही

  • Systems engineering की classes होती हैं जो बताती हैं कि कैसे छोटी-छोटी समस्याएं एक खास क्रम में लगातार जुड़कर आखिरकार catastrophic failure तक पहुंचती हैं। यह मामला वही catastrophic failure कहा जा सकता है
    पहले race condition होनी चाहिए, और वह race condition unexpected result तक ले जानी चाहिए। अगर code test हुआ था और अक्सर इस्तेमाल होता था, तो यहां ही occurrence probability शायद 10% से कम होगी। फिर engineer को ठीक यही crash dump चाहिए, ऐसा तय करना होगा; credential scanning software को यही specific credential miss करना होगा; एक account compromise होकर network access मिलना होगा और उस user के पास उस dump तक access होना होगा; और hacker को उसे ढूंढकर ले जाना होगा
    फिर भी key पुरानी थी और सिर्फ consumer email accounts तक access के लिए इस्तेमाल हो सकती थी, इसलिए safe होनी चाहिए थी, लेकिन पुराने keys स्वीकार करने वाला bug और company email accounts के tokens में इस signing key को reject न करने वाला bug भी मौजूद था
    Systems engineering का अच्छा lesson है। कितनी भी कोशिश करें, आखिरकार छोटी चीजें पर्याप्त मात्रा में जमा हों तो बड़ा हादसा हो जाता है, इसलिए design ऐसा होना चाहिए कि अगर blast हो भी तो blast radius सीमित रहे

    • Security में इस तरह की chains random process की तरह नहीं आतीं; यह संकेत जरूरी है कि उन्हें actively targeted और exploited किया जाता है। attacker random coin toss करने वाला नहीं होता, बल्कि वह अपने पक्ष में heads ज्यादा आने वाला coin फेंक सकता है
      postmortem में चीजें ऐसे पेश की जाती हैं मानो बदकिस्मत events random तौर पर overlapping हो गए। जैसे attacker ने संयोग से Microsoft को target किया, संयोग से race condition थी, संयोग से crash हुआ, और संयोग से कहीं crash dump मिल गया
      लेकिन यह संभावना भी सोचनी चाहिए कि शुरुआती race condition bug ही जानबूझकर डाला गया हो। crash intentionally trigger किया गया हो सकता है, attacker dump के किसी specific location पर बनने का इंतज़ार कर रहा हो सकता है, और कोई accomplice भी रहा हो सकता है
    • लगता है आप यह मानकर चल रहे हैं कि Microsoft systems engineering करता है और products को test करता है, जबकि reality उससे दूर दिखती है
      Microsoft ecosystem उस Lego car जैसा लगता है जिसे मोहल्ले के बच्चों ने अपने-अपने घर से लाए parts को जैसे-तैसे जोड़कर बना दिया हो
    • Race condition वह वजह है जिसे लोग बेवकूफी भरा bug लिखने पर management को समझाने के लिए इस्तेमाल करते हैं। “masker async था, इसलिए masker set होने से पहले writer ने dump लिखना शुरू कर दिया” यह बात बस एक बेहूदा implementation जैसी लगती है
      Race condition कहने पर लोग “occurrence probability 10% से कम” कहते हैं, लेकिन असल में यह हर बड़े crash में हो सकता है और बस crashes अक्सर नहीं होते होंगे
      disk पर लिखने से पहले masking क्यों नहीं की गई, यह तो भगवान ही जाने
    • ऐसे unknown unknown catastrophic failures हमेशा रहे हैं और आगे भी होते रहेंगे। इसलिए resilience चाहिए, और शायद कम centralized नजरिया भी चाहिए
      पश्चिमी business world के आधे से ज्यादा का Outlook.com पर निर्भर होना बेहद गलत स्थिति के करीब है, लेकिन मौजूदा financial incentives resilience या Outlook.com जैसे hyper-centralized entity को तोड़ने की दिशा में aligned नहीं हैं, इसलिए आगे भी ऐसी चीजें होती रहेंगी
    • पढ़ते हुए लगा, “यह तो सचमुच बहुत सारे needle eyes से होकर निकला है।” ऐसा लगा मानो Voyager की Grand Tour gravity-assist trajectory गलती से बन गई हो

  • कुछ बातें साफ़ तौर पर समझाई नहीं गई हैं: अगर यह 11 जुलाई 2023 को पकड़ा गया और शक है कि यह अप्रैल 2021 में हुआ था, तो इसका मतलब है कि attacker के पास ये credentials 2 साल से ज़्यादा समय तक थे, और detection से public disclosure तक 2 महीने लगे
    कितने forged tokens थे और कितनी access मिली, यह भी गायब है। अगर उन्होंने disclose नहीं किया, तो लोग बुरा ही मानकर चलेंगे
    detection के बाद fix लागू करने की timeline भी नहीं है, बस इतना कहा गया है कि “यह समस्या fix कर दी गई है।” बस उम्मीद है कि उन्होंने इसे जल्दी ठीक किया होगा
    सीधे दिखने वाली 4 समस्याएँ तो ठीक कर दी गईं, लेकिन साफ़ तौर पर systemic problem लगती है, और उसके बारे में वे क्या करेंगे यह भी नहीं दिखता

    • प्रतिकूल अनुमान लगाना पूरी तरह वाजिब है
      https://en.m.wikipedia.org/wiki/Adverse_inference
    • अगर ये credentials 2 साल बाद भी valid थे, तो सच में जानना चाहूँगा कि उनकी credential rotation policy आखिर कैसी है

  • इस तरह के breach के लिए Microsoft की internal infrastructure की बहुत गहरी समझ चाहिए। इसे किसी hacker team का संगठित काम मानना सुरक्षित है
    यह सस्ते में होने वाला काम नहीं है, लेकिन reward बहुत बड़ा है। अति-केंद्रीकरण hackers को कुछ ही high-value targets पर अपनी मेहनत केंद्रित करने के लिए प्रेरित करता है, क्योंकि सफल होने पर मिलने वाला फायदा बेहद बड़ा होता है
    मुझे लगभग यकीन है कि state-sponsored hacker teams पहले से ही Google, Microsoft, Amazon जैसी जगहों की internal infrastructure को गहराई से study और analyze कर रही होंगी। यह breach दिखाता है कि वे पहले से कितना अच्छा समझती हैं
    मुझे लगता है कि अब broader security boundary के अंदर decentralize करने का समय आ गया है

    • अगर संगठन का आकार काफी बड़ा है, तो यह मानकर चलना चाहिए कि state actors अंदर से काम कर रहे हैं। दुर्भाग्य से कोई भी, कभी भी breach हो सकता है, इसलिए इस assumption से बचना मुश्किल है

  • सावधानी भरी भाषा हटाएँ तो, किसी ने production environment से minidump को development workstation पर download किया, और वह शायद उस developer के corporate OneDrive में कहीं पड़ा सड़ता रहा, फिर account compromise हो गया। किसी ने dump उठा लिया, key ढूँढ ली और jackpot मार लिया

    • इस attack के वास्तव में इतना सफल होने में निर्णायक बात यह थी कि Microsoft developers अपनी ही libraries और infrastructure पर secure authentication checks implement नहीं कर पाए
    • और एक scrubbing/masking system था जो key को छिपा नहीं पाया, और detection system भी था जो उस key को ढूँढ नहीं पाया। उसके बाद key पूरी तरह अलग access level वाले, पूरी तरह अलग system में इस्तेमाल हुई, फिर भी काम कर गई
      “कुछ अस्पष्ट bugs का sophisticated exploitation हुआ” कहना थोड़ा गलत लगता है। यह ज़्यादा ऐसे mistakes की chain drama जैसा दिखता है जिसमें कोई भी security system अपना काम नहीं कर पाया

  • समझ नहीं आता कि HSM क्यों नहीं इस्तेमाल किया गया। ऐसे hardware का मुख्य उद्देश्य key material exfiltration को रोकना ही तो है

    • ये कंपनियाँ [1] दावा करती हैं कि यह “दुनिया का सबसे तेज़ payment HSM है, जो प्रति सेकंड 20,000 से ज़्यादा transactions handle कर सकता है।” Microsoft account authentication token signing का peak load शायद उससे कहीं ज़्यादा होगा
      [1] https://www.futurex.com/download/excrypt-ssp-enterprise-v-2-...
    • जिस तरह से explanation लिखा गया है, उससे मुझे लगा था कि उन्हें जो crash logs मिले वे HSM से आए थे

  • इसका मतलब है कि key किसी non-extractable hardware में stored नहीं थी, बल्कि high-privilege environment में चल रहे सामान्य server process, यानी बस compiled code, उसे access कर सकता था
    यह भी नहीं कहा गया कि जिस system को इस key की access थी वह सामान्य production environment से अलग किसी environment में था। इसलिए माना जा सकता है कि कोई भी production machine key access कर सकती थी, और उस environment तक access रखने वाला कोई भी व्यक्ति संभावित रूप से key material exfiltrate कर सकता था

  • https://learn.microsoft.com/en-us/azure/active-directory/dev... के validation section को देखें तो, अगर मैं कुछ miss नहीं कर रहा हूँ, issuer की date या revocation status check करने की अहमियत अभी भी गायब लगती है
    pseudocode में भी यह नहीं है, इसलिए संभव है कि और भी implementations हों जो Microsoft द्वारा कभी भी publish की गई किसी भी key पर trust करती हों। cache deletion जैसी exceptions को छोड़ दें तो यही मतलब है

    • यही सबसे ज़्यादा चिंता वाली बात है। Microsoft developers अपनी ही libraries और infrastructure पर secure authentication checks implement नहीं कर पाए
      अगर Microsoft भी अपने flagship product Outlook में अपनी ही identity platform को सही से इस्तेमाल नहीं कर सकता, तो बाकी लोगों के लिए क्या संभावना बचती है
    • यही असली मुद्दा है। सब crash dump और leak की बात कर रहे हैं, लेकिन core यह है कि Microsoft ने न तो key की validity verify की, न key के usage context को verify किया। leaked key पहले ही invalid थी, और वह key admin tokens बनाने के लिए allowed key भी नहीं थी
      उन्होंने बस इतना check किया कि क्या Microsoft CA ने sign किया है। code review में यह भरोसा न होने लायक साफ़ दिखने वाली problem है

  • सच में बड़ा नुकसान होने की एक वजह शायद यह थी कि key को rotate नहीं किया गया। key के उस जगह पहुँचने के समय, जहाँ उसे नहीं होना चाहिए था, और उसके वास्तव में चोरी होने के समय के बीच काफी समय बीता लगता है
    अगर key को अक्सर rotate किया गया होता, तो उस key से tokens forge करना असंभव होता

  • ऐसी पोस्ट जब भी आती है, मुझे लगता है कि हमला सिर्फ़ physical नहीं बल्कि digital है, इसी वजह से nation-state level attack से निपटने की ज़िम्मेदारी private companies पर डाल देने वाला ढांचा सचमुच अजीब लगता है
    अगर चीनी लड़ाकू विमान ने Pacific के ऊपर FedEx के विमान को मार गिराया होता, तो इसे अमेरिकी संप्रभुता पर हमला माना जाता और सरकार उचित जवाब देती। FedEx से यह उम्मीद भी नहीं की जाती कि वह अपने cargo विमान की सुरक्षा के लिए खुद fighter jets का squadron रखे। कोई यह भी नहीं कहता कि “FedEx की गलती है कि उसने air defense ठीक से नहीं किया”
    लेकिन digital domain में आते ही माहौल ऐसा हो जाता है कि Microsoft को चीन और रूस के खिलाफ़ खुद अपना बचाव करना चाहिए

    • अगर चीनी लोगों के एक समूह ने किसी अमेरिकी बैंक, जैसे Federal Reserve, में सेंध लगाकर भारी financial नुकसान पहुंचाया होता, लेकिन कोई मौत नहीं हुई होती, तो प्रतिक्रिया भी मिलती-जुलती होती। अगर असली चीनी सरकार से संबंध होने का शक हो, लेकिन उसे पक्के तौर पर साबित करना मुश्किल हो, तो यह और भी सच होता
      सरकारें विदेशी agents को काफ़ी नियमित रूप से पकड़ती हैं, लेकिन ऐसी गिरफ्तारियां full-scale war में नहीं बदलतीं
    • FedEx विमान वाले उदाहरण के उलट, इस मामले में infrastructure पर हमला या उसे नष्ट नहीं किया गया, और कोई जान-माल का नुकसान भी नहीं हुआ। बस अमेरिकी सरकारी अधिकारियों के emails पढ़े गए
      दूसरी बात, अमेरिका भी ऐसे काम हमेशा करता है, और सहयोगी देशों के साथ भी करता है, इसलिए इससे कड़ी कार्रवाई को justify करना मुश्किल है
    • Digital domain स्वाभाविक रूप से physical domain की तुलना में कम जोखिम वाला और defend करना ज़्यादा मुश्किल है। Cyber attacks का जवाब physical attacks की तरह न देना अच्छी बात है। अगर ऐसा होता, तो 10 साल से भी पहले मामला nuclear war तक escalate हो गया होता
      Cyber attacks का दायरा और मात्रा बहुत बड़ी है, लेकिन मेरी समझ है कि अमेरिका भी उसके बराबर पैमाने पर काफ़ी external attacks करता है
    • ऐसे कई उदाहरण हैं जहां किसी देश ने passenger plane को मार गिराया या जहाज को ज़ब्त किया, फिर भी उसे act of war नहीं माना गया
    • अमेरिका से Asia जा रहे एक civilian aircraft को, जिसमें अमेरिकी सांसद सवार थे, मार गिराया गया था, लेकिन असल में World War III नहीं हुआ: https://en.wikipedia.org/wiki/Korean_Air_Lines_Flight_007