Google उपयोगकर्ता के फ़ोन नंबर पर brute-force हमला (Bruteforcing the phone number of any Google user)

• Google account recovery फ़ॉर्म को बायपास करके यह जाँचा जा सकता था कि किसी खास username से जुड़ा फ़ोन नंबर मौजूद है या नहीं
• JavaScript disabled वातावरण में भी BotGuard token को जानबूझकर inject करके IP rate limit को बायपास करने वाला हमला संभव था
• नीदरलैंड जैसे कुछ देशों में फ़ोन नंबर फ़ॉर्मैट की वजह से 10 लाख से कम combinations होते हैं, इसलिए proxy और IPv6 rotation के साथ बड़े पैमाने पर brute force व्यावहारिक था
• Google account का display name Looker Studio का उपयोग करके पीड़ित की किसी भी कार्रवाई के बिना आसानी से उजागर किया जा सकता था
• इस vulnerability की Google को रिपोर्टिंग और patching पूरी हो चुकी है, और वास्तविक attack chain में automation के जरिए बहुत कम समय में फ़ोन नंबर सत्यापित किए जा सकते थे

---

अवलोकन

यह लेख Google account के फ़ोन नंबर को brute-force हमले से पता लगाने के तरीके, उसकी प्रक्रिया, और defender side की प्रतिक्रिया तक का एक वास्तविक केस विस्तार से बताता है। आम तौर पर account recovery फ़ॉर्म JavaScript वातावरण और bot prevention सिस्टम का उपयोग करके abuse को रोकते हैं। लेकिन यह दिखाया गया कि JS बंद होने वाले वातावरण और एक खास पैटर्न के साथ इस सिस्टम को बायपास किया जा सकता है।

जाँच की पृष्ठभूमि और तरीका

• यह पाया गया कि Google का account username खोजने वाला फ़ॉर्म JavaScript के बिना भी काम करता है
• यह फ़ॉर्म किसी खास नाम (Display Name) से जुड़े फ़ोन नंबर के अस्तित्व को 2 HTTP requests से जाँचता था
  • पहली request: फ़ोन नंबर के आधार पर ess value (session token) प्राप्त करना
  • दूसरी request: ess और name (GivenName/FamilyName) parameters के साथ account के अस्तित्व का निर्धारण
• account मौजूद होने पर usernamerecovery/challenge redirect, और न होने पर noaccountsfound redirect मिलता था

IP limit bypass (proxy, IPv6 का उपयोग)

• शुरुआत में IP-आधारित rate limit और CAPTCHA की वजह से brute force संभव नहीं था
• नीदरलैंड के mobile numbers के मामले में 10 लाख combinations (prefix तय होने के कारण) होने से proxy के साथ यह व्यावहारिक था
• AWS/Vultr जैसे cloud के /64 IPv6 block का उपयोग करके हर request पर अलग address पर rotation संभव था, और server भी IPv6 सपोर्ट करता था

BotGuard token bypass

• JS फ़ॉर्म में BotGuard token की ज़रूरत होती थी
• No-JS फ़ॉर्म में bgresponse=js_disabled parameter की जगह JS फ़ॉर्म से जुटाया गया token डालने पर unlimited submissions संभव थीं
• एक multithreaded tool बनाया गया, जो बड़ी संख्या में फ़ोन नंबर डालकर तेज़ी से मौजूद accounts का पता लगा सकता था

false positives को हटाना (filtering)

• समान नाम/नंबर के आख़िरी 2 अंकों की शर्त के कारण एक से अधिक लोग match हो सकते थे
• random last name डालकर दोबारा test करने से false positive को अपने-आप filter करने वाला logic जोड़ा गया

देशवार फ़ोन नंबर फ़ॉर्मैट और name जानकारी संग्रह

