हैक किए गए Microsoft टेस्ट अकाउंट को admin privileges दिए गए थे

 (arstechnica.com)
1 पॉइंट द्वारा GN⁺ 2024-01-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Microsoft में हुई सेंधमारी सिर्फ अकाउंट टेकओवर से अधिक गंभीर थी, क्योंकि MFA के बिना एक पुराना टेस्ट अकाउंट वरिष्ठ अधिकारियों तथा security और legal टीम के ईमेल तक पहुंच का रास्ता बन गया
  • रूस-समर्थित समूह Midnight Blizzard ने कमजोर credentials का password spraying के जरिए दुरुपयोग कर “legacy non-production test tenant account” में लॉगिन किया
  • हमलावरों ने compromised test tenant से OAuth app permissions का उपयोग कर Office 365 Exchange Online में full_access_as_app role हासिल किया
  • full_access_as_app देने के लिए admin privileges आवश्यक होते हैं, इसलिए आलोचना हुई कि टेस्ट अकाउंट production environment में जरूरत से ज्यादा privileges के साथ एक misconfiguration था
  • least privilege principle से हटकर बना यह टेस्ट अकाउंट और residential proxy-आधारित password spraying, पारंपरिक compromise indicators पर आधारित detection को कठिन बना देता है

टेस्ट अकाउंट से ईमेल एक्सेस तक

  • रूस-समर्थित हैकरों ने password spraying के जरिए कमजोर credentials का दुरुपयोग कर “legacy non-production test tenant account” में लॉगिन किया
  • यह टेस्ट अकाउंट multi-factor authentication से सुरक्षित नहीं था
  • इसके बाद Microsoft के वरिष्ठ अधिकारियों और security व legal टीम के कर्मचारियों के ईमेल अकाउंट्स तक पहुंचने की अनुमति हासिल कर ली गई
  • हमलावर समूह Midnight Blizzard ने OAuth authentication protocol का दुरुपयोग कर privileged ईमेल अकाउंट्स तक लगातार पहुंच बनाए रखी
    • compromised test tenant में एक malicious app बनाई गई
    • app को Microsoft Office 365 ईमेल सेवा के सभी ईमेल पतों तक पहुंचने की अनुमति दी गई
    • मौजूदा test OAuth application के जरिए Office 365 Exchange Online का full_access_as_app role दिया गया

admin privileges वाला legacy टेस्ट अकाउंट

  • Microsoft के अपडेट में यह शामिल था कि “legacy test OAuth application” के पास Microsoft corporate environment में elevated access था
  • Kevin Beaumont के अनुसार, किसी OAuth app को full_access_as_app role देने के लिए अकाउंट के पास admin privileges होने चाहिए
  • Beaumont ने इस configuration को “production में काफी बड़ी configuration error” बताया
  • आलोचना हुई कि इतने पुराने legacy टेस्ट अकाउंट को इतनी व्यापक permissions देना और बनाए रखना क्यों उचित समझा गया
  • Microsoft ने यह बताने से इनकार किया कि टेस्ट अकाउंट को शुरू से इस तरह क्यों configure किया गया था, और legacy बन जाने के बाद भी इसे क्यों बनाए रखा गया

least privilege principle से बाहर की configuration

  • यह configuration least privilege principle का उल्लंघन करती है, जिसके अनुसार किसी अकाउंट के पास केवल वही न्यूनतम permissions होनी चाहिए जो उसके काम के लिए आवश्यक हों
  • मुख्य समस्या यह है कि यह समझना कठिन है कि किसी legacy टेस्ट अकाउंट को admin privileges की जरूरत क्यों होनी चाहिए
  • Beaumont ने इसकी तुलना ऐसी स्थिति से की, जैसे बिना security, MFA, firewall और monitoring वाले test domain में production system का Domain Admin user रखा गया हो
    • Domain Admin user के पास domain controller और Active Directory सहित network से जुड़े डिवाइसों पर पूर्ण admin privileges होते हैं
    • यह network का सबसे शक्तिशाली अकाउंट होता है, इसलिए इसे अलग-थलग रखा जाना चाहिए और production system में इसका शामिल होना बहुत दुर्लभ होना चाहिए
    • मजबूत password और मानक security controls के बिना ऐसे अकाउंट को छोड़ देने पर नुकसान बहुत बड़ा हो सकता है

