नवीनतम Instagram “exploit” मेरे देखे सबसे बेहूदा मामलों में से एक है

 (0xsid.com)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Instagram अकाउंट के username भर से Meta customer support AI को धोखा देकर password reset और account takeover संभव करने वाली एक vulnerability के कारण Obama White House अकाउंट समेत कई मशहूर अकाउंट प्रभावित हुए
  • हमलावर पीड़ित के शहर के आसपास के VPN·proxy से कनेक्ट होकर security algorithm के शक से बचते हैं, फिर support AI से कहते हैं कि "अकाउंट hack हो गया है" और verification code को अपनी मनचाही email पर भेजने का अनुरोध करते हैं
  • उस email के बारे में यह बिना किसी अतिरिक्त सत्यापन के कि वह पहले कभी उपयोगकर्ता द्वारा इस्तेमाल की गई थी या नहीं, code भेज दिया जाता है; हमलावर code वापस दे देता है और password reset link सीधे मिल जाता है — यह एक zero auth password reset है
  • क्योंकि इस recovery flow को मालिक स्वयं द्वारा किए गए पूरे account reset की तरह प्रोसेस किया जाता है, मौजूदा 2FA bypass हो जाता है
  • $1.5 trillion की कंपनी के support AI में सिर्फ अनुरोध करने भर से linked email बदल देने जैसी guardrail की कमी मूल समस्या थी, और इसे patch किया जा चुका है लेकिन यह कई हफ्तों से महीनों तक सक्रिय था

अकाउंट takeover का flow

  • Step 01 — लोकेशन छिपाना और support request शुरू करना

    • हमले की शुरुआत के लिए लक्ष्य अकाउंट का सिर्फ username चाहिए, और public profile या "About" section जैसे कई रास्तों से उपयोगकर्ता की location आसानी से पता की जा सकती है
    • पीड़ित के शहर के पास के VPN या proxy से कनेक्ट होकर request region को सामान्य जैसा दिखाया जाता है ताकि Instagram security algorithm को शक न हो
    • जब request सही region से आई हुई लगे, तो Meta support AI से कहा जाता है कि अकाउंट hack हो गया है और verification code को हमलावर द्वारा नियंत्रित किसी email पर भेजने को कहा जाता है

  • Step 02 — बस इतना ही

    • असल में प्रक्रिया यहीं खत्म हो जाती है, और production में देखा गया यह पहला zero auth password reset मामला है
    • दी गई email वास्तव में उपयोगकर्ता द्वारा पहले इस्तेमाल की गई थी या नहीं, इसकी कोई अतिरिक्त जांच नहीं होती
    • AI जब हमलावर की email पर security code भेज देता है, तो हमलावर वही code वापस देकर verification पूरा कर देता है; platform नया password reset link दे देता है और पूरी ownership transfer हो जाती है

  • वीडियो सेल्फी सत्यापन

    • Instagram AI पहचान साबित करने के लिए video selfie मांग भी सकता है और नहीं भी
    • अभी इसकी पहचान क्षमता बहुत मजबूत नहीं मानी जाती; व्यापक रूप से रिपोर्ट है कि target feed की public photos को AI से animate करने भर से भी यह पास हो जाता है

2FA भी नहीं रोक पाता

  • क्योंकि system इस high-privilege recovery flow को "असली" मालिक द्वारा किया गया पूरा account reset मानता है, इसलिए इस प्रक्रिया में मौजूदा 2FA पूरी तरह bypass हो जाता है
  • मौजूदा sessions समाप्त कर दिए जाते हैं और password बदल दिया जाता है, लेकिन email·SMS·push notification बिल्कुल नहीं भेजे जाते
  • वास्तविक मालिक recovery शुरू भी नहीं कर पाता क्योंकि email और phone number पहले ही हमलावर से map हो चुके होते हैं, और escalation के लिए कोई व्यक्ति न होने से वह chat support से जूझते हुए control वापस पाने की कोशिश करता है
  • अगर अकाउंट A/B test के तहत AI support option enabled समूह में है, तो उस option को बंद भी नहीं किया जा सकता

