चेतावनी: Microsoft द्वारा प्रमाणित सब कुछ दूषित हो चुका है

 (graz.social)
1 पॉइंट द्वारा GN⁺ 2023-09-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Karl Voit का मानना है कि Microsoft Azure क्लाउड व्यावहारिक रूप से हैक हो चुका है, और अपर्याप्त isolation उपायों के कारण बाद की घटनाएँ सार्वजनिक होने लगी हैं
  • सार्वजनिक उदाहरण के रूप में वे Reuters की उस रिपोर्ट का हवाला देते हैं जिसमें अमेरिकी विदेश विभाग के 10 खातों से 60,000 ईमेल चोरी होने की बात कही गई है
  • मुख्य चिंता यह है कि Microsoft या तो घुसपैठियों को हटा नहीं पाया है, या हटा नहीं रहा है, इसलिए Microsoft-प्रमाणन आधारित पूरे सिस्टम पर भरोसा करना मुश्किल है
  • दूषण के दायरे में Windows authentication भी शामिल है, और यदि हैक किए गए Azure certificate तथा GitHub के बीच आंतरिक trust relationship है, तो GitHub भी प्रभावित माना जाएगा
  • यह चिंता GitHub पर भारी निर्भरता वाले NixOS उपयोग परिवेश तक फैलती है, और क्लाउड में उपयोगकर्ता अपने डेटा को स्वयं नियंत्रित करना कठिन पाते हैं

Azure हैक और isolation विफलता की आशंका

  • Karl Voit ने Microsoft Azure क्लाउड को समग्र रूप से व्यावहारिक रूप से हैक हो चुका बताया है
  • उन्होंने कहा कि संबंधित स्रोतों की सूची अपनी पोस्ट You Can't Control Your Data in the Cloud में संकलित की है
  • समस्या का मूल बिंदु हैकिंग से अधिक यह है कि उसके बाद isolation उपाय पर्याप्त नहीं थे, और इसलिए बाद की घटनाएँ सामने आने लगीं

अमेरिकी विदेश विभाग ईमेल चोरी का मामला

  • बाद की घटना के उदाहरण के रूप में उन्होंने Reuters की उस रिपोर्ट को पेश किया जिसमें अमेरिकी विदेश विभाग के 10 खातों से 60,000 ईमेल चोरी होने की बात है
  • लिंक की गई Reuters रिपोर्ट में कहा गया है कि चीनी हैकरों ने Microsoft हैक के जरिए अमेरिकी विदेश विभाग के 60,000 ईमेल चुरा लिए
  • इस मामले को Microsoft हैक के बाद वास्तविक नुकसान जारी रहने के प्रमाण के रूप में जोड़ा गया है

Microsoft authentication प्रणाली पर अविश्वास

  • Voit का मानना है कि Microsoft या तो घुसपैठियों को हटा नहीं पाया है, या हटाना नहीं चाहता
  • इसके परिणामस्वरूप वे मानते हैं कि Microsoft द्वारा प्रमाणित हर चीज tainted, यानी दूषित, स्थिति में है
  • वे स्पष्ट रूप से कहते हैं कि इस दूषण के दायरे में Windows authentication भी शामिल है

GitHub और NixOS तक पहुँचती चिंता

  • बाद की पोस्ट में उन्होंने कहा कि यदि हैक किए गए Azure certificate और GitHub के बीच Microsoft की आंतरिक trust relationship है, तो GitHub को भी हैक या दूषित माना जाना चाहिए
  • कुछ होस्ट को NixOS पर ले जाने के बाद भी Microsoft और GitHub से जुड़े मुद्दों के कारण असुरक्षा बनी हुई है
  • वे मानते हैं कि अपनी NixOS अनुभव पोस्ट I Started With Nix, NixOS, Home Manager and Flakes में उल्लेखित गहरी GitHub निर्भरता इस OS की एक बड़ी कमी के रूप में सामने आई है

क्लाउड डेटा नियंत्रण की समस्या

  • लिंक की गई पोस्ट You Can't Control Your Data in the Cloud Azure और Microsoft authentication समस्या को क्लाउड डेटा नियंत्रण के मुद्दे तक विस्तारित करती है
  • Mastodon पोस्ट की चेतावनी इस बात पर केंद्रित है कि Microsoft authentication और आंतरिक trust relationship पर निर्भर पूरे सिस्टम पर भरोसा करना कठिन है

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