अन्य संगठनों में सेंध और stealthy password spraying

  • Microsoft ने पाया कि Midnight Blizzard ने अन्य संगठनों में भी अतिरिक्त घुसपैठ की है, और प्रभावित संगठनों को सूचित किया
  • Hewlett-Packard Enterprises ने भी बताया कि उसके नेटवर्क को Midnight Blizzard ने हैक किया था
    • यह breach मई में हुआ था
    • इसका पता लगाकर इसे रोकने का काम दिसंबर तक नहीं हो पाया
  • टेस्ट अकाउंट तक पहुंच के लिए इस्तेमाल किया गया password spraying सीमित संख्या के अकाउंट्स पर, प्रति अकाउंट बहुत कम प्रयासों के साथ किया गया
  • हमलावरों ने वितरित residential proxy infrastructure का उपयोग कर अपनी malicious activity को कम दिखाई देने वाला बनाया
    • उन्होंने अच्छी reputation वाले IP addresses से एक्सेस किया
    • उन्होंने अपेक्षित क्षेत्रों में स्थित IP addresses का उपयोग किया
    • इससे ट्रैफिक वैध user traffic में घुला-मिला दिखा

पारंपरिक compromise indicator detection की सीमाएं

  • residential proxy का यह उपयोग कोई नई तकनीक नहीं है; 2020 के SolarWinds supply chain attack में भी इसका इस्तेमाल हुआ था
  • SolarWinds attack को भी Midnight Blizzard से जोड़ा गया है
  • residential proxies बहुत बड़ी संख्या में वैध user IPs के जरिए traffic route करते हैं, इसलिए पारंपरिक compromise indicator-based detection व्यवहारिक रूप से बहुत कठिन हो जाती है
  • Midnight Blizzard वह समूह है जिसके बारे में अमेरिकी और ब्रिटिश सरकारों ने कहा है कि वह रूस की विदेशी खुफिया एजेंसी SVR के लिए काम करता है
  • इसी समूह को ट्रैक करने के लिए APT29, the Dukes, Cloaked Ursa, UNC2452, Dark Halo जैसे नाम भी उपयोग किए जाते हैं

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