ब्लैक मार्केट में तेजी

  • कई black market Telegram groups ऊंची कीमत और तेज़ turnaround time का दावा करते हुए "account takeover" service दे रहे हैं
  • short handle की कीमत सैकड़ों हजार डॉलर से लेकर कई million dollar तक हो सकती है, इसलिए ऐसे market का बनना आश्चर्यजनक नहीं है
  • वास्तविक उदाहरणों में hey जैसे अकाउंट का सौदा होना, या obamawhitehouse और ocmssf (अमेरिकी Space Force के Chief Master Sergeant का अकाउंट) जैसे हैंडल का propaganda के लिए दुरुपयोग शामिल है

अभी patch हो चुका है

  • Meta ने इसे पहले ही patch कर दिया है और Telegram groups भी शांत हो गए हैं, लेकिन यह तरीका कई हफ्तों से महीनों तक सक्रिय रहा था
  • $1.5 trillion की कंपनी के पास मजबूत guardrails न होना, और support AI का पर्याप्त विनम्र अनुरोध मिलने पर किसी का भी linked email बदल देना, यही असली समस्या है

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • बड़ी कंपनियों की security chain में support request हमेशा सबसे कमज़ोर कड़ी रही है
    पहले भी किसी इंसान ने 2FA बंद करके मेरा account किसी और को दे दिया था, इसलिए अगर अब LLM वही काम कर रहा है तो इसमें बहुत हैरानी नहीं होनी चाहिए
    यह बात ही गुस्सा दिलाती है कि निचले स्तर का support staff 2FA disable कर सकता है, क्योंकि इससे पूरी प्रक्रिया का मकसद ही खत्म हो जाता है

    • recovery flow आखिरकार fail safe या fail secure में से एक ही हो सकता है
      अगर वह fail secure है, तो email खोते ही account हमेशा के लिए lock हो जाता है; और अगर वह fail safe है, तो email खोने पर account हमेशा के लिए lock नहीं होता, लेकिन कोई उस स्थिति का नाटक करके account हथिया सकता है
      यह वैसा ही है जैसे electronic door controller की power चली जाए तो दरवाज़ा या तो locked रहे या खुला रहे; आग लगने पर लोगों को बाहर निकलना होता है, इसलिए खुला रहना चाहिए, लेकिन चोर power काटकर अंदर आ सकते हैं
      power outage में स्थायी रूप से lock हो जाने वाला दरवाज़ा सिर्फ़ बहुत चरम security-first मामलों में ही स्वीकार्य है, और Instagram account आग की स्थिति वाले दरवाज़े जितना महत्वपूर्ण नहीं है
    • Crazy Domains मेरे ccTLD registrars में से एक था, और जब मेरा account hijack हो रहा था, तब मैंने फ़ोन पर साफ़ कहा था कि ऐसा मत करना, फिर भी उन्होंने 2FA हटा दिया [1][2]
      इससे भी बुरी बात यह थी कि बाद में, शायद support system बदलने के बाद, उसी hijacker ने फिर से मेरा account निशाना बनाया, और कुछ घंटों के लिए वह सचमुच hijack हो गया, यहाँ तक कि मेरा Twitter account भी compromise हो गया
      यह सब लगभग उसी समय हुआ जब fElon बड़े पैमाने पर layoffs कर रहा था और accounts से phone-based 2FA हटा रहा था
      Crazy Domains और Newfold Digital (पहले EIG) सच में सबसे घटिया हैं, और आखिर में fElon ने Grok की बकवास में इस्तेमाल करने के लिए मेरा OG username भी छीन लिया, इसलिए वह भी चला गया
      [1] https://news.ycombinator.com/item?id=47913341
      [2] https://news.ycombinator.com/item?id=47859496
      [3] https://news.ycombinator.com/item?id=47856983
    • HN के लोगों को नाम सुनते ही समझ आ जाने वाली एक बड़ी storage appliance vendor के साथ हुआ अनुभव सबसे अजीब और डरावना था
      हमें तुरंत जगह खाली करने के लिए एक storage volume delete करना था, लेकिन वह destructive action होने के कारण इस तरह locked था कि vendor को हमारी तरफ़ की key के साथ दूसरी key की भूमिका निभानी पड़ती थी
      हमने यह setup कभी ठीक से configure नहीं किया था, और मैंने तो उनके support account में कभी login भी नहीं किया था
      vendor ने कहा कि हमारी तरफ़ के दो approved contacts को इस action की पुष्टि करनी होगी, और असल प्रक्रिया बस इतनी थी कि Sev1 incident संभाल रहा एक सहकर्मी मुझे Zoom call पर ले आया
      support representative ने मेरा 2FA मांगा, लेकिन जब मैंने कहा कि मैंने कभी सेट नहीं किया और कोई email भी दर्ज नहीं है इसलिए मैं उसे पा नहीं सकता, तो outsourced लगने वाले उस representative ने code Zoom chat में paste कर दिया और यह मान लिया कि मेरा उसे फिर से पढ़ देना प्रक्रिया आगे बढ़ाने के लिए काफ़ी है
      उस समय मैं इतना हैरान था कि ज़्यादा गहराई से सोच नहीं पाया, लेकिन यह दिलचस्प था कि वे expected generated code देख सकते थे और उसे अपने system में सीधे डाल भी सकते थे
      नतीजतन इसने Sev1 को Sev0 बनने से तो रोक दिया, लेकिन कुल मिलाकर यह social engineering और insider attacks के लिए बेहद कमज़ोर संरचना है
      ऐसा नहीं लगता कि इस तरह की bypass authority साफ़ तौर पर tier-1 या tier-2 support staff को दी गई होगी; शायद इसे किसी ऊँचे privilege स्तर पर छिपाकर रखा गया होगा, जहाँ escalation चाहिए, लेकिन समय घंटों नहीं बल्कि मिनटों में हो सके
      फिर भी, organization जितनी बड़ी होती है, इस तरह का संतुलन उतना ही मुश्किल हो जाता है
    • account hijack होने के बाद recovery भी fail हो गई
      मेरे पिता का Facebook account शायद phishing से hack हो गया था, लेकिन उसे वापस पाने के लिए संपर्क करने लायक कोई इंसान ही नहीं था
      account चुराने वाले कचरे ने उसमें illegal content भी पोस्ट कर दिया, और account के साथ लगभग 10 साल की निजी यादें भी बिना किसी remedy process के delete हो गईं; Meta में किसी असली इंसान से बात करना नामुमकिन था
      बस पागल कर देने वाले, बिल्कुल बेकार FAQ pages थे
      मैं ज़ोर देकर सलाह देता हूँ कि अपने और अपने परिवार के सभी social media accounts से personal data डाउनलोड करके backup रख लें
      इन बड़ी कंपनियों को users की परवाह सिर्फ़ उतनी है जितनी China से सीधे आने वाले बेतुके सामान के ads और AI कचरा TikTok दिखाने के लिए ज़रूरी हो
    • अगर कोई account 14 साल से ज़्यादा समय से वही email और phone number इस्तेमाल कर रहा है, और support team फिर भी यह मान ले कि वह hacked है, तो यह उससे भी ज़्यादा शर्मनाक लगता है

  • क्या AI agent के पास ऐसा privileged access था कि वह 2FA हटा सके, account email को नज़रअंदाज़ कर सके, और account requester को सौंप भी सके?
    सच कहूँ तो यह इतनी गंभीर लापरवाही लगती है कि शक होता है कहीं उस “feature” को बनाने वाली team ने तयशुदा layoffs से पहले Meta को जितना हो सके उतना छिपा हुआ नुकसान पहुँचाने की कोशिश तो नहीं की
    लगभग अफ़सोस होता है कि किसी ने पूरी operations table delete करने की भी कोशिश नहीं की
    बस किसी high-privilege SRE होने का नाटक करके यह दावा करना था कि किसी fatal production bug को ठीक करना है और उसका एकमात्र समाधान database delete करना है

  • मैं Instagram के शुरुआती 6000 यूज़र्स में था, और मेरा बिल्कुल शब्दशः वाला username कई साल पहले चुरा लिया गया था
    verified account support टीम ने समस्या मानी थी, लेकिन कहा कि वे कुछ नहीं कर सकते
    इस बार मामला AI के दुरुपयोग का है, लेकिन मेरे मामले में outsourced support का दुरुपयोग हुआ था, और किसी ने पैसे देकर मेरा username मैन्युअली बदलवाया और फिर दूसरे यूज़र को दिला दिया
    अगर ज़िम्मेदार human support मौजूद नहीं है और नियम तोड़ने वाले कर्मचारियों पर कोई आपराधिक नतीजा नहीं होता, तो अकाउंट तक पहुँचने का रास्ता हमेशा निकल आता है

    • हाल ही में मेरा Threads अकाउंट इस वजह से suspend हो गया कि मैंने पाँच पोस्ट पर बहुत जल्दी like कर दिया था, और कहा गया कि अकाउंट अप्रामाणिक है
      जुड़ा हुआ Instagram अकाउंट ठीक था, लेकिन जब मैंने Meta Verified support इस्तेमाल करने की कोशिश की तो कहा गया कि मैं अपना support quota पहले ही पूरा इस्तेमाल कर चुका हूँ, और मेरी सभी requests ठुकरा दी गईं
    • रैपर्स पहले मेरे Instagram username के लिए 10,000 डॉलर ऑफर कर चुके हैं
      मैं तब तक रुका हूँ जब तक कोई बैंक इसे खरीदने न आ जाए
    • क्या इस पर मुकदमा किया जा सकता है? लगता है इस अपराध के पीछे आर्थिक मकसद हो सकता है
    • जिस दिन किसी कर्मचारी पर username “चुराने” के लिए आपराधिक मुकदमा चलेगा, वही दिन होगा जब मानवता सच में हार गई होगी

  • यह बिल्कुल बेहूदा है कि AI को किसी भी मनमाने पते पर email भेजने की tool permission दी गई
    यूज़र की request पर 2-step verification code भेजना अपने आप में समझ में आता है, लेकिन उसे सिर्फ अकाउंट से जुड़े पते पर 2-step verification email भेजने वाला बटन दबाने की ही अनुमति होनी चाहिए, और बाकी काम हाथ से लिखे code को करना चाहिए
    AI के पास 2-step verification code, message subject, body, recipient address वगैरह तक पहुँचने की कोई वजह नहीं है
    समझ नहीं आता ऐसी permission दी ही क्यों गई

    • यह exploit मूल रूप से AI से बहुत कम जुड़ा है, और ज़्यादा बेहद खराब तरीके से डिज़ाइन किए गए account recovery flow से जुड़ा है
      यही flow static code से भी बनाया जा सकता था, और शायद वास्तव में ऐसा ही किया गया हो
      यहाँ chatbot ने असल में कितना किया, यह पता नहीं
    • मैं Meta और Instagram पर बहुत bug bounty research करता हूँ, और जिन bugs को मैं ढूँढता हूँ उनमें कुछ ऊपर से इतने साधारण दिखते हैं, लेकिन असल वजह थोड़ी जटिल होती है
      ज़रूरी नहीं कि इस बार भी वही मामला हो, लेकिन मेरे पास इस बारे में एक अंदाज़ा है कि वास्तव में क्या हुआ होगा
      अब तक जो दिखा है, उसके आधार पर लगता है कि Meta AI Support Assistant, यानी “MAISA”, के पास a) किसी खास email, phone number, या अकाउंट से जुड़े contact point पर email verification शुरू करने वाला tool call था, और b) email verification attempt के आधार पर अकाउंट का password reset link जनरेट करने वाला tool call था
      मुझे असली code तक पहुँच नहीं मिली, लेकिन लगता है कि email verification attempt का handle या ID और यूज़र द्वारा डाला गया verification code “password reset link generate” tool call को पास किया गया, और उस tool call ने यह ठीक से verify नहीं किया कि उस verification attempt में इस्तेमाल किया गया email सच में उसी अकाउंट का है या नहीं, जिससे account takeover संभव हो गया
      MAISA का password reset link जनरेट करने वाला tool call तब fail होना चाहिए था जब verification attempt ऐसे email के लिए हो जो अकाउंट से जुड़ा न हो
      जब मैंने Facebook पर कुछ ऐसा ही test किया था, तब वह सच में error देकर रुक गया था, लेकिन संभव है कि Instagram की तरफ़ हाल में ऐसा बदलाव किया गया हो ताकि attacker द्वारा hijack किए गए अकाउंट को recover करने के लिए हाल में unlink किए गए थोड़े पुराने email का भी इस्तेमाल किया जा सके
      तब मौजूदा अकाउंट से जुड़े बिना भी उस email का इस्तेमाल करना और उसे यूज़र के primary email के रूप में सेट करने की ज़रूरत पड़ती
      यह भी हो सकता है कि MAISA tool call में बदलाव के दौरान गलत API call कर दी गई हो, या कुछ ऐसा बना दिया गया हो जिससे कोई भी सफल email verification attempt इस्तेमाल हो सके, और engineers ने tool call में असंबंधित email verification attempts डालकर end-to-end testing पर्याप्त नहीं की हो
      मुझे लगता है ध्यान सबसे ज़्यादा यहीं होना चाहिए
      attacker जिन agent tool calls के output को प्रभावित कर सकता है, उन्हें किसी public external API की तरह treat करना चाहिए और उसी तरह test करना चाहिए
      बेशक यह सब अनुमान है, और account recovery attempts की वैधता तय करने वाले कई signals को इसमें शामिल नहीं किया गया है, इसलिए यह काफी हद तक गलत भी हो सकता है, लेकिन Meta security पर बहुत काम करने के नाते यह मुझे सबसे नज़दीकी व्याख्या लगती है कि यह कैसे संभव हुआ होगा
    • इसमें vibe coding की तेज़ गंध आती है
      जैसे किसी ने कहा हो, “AI agent को password reset में मदद करने दो,” और उस बदलाव की कोई human review हुई ही न हो
    • यह बुरा है, लेकिन इस तरह की चीज़ के चलने के लिए AI ज़रूरी नहीं है
      कुछ साल पहले मेरा Facebook अकाउंट भी TOTP-आधारित 2-step verification disable होने के बाद compromise हो गया था
      तब भी मुझे Facebook की security policy पर बिल्कुल भरोसा नहीं हुआ था, और यह नया attack उसी धारणा की फिर पुष्टि करता है
    • लगता है किसी junior engineer ने बेवकूफ़ाना support requests संभालते-संभालते तंग आकर इसे agent के ज़रिए automate कर दिया होगा
      security support पर junior engineers लगाना हास्यास्पद है
      इसकी एक वजह यह भी है कि युवा लोग हमेशा नहीं समझते कि security कभी-कभी कितनी विनाशकारी हो सकती है, और वे privacy को भी उतनी गंभीरता से नहीं लेते

  • इसे “production में देखा गया पहला सही मायनों वाला unauthenticated password reset” कहा गया, लेकिन LinkedIn में पहले भी ऐसा कुछ था
    शायद यह bug bounty rewards शुरू होने से पहले की बात थी, इसलिए कोई ढंग का जवाब नहीं मिला, लेकिन आखिरकार इसे ठीक कर दिया गया
    तरीका यह था
    LinkedIn मानता था कि अगर आप किसी पते पर भेजी गई mail पढ़ सकते हैं, तो वह पता आपका है और उसे अकाउंट में जोड़ा जा सकता है
    इसलिए अगर मैं किसी email address पर LinkedIn invitation भेजूँ और सामने वाला invitation accept बटन दबा दे, तो वह email address उसके अकाउंट में जुड़ जाता था
    अगर मैं अपने control वाले पते, जैसे foo@example.com, पर invitation भेजकर forged email के अंदर का invitation button link किसी और को भेज दूँ, तो जैसे ही वह व्यक्ति क्लिक करता, foo@example.com चुपचाप उसके अकाउंट में जुड़ जाता था
    जब friend बन जाने का response मिलता, तो यह भी पता चल जाता कि उस यूज़र अकाउंट में मेरे जानने वाला email address जुड़ गया है, और फिर मैं शुरू में भेजे गए foo@example.com का इस्तेमाल करके पूरा password reset कर सकता था
    यह तब पता चला जब किसी ने पूरी mailing list को invite कर दिया, और click होने के बाद mailing list address कई लोगों के अकाउंट्स में अचानक जुड़ गया

    • जहाँ तक याद है, पुराने LinkedIn को address book या जो भी उसे मिल जाए, उसमें खोजकर पूरी address book को email भेजने की आदत थी

  • “अगर अनुरोध सही क्षेत्र से आया हुआ दिखे, तो Meta support AI से कहो कि अकाउंट hack हो गया है और verification code हमलावर के नियंत्रण वाले किसी भी email address पर भेज दे” — Instagram आखिर कर क्या रहा है?
    समझ नहीं आता कि reset को उसी अकाउंट पर भेजने के बजाय किसी भी email पर क्यों भेजा जा रहा है

    • हो सकता है हमलावर ने यह भी कहा हो कि email भी hack हो चुका है और “यह अब मेरा नया email है”
      यह किसी असली इंसान के बजाय AI support का नतीजा लगता है, और स्थिति कुछ ऐसी है कि “अगर आपका अकाउंट उस A/B test group में है जहाँ AI support option enabled है, तो आपकी किस्मत खराब है; इसे बंद भी नहीं किया जा सकता”

  • मैं सोच रहा था कि पूरे weekend में मुझे Instagram password reset email 15 बार क्यों मिले
    इसी वजह से मुझे याद आया कि मेरा Instagram अकाउंट भी है, और मैं तुरंत login करके उसे delete करना चाहता था
    वह अकाउंट तब बनाया था जब Instagram नया-नया आया था, उसे कभी इस्तेमाल नहीं किया, और मैं उसे पूरी तरह भूल चुका था
    लेकिन मैं ऐसी अजीब स्थिति में फँस गया जहाँ login उसी device से करना था जिससे पहले कभी login किया गया हो, और 10 साल से भी ज़्यादा समय बीत चुका है, इसलिए अकाउंट बनाने या access करने में इस्तेमाल हुआ कोई भी device अब मेरे पास नहीं है
    अकाउंट से जुड़ी email और phone number — दोनों तक मेरी पहुँच थी, लेकिन उससे भी काम नहीं बना
    यह इतनी हास्यास्पद हद तक अयोग्यता थी कि मैंने CCPA complaint दर्ज कर दी

    • मेरे कुछ पुराने Gmail अकाउंट्स में भी मैं इसी तरह lock out हो गया था
      वे बिना phone number के बनाए गए थे, मुझे password भी पता है, लेकिन login करने पर उन्हें suspicious activity के रूप में flag कर दिया जाता है और कोई workable recovery flow नहीं है
    • कंपनी से नफरत के विरोध में अकाउंट delete मत करो; उसे spam operator को सौंपना कंपनी को ज़्यादा नुकसान पहुँचाएगा

  • यह हमेशा थोड़ा ज्ञानवर्धक लगता है कि बहुत-से abuse इतने बेवकूफाना दिखते हैं कि अगर मैं होता तो कोशिश भी न करता
    क्या बस password माँग लेना ही काफी है, और वही काम कर जाता है?

  • इस घटना के निहितार्थ काफ़ी परेशान करने वाले हैं
    क्या Meta ने बिना human review के user accounts पर privileged read-write access किसी agent को दे दिया?

    • अगर ऐसा है, तो यही तो वह चीज़ है जो AI समर्थक हम सब से करवाना चाहते हैं
    • सिर्फ human review नहीं था ऐसा नहीं, लगता है बुनियादी verification भी नहीं थी
      यह पागलपन है
    • यह किसी LLM agent द्वारा arbitrary write access इस्तेमाल करने से ज़्यादा, पहले से परिभाषित account recovery flow जैसा लगता है
    • अगर human को loop में बनाए रखोगे, तो उन्हें निकाला नहीं जा सकेगा, इसलिए ऐसा किया गया

  • मेरे एक Facebook alt account की credentials किसी तरह मेरे एक दूसरे पुराने alt account के साथ merge हो गई हैं
    यानी एक अकाउंट की email से दूसरे अकाउंट में login किया जा सकता है, और लगता है यह merge अब भी बना हुआ है
    लगता है Meta ने किसी तरह तय कर लिया कि ये दोनों अकाउंट एक ही व्यक्ति के हैं