1Password ने आंतरिक Okta अकाउंट में “संदिग्ध गतिविधि” का पता लगाया

 (arstechnica.com)
1 पॉइंट द्वारा GN⁺ 2023-10-25 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 1Password ने कर्मचारियों के ऐप एक्सेस को प्रबंधित करने वाले आंतरिक Okta instance में 29 सितंबर को संदिग्ध गतिविधि का पता लगाया, और उपयोगकर्ता डेटा या संवेदनशील सिस्टम में किसी घुसपैठ का पता नहीं चला
  • यह एक्सेस Okta के customer support management system breach से जुड़ा था, और हमलावर ग्राहक द्वारा अपलोड की गई HAR files से authentication cookies और session tokens हासिल कर सकते थे
  • 1Password की आंतरिक Notion रिपोर्ट में संक्षेप में बताया गया कि हमलावर ने IT कर्मचारी द्वारा Okta support के साथ काम करते समय बनाई गई HAR file हासिल की थी, जिसमें Okta ट्रैफ़िक और session cookies शामिल थे
  • हमलावर ने 1Password के Okta tenant में admin user report का अनुरोध किया और Google production environment authentication के लिए IDP को update और enable किया, लेकिन बाद में दोबारा इस्तेमाल की कोशिश IDP हटाए जाने के कारण विफल रही
  • Okta breach ऐसा follow-on attack मामला बन गया जिसमें vendor breach के बाद ग्राहक कंपनियों पर हमला हुआ, और 1Password ज्ञात रूप से निशाना बनाए गए Okta ग्राहकों में दूसरा बना

1Password ने आंतरिक Okta एक्सेस का पता लगाया

  • 1Password एक password manager है, जिसका इस्तेमाल लाखों उपयोगकर्ता और 1 लाख से अधिक कंपनियां करती हैं
  • कंपनी ने कर्मचारियों के ऐप प्रबंधन के लिए इस्तेमाल होने वाले Okta instance में 29 सितंबर को संदिग्ध गतिविधि की पुष्टि की
  • CTO Pedro Canahuati ने कहा कि संबंधित गतिविधि को तुरंत समाप्त कर उसकी जांच की गई, और उपयोगकर्ता डेटा या कर्मचारियों/उपयोगकर्ताओं के संवेदनशील सिस्टम में किसी घुसपैठ का पता नहीं चला
  • इसके बाद 1Password ने Okta के साथ मिलकर यह जांच की कि एक अज्ञात हमलावर ने अकाउंट तक पहुंच कैसे बनाई

Okta support system breach और HAR files का जोखिम

  • पुष्टि हुई कि 1Password की यह घटना Okta द्वारा सार्वजनिक किए गए customer support management system breach से शुरू हुई थी
  • Okta ने कहा कि एक threat actor ने customer support case management system में अनधिकृत पहुंच हासिल की और कुछ Okta ग्राहकों द्वारा अपलोड की गई files देखीं
  • हासिल की गई files में HAR files शामिल थीं, जिनका उपयोग Okta support कर्मी troubleshooting के दौरान ग्राहक के browser activity को पुन: तैयार करने के लिए करते हैं
  • HAR files में authentication cookies और session tokens जैसी संवेदनशील जानकारी संग्रहीत हो सकती है, जिनका दुरुपयोग कर हमलावर वैध उपयोगकर्ता का रूप धारण कर सकता है

BeyondTrust के बाद ज्ञात रूप से दूसरा निशाना

  • security company BeyondTrust ने तब घुसपैठ का पता लगाया जब हमलावर ने वैध authentication cookie के साथ उसके Okta अकाउंट तक पहुंचने की कोशिश की
  • BeyondTrust में हमलावर कुछ “सीमित कार्य” कर सका, लेकिन access policy controls ने गतिविधि को रोक दिया और अकाउंट एक्सेस ब्लॉक कर दिया
  • 1Password, Okta breach के बाद follow-on attack का निशाना बनने वाला ज्ञात रूप से दूसरा Okta ग्राहक बन गया