1 टिप्पणियां

 
GN⁺ 2024-01-29
Hacker News की टिप्पणियाँ

  • मुझे पहले सुना हुआ पुराना Roblox hack याद आ गया। एक non-production staging site था जहाँ users sign up कर सकते थे, और उस पर “यहाँ मौजूद चीज़ें स्थायी नहीं हैं” वाला banner लगा था
    production environment में एक नया admin account जोड़ा गया, और किसी ने staging site पर उसी username से sign up करके उसके cookies और tokens का इस्तेमाल किया, production account takeover कर लिया और site को compromise कर दिया
    अगर username या user ID के आधार पर encrypted tokens बनाए जाते हैं लेकिन production/staging के लिए अलग secrets नहीं इस्तेमाल होते, या staging site external services से बात करते हुए production authorization के साथ mix हो जाती है, तो ऐसी समस्या बहुत दुर्लभ नहीं लगती

    • मैंने पहले e-commerce के लिए shipping API implement किया था, जो DHL जैसी कंपनियों से integrate था। production server पर switch करना भूल गया, इसलिए कई महीनों तक test API से निकले labels से shipments भेजते रहे; सामान deliver हो गया और billing नहीं हुई
      पता चलते ही तुरंत ईमानदारी से बता दिया
    • इसलिए token में audience field होता है

  • बड़ी कंपनियों में development/production की boundary लोगों की कल्पना से कहीं ज्यादा छेदों वाली होती है
    एक typical दिन सोचिए: PC में login करते हैं, email check करते हैं, फिर उन्हीं credentials से Azure portal में login करते हैं। अंत में सब एक ही tenant से जुड़ा होता है, और account GitHub और cloud accounts से भी connected होता है
    Groups और Teams इधर-उधर बनते रहते हैं, और संदिग्ध permissions के साथ Teams या OneDrive इस्तेमाल करने के लिए बने objects company directory में security groups से लगभग अलग न दिखते हुए पड़े रहते हैं
    कभी-कभी “क्या आपको अभी भी इसकी जरूरत है?” वाला automated email आता है, लेकिन message अस्पष्ट होता है, और बहुत बड़ी company में पूछने के लिए सही व्यक्ति भी नहीं मिलता। helpdesk दो दिन बाद जवाब देता है, और Twitter पर John Savill से पूछ भी नहीं सकते, तो बस confirm दबाकर आगे बढ़ जाते हैं
    आखिरकार organization का fabric फटने लगता है, और attacker किसी कमजोर जगह से किस्मत से अंदर आकर tenant के भीतर lateral movement करता है और जो चाहिए वह ले जाता है
    जैसा एक समझदार CISO ने कहा था, hackers break in नहीं करते, login करते हैं

    • यहाँ “typical” वाली assumption काफी bold है, यह दिलचस्प है
      जाहिर है, मानो सब Microsoft cloud, Skype, Twitter, OneDrive जैसी चीजें इस्तेमाल कर रहे हैं, और उसे credible बनाने के लिए किसी व्यक्ति का नाम भी डाल दिया गया है

  • Kevin Beaumont की इस बात पर कि “admin privileges वाला account ही OAuth app को लगभग full control वाला full_access_as_app role दे सकता है। production environment में किसी ने काफी बड़ा configuration mistake किया,” system details जाने बिना देखें तो यह मुख्य समस्या नहीं लगती
    ऐसी गलती करने का तरीका ही नहीं होना चाहिए। इसे design करने वालों और operate करने वालों को इसे impossible बनाना चाहिए था, और जिम्मेदारी भी वहीं है
    अगर कोई factory बनाई और चलाई जाए जिसमें अंदर के सभी लोगों को electric shock देने वाला button हो, और किसी ने गलती से वह button दबा दिया, तो समस्या कहाँ है यह साफ है

    • यह बहुत संभव है कि यह technical problem नहीं है। इसे technical रूप से रोकने के लिए करीब 20 best practices और safeguards रहे होंगे, लेकिन ऐसे guardrails तभी मायने रखते हैं जब organization, leadership और bureaucracy उनकी परवाह करें
      कई वर्षों तक मुझे policies, procedures, regulations और laws सबको ignore करके ऐसे VIP को super admin/root privileges देने की मांग कई बार मिली, जिन्हें उन permissions की बिल्कुल जरूरत नहीं थी
      आजकल हर काम cross-assignment, part-time, dual role, triple role जैसा हो गया है, इसलिए हालात और खराब हैं
      मैंने role-based access control भी देखा है जहाँ assign की जा सकने वाली actual permissions से ज्यादा roles थे। तब RBAC का मकसद अपने-आप ढह जाता है। permissions individually assign करना तेज था, लेकिन इसकी अनुमति नहीं थी क्योंकि report में role नहीं दिखता
      ऐसी चीजें technical staff से नहीं, bad leadership से आती हैं
      पहले मैंने internal ERP के RBAC permission system में इस समस्या को कम करने के लिए एक extension design किया था। “permission exception” नाम की type रखी, ताकि जिन्हें role के बाहर permissions चाहिए हों उन्हें उसी तरीके से assign किया जाए और job role से बाहर काम कर सकने वाले लोगों की list report में बनाई जा सके
      अंत में यह permission में बस एक flag जोड़ने जैसा था, लेकिन अच्छी तरह काम किया। HR हर quarter permission exceptions check करके हटाने पर review करता था, और part-time helpdesk trial-and-error से permissions खोलने के बजाय सच में जानने वाला authorized व्यक्ति control रख सकता था
    • मैं जानना चाहूँगा कि configuration mistake को impossible कैसे बनाया जाएगा

  • quantifiable risk के आधार पर companies और industries को protect करने का दावा करने वाली शानदार security certifications ढेरों हैं, लेकिन Amazon पर 36 डॉलर की book में लिखी rational और thoughtful best practices को पूरी तरह ignore कर दिया जाता है, यह मजेदार है
    security किसी ribbon campaign जैसी दिखती है

    • security एक process है, product नहीं
      जो security को product की तरह बेचता है, वह scam कर रहा है
    • मेरे पास security certification हो सकती है, लेकिन बाकी 1,000 employees के पास नहीं हो सकती
      सामान्य employees को security में लगभग कोई दिलचस्पी नहीं होती और वे बस अपना काम करते हैं
      servers, applications और configurations इतने ज्यादा हैं कि केवल security-aware employees सबका review करने के लिए पर्याप्त नहीं होते
      लंबे समय तक देखें तो किसी भी company में कभी न कभी कुछ ऐसा खुला रह जाएगा जो खुला नहीं होना चाहिए। hacker groups का काम ही लगातार gaps ढूँढना है
      company को operations के दौरान नए servers और नई configurations लगातार बनानी पड़ती हैं, इसलिए यह once-set-and-done problem नहीं है
    • कौन-सी book है, जानना चाहूँगा

  • नए workplace में जब कोई “यह ज्यादा आसान है” कहकर बहुत सारी permissions दे देता है, तो मुझे सच में नापसंद है। ऐसा नहीं करना चाहिए
    इससे company breach के लिए expose होती ही है, साथ ही मुझ पर unwanted responsibility भी आ जाती है। मैं गलती से कोई important चीज बिगाड़ सकता हूँ, और अगर कुछ hack हो जाए तो लोग शक कर सकते हैं क्योंकि मेरे पास वे permissions थीं

    • हर employee के लिए कई services के accounts और permissions manage करने की मात्रा सोचें तो यह flow natural evolution जैसा भी लगता है
      असल में service level पर हम Windows XP security popup जैसी चीज का सामना कर रहे हैं। काम के हर step पर किसी और चीज के लिए authenticate करने को कहा जाता है, और सही permissions वाले सही credentials मिलने में कई दिन लग सकते हैं
      support team हार मानकर नए joiners को accounts और permissions एक साथ थमा दे, यह मानवीय स्तर पर समझ आता है

  • इस लेख में जो हिस्सा छूट गया है, वह यह है कि अगर किसी non-production account के पास production domain admin अधिकार हैं, तो लेखक “production” को कैसे define कर रहे हैं

    • मेरे हिसाब से यही मुख्य बात है। लेख और उद्धरण इसे “गलती” कहते हैं, लेकिन Microsoft जैसे बड़े और जटिल संगठन में गलत permissions assignment को अपरिहार्य मानता/मानती हूँ
      इसलिए “2.2 लाख लोगों वाली कंपनी में किसी समय किसी ने गलती की” वाले angle पर ध्यान देना खास मददगार नहीं है
      लेकिन ज़्यादातर कंपनियों में production systems और test systems के बीच आम तौर पर एक मजबूत और मोटी रेखा होती है। test account को production access देना व्यावहारिक रूप से असंभव होना चाहिए, इसलिए जांच का focus इस बात पर होना चाहिए कि ऐसा कैसे हुआ

  • इससे भी खराब मामले देखे हैं। एक law firm में काम किया था, जहां administrators और partners को हर चीज़ पर administrator access दिया गया था
    password reset के बाद default password “passme” था, क्योंकि मूल password बहुत लंबा था और याद रखना मुश्किल था। server में login करने के बाद password बदलना होता था
    एक hacker ने उनके कुछ accounts हथिया लिए, इधर-उधर छेड़छाड़ की और data चुरा लिया। कुछ test accounts के पास भी administrator अधिकार थे
    अच्छा है कि अब वहां काम नहीं करता/करती। मैं programmer analyst था/थी और Visual BASIC 6.0 चलाने के लिए मेरे पास सिर्फ अपने PC के admin अधिकार थे

  • यह pattern Microsoft ecosystem में अपवाद से ज़्यादा नियम जैसा है, लेकिन Microsoft खुद ऐसा कर रहा था, यह खास तौर पर शर्मनाक है
    Microsoft security team ने ऐसे बड़े incidents रोकने के tools और best practices documents पर काफी मेहनत की है

    • जिज्ञासा है कि शुरुआती test account कैसे compromise हुआ। शायद multi-factor authentication नहीं था और OAuth ROPC flow के जरिए password spraying के बाद lateral movement हुआ होगा
      M365 में multi-factor authentication enforcement काफी खराब है। यह पैसे देकर लेने वाला ढांचा है
    • ऐसी चीज़ें हर जगह होती हैं। जिन कई लोगों के साथ मैंने काम किया, उनकी testing का तरीका लगभग हमेशा maximum privileges देने वाला था। पता नहीं, लेकिन यह shotgun debugging जैसा लगता है
      बड़ी समस्या यह है कि लोग भूल जाते हैं। admin अधिकारों वाले पांच test accounts बना देते हैं, और जब तक कोई company-wide user permissions audit नहीं करता, तब तक यह सामने नहीं आता

  • जिस कंपनी में पहले काम किया था, उसने production servers और databases के सभी passwords code repository की text file में रखे हुए थे। वजह यह थी कि chief architect passwords याद नहीं रखना चाहता था
    CTO को बताया कि यह कितना बेवकूफी भरा है, तो जवाब मिला “हम अपने कर्मचारियों पर भरोसा करते हैं”, “हम security audit पास कर चुके हैं”
    अभी भी facepalm का असर बाकी है

    • मुझे भी database passwords पसंद नहीं हैं। वे बहुत जल्दी crack हो जाते हैं
      वे बस चिढ़ाने वाली चीज़ हैं, security feature नहीं। “c00lz500” जैसे passwords नहीं इस्तेमाल करता/करती, बल्कि बिल्कुल empty string जैसा कुछ इस्तेमाल करता/करती हूँ
      इसके बजाय firewall और internal network का इस्तेमाल करता/करती हूँ