• recovery फ़ॉर्म फ़ोन नंबर का masked format आंशिक रूप से देता था
• अलग-अलग देशों के फ़ोन नंबर pattern (national format) को Google की libphonenumbers जानकारी से समझा जा सकता था
• पीड़ित का display name Looker Studio में ownership transfer feature के दुरुपयोग से, बिना किसी user action के, पता लगाया जा सकता था

optimization और automation

• libphonenumbers से देशवार prefix/length/validity rules का dictionary बनाया गया
• Go-आधारित chromedp से BotGuard token auto-issuing API बनाया गया, जिससे वास्तविक हमले में automation संभव था

वास्तविक attack procedure

1. Looker Studio ownership transfer से पीड़ित का नाम (display name) प्राप्त करना
2. “पासवर्ड भूल गए” flow में उस email के फ़ोन नंबर की आंशिक masking जुटाना
3. gpb tool के जरिए name, masking, और country code के आधार पर brute-force हमला चलाना

समय और दक्षता

• 16 vcpu, 3000-thread server के आधार पर, प्रति सेकंड लगभग 40,000 checks
• देशवार number combinations और hint length के अनुसार अमेरिका (20 मिनट), ब्रिटेन (4 मिनट), नीदरलैंड (15 सेकंड), सिंगापुर (5 सेकंड) पर्याप्त थे
• अगर किसी दूसरी service से full hint मिल जाए (जैसे PayPal), तो समय और कम हो सकता था

Google और patch timeline

• 2025.4.14: Google को रिपोर्ट, 4.25 panel में acknowledgment
• 2025.5 मध्य: $5,000 bug bounty भुगतान
• 2025.5: No-JS फ़ॉर्म का gradual shutdown और mitigation लागू
• 2025.6.9: vulnerability का आधिकारिक खुलासा

निष्कर्ष

यह केस दिखाता है कि account recovery flow, फ़ोन नंबर masking, और display name जैसी कई जानकारियों के संयोजन से बड़े पैमाने पर automated हमला संभव हो सकता है। Google ने प्रक्रिया की कमजोरियों को सुधारकर और संबंधित फ़ॉर्म बंद करके प्रतिक्रिया पूरी कर ली।

संपर्क Signal/email (मूल लेख देखें) से किया जा सकता है

[GN⁺]

Hacker News राय

• इस लेख की दिलचस्प बात यह है कि ज़्यादातर होस्टिंग providers या ISP कम से कम एक /64 IPv6 block देते हैं, फिर भी अधिकांश rate limit या IP block अब भी single IP पर लागू होते हैं। IPv6 माहौल में rate limiting या blocking पूरे /64 block के आधार पर होनी चाहिए

  • अक्सर देखता हूँ कि जिन कंपनियों की ज़िम्मेदारी यह संभालना है, या जो इससे पैसे कमाती हैं, वे भी IPv6 प्रबंधन में अजीब प्रतिक्रिया देती हैं। मेरी कंपनी एक मशहूर CDN service इस्तेमाल करती है, लेकिन उसी /64 block के अंदर से कनेक्ट करने पर भी कभी-कभी “असामान्य IP से login” जैसी बेतुकी security alert मिलती है

  • IPv6 आने के बाद से पारंपरिक IP blocking काफ़ी हद तक बेअसर हो गई है। आम home internet user भी DHCPv6 Prefix Delegation से अपने-आप /56 या /48 block पा सकता है। उदाहरण के लिए, मुझे Comcast के ज़रिए /56 मिलता है, जिसे अधिकतम 65536 /64 blocks में बाँटा जा सकता है। IPv6 में असरदार IP filtering के लिए पुरानी single-IP आधारित नीति को सिर्फ /64 से बदल देना काफ़ी नहीं है

  • /64 block पर rate limit लगाना भी काफ़ी न हो सकता है। /48 block पाना भी बहुत आसान है। बेहतर control के लिए ASN के हिसाब से classify करना होगा, और हर provider IP कैसे allocate करता है, यह देखकर granularity adjust करनी होगी

  • IPv6 में /64 unit rate limiting उद्योग में पहले से अच्छी तरह जानी जाती है, और Google इसे दूसरी services पर लागू भी करता है। यह मुझे IPv6 अपनाने के दौरान पुरानी policies को ठीक से update न करने का नतीजा लगता है

  • BuyVM जैसी सस्ती होस्टिंग कंपनी भी अपने सबसे सस्ते plan में /48 address देती है ($2/माह, अभी सिर्फ $7/माह वाला stock में है)। इसलिए संदिग्ध operators इसे पसंद करते हैं

