Quand une faille révèle le numéro de téléphone associé à n'importe quel compte Google

Y’a pas si longtemps que ça, en 15 secondes chrono, un chercheur en sécurité pouvait vous donner le numéro de téléphone associé à votre compte Google !! Incroyable non ? Et bien cette faille terrifiante, découverte en 2025, vient d’être corrigée par Google, mais l’histoire mérite quand même d’être racontée parce que j’ai trouvé ça super intéressant.

L’exploit a été découvert par BruteCat, un chercheur spécialisé dans l’analyse des services Google. Le type s’amusait à désactiver JavaScript sur son navigateur pour voir quels services Google fonctionnaient encore sans JS et surprise !! Le formulaire de récupération de nom d’utilisateur marchait toujours ! C’est là que c’est devenu intéressant pour lui.

La vulnérabilité exploitait plusieurs faiblesses combinées de façon diablement intelligente. D’abord, ce vieux formulaire de récupération sans JavaScript n’avait plus les protections “anti-abuse” modernes. Normalement, ces formulaires utilisent des solutions “BotGuard” basées sur du JavaScript lourdement obfusqué depuis 2018 mais celui-ci était resté à l’âge de pierre.

Son processus d’attaque se déroule en plusieurs étapes : Le chercheur doit d’abord récupérer le nom d’affichage du compte Google de la victime. C’est pas simple en théorie, mais BruteCat avait découvert qu’on pouvait utiliser Google Looker Studio pour ça. Il suffisait de créer un document et de transférer la propriété à la victime et boom, le nom s’affichait.

Ensuite, l’attaquant doit utiliser le système de récupération de compte de Google qui affiche gentiment les deux derniers chiffres du numéro de téléphone de récupération. Genre “•• ••••••03”. Google pensait bien faire en donnant cette indication, mais c’était en fait offrir une partie de la solution sur un plateau.

Mais le vrai génie technique de la manoeuvre réside dans le contournement des limitations. Les premiers tests de BruteCat se heurtaient aux captchas et au rate limiting classique mais le chercheur a eu une idée brillante : utiliser IPv6 pour générer une infinité d’adresses sources. Avec un subnet /64, on a 18 quintillions d’adresses disponibles soit de quoi faire tourner n’importe quel système de rate limiting en bourrique.

Enfin, l’astuce finale concerne le contournement des captchas. Le paramètre bgresponse=js_disabled a beaucoup attiré l’attention du chercheur qui a remplacé cette valeur par un vrai token BotGuard récupéré depuis la version JavaScript du formulaire. Et là, magie-margie !! Plus de captcha, plus de limitation !! Le système peut enfin accepter les requêtes en masse.

Pour cela, BruteCat a développé un outil en Rust appelé gpb (Google Phone Bruteforcer) qui automatise tout le processus. L’outil génère des adresses IPv6 aléatoirement, lance les requêtes, et filtre les faux positifs. Les performances sont d’ailleurs hallucinantes avec une moyenne de 40 000 requêtes par seconde sur un serveur à 30 centimes de l’heure.

De plus, la vitesse d’attaque dépend du pays ciblé à cause des formats de numéros différents. Pour les Pays-Bas avec leurs numéros commençant par 06, il fallait bruteforcer seulement 6 chiffres. Résultat, moins de 15 secondes pour cracker un numéro complet. Pour le Royaume-Uni, 4 minutes suffisaient. Les États-Unis prenaient 20 minutes à cause de leur format plus long mais franchement, même 20 minutes, c’est ridicule pour obtenir une donnée aussi sensible.

Et l’impact potentiel de cette faille dépasse largement la simple fuite de numéro car avec un brute force réussi, un attaquant pouvait ensuite lancer des attaques SIM swap ciblées. Il suffit de convaincre l’opérateur mobile de transférer le numéro vers une nouvelle carte SIM contrôlée par l’attaquant et une fois maître du numéro de téléphone, il pouvait alors réinitialiser les mots de passe de tous les comptes associés à ce téléphone.

Google a d’abord minimisé le problème (comme d’hab) quand BruteCat l’a signalé le 14 avril 2025 via leur programme de bug bounty. L’entreprise jugeait le risque “faible” mais le 22 mai, après avoir mieux analysé l’exploit, Google a requalifié la faille en “sévérité moyenne” (lol) et a appliqué des mesures temporaires. Le chercheur a ainsi touché 5 000 dollars de récompense grâce à sa découverte, ce qui reste correct pour une faille de cette ampleur.

Le correctif final est ensuite arrivé le 6 juin dernier avec la suppression complète de l’ancien endpoint de récupération sans JavaScript. Google l’a confirmé dans un communiqué : “Ce problème a été corrigé. Nous avons toujours insisté sur l’importance de travailler avec la communauté de recherche en sécurité via notre programme de récompenses et nous remercions le chercheur d’avoir signalé ce problème.”

Bref, ça fait flipper mais ça montre quand même l’important qu’il y a de diversifier nos méthodes de récupération de compte car utiliser uniquement un numéro de téléphone pour ça, c’est dangereux. Il vaut mieux activer l’authentification à deux facteurs avec une application dédiée, configurer plusieurs méthodes de récupération, et bien sûr se méfier des services qui affichent des “indices” sur nos données personnelles.

En tout cas, BruteCat mérite des félicitations pour sa découverte et sa divulgation responsable car sans chercheurs comme lui, ces failles resteraient exploitables pendant des années !!!

Source