हैकर्स ने Okta सपोर्ट टीम से access tokens चुरा लिए

 (krebsonsecurity.com)
1 पॉइंट द्वारा GN⁺ 2023-10-22 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Okta के customer support system breach के कारण कुछ ग्राहकों द्वारा support cases में अपलोड की गई फाइलें उजागर हो गईं, और हमलावरों ने ब्लॉक किए जाने से पहले कम-से-कम 2 हफ्तों तक support platform तक पहुंच बनाए रखी थी, ऐसा लगता है
  • हमलावर चुराए गए credentials का इस्तेमाल कर support case management system में घुसे और ग्राहकों द्वारा troubleshooting के लिए जमा की गई HAR files देख सके
  • HAR files में cookies और session tokens हो सकते हैं, इसलिए इनके चोरी होने पर हमलावर किसी वैध user की तरह session को दोबारा इस्तेमाल कर सकते हैं
  • BeyondTrust ने 2 अक्टूबर को अपने Okta environment में admin account बनाने की कोशिश का पता लगाया था, और उससे 30 मिनट पहले उसने Okta के साथ एक HAR file साझा की थी जिसमें वैध Okta session token शामिल था
  • Okta ने 18,000 से अधिक ग्राहकों में से लगभग 1%, यानी करीब 170 संगठनों को सूचना दी, और 1Password तथा Cloudflare ने भी बताया कि उनका Okta authentication platform प्रभावित हुआ था, लेकिन उनके अनुसार customer data या systems पर असर नहीं पड़ा

support case management system में उजागर हुई ग्राहक फाइलें

  • Okta एक ऐसी कंपनी है जो हजारों enterprises को ID tools देती है, जिनमें multi-factor authentication और single sign-on शामिल हैं, और यह घटना उसके customer support विभाग में हुई सेंध से शुरू हुई
  • 19 अक्टूबर को कुछ ग्राहकों को भेजी गई सूचना में कहा गया कि चुराए गए credentials का इस्तेमाल support case management system तक पहुंचने के लिए किया गया
  • हमलावर हाल की support cases में कुछ Okta ग्राहकों द्वारा अपलोड की गई फाइलें देख सके
  • शुरुआत में असर का दायरा “बहुत कम संख्या” बताया गया था, बाद में पुष्टि हुई कि ग्राहक आधार के लगभग 1%, यानी करीब 170 संगठनों को सूचना दी गई

HAR files खतरनाक क्यों बन गईं

  • ग्राहक समस्याओं को हल करते समय Okta कभी-कभी web browser session record वाली HTTP Archive(HAR) files मांगता है
  • HAR files संवेदनशील होती हैं क्योंकि इनमें ग्राहक की cookies और session tokens शामिल हो सकते हैं
  • हमलावर फाइल के अंदर मौजूद cookies या tokens का इस्तेमाल कर किसी वैध user का रूप धारण कर सकते हैं
  • Okta ने प्रभावित ग्राहकों के साथ मिलकर जांच की और embedded session tokens को revoke करने जैसे सुरक्षा कदम उठाए
  • HAR files साझा करने से पहले सभी credentials, cookies और session tokens हटा देने चाहिए

BeyondTrust ने कैसे पकड़ा attack flow

  • security company BeyondTrust उन ग्राहकों में से एक थी जिन्हें 19 अक्टूबर को Okta की सूचना मिली थी
  • BeyondTrust के CTO Marc Maiffret ने कहा कि यह सूचना तब पहुंची जब BeyondTrust, Okta को संभावित समस्या के बारे में 2 हफ्ते से अधिक पहले बता चुका था
  • 2 अक्टूबर को BeyondTrust की security team ने पाया कि कोई व्यक्ति उसके engineer को सौंपे गए Okta account का इस्तेमाल करके उसके Okta environment के भीतर एक शक्तिशाली administrator account बनाने की कोशिश कर रहा था
  • उस employee account की activity की समीक्षा में पता चला कि unauthorized activity से 30 मिनट पहले एक support engineer ने Okta के अनुरोध पर Okta के साथ एक HAR file साझा की थी जिसमें वैध Okta session token शामिल था
  • हमलावर ने browser record के अंदर मौजूद cookies का इस्तेमाल करके session hijacking की कोशिश की और उस user की ओर से काम करना चाहा
  • BeyondTrust ने 3 अक्टूबर को Okta को बताया कि उसके साथ breach होने की संभावना बहुत अधिक है, और 11 अक्टूबर व 13 अक्टूबर की calls में भी वही आकलन साझा किया
  • BeyondTrust ने हमले को चलते समय ही पकड़ लिया और कहा कि उसके ग्राहकों पर कोई असर नहीं पड़ा

