हाल में Apple यूज़र्स को निशाना बनाने वाले ‘MFA Bombing’ हमले

 (krebsonsecurity.com)
1 पॉइंट द्वारा GN⁺ 2024-03-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Apple के password reset notifications बड़ी संख्या में बार-बार दिखने लगे, जिससे कुछ यूज़र्स को ऐसे phishing हमले का सामना करना पड़ा कि वे अपने devices सामान्य रूप से इस्तेमाल नहीं कर पा रहे थे
  • हमलावर notifications की बाढ़ के बाद Apple Support caller number को spoof करके कॉल करते हैं और account protection प्रक्रिया जैसा दिखाकर one-time code मांगते हैं
  • Parth Patel के मामले में PeopleDataLabs में मौजूद गलत alias तक का दुरुपयोग किया गया, और Apple ID reset code दे देने पर account lock और devices के remote erase तक की नौबत आ सकती है
  • Chris और Ken के मामले दिखाते हैं कि account में registered phone number attack flow का मुख्य सुराग हो सकता है, और Apple Recovery Key भर से reset notifications भेजना नहीं रुकता
  • Mitigation के तौर पर कम ज्ञात VOIP number या email alias इस्तेमाल करने के तरीके बताए जाते हैं, लेकिन असली mobile number हटाने पर iMessage और Facetime deactivate हो सकते हैं

Apple password reset notifications का दुरुपयोग करने वाला MFA fatigue हमला

  • हाल में कई Apple customers ने MFA Bombing या MFA fatigue हमले झेले
  • हमला Apple के password reset feature में bug जैसा दिखने वाले behavior का फायदा उठाता है
    • target के Apple devices पर दर्जनों system-level notifications दिखते हैं
    • यूज़र को हर notification में Allow या Don’t Allow दबाना पड़ता है
    • notifications लगातार जमा हों तो device का इस्तेमाल ही रुक जाने जैसी स्थिति बन जाती है
  • हमलावर उम्मीद करता है कि बार-बार request से थककर यूज़र गलती से Allow दबा देगा, या phone का इस्तेमाल वापस पाने के लिए approve कर देगा
  • सभी notifications reject करने के बाद Apple Support जैसा दिखाने के लिए caller number spoof की गई कॉल आती है
    • phone number Apple के वास्तविक customer support number 1-800-275-2273 के रूप में दिख सकता है
    • ठग कहता है कि account पर हमला हो रहा है और one-time code confirm करना होगा

Parth Patel मामला: notifications की बाढ़ के बाद spoofed support call

  • Parth Patel ने 23 मार्च को Twitter/X पर अपने खिलाफ चलाए गए phishing campaign को record किया
  • उनके Apple Watch, laptop और phone पर एक साथ notifications की बौछार हुई, और उन्हें 100 से अधिक password reset notifications reject करने पड़े
  • सभी notifications reject करने के बाद iPhone पर Apple Support से आई हुई लगने वाली call आई
  • ठग ने Patel से उनके बारे में जानकारी confirm करने को कहा; उसने सही personal information दी, लेकिन असली नाम सही नहीं बता पाया
    • ठग ने जो नाम बताया वह एक गलत alias था जिसे Patel ने केवल PeopleDataLabs की background report में देखा था
    • Patel ने कहा कि उन्होंने कई people-search sites से अपनी जानकारी हटाने की कोशिश की, लेकिन PeopleDataLabs में वह alias consumer profile में लगातार दिखता रहा
  • voice phishing का लक्ष्य Apple ID reset code को यूज़र के device पर भेजवाकर वह one-time code हासिल करना है
    • अगर यूज़र code बता देता है, तो हमलावर account password reset करके यूज़र को lock out कर सकता है
    • इसके बाद यूज़र के Apple devices को remotely erase भी किया जा सकता है