आंतरिक Notion रिपोर्ट में दर्ज घटना का क्रम

  • 18 अक्टूबर की तारीख वाली और 1Password के आंतरिक Notion workspace में साझा की गई रिपोर्ट में कहा गया कि हमलावर ने कंपनी के IT कर्मचारी द्वारा बनाई गई HAR file हासिल की थी
    • संबंधित कर्मचारी ने यह file हाल ही में Okta support के साथ काम करते समय बनाई थी
    • file में 1Password कर्मचारी के browser और Okta server के बीच के सभी traffic records और session cookies शामिल थे
  • 1Password ने एक गुमनाम कर्मचारी द्वारा text और screenshots के रूप में दिए गए दस्तावेज़ की प्रामाणिकता पर टिप्पणी के अनुरोध का जवाब नहीं दिया
  • रिपोर्ट के अनुसार हमलावर ने 1Password के Okta tenant तक भी पहुंच बनाई
    • Okta tenant का उपयोग कर्मचारियों, partners और ग्राहकों को दिए जाने वाले system access permissions और permission levels को प्रबंधित करने के लिए होता है
    • हमलावर ने group assignments देखे और अन्य कार्य भी किए, लेकिन कुछ गतिविधियां event log में दर्ज नहीं हुईं
    • login के दौरान Google द्वारा प्रदान किए जाने वाले production environment authentication में इस्तेमाल होने वाले IDP(identity provider) को update किया

हमलावर ने क्या किया और दोबारा कोशिश कैसे रोकी गई

  • 29 सितंबर को 1Password IT team को ऐसा अप्रत्याशित email मिला, जिससे admin privileges वाले 1Password users की सूची मांगे जाने का संकेत मिला, और इसी से एक्सेस का पता चला
  • टीम के सदस्यों ने निष्कर्ष निकाला कि किसी अधिकृत कर्मचारी ने यह अनुरोध नहीं किया था, और कंपनी की security response team को सूचित किया
  • हमलावर द्वारा किए गए कार्य इस प्रकार थे
    • IT कर्मचारी के Okta dashboard तक पहुंचने की कोशिश की, लेकिन रोका गया
    • 1Password के production Google environment से जुड़े मौजूदा IDP को update किया
    • उस IDP को enable किया
    • admin user report का अनुरोध किया
  • 2 अक्टूबर को हमलावर ने फिर से 1Password के Okta tenant में login कर पहले enable किए गए Google IDP का उपयोग करने की कोशिश की, लेकिन IDP हटाए जाने के कारण विफल रहा
  • दोनों बार की गई पहुंच अमेरिका के cloud host LeaseWeb server से हुई और Windows machine के Chrome version का उपयोग किया गया
  • घटना के बाद 1Password ने Okta tenant settings बदलकर non-Okta identity providers के जरिए login अस्वीकार करना शुरू कर दिया

vendor breach से ग्राहक कंपनियों पर हमले तक की संरचना

  • Okta breach हाल के वर्षों में बड़े ग्राहक आधार वाले software और service providers को निशाना बनाने वाले हमलों की एक श्रृंखला में से एक है
  • हमलावर provider में घुसपैठ करने के बाद उसी पहुंच का उपयोग कर ग्राहक कंपनियों पर follow-on attacks करते हैं
  • आगे चलकर और अधिक Okta ग्राहकों के सामने आने की संभावना है

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

