Google उपयोगकर्ताओं के फ़ोन नंबर पर brute-force हमला

• Google के No-JS username recovery form ने फ़ोन नंबर और display name के संयोजन की पुष्टि कर दी, जिससे किसी खास Google उपयोगकर्ता का पूरा फ़ोन नंबर पता लगाने वाली attack chain बन गई
• मुख्य बात /signin/usernamerecovery और /signin/usernamerecovery/lookup के redirect में अंतर की थी, जिससे account न होने और account मौजूद होने की स्थिति अलग की जा सकती थी
• IP-आधारित request limit और CAPTCHA मौजूद थे, लेकिन JS form के BotGuard token को No-JS form के bgresponse में डालने पर यह बिना limit के काम करने लगा, और इसे IPv6 rotation के साथ जोड़ा गया
• हमलावर Looker Studio से Google account display name हासिल कर सकता था, और password recovery flow में masked फ़ोन नंबर व देश-वार number format को मिलाकर candidates की संख्या काफी घटा सकता था
• प्रति घंटा $0.30 वाले 16 vCPU-class server पर लगभग 40,000 checks प्रति सेकंड संभव थे, और Google ने 6 जून 2025 को No-JS username recovery form को पूरी तरह बंद कर दिया तथा कुल $5,000 का भुगतान किया

---

No-JS username recovery form से शुरू हुई vulnerability

• browser में JavaScript बंद करके Google services का व्यवहार जांचते समय पाया गया कि username recovery form अब भी काम कर रहा था
• account recovery form को लंबे समय से obfuscated proof-of-work JavaScript code द्वारा बनाए जाने वाले BotGuard-type defenses पर निर्भर माना जाता था, इसलिए JavaScript ज़रूरी समझी जाती थी
• लेकिन No-JS form ऐसा flow देता था जिससे यह जांचा जा सकता था कि recovery email या फ़ोन नंबर किसी खास display name से जुड़ा है या नहीं

दो requests से account मौजूद है या नहीं, इसकी पुष्टि

• पहली request में /signin/usernamerecovery पर फ़ोन नंबर भेजा जाता है, और response के Location से उस फ़ोन नंबर से जुड़ा ess value लिया जाता है
  • cookies और gxf value शुरुआती page HTML से ली जाती हैं
• इसके बाद /signin/usernamerecovery/lookup पर ess, first name, last name, bgresponse=js_disabled डालकर भेजा जाता है
• response redirect बदल जाता था, जिससे यह तय किया जा सकता था कि उस फ़ोन नंबर और display name वाला Google account मौजूद है या नहीं
  • account नहीं: usernamerecovery/noaccountsfound
  • account मौजूद: usernamerecovery/challenge

IP limits, IPv6, और BotGuard bypass

• शुरुआती कोशिशों में कुछ requests के बाद IP address request limit में फंस गया और CAPTCHA दिखा
• Netherlands mobile number के उदाहरण में password recovery flow •• ••••••03 जैसा hint देता है
  • Netherlands mobile numbers 06 से शुरू होते हैं, इसलिए बाकी 6 digits, यानी 10^6 = 1,000,000 candidates आज़माने पड़ते हैं
• Vultr जैसे providers /64 IPv6 range देते हैं, और सिद्धांत रूप में 18,446,744,073,709,551,616 addresses इस्तेमाल किए जा सकते हैं
• reqwest के ClientBuilder.local_address से हर request के लिए subnet का random IPv6 address set करने वाला PoC बनाया गया
• datacenter IP से JS-disabled form इस्तेमाल करने पर CAPTCHA लगातार आता रहा, लेकिन JS-enabled account recovery form के BotGuard token को No-JS form के bgresponse में डालने पर requests पास हो गईं
  • No-JS form में उस BotGuard token पर request limit नहीं दिखी

गलत hits को छांटना