phone number attack clue हो सकता है

  • cryptocurrency hedge fund के owner Chris ने भी फरवरी के अंत में ऐसा ही phishing attempt झेला
  • पहले notification को Don’t Allow से reject करने के तुरंत बाद करीब 30 notifications लगातार आए, और कई दिनों तक reset notifications आते रहे
  • उन्हें Apple Support से आई हुई लगने वाली call भी मिली, लेकिन Chris ने कहा कि वे खुद वापस call करेंगे और call काट दी
    • जब उन्होंने वास्तविक Apple को call किया, तो Apple यह confirm नहीं कर पाया कि अभी support call हुई थी या नहीं
    • Apple ने बताया कि जब तक customer contact का request न करे, Apple पहले call नहीं करता
  • Chris ने password बदला और Apple Store से नया iPhone खरीदा, फिर नए email address से नया iCloud account बनाया
  • लेकिन Apple Genius Bar में बैठे रहने के दौरान भी नए iPhone और नए iCloud account पर system notifications आते रहे
    • Chris के मुताबिक नए account में जो एकमात्र चीज़ नहीं बदली थी, वह account में registered phone number था
    • उन्हें शक है कि हमलावर को Apple system notifications तेजी से generate करने के लिए target Apple account का phone number जानना पड़ सकता है

Recovery Key से भी नहीं रुके Ken के notifications

  • security industry का अनुभव रखने वाले Ken को इस साल की शुरुआत से Apple devices पर अनचाहे system notifications मिले, लेकिन अन्य मामलों के विपरीत उन्हें fake Apple support call नहीं आई
  • एक बार वे रात 12:30 बजे Apple Watch notification से जाग गए; Watch पर पहले Allow दिख रहा था और Don’t Allow दबाने के लिए wheel scroll करना पड़ता था
  • सिर्फ Allow दबाने से हमलावर Ken का password नहीं बदल सकता
    • Allow दबाने पर Ken के device पर password बदलने के लिए जरूरी 6-digit PIN दिखता है
    • बार-बार आने वाले reset notifications का इस्तेमाल बाद में Apple बनकर की जाने वाली call को अधिक विश्वसनीय बनाने के लिए होता दिखता है
  • Ken ने वास्तविक Apple support से संपर्क किया, और एक senior Apple engineer ने उन्हें बताया कि Apple Recovery Key on करने से notifications रुक जाएंगे
  • Apple Recovery Key Apple ID account security बढ़ाने वाला optional feature है, और यह random 28-character code होता है
    • इसे activate करने पर Apple की standard account recovery प्रक्रिया disable होनी चाहिए
    • recovery key और सभी Apple devices खो देने पर account से permanent lockout हो सकता है
  • Ken ने recovery key on किया, लेकिन हर कुछ दिनों में सभी devices पर unwanted system notifications आते रहे
  • testing में पता चला कि recovery key on करने पर भी iforgot.apple.com से Apple devices पर password reset notifications भेजने वाला flow नहीं रुकता
    • page email address और CAPTCHA मांगता है
    • इसके बाद account से जुड़े phone number के last two digits दिखाता है
    • बाकी digits enter करके submit करने पर, Recovery Key active है या नहीं, इससे परे system notification भेज दिया जाता है

rate limiting पर सवाल और पुराने MFA Bombing मामले

  • authentication system का design सवालों के घेरे में है कि जब user ने पहली request पर भी respond नहीं किया, तो कुछ ही मिनटों में दर्जनों password change requests कैसे भेजी जा सकती हैं
  • Apple ने comment request का अभी जवाब नहीं दिया है
  • 2022 में criminal hacking group LAPSUS$ ने MFA Bombing का इस्तेमाल करके Cisco, Microsoft, Uber में intrusions में असर दिखाया
  • Microsoft ने countermeasure के तौर पर MFA number matching लागू करना शुरू किया
    • login attempt करने वाले user को numbers का array दिखाया जाता है
    • account owner को login confirmation पूरा करने के लिए mobile device के Microsoft Authenticator app में वही number enter करना होता है
  • security researcher Kishan Bagaria के मुताबिक समस्या Apple की तरफ है
    • उन्होंने 2019 में Apple को AirDoS bug report किया था
    • यह bug AirDrop file sharing prompts को आसपास के iOS devices पर अनंत बार दिखा सकता था
    • Apple ने दिसंबर 2019 में वह bug fix किया और संबंधित security bulletin में Bagaria को credit दिया
    • Bagaria के अनुसार Apple का fix AirDrop requests पर ज्यादा सख्त rate limiting जोड़ने वाला था
  • संभव है कि किसी ने Apple के password reset requests की rate limiting को bypass करने का तरीका खोज लिया हो, और यह Apple rate limiting bug हो सकता है जिसे formally report किया जाना चाहिए