Okta की प्रतिक्रिया और बाकी बचे सवाल

  • Okta की Deputy CISO Charlotte Wylie ने कहा कि 2 अक्टूबर को BeyondTrust से मिली सूचना को शुरू में उसने अपनी systems breach का नतीजा नहीं माना
  • 17 अक्टूबर तक Okta ने घटना की पहचान कर उसे रोक दिया, compromised customer case management account को disable किया और संबंधित Okta access tokens को invalidate कर दिया
  • Wylie ने यह सटीक संख्या नहीं बताई कि संभावित security issue की सूचना कितने ग्राहकों को दी गई, लेकिन 18,000 से अधिक ग्राहकों में इसे “बहुत, बहुत छोटा हिस्सा” बताया
  • घुसपैठियों ने कंपनी के case management account तक कितने समय तक पहुंच बनाए रखी थी और हमले के पीछे कौन था, यह सार्वजनिक नहीं किया गया
  • Wylie ने कहा कि इस हमले के पीछे known threat actor था, जिसने पहले भी Okta और Okta के कुछ खास ग्राहकों को निशाना बनाया है

संबंधित breaches और बाद की disclosures

  • Okta की यह disclosure Caesar’s Entertainment और MGM Resorts hacks के कुछ ही हफ्तों बाद आई
  • इन दोनों casino company incidents में हमलावरों ने social engineering के जरिए कर्मचारियों को Okta admin account की multi-factor authentication login requirements reset करने के लिए बहकाया था
  • मार्च 2022 में Okta ने social engineering हमलों में विशेषज्ञ hacking group LAPSUS$ से जुड़ी एक breach का खुलासा किया था
  • Okta की postmortem report के अनुसार, LAPSUS$ ने social engineering के जरिए third-party outsourcing company Sitel के एक support engineer workstation तक पहुंच बनाई थी, जिसे Okta resources तक पहुंच प्राप्त थी
  • इसके बाद Okta ने incident-related blog post प्रकाशित की, जिसमें compromise indicators शामिल थे ताकि ग्राहक यह जांच सकें कि वे प्रभावित हुए या नहीं
    • कंपनी ने कहा कि उसने सभी प्रभावित ग्राहकों को सूचना दे दी है
    • उसने ज़ोर देकर कहा कि जिन Okta ग्राहकों से अलग से संपर्क नहीं किया गया, उनके environment या support tickets प्रभावित नहीं हुए
  • BeyondTrust ने भी अपनी जांच के नतीजे प्रकाशित किए
  • 24 अक्टूबर के update में 1Password और Cloudflare ने खुलासा किया कि Okta breach के परिणामस्वरूप उनका Okta authentication platform प्रभावित हुआ था
    • दोनों कंपनियों ने कहा कि उनकी जांच में customer data या systems पर कोई असर नहीं मिला
    • Okta के spokesperson ने TechCrunch से कहा कि ग्राहक आधार के लगभग 1%, यानी करीब 170 संगठनों को सूचना दी गई थी

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