1 टिप्पणियां

 
GN⁺ 2023-10-25
Hacker News टिप्पणियाँ

  • SSO को बाहर सौंपना सिर्फ तकनीकी रूप से आसान होने या operational capability होने का मामला नहीं है। आप customer contract में लिख सकते हैं कि आप reputable SSO provider का उपयोग करते हैं, और key management approach तथा key material protection से जुड़ी documentation responsibility भी वही provider उठाता है
    1Password के पास शायद पहले से ऐसी व्यवस्था रही होगी, इसलिए यह थोड़ा असामान्य मामला है, लेकिन आम तौर पर “हमारे संगठन के अंदर कोई भी keys तक पहुँच नहीं सकता” कहना, “सिर्फ Bob अपवाद है, वह SSO server चलाता है और हम उस पर भरोसा करते हैं” कहने से कहीं आसान होता है

    • “Bob पर भरोसा है” की तुलना में Okta बेहतर क्यों है? इसका मतलब तो यह है कि आप उन लोगों पर भरोसा कर रहे हैं जिन्हें आप बिल्कुल नहीं जानते, और वे पहले ही कई चर्चित security incidents कर चुके हैं
    • messaging के पहलू पर सहमत हूँ, लेकिन actual security के नज़रिए से service provider वाली तरफ़ के Bob को कैसे देखेंगे?

  • यह दिलचस्प है कि C की memory safety vulnerabilities पर सबसे ज़्यादा बात होती है, लेकिन वास्तविक असर अक्सर उस तरह की insight collapse से आता है जो तथाकथित best-practice design का पालन करते हुए पैदा हुई अत्यधिक complexity से निकलती है

    • असुरक्षित C की आलोचना करते हुए फिर से Byzantine monster खड़ा कर देने वाले लोग अक्सर वही camp होते हैं। ऐसा लगता है कि simple mechanism को Rube Goldberg machine में बदलकर रोजगार बनाए रखने का एक सामान्यीकृत incentive काम कर रहा है
    • organizational bugs किसी organization पर बड़ा असर डाल सकते हैं, लेकिन memory safety bugs आम तौर पर automated तरीके से exploit किए जा सकते हैं और उस software का उपयोग करने वाली हर organization को प्रभावित करते हैं। Heartbleed पर इतनी चर्चा भी इसी वजह से हुई क्योंकि उसका impact बहुत बड़ा था
    • आखिरकार बात complexity की है। कुछ न कुछ छूट ही जाता है, और जब आप कुछ update करते हैं तो दूसरे logic पर उसके cascading effects को नज़रअंदाज़ कर देते हैं। complexity vulnerabilities पैदा करती है, लेकिन layered security defenses और countermeasures जोखिम को कम कर सकते हैं
      मुझे लगता है कि मूल कारण विशाल complexity को समझ पाने में इंसानों की सीमाएँ हैं
    • जो measurable होता है, वही optimize होने लगता है। software vulnerabilities के मामले में हमारे पास numeric और आसानी से इकट्ठा किए जा सकने वाले data हैं, लेकिन organizations में data कैसे चोरी होता है, और कभी-कभी यह भी कि वह कब चोरी हुआ, इस पर जानकारी कम है
      दूसरा हिस्सा इंसानों से जुड़ा होने के कारण ज़्यादा complex होने की संभावना है, इसलिए technology में salvation ढूँढना आसान हो जाता है
    • मुझे जानना है कि “insight collapse” क्या है। यह एक बहुत दिलचस्प अवधारणा लगती है

  • “IT टीम के सभी सिस्टम credentials बदल दिए गए, और MFA को सिर्फ Yubikey तक सीमित कर दिया गया” वाला हिस्सा देखकर लगता है कि यह पूरे स्टाफ के लिए Yubikey-आधारित 2-फैक्टर authentication अपनाने की प्रेरणा बन सकता है। FIDO2 से कम कुछ भी सच में कमजोर है
    अब भी लोग Okta क्यों चुनते हैं, यह समझ नहीं आता। व्यक्तिगत रूप से मुझे ID provider के रूप में GSuite इस्तेमाल करना कहीं ज्यादा सुविधाजनक लगता है। Okta को काफ़ी गंभीर breach झेलने पड़े हैं, और सच कहूँ तो उससे पहले भी उसकी security practices के बारे में अच्छी बातें नहीं सुनी थीं

    • Yubikey या दूसरे browser-based MFA इस हमले को नहीं रोक पाते। हमलावरों ने MFA पूरा होने के बाद का वैध admin session token हासिल कर लिया था
      hardware-based MFA को अनिवार्य करना अच्छी practice है और भविष्य में spear phishing जैसे हमलों को रोक सकता है, लेकिन इस घटना से उसका सीधा संबंध नहीं है
      लोग Okta इसलिए चुनते हैं क्योंकि मामला कुछ-कुछ “IBM खरीदने पर किसी की नौकरी नहीं जाती” जैसा है। खुद का Keycloak चलाकर breach हो जाए तो ज़िम्मेदारी मेरी, लेकिन Okta हो तो वह मेरी समस्या नहीं रह जाती — इस outsourcing संरचना का भी बड़ा हाथ है
    • चोरी हुई चीज़ session cookie थी, और 2-फैक्टर authentication का इस समस्या से कोई लेना-देना नहीं है
      शक है कि आपने Google Workspace को किसी गंभीर उपयोग के लिए वास्तव में इस्तेमाल किया भी है या नहीं। यह सबसे कम फीचर वाले ID providers में से एक है, जबकि Okta सबसे अधिक फीचर वाले विकल्पों में आता है। सिर्फ इस वजह से कि दोनों में दो पहिए हैं, साइकिल और मोटरसाइकिल की तुलना करने जैसा है
      टेक फ़ोरम पर Google Workspace को ID provider के रूप में recommend करते देखूँगा, यह कभी नहीं सोचा था
    • ज़्यादातर लोग Okta नहीं चुनते। कोई executive स्तर का व्यक्ति Okta चुनता है, और बाकी लोगों को उसका नतीजा भुगतना पड़ता है
      Yubikey इस्तेमाल करने पर सभी password-संबंधी customer support मुद्दे किसी बाहरी vendor की बजाय internal IT विभाग को संभालने पड़ते हैं
      MFA में तकनीकी समस्याएँ भी हैं और सामाजिक समस्याएँ भी, लेकिन key·token·phone·SMS जैसी implementations की तकनीकी security लगभग मामूली बात है; customer support, खोए हुए password, वॉशिंग मशीन में चले गए key, mail न मिलना जैसी सामाजिक समस्याएँ कहीं ज़्यादा भारी पड़ती हैं
      हर कोई security में यह विशाल और मूर्खतापूर्ण customer support भूमिका outsource करना चाहता है, लेकिन ऐसा करने के बाद सब पर लागत घटाने का दबाव बनता है। उसका नतीजा Okta है
    • GSuite को ID provider की तरह इस्तेमाल करना बहुत सीमित है। “हम ID provider हैं” वाला checkbox तो टिक हो जाता है, लेकिन “connect हो सकता है” से आगे बढ़ते ही चीज़ें मुश्किल या नामुमकिन हो जाती हैं
      उदाहरण के लिए, अगर सभी कर्मचारी GSuite में हों और किसी संगठन को AWS organization access देना हो, तो AWS SSO[1] सुझाया गया तरीका है। integration सेट कर देने के बाद login तो हो जाता है, लेकिन कई खाली जगहें रह जाती हैं
      GSuite user groups के आधार पर AWS SSO में users को अपने-आप provision या remove करने की सुविधा नहीं है। SSO के SCIM support के साथ अपना code लिखा जा सकता है, लेकिन फिर उसे maintain भी करना पड़ेगा
      SSO session बनाते समय MFA verification को अनिवार्य करने का कोई तरीका न GSuite की तरफ़ है, न AWS SSO की तरफ़। GSuite, SAML application authentication से पहले MFA verification अनिवार्य नहीं कर सकता, और AWS SSO भी internal Directory इस्तेमाल करने के विपरीत, ID provider उपयोग करने पर MFA verification enforce नहीं कर सकता
      कहा जाता है कि Okta और उसके जैसे products ये काम कर देते हैं, और इस्तेमाल हो रहे endpoint के आधार पर MFA verification भी लागू कर सकते हैं। मैंने खुद इसे नहीं आजमाया, यह marketing materials और sales explanations पर आधारित बात है
      संक्षेप में, Okta ID provider और इस्तेमाल की जा रही applications के बीच कहीं अधिक automation और security glue देता है
      [1] यहाँ AWS SSO से आशय AWS के product “AWS IAM Identity Center (Successor to AWS Single Sign-On)” से है
    • क्या कोई सबूत है कि Okta दूसरे solutions से बेहतर है या बदतर? security measurement करना बहुत कठिन है
      अभी जो दिख रहा है, वह बस इतना है कि Okta पिछले साल breach हुआ था, इस बार भी breach हुआ, और इस बार की घटना customer support विभाग या systems में हुई लगती है। breach disclosure देर से हुई हो सकती है, लेकिन यह भी संभव है कि false reports बहुत थीं और हाल तक सबूत नहीं मिला। यह भी हो सकता है कि शुरू में रिपोर्ट करने वाले customer को credit न दिया गया हो, और रिपोर्ट के बाद customers से ठीक से communication न किया गया हो
      जो नहीं पता, वह इससे कहीं ज़्यादा है। हम नहीं जानते कि attacker कितने skilled थे, हर ID provider कितनी बार breach हुआ, कितनी बार detect किया, detect करके छिपाया या नहीं, हर service में कितने security bugs हैं, वे कितने गंभीर हैं, उन्हें ढूँढना कितना आसान है, breach detection क्षमता कैसी है, employee training कितनी अच्छी है, और कर्मचारियों में वास्तव में security की परवाह करने वालों का अनुपात कितना है
      सिर्फ इसलिए कि Okta ने breach रिपोर्ट किया, यह निष्कर्ष नहीं निकाला जा सकता कि उसका product बदतर है। हमें यह नहीं पता कि दूसरे products कितने अच्छे हैं; संभव है Okta कुछ या सभी competitors से बेहतर हो, और निश्चित ही यह भी संभव है कि वह बदतर हो

  • पहले 1Password एकमुश्त कीमत पर खरीदा जाता था, और software पूरी तरह offline चलता था, जिसमें encrypted vault local रूप से या Dropbox में stored रहता था। ऑनलाइन चुराने के लिए कुछ था ही नहीं, इसलिए hackers की चिंता करने की ज़रूरत नहीं पड़ती थी
    फिर किसी ने calculator चलाकर तय किया कि profitability बढ़ाने का रास्ता सबका data cloud में ले जाकर subscription fee लेना है। और अब हम इस बात की चिंता कर रहे हैं कि कहीं data leak तो नहीं हो गया

    • यह भी सच है कि जो लोग इसे खुद संभालने लायक skilled नहीं हैं, उनके लिए convenience काफ़ी बढ़ी है
      और जहाँ तक अभी पता है, vault को Dropbox में रखने से यह कितना अलग है? Dropbox भी hack हो सकता है, और वह डेटा encrypted नहीं होता, इसके लिए तो वह मशहूर है। अभी तक क्या हमें 1Password vault के वास्तव में compromise होने का कोई मामला पता है?

  • https://blog.1password.com/okta-incident/
    मूल incident report: https://blog.1password.com/files/okta-incident/okta-incident...

    • यह हिस्सा दिलचस्प है। IT टीम का एक सदस्य Okta support टीम के साथ काम कर रहा था, और अनुरोध पर Chrome developer tools में HAR file बनाकर उसे Okta support portal पर upload किया। इस फ़ाइल में browser और Okta server के बीच का पूरा traffic log तथा session cookie जैसी sensitive जानकारी शामिल थी
      बाद में किसी अज्ञात actor ने उसी Okta session का इस्तेमाल करके, जो HAR file बनाते समय उपयोग हुआ था, Okta admin portal तक पहुँच बना ली
      जैसे बैंक हमेशा कहते हैं, support staff को password नहीं देना चाहिए

  • इस बार ज़िम्मेदारी साफ़ तौर पर Okta की है। समस्या सुलझाने के लिए plain-text HAR-encoded session माँगना और यह उम्मीद करना कि end user उसे ठीक से साफ़ कर देगा, गलत है
    upload के समय HAR data को sanitize कर देना चाहिए, ताकि वह system में जाए और कम वेतन व कम स्टाफ़ वाले support technicians जब उसे देखें तो केवल प्रासंगिक और सुरक्षित हिस्से ही बचे हों
    HAR structured data है, इसलिए इसे program के ज़रिये साफ़ करना बहुत आसान है। यह कोई rocket science नहीं है

  • लोग बार-बार पूछते हैं कि लोग ultra-simple, ultra-friendly online service की जगह self-hosted·self-synced password manager क्यों इस्तेमाल करते हैं, और वजह वही है। यह वैसा ही है जैसे अपने apartment की चाबी मोहल्ले के train station के locker में फेंककर न रखी जाए

    • ऐसा करने पर आपको ज़्यादा सुरक्षित महसूस हो सकता है, लेकिन ज़रूरी नहीं कि वह सच में ज़्यादा सुरक्षित हो। अगर कोई dedicated attacker Okta में घुस सकता है, तो वह आपके self-hosted password manager में भी घुस सकता है, जिसे आपने समय पर update करना भूल गए हों या जिसका update देर से आता हो
      ऐसे संगठन अक्सर बयान जारी करने से हफ़्तों, कभी-कभी महीनों पहले समस्या ठीक कर देते हैं
      open source इस्तेमाल करते समय अगर कोई critical bug मिलता है तो आपको patch press release के साथ मिलेगा, लेकिन बड़े services संभवतः वह समस्या पहले ही ठीक कर चुके होते हैं। औसत user के लिए risk-reward का संतुलन as-a-service solution की तरफ़ जाता है
    • यह अप्रासंगिक बात है। 1Password के passwords उस key से encrypt होते हैं जो केवल user के पास होती है। यह बहुत संदिग्ध है कि कोई अपना personal home server, 1Password के server से ज़्यादा सुरक्षित रख सकेगा
    • मैं भी pass command-line tool + git इस्तेमाल करता हूँ, और अब तक एक भी बार कोई समस्या नहीं हुई
      इसे scripts में भी इस्तेमाल किया जा सकता है
      न server compromise, न web extension vulnerability, न server error की वजह से सारे passwords खोने का डर। यह बस काम करता है
    • बात समझ में आती है, लेकिन अगर password vault self-hosted software और self-hosted vault file होती, तो शायद मैं हर दिन data loss की चिंता करता
    • जानना चाहूँगा कि आप क्या इस्तेमाल करते हैं

  • “1Password follow-up attack का target बनने वाला दूसरा ज्ञात Okta customer बन गया” यह वाक्य अजीब है। क्या Ars को नहीं पता कि Cloudflare भी victim था?
    https://blog.cloudflare.com/how-cloudflare-mitigated-yet-ano...

    • लगता है मतलब यह है कि BeyondTrust ने समस्या report की, Cloudflare attack target बनने वाला पहला ज्ञात Okta customer था, और 1Password दूसरा

  • मैं जानना चाहता हूँ कि app में suspicious behavior monitor करने की best practice क्या है। service-wide request rate या error rate देखने जैसी basics तो समझता हूँ, लेकिन व्यवहार में यह कितना sophisticated हो जाता है?
    क्या ऐसे intelligent tools हैं जो event stream डालने पर anomalous behavior ढूँढ दें, या फिर monitor करने लायक हर चीज़ पहले से सोचकर rules जोड़ने पड़ते हैं?

    • इस क्षेत्र का अनुभव न रखने वाला घर-बैठा आम आदमी हूँ, इसलिए मेरी बात छाँटकर लें। प्राथमिकता audit trail होनी चाहिए। user account या data पर की गई हर action, system के हर बदलाव का audit log होना चाहिए, जिसमें timestamp और user जैसी जानकारी शामिल हो। खासकर password या account details बदलने जैसी चीज़ें
      जब आपके पास ऐसी event stream हो, तो आप data analysis tools चला सकते हैं। कुछ दिनों, हफ़्तों या महीनों की activity से normal baseline बनाकर, bulk password changes या email changes जैसे outlier behavior पर alert बजना चाहिए
      लेकिन यह सिर्फ़ घर-बैठा अनुमान है, इसलिए जानना चाहूँगा कि क्या कोई ऐसा है जिसने वास्तव में audit logs और उनके इस्तेमाल को संभाला हो
    • AI startup idea के तौर पर यह ठीक है। Security as a Service के रूप में हर request को किसी third-party service के ज़रिये proxy कराइए और anomaly detect कराइए। बस अगर वह detect न कर पाए, तो भी वह service ज़िम्मेदारी नहीं लेगी
    • https://www.obsidiansecurity.com/

  • फिर से detect किया गया?
    https://news.ycombinator.com/item?id=37991863