• मैंने पहले Facebook पर किसी खास व्यक्ति का phone number ढूँढने के लिए ऐसा ही तरीका आज़माया था। Password reset process में Facebook phone number का अधिकांश हिस्सा दिखा देता था, तो मैंने उन digits को vcard file में व्यवस्थित करके अपने phone में import किया और photo से मिलान किया। यह तरीका उम्मीद से ज़्यादा असरदार था

  • Google profile photo या Google apps में भी ऐसी ही कमज़ोरी है। जैसे अगर Google Maps review में John Smith दिखे, तो कई email variations ([e-mail], [e-mail] आदि) Hangouts में जोड़कर profile photo देखने से उसी व्यक्ति को track किया जा सकता है

  • इसी वजह से मैं अपना असली phone number कभी नहीं देता। Service चलाने के लिए इसकी ज़रूरत भी नहीं होती

• यह काफ़ी प्रभावशाली है कि एक व्यक्ति लंबे समय तक server पर 40k requests per second भेजता रहा, फिर भी resource usage बहुत नहीं बढ़ा या alarm नहीं बजे

  • हो सकता है alarm वास्तव में बजे हों, लेकिन activity जल्दी रुक गई हो या स्थिति इतनी जल्दी recover हो गई हो कि engineer के dashboard खोलने तक सब normal हो चुका हो। 40k QPS Focus या Google API के traffic scale पर इतना अलग नहीं दिखता, और अगर यह कई IPs और IPv6 /64 blocks में distribute हो तो चुपचाप निकल सकता है। इस मामले का असली मुद्दा monitoring नहीं, बल्कि JS-disabled flow में rate limit का पूरी तरह गायब होना था (जहाँ पहले के JS-enabled flow से लिया गया token इस्तेमाल हुआ)

  • यह भी सोचता हूँ कि शायद botnet इस्तेमाल हुआ हो, लेकिन ऐसा भी लगता है कि हर request पर IP बदला गया था

• इस तरह के bug bounty में reward amount अक्सर बेहूदगी की हद तक कम होती है। अफ़सोस की बात है

  • reward बार-बार कम करोगे तो आख़िरकार ख़ुद का ही नुकसान करोगे

  • ऐसे security issue पर $100k से कम देना सच में बहुत शर्मनाक है

• मुझे अक्सर लगता है कि legacy web pages को maintain करना बहुत बड़ा बोझ है। कई sites को दशकों पुराने code और pages तक संभालने पड़ते हैं, और हर combination को test करना practically impossible है। Gmail settings के अंदर गहराई में जाओ तो आज भी 2004-style पुराने popups दिख जाते हैं

  • bug bounty program लागत के हिसाब से बेहद efficient लगते हैं। कुछ हज़ार dollars में आप ऐसे स्वैच्छिक लोग जुटा लेते हैं जो extreme edge cases ढूँढ देते हैं। अगर यह काम in-house staff से कराया जाए तो लागत बहुत ज़्यादा होगी

  • यही सबसे बड़ा कारण है कि कंपनियाँ पुराने services और products को आक्रामक तरीके से बंद करना चाहती हैं। “उसे बस वैसे ही छोड़ क्यों नहीं देते?” का जवाब यह है कि हर legacy service आख़िरकार security hole बन जाती है। सच में सुरक्षित code वही है जो है ही नहीं

  • मैं हमेशा सोचता हूँ कि Facebook के “Poke” feature की ज़िम्मेदारी अब किसके पास होगी

  • बड़ी कंपनियों के अंदर भी ऐसा ही legacy infrastructure चलता रहता है। उदाहरण के लिए, मेरा एक दोस्त एक global conglomerate के अंदर internal link-shortening app maintain करता है, और usage spikes के बावजूद node version update जैसी बहुत साधारण वजहों से हर बार सिर्फ एक-दो tickets ही आते हैं। Monitoring ठीक से काम न करे तब भी bug reports इतनी कम आती हैं

  • हाल ही में मुझे भी Google में एक ऐसा page मिला जिस पर पुराना (~2013) Catull logo दिख रहा था