1 टिप्पणियां

 
GN⁺ 2023-10-22
Hacker News की राय

  • इस लेख का मज़ेदार हिस्सा यह है कि Okta को एक third party से संदिग्ध tenant activity की सूचना मिली, और शुरू में उसे कोई breach evidence नहीं मिला, फिर BeyondTrust के लगातार दबाव डालने के बाद ही उसने दोबारा जांच की और breach की पुष्टि की
    Okta ने यहां यह blog post डाली: https://sec.okta.com/harfiles
    शुरुआती पंक्ति है “Okta Security has identified adversarial activity”, लेकिन third-party सूचना का कोई ज़िक्र नहीं है। क्या शानदार transparency है

    • अब भी कोई Okta क्यों इस्तेमाल करता है, यह समझ नहीं आता। authentication पूरे IT का सबसे महत्वपूर्ण हिस्सा है, और Okta बार-बार साबित कर चुका है कि वह भरोसेमंद नहीं है और उसमें integrity की कमी है। यह फटने को तैयार time bomb जैसा लगता है
    • Okta का शीर्षक शायद security breach announcement के इतिहास का सबसे फीका शीर्षक है: “Tracking Unauthorized Access to Okta's Support System”
      शीर्षक भयानक है, और न पारदर्शी है न सीधे मुद्दे पर। यह तक न बताना कि BeyondTrust ने 2 अक्टूबर को, HAR file को Okta Support पर अपलोड किए जाने के 30 मिनट बाद ही सूचना दे दी थी, Okta की तरफ से सचमुच बहुत खराब है

  • “Okta की deputy CISO Charlotte Wylie ने कहा कि शुरुआत में Okta को लगा था कि 2 अक्टूबर को BeyondTrust का alert उसके अपने सिस्टम के breach का नतीजा नहीं था। लेकिन 17 अक्टूबर तक कंपनी ने घटना की पहचान कर उसे रोक लिया था”
    मतलब cyber security और authentication expert कहलाने वाली कंपनी को 30 मिनट के भीतर hack होने की जानकारी दे दी गई, लेकिन उसने कहा कि ऐसा नहीं है, और 15 दिनों तक मानने से इनकार किया जबकि उस दौरान attacker खुलेआम सक्रिय रहा
    Wylie, आपको इससे बेहतर करना चाहिए

  • मूल लेख में लिंक किया गया यह blog post देख लेना चाहिए। Okta का एक customer रही security company ने Okta के साथ HAR file साझा करने के तुरंत बाद अपने नेटवर्क में संदिग्ध गतिविधि पकड़ी और Okta को breach के बारे में बताया
    https://www.beyondtrust.com/blog/entry/okta-support-unit-bre...

    • Amazon service ने अभी मुझसे HAR file शेयर करने को कहा था, और मुझे यह साफ security risk लगा। क्या इसका मतलब यह नहीं कि support agent के पास मेरे account की authentication cookie आ जाएगी? समझ नहीं आता कि यह प्रथा इतनी आम कैसे हो सकती है
    • वह लेख ठीक-ठीक यह बताने से बच निकलता है कि session hijacking को कैसे detect किया गया। उसमें कहा गया, “यह detection ऐसे संदिग्ध session ढूंढ़ती है जो authentication event के बिना दिखाई देते हैं, और यह session hijacking से मेल खाता है”, लेकिन अगर कोई session मौजूद है तो किसी न किसी समय authentication तो हुआ ही होगा
      शायद यह कहने का जटिल तरीका है कि login के बाद IP बदल गया। बेशक सबसे आसान समाधान यह है कि active session की HAR file स्वेच्छा से साझा ही न की जाए
    • इस लेख में समस्या को समझने लायक पर्याप्त और उचित detail है। दूसरी तरफ Okta की पोस्ट को समझने के लिए काफी context चाहिए

  • यह बात शायद लोकप्रिय न हो, लेकिन OAuth, SAML, 2FA वाले SSO का मुख्य gateway SaaS के “easy button” पर भरोसा करने के बजाय on-premises चलाया जाना चाहिए
    इसमें सिर्फ Okta नहीं बल्कि Auth0(जिसे Okta ने खरीदा), Authy, और Duo भी शामिल हैं

    • दुर्भाग्य से on-premises चलाने से security breach रुक ही जाएगा, ऐसा नहीं है; और यह authentication को cloud provider को सौंपने से कहीं बदतर भी हो सकता है
      हर software में security bug होते हैं, और on-premises software भी इसका अपवाद नहीं है। बहुत-सी IT organizations के पास directory को चलाने और सुरक्षित रखने की expertise नहीं होती। यह सिर्फ software install करके कुछ accounts बनाकर उसे किसी कोने में छोड़ देने का काम नहीं है; इसमें disaster recovery, backup testing, और breach हुआ है या नहीं यह तय करना भी शामिल है, और यह बहुत कठिन काम है
      किसी ने यह साबित नहीं किया है कि on-premises IT security, cloud provider security से बेहतर है। मैंने खुद कुछ on-premises IT departments देखे हैं जिनकी security बेहद खराब थी: 2010~2020 के बीच भी MD5 certificate इस्तेमाल करने वाले VPN चलाना, unauthenticated users को social security/tax number, address, name, phone number जैसी personal information तक पहुंच देने वाली web service deploy करना, nurses को patient notes लिखने के लिए ad-supported text editor देना, और known security bug वाले end-of-support Redcap version को update न करना
      मेरी समझ से Redcap ऐसा software है जिसमें medical research और public health statistics की गणना में इस्तेमाल होने वाली जानकारी रखी जाती है, और इसमें बहुत सारा sensitive data होता है
      असली बात यह है कि cloud से on-premises पर ले जाने से security बेहतर भी हो सकती है और नहीं भी। यह हर IT organization की capability पर निर्भर करता है, और कई organizations में Okta जैसी identity service चलाने की क्षमता नहीं होती। साथ ही cloud providers के पास आमतौर पर बहुत बड़ा budget होता है और वे लागत को बहुत सारे customers में बांट सकते हैं, इसलिए वे security experts, system protection, और breach detection में अधिक निवेश कर सकते हैं
    • सहमत हूं, लेकिन आजकल on-premises cost calculation को बहुत सख्ती से परखा जाता है, जबकि cloud में कोई भी बस यह कह दे कि “हमने capital expenditure को operating expenditure में बदल दिया और world-class auto-scaling cloud-native solution लागू कर दिया” तो उसे genius माना जाता है
      ऐसे managers और executives से कोई सवाल नहीं पूछा जाता
    • एक और अलोकप्रिय राय जोड़ूं तो: अगर किसी चीज़ को network से जोड़ने की ज़रूरत नहीं है, तो उसे मत जोड़ो
      वास्तव में आप ऐसे systems पर software लिख और test कर सकते हैं जो कभी connected ही नहीं होते। हैरानी की बात है, लेकिन सच है
    • Azure AD को भी मत भूलो। वहीं root key compromise हुई थी
    • क्या Duo का on-premises version है? या फिर अपने domain में लगभग वही functionality पाने के लिए मुझे पाँच solutions deploy करके उन पर mastery हासिल करनी पड़ेगी?

  • पहचान प्रदाता, password manager, VPN कंपनियों जैसी जगहों को कभी hack नहीं होना चाहिए। ये security products बेचकर पैसा कमाती हैं, और जिन जगहों में breach हो चुका हो उन्हें मैं इस्तेमाल नहीं करूंगा। संभव है कि कोई और गहरी समस्या हो

    • हर चीज़ hack हो सकती है। यह साफ़ है कि किसी को भी पूरी तरह सुरक्षित software इस्तेमाल करने का तरीका नहीं आता। किसी को यह भी नहीं आता कि operations में कभी गलती न हो, configuration errors न हों, access हटाना न भूलें, और secrets हमेशा rotate करते रहें
    • जब तक वे यह साबित न कर दें कि breach हो ही नहीं सकता, मुझे समझ नहीं आता कि उनका इस्तेमाल क्यों किया जाए
      मूल धारणा यही होनी चाहिए कि हर चीज़ breach हो सकती है, और यह साबित करने की ज़िम्मेदारी उन्हीं की है कि ऐसा नहीं होगा। बार-बार अयोग्यता दिखा चुके लोगों को सद्भावना देने के बजाय, इस असाधारण दावे के समर्थन में सकारात्मक प्रमाण का इंतज़ार करना ज़्यादा विवेकपूर्ण लगता है कि वे hack नहीं होंगे
    • पुरानी कहावत की तरह, security कोई product नहीं बल्कि एक process है। लेकिन वह process इतना कठिन है कि हमेशा पहले वाले पर निर्भर हो जाने का लालच बना रहता है
    • ऐसी services परिभाषा के अनुसार honeypot होती हैं। यह सोचना भोला है कि वे कभी hack नहीं होंगी। hack होना बस समय की बात है
      अगर वे पर्याप्त सक्षम और ज़िम्मेदार हों तो वे इसका पता लगाकर खुलासा करेंगी, लेकिन ज़्यादातर शायद ऐसा नहीं करेंगी। क्योंकि ठीक आप जैसे लोग फिर उनका इस्तेमाल बंद कर देंगे। इसलिए जिसे भी ज़रा-सी चिंता है, उसे offline, self-hosted, self-built alternatives इस्तेमाल करने चाहिए

  • Okta का एक महीने तक hack न होने का challenge: कठिनाई स्तर असंभव
    मज़ाक अपनी जगह, Okta को देखकर लगता है जैसे उसे breach होना पसंद हो। आप उम्मीद करेंगे कि ऐसी घटनाओं से stock price लगातार गिरने पर कुछ बदलाव होगा, लेकिन लगता नहीं है

    1. https://www.malwarebytes.com/blog/news/2023/01/okta-breached...
    2. https://www.theverge.com/2022/4/20/23034360/okta-lapsus-hack...
    3. https://techmonitor.ai/technology/cybersecurity/okta-cyberat...

  • असली बात बारीकियों में छिपी होती है। शायद वे zero trust के साथ operate कर रहे थे
    एक तरफ़ देखें तो यह core product breach नहीं था। दूसरी तरफ़, हर core product breach के साथ किसी न किसी तरह का अप्रत्यक्ष non-core breach जुड़ा होता है

  • अच्छा हुआ कि उन्हें प्रतिस्पर्धी Auth0 का अधिग्रहण करने दिया गया

  • कभी न कभी मैं किसी conference talk में यह प्रयोग करूंगा कि अलग-अलग कंपनियों की support roles में लोगों को पैसे देकर अंदर बैठाया जाए, और फिर उन्हें दिए गए system access का इस्तेमाल करके उन्हीं कंपनियों में breach किया जाए

  • ईमेल के नीचे यह लिखा था
    “यह जानकारी Okta की गोपनीय जानकारी है और इसे आपके संगठन के बाहर साझा नहीं किया जाना चाहिए”
    सच कहूं तो यह काफ़ी मज़ेदार है

    • अगर HAR files को default support procedure के रूप में मांगा जाता है, तो upload के समय अपने-आप sensitive information removal क्यों नहीं किया जाता?