• पहली run के results में ऐसे कई accounts शामिल थे जिनका first name Henry था, last name खाली था, और फ़ोन नंबर के आखिरी दो digits 03 थे
• इस case में अगर first name Henry हो, तो last name कोई भी हो, usernamerecovery/challenge return होता था
• संभावित hits verify करने के लिए उसी first name के साथ 0fasfk1AFko1wf जैसा random last name डालकर फिर से check किया गया
  • अगर फिर भी hit आता, तो उसे false positive मानकर filter किया गया
• यह संभावना कम मानी गई कि किसी दूसरे Google user का वही पूरा display name, वही country code और वही last two digits वाला number हो

country code और display name हासिल करना

• password recovery flow का फ़ोन नंबर mask country code अनुमान लगाने में इस्तेमाल किया जा सकता था
• Google हर number के national format के लिए libphonenumber इस्तेमाल करता है
• देश-वार masked national format इकट्ठा करके mask.json बनाया गया
  • Russia, Netherlands, UK, और US में अलग-अलग mask patterns हैं
• Google ने 2023 में policy बदली कि नाम तभी दिखाया जाए जब target के साथ direct interaction हो, और अप्रैल 2024 में Internal People API ने unauthenticated accounts के display name लौटाना पूरी तरह बंद कर दिया
• हालांकि Looker Studio document बनाकर उसका ownership victim को transfer करने पर, victim के interaction के बिना home screen पर display name expose हो जाता था

candidate range optimization और tools

• libphonenumber की number validation का इस्तेमाल करके देश-वार mobile prefixes, known area codes और digit counts वाला format.json बनाया गया
  • Netherlands example में country code 31, area codes 61, 62, 63, 64, 65, 68, और digit counts [7] शामिल हैं
• real-time libphonenumber validation से invalid numbers के लिए Google API queries घटाई गईं
• BotGuard token generation के लिए chromedp इस्तेमाल करने वाली Go script लिखी गई
  • http://localhost:7912/api/generate_bgtoken call से bgToken मिल सकता है
• पूरा attack flow तीन चरणों में चलता है
  • Looker Studio से Google account display name leak करना
  • password recovery flow से masked फ़ोन नंबर हासिल करना
  • display name और masked फ़ोन नंबर डालकर gpb से पूरा फ़ोन नंबर brute-force करना

brute-force performance और अनुमानित समय

• प्रति घंटा $0.30 server और consumer-grade 16 vCPU पर लगभग 40,000 checks प्रति सेकंड संभव थे
• password recovery flow में सिर्फ आखिरी दो digits मिलने पर अनुमानित समय:
  • US +1: 20 मिनट
  • UK +44: 4 मिनट
  • Netherlands +31: 15 सेकंड
  • Singapore +65: 5 सेकंड
• PayPal जैसी अन्य services के password reset flow अगर ज्यादा numeric hints दें, तो समय काफी घट सकता है
  • उदाहरण: +14•••••1779

Google report और action timeline

• 2025-04-14: vendor को report भेजी गई
• 2025-04-15: vendor ने report receive कर triage की
• 2025-04-25: “Nice catch!” response
• 2025-05-15: panel ने $1,337 + swag reward तय किया
  • आधार यह था कि abuse की संभावना कम है, और issue को high impact की abuse-related methodology माना गया
• 2025-05-15: reward के कारण पर आपत्ति दर्ज की गई
  • Abuse VRP table के अनुसार probability/exploitability attack prerequisites और इस बात से तय होती है कि victim abuse को detect कर सकता है या नहीं
  • यह बताया गया कि इस attack की कोई prerequisite नहीं है और victim abuse detect नहीं कर सकता
• 2025-05-22: panel ने अतिरिक्त $3,663 देकर कुल reward को $5,000 में adjust किया
  • likelihood को medium तक बढ़ाया गया
• 2025-05-22: vendor ने पुष्टि की कि global endpoints बंद करने से पहले चल रहे mitigations deploy कर दिए गए हैं
• 2025-05-22: 2025-06-09 publication schedule coordinate किया गया
• 2025-06-06: vendor ने No-JS username recovery form को पूरी तरह बंद करने की पुष्टि की
• 2025-06-09: report publicly release हुई