1 टिप्पणियां

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

  • Microsoft के incident blog post में mitigation और hardening sections देखें, तो 26 जून को OWA ने GetAccessTokensForResource से जारी tokens का renewal लेना बंद किया, 27 जून को OWA में चोरी हुई MSA key से signed tokens के उपयोग को block किया गया, और 29 जून को key rotation और उस समय valid MSA signing keys को revoke करना पूरा किया गया बताया गया है।
    3 जुलाई को कहा गया है कि पहले से जारी tokens के दुरुपयोग को रोकने के लिए प्रभावित सभी consumer customers के लिए उस key का उपयोग block कर दिया गया।
    मैं security expert नहीं हूं, लेकिन इस strategy में छेद क्या है, यह जानना चाहता हूं।

    • समस्या यह है कि उस बीच attacker ने चोरी हुई key से क्या किया, इसे verify करने का कोई तरीका नहीं है।
      अगर immutable permanent audit logs हों, तो leaked key द्वारा सीधे या indirectly signed authentication से किए गए सभी actions को track किया जा सकता है, लेकिन ऐसा audit log बनाना जिसे highest privileges वाला व्यक्ति भी manipulate न कर सके, न आसान है न सस्ता।
      सबसे खराब स्थिति में audit log में सिर्फ authenticated identity हो और authentication method न हो, जिससे potentially compromised access को आसानी से identify न किया जा सके।
      अंततः इस strategy का छेद यह है कि leaked key से access possible रहने के दौरान जोड़े गए persistence backdoors को यह ध्यान में नहीं रखती। आगे के abuse को तो रोकती है, लेकिन key जिस तरह चोरी हुई, उसे देखते हुए अगर attacker बहुत sophisticated था, तो उसने कितने secondary access paths बना रखे हैं, यह पता लगाना लगभग असंभव है।
    • बड़ी समस्या यह है कि attacker के पास वे credentials रहने की अवधि में उसने कौन से दूसरे छेद या backdoors डाले, यह जानने का कोई तरीका नहीं है। हो सकता है उसने नई key भी तुरंत हासिल कर पाने की व्यवस्था कर दी हो।
    • ये items तो “key compromised है और अभी भी इस्तेमाल हो रही है” या “सब कुछ दूषित हो गया है” जैसे title से उलटे टकराते दिखते हैं।

  • यह समस्या Azure और Microsoft तक सीमित लगती है, और AWS व GCP ठीक हैं, ऐसा मुझे लगता है।
    Microsoft के पास अब तक देखी गई सबसे खराब स्तर की security vulnerabilities और practices हैं। Fortune 500 की बड़ी कंपनियों के executives workloads को Azure पर कैसे move करते हैं, यह मेरी समझ से बाहर है।
    कुछ areas में Azure का एकमात्र selling point बस यह है कि Amazon competitor है। अच्छा होगा अगर Amazon AWS को बस independent रहने दे।
    उम्मीद है Microsoft security को improve करेगा, लेकिन अब तक तो यह लगभग hopeless लगता है।

    • Microsoft Active Directory और Office 365 के जरिए non-technical companies को खींचता है, फिर सभी services के साथ अच्छे integration का वादा करके उन्हें रोके रखता है।
      एक बार companies Azure dashboard के अंदर आ जाती हैं, तो वहां उपलब्ध दिखने में शानदार services को भी एक बार try करने लगती हैं।
      सब smoke and mirrors जैसा है, लेकिन असर करता है।
    • लगभग हर organization का पहले से Windows, AD, Office, Teams, Exchange आदि को लेकर Microsoft के साथ बड़ा contract होता है, और वह core IT में गहराई से integrated होता है।
      इसलिए अगर organization ने पहले से AWS को vendor के रूप में register नहीं किया है, तो आम तौर पर existing vendor को आगे बढ़ाना आसान होता है।
    • CTO और system administrators भी दोषी हैं। या तो वे familiar होने के कारण उसी stack में lock-in हैं, या CTO ने “Gartner upper-right quadrant option चुनने पर कोई fired नहीं होता” जैसे logic से मजबूर किया।
    • 1996–1997 में US military federal contractor के रूप में काम करते समय, बेहतर security के कारण Windows web servers को Macintosh servers से replace किया था।
      मैंने भी Windows 2000 Pro web server चलाया था, फिर security की कमी के कारण Linux पर switch कर दिया।
      Microsoft popular हो सकता है, लेकिन security में बड़े holes हैं और हमेशा से रहे हैं।
    • “यह समस्या” के बारे में बात सही है।
      Services cloud में हों या customer-managed, अक्सर compromised होती हैं। Microsoft के पास mature, professional और effective security team है।
      Implementation flaw और, मेरी निजी अटकल के अनुसार, एक या अधिक corrupt insiders के कारण breach हुआ।
      अधिकांश organizations को शायद पता भी नहीं चलता कि आखिर हुआ क्या, और public की गई बातों को भी वे identify नहीं कर पाते।
      hindsight में सब आसान लगता है।

  • यह बहुत बढ़ा-चढ़ाकर कही गई बात है। यह निश्चित रूप से एक खराब breach था और हो सकता है कि इसका scope अभी पूरी तरह समझ में न आया हो, लेकिन “हर जगह backdoor और खुद बनाए गए keys लगा सकते थे” में मुख्य बात कर सकते थे है, यानी “मेरी जानकारी में, यह सैद्धांतिक रूप से संभव है”; इसका मतलब यह नहीं कि उन्होंने सच में ऐसा किया
    “Microsoft की हर चीज़ hack हो गई है और वे intruder को हटा नहीं सकते या हटाते नहीं। Microsoft ने जिस भी चीज़ को certify किया है सब contaminated है, Windows certification तक” वाला निष्कर्ष भी बहुत तीखा है
    Microsoft की प्रतिक्रिया साफ़ तौर पर यह कहती दिखती है कि keys बदल दिए गए और उन्हें ज़्यादा सुरक्षित storage में shift किया गया। वे यह नहीं कहते कि attacker को हटा दिया गया है, लेकिन यह भी नहीं कहते कि attack अभी जारी है। इसका मतलब यह भी नहीं कि सारी authentication हमेशा के लिए खराब हो गई है
    निकाला गया निष्कर्ष मुझे चरम लगता है
    https://msrc.microsoft.com/blog/2023/09/results-of-major-tec...

    • आपने Microsoft की exploit investigation report link की है, जिसमें attacker ने पहले Microsoft development network तक access हासिल किया, crash dump पाया, उसका मतलब समझा और खंगालकर private key ढूंढी, फिर Microsoft authentication system को इतना समझ लिया कि उस key को उसके मूल उद्देश्य से आगे कैसे इस्तेमाल किया जा सकता है, और इसे अंजाम दिया
      फिर भी क्या यह माना जाए कि उन्होंने high-profile targets पर persistent backdoor नहीं छोड़ा?
      यहां निकाला गया निष्कर्ष पूरी तरह वाजिब है। आम public cloud customers के लिए शायद यह दावा कुछ हद तक समझ में आ सकता है, क्योंकि indiscriminate backdoor से discovery का risk ही बढ़ता है
      लेकिन बड़े enterprise और government users को breach मानकर चलना चाहिए; वरना यह अविश्वसनीय रूप से भोला रवैया होगा
      संदर्भ:
      https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...
      Microsoft भी लिखता है कि Storm-0558 के पास उच्च स्तर की technical tradecraft और operational security है, और वह target environments, log policies, authentication requirements, policies और procedures को अच्छी तरह जानता है
    • security के नजरिए से, संभावित impact और संभव scenarios को देखते हुए इसे सिर्फ “संभव” नहीं माना जा सकता; इसे वास्तविक मानकर चलना चाहिए
      zero-day vulnerability मिलने पर हम यह कहकर patch ignore नहीं करते कि “शायद किसी और के पास नहीं होगी”
    • मुझे लगता है Microsoft को planted binaries और गलत configurations हटाने के लिए जरूरी सभी resources और federal agencies की मदद तक मिल जाएगी

  • इस घटना की coverage बहुत कम हुई, और संभावित impact बहुत बड़ा हो सकता है। Microsoft से शिकायत यह है: key 2021 में leak हुई थी और 2023 में भी authentication tokens sign कर रही थी, जबकि Azure services में ऐसी कोई चीज़ नहीं जहां user 2 साल की credentials डाल सके
    यह क्लासिक “जो मैं कहूं वह करो, जो मैं करता हूं वह नहीं” वाला मामला है

    • कल्पना कीजिए कि अगर CA/Browser Forum को पता चलता कि किसी PKIX CA ने signing key का control खो दिया, फिर भी उसे revoke नहीं किया, किसी को बताया नहीं, और 2 साल तक उसका इस्तेमाल जारी रखा, तो वे क्या करते
    • अगर मेरी समझ सही है, तो उन्होंने HSM तक इस्तेमाल नहीं किया, और mitigation plan में भी HSM इस्तेमाल शामिल नहीं था। यह ठीक नहीं है
    • इस कहानी का सबसे खराब हिस्सा यह है कि वे keys असल में सही keys भी नहीं थे। वे किसी client को issue किए गए और scope-limited keys थे, लेकिन scope check टूटा हुआ था। कुल मिलाकर यह भरोसा न हो सके इतना खराब है
    • अब भी app registration secrets बनाए जा सकते हैं जो अधिकतम 2 साल तक चलते हैं। कुछ समय पहले तक तो व्यावहारिक रूप से अनिश्चितकालीन secrets भी बनाए जा सकते थे

  • यह कुछ ज़्यादा ही बढ़ा-चढ़ाकर और alarmist लगता है। मुझे नहीं लगता कि sources लेख में किए गए दावे—यानी “पूरे Microsoft” के compromise—को साबित करते हैं
    बल्कि यह एक अस्थायी key leak का मामला लगता है, जिसे बाद में revoke/retire कर दिया गया

    • लेख में दिए links को follow किया तो उसमें लिखा था कि जुलाई 2023 में hackers ने Microsoft Azure Active Directory certificate चुरा लिया था, और इससे Outlook, Office, SharePoint, Teams, “Login with Microsoft” आदि सहित practically सभी Microsoft cloud services तक full access मिल गया था
      नीचे भी है:
      https://infosec.exchange/@briankrebs/110820474957163710
      अगर सच है, तो यह काफी गंभीर है
      [1]: https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...
      [2]: https://www.wiz.io/blog/storm-0558-compromised-microsoft-key...
    • बेहतर link शायद लेख के अंदर जुड़ा यह page होता:
      https://karl-voit.at/cloud/
      लंबी list में यह भी लिखा है कि अगस्त 2023 में Azure में “cross-tenant applications और sensitive data तक unauthorized access, जिसमें authentication secrets भी शामिल” की समस्या थी, जिसे Microsoft कई महीनों तक ठीक नहीं कर पाया, और 2023-08-03 तक भी यह Azure की public vulnerability थी
      जुलाई 2023 की घटना में, basic logs से customer intruder को detect भी नहीं कर सकते थे, और उन log files तक access के लिए extra payment करना पड़ता था
      लिखा है कि Microsoft ने यह नहीं बताया कि कौन-सी services affected थीं और कौन-सी नहीं, और इसे ऐसे summarize किया गया कि सभी Microsoft cloud services को potentially compromised मानना चाहिए
      यह भी लिखा है कि Mike Kuketz जैसे security experts के मुताबिक cloud authentication इस्तेमाल करने वाले सभी Microsoft systems, यहां तक कि Windows hosts को भी compromised मानना चाहिए
    • कुछ services में Microsoft के पास भी data पर control नहीं होता। KV या MHSM जैसे cases हैं
      उसी link में Microsoft का लेख भी ऐसा कहता है:
      https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...
      “Post-compromise activity: हमारी telemetry और investigation के अनुसार, post-compromise activity targeted users के email access और exfiltration तक सीमित थी”
      इसलिए “पूरा Microsoft” नहीं। यह आम बढ़ा-चढ़ाकर लिखा गया title है, बस इस बार Mastodon post ने attention खींच लिया
      यह platform भी Twitter से बहुत अलग नहीं है

  • कुछ सालों में on-premises hardware और simple server hosting फिर से trend में आ जाएंगे, ऐसा लगता है

    • हाल के समय में internet और electronic devices का centralization और cloudification काफी ironic है
      जब सब कुछ local और private था, तब security अक्सर कमजोर होती थी, फिर भी attacker को सिर्फ किसी specific device या network तक ही access मिल पाता था
      अब centralized एक organization पर हमला करने का reward इतना बड़ा हो गया है कि attackers के लिए कहीं ज्यादा resources लगाना worthwhile हो जाता है
    • लेकिन cloud तो कहीं ज्यादा सुरक्षित है। भला Microsoft cloud पूरा कौन hack करेगा। अरे, एक मिनट…
    • असली बात “simple” होना है। कुछ apps को देखकर शुरू से ही सवाल था कि इन्हें cloud पर क्यों चढ़ाया गया
      हर एक-दो महीने में किसी बेवकूफी भरे नए environment version पर migrate करना पड़ता था, app mail नहीं भेज पा रहा था तो DNS entries से छेड़छाड़ करनी पड़ती थी, जरूरत न होते हुए भी cloud provider का घटिया IAM setup करना पड़ता था, और database access के लिए app register करना पड़ता था
      अब कुछ apps ऐसे हैं जिनमें सालाना maintenance 15 मिनट, installation और setup 5 मिनट में हो जाता है
      कुछ cloud providers के पास शानदार features हैं, लेकिन सब कुछ धीरे-धीरे bloated लगता जा रहा है, और मेरे use case के लिए पूरा cluster जरूरी नहीं है
    • यह शुरू हो चुका है। Europe के एक देश में systems design करते समय, municipalities और state government agencies ज्यादा on-premises configurations मांग रही हैं
      European cloud services ज्यादा बनाने के कई projects के बारे में भी सुना है
    • on-premises hardware trend में आ सकता है, लेकिन simple server hosting के साथ ऐसा होने की संभावना कम है
      अगर trend बना, तो शायद on-premises hardware के ऊपर containers या Kata Containers orchestrator लगाने के रूप में होगा
      और on-premises deployed software में भी बड़ी organizations को फिर भी single sign-on चाहिए होगा, इसलिए इस तरह के attacks के लिए exposure बना रह सकता है

  • यह वाकई गंभीर है। इस लेख की वजह से अब जाकर इसे ठीक से पढ़ रहा हूं, और समझ नहीं आता कि यह कैसे इतनी आसानी से radar के नीचे निकल गया
    मेरी company ने भी हाल ही में internal apps और services की authentication पूरी तरह Azure के जरिए consolidate की है। अब पीछे मुड़कर देखें तो यह गलती लगती है, हालांकि शायद मैं ज़्यादा ही overreact कर रहा हूं

    • समझ नहीं आता कि इसे इतना कम attention कैसे मिला
      इस घटना से कुछ समय पहले भी एक “incident” हुआ था जिसमें कोई भी कुछ Bing search results बदल सकता था, और शायद दूसरी services के साथ भी ऐसा कर सकता था
      नतीजतन browser द्वारा Bing के साथ share किए गए सारे data तक access मिल सकता था, जिसमें उस specific search के लिए Bing इस्तेमाल करने वाले users के सभी MS account access keys भी शामिल थे
      impact पता नहीं है, क्योंकि Microsoft ने disclose नहीं किया। क्यों नहीं किया, इसका अंदाजा हर कोई खुद लगा सकता है
    • यह postmortem कुछ हफ्ते पहले भी front page पर था। conspiracy theory तक जाने की जरूरत नहीं; यह बस सामान्य Big Tech की खराब operations है

  • लेख बेहतरीन और डरावना है, और ऐसा लगता है कि इसमें सिर्फ सही और सत्यापित की जा सकने वाली जानकारी है, लेकिन यह साफ़ नहीं कि हमें किस बात की उम्मीद करनी चाहिए
    “आम” लोग इसे न पढ़ेंगे, न समझेंगे, और न ही असर का अंदाज़ा लगा पाएंगे। चीज़ें बहुत जटिल हो गई हैं। समाज के स्तर पर जिन सेवाओं का ज़िक्र है, उन्हें बस इस्तेमाल करना बंद भी नहीं किया जा सकता
    शायद यह सिखाना ज़्यादा तार्किक होगा: privacy नहीं है, उसे guarantee नहीं किया जा सकता और किसी के पास उसे guarantee करने का incentive नहीं है; security नहीं है और सारी security या तो breach हो चुकी है, breach होने के लिए design की गई है, या आगे breach होगी; सारी digital information या तो पहले से public है या कभी न कभी public हो जाएगी

    • मैं इस बात से सहमत नहीं कि “आम” लोग समझ नहीं सकते
      “Microsoft ने ग्राहकों को अपने घर की चाबी से सबके office safes खोलने दिया, इसे 2 साल तक छिपाया, और अब भी इसे ठीक करने की कोई योजना नहीं है”—इसका मतलब समझने के लिए IT में 10 साल का experience ज़रूरी नहीं
      McNeally बस गलत थे। लेकिन निराश होना चीज़ें ठीक करने से आसान है, इसलिए बहुत लोगों ने निराशा चुनी, और cloud व SaaS की लोकप्रियता उसी का परिणाम है
      यह कोई तयशुदा किस्मत नहीं है; असल में बस उन लोगों पर भरोसा न करें जिन पर आप सच में भरोसा नहीं करते
    • वे तीनों बातें सिर्फ निराशा सिखाती हैं। ज़्यादा उपयोगी यह सिखाना है कि किसे जवाबदेह ठहराया जा सकता है, और असल privacy और security कैसे वापस पाई जाए
      भले ही इसके लिए डरावने regulation hammer का इस्तेमाल करना पड़े
    • यह ऐसा नज़रिया है जो पूरी transparency को आगे बढ़ाने वाले संगठनों—जैसे ad industry या national security पक्ष—या उनसे brainwash हुए लोगों से ही आ सकता है। अभी उस स्तर की निराशा तक जाने की ज़रूरत नहीं है
      लोगों के पास अब भी guaranteed privacy हो सकती है। उदाहरण के लिए, बिना device के जंगल में जाना
      दूसरों की privacy guarantee करने का incentive, failure पर punishment वाला legal mechanism हो सकता है
      absolute security नहीं होती, लेकिन किसी specific threat model के खिलाफ security होती है
      network से connect न किए गए device में रखे data का अनिवार्य रूप से public हो जाना भी समझ में नहीं आता
    • जब कोई समस्या सामने आती है, तो लोगों और कंपनियों से उसे ठीक करने की उम्मीद करना स्वाभाविक है
      “आम” लोग वाली अभिव्यक्ति को छोड़ भी दें, तो यह वजह नहीं दिखती कि हम जिन services का नाम तक नहीं लिया गया उनके बिना नहीं रह सकते, या ज़्यादा privacy-friendly विकल्पों पर switch नहीं कर सकते
      ज़्यादा तार्किक शिक्षा यह है कि privacy एक functioning society और economy के लिए ज़रूरी है। जो कोई इसके उलट कहता है, वह मानता है कि आपके और अपने बीच information asymmetry का इस्तेमाल करके short term में पैसा कमा सकता है
      Scott का सम्मान है, लेकिन वह बयान उनका अच्छा moment नहीं था। उसी वाक्य को “property नहीं है, उसे guarantee नहीं किया जा सकता, और किसी के पास उसे guarantee करने का incentive नहीं है” में बदल दें तो वह भी पूरी तरह सच जैसा लग सकता है, लेकिन असल में हमने property guarantee करने के तरीके बनाए हैं, और वे हैं law और enforcement government। privacy पर भी इस tested concept को लागू किया जा सकता है
      हर lock खोला जा सकता है, लेकिन हर कोई lockpick नहीं कर सकता, इसलिए हम अब भी दरवाज़े lock करते हैं
      यह भी संदेहास्पद है कि top consulting firms यह मानकर चलती हैं कि सारी digital information public हो जाती है। Mazzucato और Collington की “The Big Con” में आने वाली ऐसी firms यह premise बेच सकती हैं, लेकिन वे खुद उस तरह operate नहीं करतीं
      उदाहरण के लिए, अगर McKinsey को पता होता कि Purdue Pharma को दी गई उसकी advice public हो जाएगी, तो उसे इतना बड़ा नुकसान नहीं होता
      संक्षेप में, जो लोग कहते हैं कि privacy मायने नहीं रखती, वे असल में कह रहे होते हैं कि आपकी privacy मायने नहीं रखती, और वे अति-आत्मविश्वास में होते हैं कि information asymmetry में वे आगे रहकर खुद private बने रह सकते हैं। Google का public antitrust trial में अपनी जानकारी private रखने की कोशिश करना इसे ironic तरीके से दिखाता है
    • यह बहुत खराब सलाह है, और अगर कोई industry insider है तो यह self-serving advice भी हो सकती है। हमेशा की तरह nuance है। “सिर्फ Sith ही absolute बातें करते हैं” वाली बात है
      online privacy नहीं होती, और providers के पास users को बेच देने का incentive होता है। इसलिए खुद को बचाने के लिए सिर्फ shallow online presence रखें
      general user हैं तो खासकर social media पर जितनी कम हो सके उतनी जानकारी डालें। अगर online presence ज़रूरी है, तो risks assess करें और उन्हें mitigate करने में समय और पैसा लगाएं। अगर उस mitigation effort में अच्छा return on investment नहीं दिखता, तो संभव है कि आपको online presence की ज़रूरत है—यह बात आपको गलत तरीके से समझाई गई हो
      absolute security नहीं होती। हर defense को bypass किया जा सकता है, लेकिन ज़रूरी नहीं कि वह bypass हो ही। जितने हो सकें उतने risks assess करें, और सिर्फ उन्हीं को mitigate करें जिनमें positive return on investment की उम्मीद हो। जिन risks को mitigate नहीं करते उन्हें accept करें, और जिन risks को आप afford नहीं कर सकते उनके लिए system का इस्तेमाल करने से इनकार करके उन्हें अपने ऊपर लें ही नहीं
      कोई risk management न करने पर भी basic security level मौजूद रहता है, क्योंकि criminal tendency वाली आबादी का एक हिस्सा cost और reward की गणना करता है। अंदर की बातें जानने वाले cynical लोग जितना ज़्यादा कहते हैं कि security नहीं है, यह baseline उतना ही 0 के करीब जाता है, और आम जनता उतनी ही vulnerable हो जाती है
      baseline जितना कम होगा, व्यक्ति को सहने लायक safety level पाने के लिए खुद जितना समय और पैसा लगाना पड़ेगा, वह उतना ही बढ़ेगा। cynicism हमें कीमत चुकवाता है, इसलिए सिर्फ cool दिखने के लिए गांव की चक्की में पेशाब या गंदगी मत करो—बात यही है
      मौजूदा digital information या तो पहले से public है या कभी न कभी public हो सकती है। लेकिन आप ऐसी technology चुन सकते हैं जो उस समय को और दूर भविष्य में धकेल दे, और जो जानकारी अभी digitize नहीं हुई है, उसके लिए आप consciously तय कर सकते हैं कि सुविधा के लिए जोखिम उठाना वाकई worth it है या नहीं

  • “Mike Kuketz जैसे security expert का मानना है कि cloud authentication इस्तेमाल करने वाले सभी Microsoft systems, यहां तक कि Windows hosts को भी compromised मानना चाहिए” — यह बहुत बड़ा दावा है
    सैद्धांतिक रूप से संभव लगता है कि चोरी हुई signing key का इस्तेमाल Windows Update या Azure control plane जैसी core services तक पहुंच वाले किसी बड़े हमले के हिस्से के रूप में हुआ हो
    लेकिन अगर ऐसा systematic breach हुआ होता, तो लगता है किसी न किसी ने notice किया होता

    • चोरी हुई key को 2 साल तक illegally इस्तेमाल किए जाने की activity भी तो किसी ने notice की होगी… आह, सही

  • मुख्य लेख और ब्लॉग की तुलना में Microsoft का स्पष्टीकरण इसे कहीं बेहतर तरीके से दिखाता है: https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...
    साथ ही, यहां किए गए दावे के विपरीत, Microsoft ने समस्या का पता चलने के बाद उसे ठीक कर दिया: https://msrc.microsoft.com/blog/2023/09/results-of-major-tec...

    • बहुत देर हो चुकी थी। नुकसान पहले ही हो चुका था। जिसके पास भी वह key थी, वह सभी MS accounts और services तक access कर सकता था
      और वे लोग पहले ही engineer accounts hack कर चुके थे। सिर्फ एक engineer account hack करके संयोग से इस key को ढूंढ लेने की संभावना बहुत कम है, इसलिए यह मानना तर्कसंगत है कि कई Microsoft engineer accounts पहले ही hack हो चुके थे
      मूल रूप से MS accounts सुरक्षित नहीं हैं