• “2025-05-15 – panel awarded $1,337 + swag. Rationale: low exploitability (lol)” वाली बात का ज़िक्र किया गया, लेकिन मुझे लगता है कि वास्तव में इसकी exploitability बहुत ज़्यादा है। Exposed phone numbers के शिकार लोगों की संख्या बहुत बड़ी न भी हो, फिर भी private investigators, criminals, investigators—ज़रूरत पड़ते ही कोई भी इस vulnerability का सच में इस्तेमाल करेगा, इस पर मुझे पूरा यक़ीन है

• इस मामले से मुझे नया एहसास हुआ कि password recovery flow में phone number का कुछ हिस्सा hint के तौर पर दिखाना वास्तव में security risk है। अगर कई services अलग-अलग masking order में phone number/email hints दें, तो जोखिम और बढ़ जाता है

  • दिलासा देने वाली बात हो या न हो, लेकिन 2FA जैसी वजहों से सैकड़ों/हज़ारों services पहले ही मेरा phone number इकट्ठा कर चुकी हैं, और मेरी सहमति हो या न हो, उनमें से काफ़ी जगह यह पहले ही leak हो चुका है। असली नाम-email-phone number का combination लगभग तय है कि public data में dump हो चुका होगा

  • ऐसी जानकारी ढूँढने वाले Telegram bots भी मौजूद हैं। जब इस तरह की brute-force vulnerabilities सामने आती हैं, तो लगता है कि automated tools इस्तेमाल करने वाले users भी असहज हो जाते हैं (EoG bot इसका एक उदाहरण है)

  • ऐसी personal information को अपने-आप इकट्ठा करने वाली paid services भी बहुत पहले से मौजूद हैं। Email, phone number और दूसरी जानकारी कई sources से इकट्ठी होती रहती है, और दुनिया भर में इसके लिए इतना incentive है कि लोग service security weaknesses को सक्रिय रूप से target करते हैं। आखिरकार यह mass leaks से जुड़ ही जाता है

  • पहले social engineering का एक मामला भी था जिसमें किसी एक कंपनी के customer support से card के आख़िरी 4 digits पूछकर, उससे दूसरी कंपनी की identity verification तोड़ दी गई थी

  • मुझे भी university के दिनों की याद है, जब एक security researcher की presentation में सुना था कि credit cards से भी इस तरह जानकारी हासिल की जा सकती है

• 2025, 2023 और 2021 में भी “इसे रोकने का कोई तरीका नहीं” जैसे articles और बड़े data leaks बार-बार दोहराए गए। 2025 version, 2023 version, 2021 version बार-बार सामने आते हैं। कौन-सा version ज़्यादा मज़ेदार है, यही सोचना पड़ता है

• मुझे यह मामला बहुत creative और शानदार लगा। Brutecat ने फिर कमाल किया

• Google अब सचमुच किसी ghost ship जैसा लगने लगा है। $5,000 bug bounty अपमानजनक है, और इतनी छोटी रकम से शुरुआत करना ही इस बात का निर्णायक सबूत लगता है कि Google user data protection को गंभीरता से नहीं लेता

  • bug bounty में हिस्सा लेना कोई मजबूरी नहीं है। अगर reward पसंद नहीं है, तो मत करो। आखिरकार इन programs की sustainable model के रूप में अपनी सीमाएँ हैं