यूज़र जो mitigation आजमा सकते हैं

  • Apple account में phone number जरूरी लगता है, लेकिन account setup के बाद उसका mobile number होना जरूरी नहीं है
  • testing से पता चला कि Apple Google Voice जैसे VOIP numbers allow करता है
    • कम widely known VOIP number से account phone number बदलना एक mitigation हो सकता है
  • हालांकि, अगर असली mobile number शामिल न हो तो उस device पर iMessage और Facetime deactivate हो जाते हैं
    • Apple devices का overall attack surface घटाना चाहने वाले users के लिए यह बात advantage भी हो सकती है
    • iMessage और Facetime के zero-click zero-days spyware providers द्वारा बार-बार इस्तेमाल किए गए हैं
  • Apple का password reset system email aliases को accept और respect करता दिखता है
    • username के बाद + और site-specific notation जोड़कर उसी account से जुड़ा unique email address बनाया जा सकता है
    • उदाहरण के लिए krebsonsecurity+example@gmail.com जैसा format संभव है
    • Apple के लिए alias में +apple जैसे बहुत obvious notation की जगह कम obvious alias बेहतर हो सकता है

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

1 टिप्पणियां

 
GN⁺ 2024-03-28
Hacker News की राय

  • लेख और शीर्ष टिप्पणियों में एक अहम बात छूट गई है: गलती से Allow दबा देने भर से हमलावर अपने ब्राउज़र में पासवर्ड नहीं बदल सकता
    डिवाइस पर Allow दबाने से उसी डिवाइस पर 6-अंकों का PIN दिखता है, और उसी PIN से अपने डिवाइस पर पासवर्ड बदला जा सकता है। हमले का आख़िरी चरण यह है कि हमलावर नकली Apple फ़ोन नंबर से कॉल करके उस 6-अंकों वाले PIN को पढ़कर बताने के लिए कहता है। अगर आने वाली कॉल पर वह PIN हमलावर को बता दिया जाए, तो हमलावर अपने ब्राउज़र में पासवर्ड reset कर सकता है
    यह थोड़ा चौंकाने वाला है कि Krebs ने अपने security blog में यह छोटी-सी detail छोड़ दी, और मानो यह पुष्टि कर दी हो कि सोते समय भी पूरे account access को सौंपा जा सकता है

    • लेख के पहले पैराग्राफ़ में यह पहले से समझाया गया है:

      Assuming the user manages not to fat-finger the wrong button on the umpteenth password reset request, the scammers will then call the victim while spoofing Apple support in the caller ID, saying the user’s account is under attack and that Apple support needs to “verify” a one-time code.

    • लेख में यह भी है:

      Ken didn’t know it when all this was happening (and it’s not at all obvious from the Apple prompts), but clicking “Allow” would not have allowed the attackers to change Ken’s password. Rather, clicking “Allow” displays a six digit PIN that must be entered on Ken’s device — allowing Ken to change his password. It appears that these rapid password reset prompts are being used to make a subsequent inbound phone call spoofing Apple more believable.

    • यह सही बात है और जानने लायक भी, लेकिन फिर भी काफ़ी समझदार लोग भी इसके झांसे में आ सकते हैं। यह सिर्फ़ 80+ उम्र के बुज़ुर्गों की समस्या नहीं है
      भले कोई न फँसे, Apple के पास ऐसा गंभीर nuisance है जिसे वह इन requests पर सिर्फ़ rate limiting लगाकर खत्म कर सकता है। समझ नहीं आता कि कम समय में सैकड़ों requests भेजना संभव ही क्यों है

  • इसे “हालिया” कहना थोड़ा संदिग्ध है
    2021 में, या ज़्यादा से ज़्यादा 2022 तक, मैं और मेरी पत्नी दोनों ने कुछ दिनों के अंतर पर यही चीज़ झेली थी। शुरू में दिन में कुछ बार हुआ, फिर बढ़कर हर घंटे तक पहुँच गया। लगता है हम दोनों को कुछ ऐसे SMS भी कई बार मिले थे जो Apple से आए हुए लगते थे
    जैसे ही यह तेज़ी से बढ़ा, हमने दोनों accounts पर Recovery Key सेट कर दी, जो हम पहले से ही इसलिए करने वाले थे कि Apple या Apple पर दबाव डालने/कब्ज़ा करने वाला कोई भी व्यक्ति हमारे accounts तक पहुँच न पाए। इससे हमला तुरंत रुक गया
    इसी तरह, Advanced Data Protection आते ही हमने उसे भी चालू किया और web access बंद कर दिया। अब सिर्फ़ trusted devices ही data देख सकते हैं, और नया device registration भी सिर्फ़ trusted device से ही संभव है

    • मुझे नहीं पता था कि Recovery Key क्या है, लेकिन यह वही दस्तावेज़ है: https://support.apple.com/en-us/109345
      यह भी काफ़ी डरावना है। अगर key खो जाए, तो account recovery में कोई भी मदद नहीं कर सकता
    • Recovery Key इस्तेमाल करने पर समस्या रुक गई थी, यह दिलचस्प है, लेकिन लगता है अब यह वह काम नहीं कर रही
      लेख के मुताबिक, “Ken said he enabled a recovery key for his account as instructed, but that it hasn’t stopped the unbidden system alerts from appearing on all of his devices every few days.
      KrebsOnSecurity tested Ken’s experience, and can confirm that enabling a recovery key does nothing to stop a password reset prompt from being sent to associated Apple devices.”
    • यह तरीका अपने आप में नया नहीं है, लेकिन यह कई लोगों पर चलाया जा रहा हालिया campaign लगता है। बहुत संभव है कि किसी ने हाल की leak dump से hacked passwords की सूची हासिल की हो और उसमें मौजूद Apple accounts को छाँट रहा हो
    • कुछ YubiKey, कम से कम तीन, खरीदना और Apple ID authentication में बेवकूफ़ाना push MFA की जगह उनका इस्तेमाल करना बेहतर रहेगा
      https://support.apple.com/en-gb/HT213154
    • हैरानी होती है कि इसमें स्पष्ट रूप से rate limiting नहीं है। दो बार कोशिश के बाद 15 मिनट में एक बार, फिर एक घंटा, 4 घंटे, एक दिन जैसे अंतर बढ़ने चाहिए। इसे failed login attempts की तरह handle किया जा सकता है

  • अगर Allow दबाने के बाद किसी दूसरे device से password reset किया जा सकता है, तो वह message बेहद ख़राब design है। उसमें साफ़ Use this iPhone to reset लिखा है, इसलिए Allow दबाने वाले को यही लगा होगा कि उसी device पर नया password सेट करने का flow है
    लेकिन अगर यह Apple Watch पर भी दिखता है, तो इसका मतलब यह सिर्फ़ silent mode को नज़रअंदाज़ करने वाली simple phone alert mirroring नहीं है; यह कल्पना करना मुश्किल है कि इरादा यह था कि watch पर Allow दबाओ और फिर उसी keyboard से password डालो

    • मुझे नहीं लगता कि सिर्फ़ Allow दबाने में अपने आप कोई ख़तरा है। उसके बाद भी 2-factor authentication है, और नया password भी चुनना पड़ता है। पूरा ख़तरा फ़ोन कॉल से आता है, जहाँ लगता है कि 2FA code निकलवाने की कोशिश की जाती है
    • जब मेरी 90 साल की माँ iMac का password भूल गई थीं, तब इस feature ने सचमुच बचा लिया था। मैं यह भी भूल गया था कि मैंने दूसरा admin account बना रखा था
      iMac में lock हो जाने के बाद भी iPad खुल रहा था, इसलिए reset किया जा सका। iPad PIN भी माँ भूल गई थीं, लेकिन शुक्र है कि वह कहीं लिखा हुआ मिल गया

  • एक बिंदु के बाद तो लगता है कि Apple डिवाइस पर ऐसे prompt दिखाए जा सकना ही अपने आप में समस्या है। पिछले साल चर्चा में रहे Bluetooth-आधारित नए डिवाइस setup prompt का मामला भी ऐसा ही था
    बेशक password reset संभव होना चाहिए, लेकिन लेख के मुताबिक कम समय में 30 password reset request भेजना संभव लगता है
    गैर-शरारती स्थिति में ऐसा होने की आखिर क्या वजह हो सकती है?

    • कोई वजह नहीं। बस ऐसी verification logic जोड़ी ही नहीं गई। इसका मतलब यह भी नहीं कि Apple को ज़रूर बहुत कड़े तौर पर कोसा जाए
      बाद में देखें तो यह स्वाभाविक लगता है, लेकिन sprint, OKR/KPI और promotion materials के बीच ऐसे कम चमकदार features आसानी से छूट जाते हैं

  • ऐसी calls का एक और मकसद यह हो सकता है कि भरोसेमंद voice cloning के लिए पर्याप्त sample इकट्ठा करने के चरण तक पहुँचने में कितना समय लगता होगा

    • इसका एक variant पहले से है, जिसमें किसी से “yes” कहलवाकर उसकी recording को किसी contract पर सहमति के “सबूत” की तरह इस्तेमाल करने की कोशिश की जाती है
    • सिर्फ 100 बार “hello?” बोलने से शायद voice cloning नहीं हो जाएगी। लेकिन voice cloning के लिए MFA bombing ज़रूरी भी नहीं है
      किसी plausible बहाने से call करके सामने वाले को लंबी बातचीत में उलझाना काफी है। जैसे “मैं Uber/Doordash driver हूँ”, “मैं hospital/school/daycare से बोल रहा/रही हूँ” वगैरह
    • यह एक और वजह है कि phone या phone number से user authentication नहीं करना चाहिए। तथाकथित voice identification या voice ID भी उन्नत voice cloning से आसानी से टूट सकती है

  • थोड़ा भ्रम है। Allow दबाने पर उसके बाद ठीक क्या होता है? समझ नहीं आ रहा कि Apple iForgot website पर मौजूद व्यक्ति को password reset form दिखाता है, या यह सिर्फ डिवाइस पर ही दिखता है

    • लगता है डिवाइस पर verification code दिखता है। उसके बाद scammer call करके वह code निकलवाने की कोशिश करता है

  • इसमें यह हिस्सा है कि iPhone पर call ऐसे दिखी जैसे Apple Support से आई हो, और नंबर भी Apple का असली customer support नंबर 1-800-275-2273 था
    मेरे साथ भी यह ठीक एक बार हुआ था, online Apple Store से नया MacBook order करने के दो दिन बाद। मैं delivery का इंतज़ार कर रहा था, इसलिए लगभग फँस ही गया था, लेकिन मैंने खुद Apple Support पर call करके पूछा कि क्या उन्होंने अभी call किया था, और जवाब मिला कि नहीं

    • जिज्ञासा है कि क्या order नया model आने के तुरंत बाद किया गया था, या order के तुरंत बाद call आना बस संयोग से सही बैठ गया

  • Instagram में भी यही समस्या है। यह समझ से बाहर है कि इतनी बड़ी कंपनियाँ account recovery flow पर rate limit नहीं लगातीं

    • rate limit जोड़ने में दिक्कत यह है कि, खासकर अगर user-आधारित global limit लगाई जाए, तो इस बार लोगों को account recover करने से रोकने वाली नई denial-of-service समस्या पैदा हो सकती है

  • कुछ दिनों से मेरे LinkedIn account पर भी ऐसा हो रहा है। हर कुछ घंटों में magic login link वाला email आता है, जो दुनिया के अलग-अलग इलाकों से भेजा गया लगता है और वैध दिखता है

    • मेरे साथ भी कल हुआ था और पहले मैं घबरा गया, लेकिन फिर समझ आया कि LinkedIn account से जुड़ा email पता भर पता हो तो one-time password request किया जा सकता है। इसलिए password leak नहीं हुआ था
      फिर भी मैंने password और primary email बदल दिए, और LinkedIn privacy settings में email visibility भी हटा दी
    • मुझे भी ऐसे मिलते हैं। मैं पहले से TOTP और Passkey जैसे कई तरह के 2-step authentication इस्तेमाल करता हूँ, इसलिए अच्छा होता अगर account में इस feature को बंद किया जा सकता
    • मेरे मामले में यह Uber था

  • push MFA मुझे शुरू से ही पसंद नहीं था
    समझ नहीं आता कि एक code डालना इतना मुश्किल कैसे है। आखिर में push bombing रोकने की कोशिश करते-करते फिर code माँगने वाले push notification पर लौटना पड़ता है

    • Apple ID MFA में इसके बदले HSM इस्तेमाल किया जा सकता है। मैंने भी इसी मकसद से अलग-अलग जगहों पर 3 YubiKey रखे हुए हैं
      https://support.apple.com/en-gb/HT213154
    • कम से कम iCloud login में, password reset में भी ऐसा है या नहीं यह जाँचने की मुझे आलस है, Allow दबाने से login allow नहीं होता, बल्कि login में डालने के लिए सिर्फ 6-अंकों का code दिखता है