Attaque par force brute des numéros de téléphone des utilisateurs Google (Bruteforcing the phone number of any Google user)
(brutecat.com)- Il est possible de contourner le formulaire de récupération de compte Google pour vérifier si un numéro de téléphone est associé à un nom d’utilisateur précis
- Même dans un environnement avec JavaScript désactivé, il est possible d’insérer volontairement un jeton BotGuard afin de mettre en œuvre une méthode d’attaque contournant les limites par IP
- Dans certains pays comme les Pays-Bas, les caractéristiques du format des numéros font qu’il existe moins d’un million de combinaisons, rendant une force brute à grande échelle réaliste via rotation de proxys et d’IPv6
- Le nom d’affichage d’un compte Google peut être exposé facilement via Looker Studio sans aucune action de la victime
- Cette vulnérabilité a été signalée à Google puis corrigée, et la chaîne d’attaque réelle permettait de vérifier les numéros de téléphone très rapidement grâce à l’automatisation
Vue d’ensemble
Cet article présente en détail un cas réel expliquant comment retrouver par force brute le numéro de téléphone d’un compte Google, le déroulement de l’attaque et la réponse défensive. En général, les formulaires de recherche/récupération de compte s’appuient sur un environnement JavaScript et des mécanismes anti-bot pour empêcher les abus. Ici, il est démontré que cette protection peut être contournée dans un environnement sans JS combiné à un schéma particulier.
Contexte de l’enquête et méthode
- Il a été constaté que le formulaire Google permettant de retrouver le nom d’utilisateur fonctionne sans JavaScript
- Le formulaire permet de vérifier en deux requêtes HTTP l’existence d’un numéro de téléphone lié à un nom (Display Name) donné
- 1re requête : obtention de la valeur ess (jeton de session) à partir du numéro de téléphone
- 2e requête : détermination de l’existence du compte via les paramètres ess et nom (GivenName/FamilyName)
- Si le compte existe, la réponse redirige vers
usernamerecovery/challenge, sinon versnoaccountsfound
Contournement des limites IP (proxys, IPv6)
- Au départ, la force brute était impossible à cause de la limitation de débit par IP et des CAPTCHA
- Dans le cas des numéros mobiles néerlandais, l’espace de recherche est réaliste avec un million de combinaisons (préfixe fixé) si l’on utilise des proxys
- Il est possible d’exploiter des blocs IPv6 /64 fournis par des clouds comme AWS/Vultr pour faire tourner l’adresse à chaque requête, les serveurs prenant aussi en charge IPv6
Contournement du jeton BotGuard
- Le formulaire JS exige un jeton BotGuard
- En injectant dans le formulaire sans JS un jeton collecté depuis le formulaire JS à la place du paramètre
bgresponse=js_disabled, il devient possible de faire des soumissions illimitées - Un outil multithread a été développé pour injecter de grands volumes de numéros et détecter rapidement les comptes existants
Filtrage des faux positifs
- Plusieurs personnes peuvent correspondre à une même condition de nom et de deux derniers chiffres du numéro
- Une logique supplémentaire reteste avec un nom de famille aléatoire afin de filtrer automatiquement les faux positifs
Format des numéros par pays et collecte des informations de nom
- Le formulaire de récupération ne fournit qu’une partie du format masqué du numéro de téléphone
- Les schémas nationaux de numérotation peuvent être déterminés en étudiant les informations de
libphonenumbersde Google - Le nom d’affichage de la victime peut être obtenu via Looker Studio en abusant de la fonction de changement de propriétaire, sans action de l’utilisateur
Optimisation et automatisation
- Création, avec
libphonenumbers, d’un dictionnaire des préfixes, longueurs et règles de validation par pays - Développement, avec chromedp en Go, d’une API d’émission automatique de jetons BotGuard, permettant l’automatisation de l’attaque réelle
Procédure d’attaque réelle
- Récupération du nom de la victime (nom d’affichage) via le transfert de propriété dans Looker Studio
- Collecte d’une partie masquée du numéro de téléphone de cet e-mail via le flux « mot de passe oublié »
- Exécution de l’attaque par force brute avec l’outil gpb à partir du nom, du masque et de l’indicatif du pays
Temps et efficacité
- Avec un serveur de 16 vCPU et 3000 threads, environ 40 000 vérifications par seconde
- Selon le nombre de combinaisons nationales et la longueur de l’indice, il suffit d’environ États-Unis (20 min), Royaume-Uni (4 min), Pays-Bas (15 s), Singapour (5 s)
- Si un autre service fournit un indice complet (ex. : PayPal), le temps peut encore être réduit
Google et calendrier du correctif
- 2025.4.14 : signalement à Google, remerciements affichés sur le panel le 4.25
- Mi-mai 2025 : versement d’un bug bounty de 5 000 $
- 2025.5 : arrêt progressif du formulaire sans JS et mise en place de mesures de réponse
- 2025.6.9 : divulgation officielle de la vulnérabilité
Conclusion
Ce cas montre qu’une attaque automatisée à grande échelle peut être rendue possible par la combinaison de plusieurs informations comme le flux de récupération de compte, le masquage du numéro de téléphone et le nom d’affichage. Google a finalisé sa réponse en corrigeant les failles de procédure et en fermant les formulaires concernés.
Il est possible de contacter l’auteur via Signal/e-mail (voir l’article original)
1 commentaires
Avis Hacker News
Ce qui est intéressant ici, c’est que, même si la plupart des hébergeurs ou FAI fournissent au moins un bloc IPv6 /64, la plupart des limites de débit ou blocages IP continuent d’être appliqués à une seule IP. En environnement IPv6, le rate limiting ou le blocage devrait, selon moi, se faire à l’échelle du bloc /64
Je vois souvent des entreprises qui devraient gérer ce problème, ou qui en tirent de l’argent, réagir complètement à côté de la plaque sur la gestion d’IPv6. Mon entreprise utilise un CDN bien connu, et il nous arrive de recevoir des alertes de sécurité absurdes du genre « connexion depuis une IP inhabituelle » même quand l’accès vient du même bloc /64
Depuis l’arrivée d’IPv6, je pense que les anciennes méthodes de blocage IP ont été largement neutralisées. Même un utilisateur résidentiel peut recevoir automatiquement un bloc /56 ou /48 via DHCPv6 Prefix Delegation. Par exemple, je reçois un /56 via Comcast, ce qui peut être découpé en jusqu’à 65536 blocs /64. Pour faire du filtrage IP efficace en IPv6, il ne suffit pas de remplacer l’ancienne logique basée sur une IP unique par du /64
Même appliquer un rate limiting au niveau du bloc /64 peut ne pas suffire. Obtenir un bloc /48 est trop facile. Pour un contrôle optimal, il faut sans doute classifier par ASN et ajuster la granularité en fonction de la manière dont chaque opérateur distribue ses IP
Le rate limiting par /64 en IPv6 est déjà bien connu dans l’industrie, et Google l’applique à d’autres services. J’y vois le résultat d’une absence de mise à jour correcte des anciennes politiques lors de l’adoption d’IPv6
Même un hébergeur low cost comme BuyVM fournit des adresses en /48 sur son offre la moins chère (2 $/mois, même si actuellement seul le plan à 7 $/mois est en stock). C’est pour ça qu’il est souvent apprécié des opérateurs douteux
J’avais tenté une méthode similaire il y a longtemps sur Facebook pour retrouver le numéro de téléphone de quelqu’un. Pendant la réinitialisation du mot de passe, Facebook affichait la majeure partie du numéro ; j’avais donc mis les chiffres dans un fichier vCard, importé ça sur mon téléphone, puis comparé via les photos. C’était étonnamment efficace
Il existe une faille comparable avec les photos de profil Google ou les apps Google. Par exemple, si Google Maps affiche un avis de John Smith, on peut ajouter dans Hangouts plusieurs variantes d’adresse e-mail (
johnsmith@gmail.com,smithjohn@gmail.com, etc.) puis vérifier la photo de profil pour identifier la même personneC’est pour ça que je ne saisis jamais mon vrai numéro de téléphone. Ce n’est généralement même pas nécessaire au fonctionnement du service
Je trouve frappant qu’une seule personne ait pu envoyer 40 000 requêtes par seconde pendant une longue période sans provoquer de forte hausse de ressources ni faire sonner d’alerte
Il est possible qu’une alerte ait bien été déclenchée, mais que l’activité se soit arrêtée rapidement ou que la situation se soit rétablie avant même qu’un ingénieur n’ouvre le dashboard. 40k QPS ne ressort pas forcément énormément à l’échelle du trafic de Focus ou des API Google, et si c’est réparti entre différentes IP et blocs IPv6 /64, ça peut passer inaperçu. Le cœur du problème ici n’est probablement pas le monitoring, mais le fait que le flux avec JavaScript désactivé (utilisant des jetons issus de l’ancien flux avec JavaScript activé) n’avait aucun rate limiting
Je me demande aussi s’il a utilisé un botnet, même si on dirait qu’il changeait d’IP à chaque requête
Les récompenses pour ce type de bug bounty sont ridiculement faibles. C’est dommage
À force de réduire les récompenses, on finit par se tirer une balle dans le pied
Payer moins de 100 000 $ pour ce genre de problème de sécurité, c’est vraiment mesquin
Je ressens souvent à quel point maintenir et gérer des pages web legacy est un poids énorme. Beaucoup de sites doivent continuer à faire tourner du code et des pages vieux de plusieurs décennies, et tester toutes les combinaisons est pratiquement impossible. Il suffit de fouiller dans les paramètres de Gmail pour voir surgir des popups anciennes au style 2004
Les programmes de bug bounty me semblent être un usage des coûts extrêmement efficace. Pour quelques milliers de dollars, on mobilise une main-d’œuvre volontaire qui va dénicher des cas limites extrêmes. Avec des équipes internes, cela aurait probablement coûté bien plus cher
C’est exactement la raison principale pour laquelle les entreprises cherchent à supprimer agressivement leurs anciens services et produits. À la question « pourquoi ne pas simplement les laisser tels quels ? », la réponse est qu’à terme, tous les services legacy deviennent des trous de sécurité. Le seul code vraiment sûr, c’est celui qui n’existe pas
Je me demande toujours qui est responsable de fonctionnalités comme le « poke » de Facebook
On retrouve la même infrastructure legacy dans les grandes entreprises. Par exemple, un ami à moi maintient une application interne de raccourcissement de liens dans une multinationale, et malgré une explosion d’usage, il ne reçoit qu’un ou deux tickets à chaque fois pour des raisons très simples comme une mise à jour de version de Node. Même quand le monitoring ne fonctionne pas correctement, les rapports de bugs restent rares
Récemment, je suis moi aussi tombé sur une page Google affichant encore l’ancien logo Catull (~2013)
Il est mentionné : « 2025-05-15 – Le panel a accordé 1 337 $ + du swag. Motif : faible exploitabilité (lol) », mais je pense au contraire que l’exploitabilité est très élevée. Il n’y aura peut-être pas énormément de personnes visées par la fuite de numéro, mais dès que le besoin existe, je suis convaincu que des détectives privés, criminels, enquêteurs et autres exploiteront réellement ce type de faille
Je réalise seulement maintenant que donner une partie du numéro de téléphone comme indice dans le flux de récupération de mot de passe constitue en réalité un risque de sécurité. Si plusieurs services fournissent chacun des indices masqués sur le numéro ou l’e-mail dans des ordres différents, le risque devient encore plus grand
Si ça peut te rassurer, pour la 2FA et pour bien d’autres raisons, des centaines ou milliers de services ont déjà collecté mon numéro de téléphone, et une bonne partie a déjà fuité, avec ou sans consentement. Les combinaisons nom réel - e-mail - numéro de téléphone sont pratiquement garanties d’avoir déjà été dumpées dans des données publiques
Il existe aussi des bots Telegram qui retrouvent ce genre d’informations. Quand ce type de vulnérabilité par bruteforce est révélé, même les utilisateurs d’outils automatisés semblent mal le vivre (le bot EoG étant un bon exemple)
Des services payants qui agrègent automatiquement ces données personnelles existent aussi depuis longtemps. E-mails, numéros de téléphone et autres informations s’accumulent depuis diverses sources ; les incitations sont suffisantes à l’échelle mondiale pour pousser à exploiter activement les failles de sécurité des services. Au final, tout cela mène à des fuites massives
Autrefois, il y a aussi eu des cas de social engineering où l’on demandait à un service client les quatre derniers chiffres d’une carte bancaire, puis on s’en servait pour contourner la vérification d’identité chez une autre entreprise
À l’université, je me souviens aussi avoir assisté à une présentation de chercheurs en sécurité expliquant qu’on pouvait obtenir des informations sur les cartes bancaires de cette façon
En 2025, 2023 et 2021, on a encore droit aux articles « impossible d’empêcher ça » et aux fuites massives de données qui se répètent. La version 2025, la version 2023 et la version 2021 reviennent sans cesse. J’hésite sur celle qui est la plus drôle
Je trouve ce cas très créatif et impressionnant. Brutecat a encore frappé
Google donne maintenant vraiment l’impression d’un vaisseau fantôme. Une bug bounty de 5 000 $, c’est insultant, et le simple fait d’avoir commencé avec une somme aussi faible me semble être une preuve accablante que Google ne prend pas au sérieux la protection des données des utilisateurs