Una vulnerabilità critica scoperta nei meccanismi di recupero account di Google ha esposto a un rischio significativo la privacy degli utenti. La falla, individuata da un ricercatore indipendente noto come Brutecat, permetteva di ottenere il numero di telefono associato a qualsiasi account Google, sfruttando un sistema automatizzato di brute-force.
L’attacco non richiedeva nemmeno l’interazione dell’utente bersaglio. Basta un nome visualizzato pubblico e alcuni elementi facilmente reperibili online per avviare il processo. L’incidente ha attirato l’attenzione di importanti testate di sicurezza informatica, sollevando interrogativi sulla sicurezza dei sistemi legacy ancora operativi nei servizi più diffusi al mondo, incluso un gigante come Google.
La dinamica dell’attacco
Il cuore della vulnerabilità si trovava nella versione “senza JavaScript” del modulo di recupero username di Google; si tratta di un endpoint rimasto attivo nonostante l’adozione diffusa di soluzioni moderne come BotGuard. Questo modulo, privo delle protezioni anti-abuso implementate nei flussi più recenti, consentiva di verificare se un numero di telefono fosse associato a un determinato nome visualizzato.
Brutecat ha illustrato una catena d’attacco in tre fasi. Nella prima fase si ottiene il nome completo tramite un documento condiviso in Looker Studio; quindi, si recupera l’indizio numerico parziale attraverso il flusso “Password dimenticata“. Infine, nella terza fase, viene usato uno script automatizzato per generare 40.000 tentativi al secondo. In base al prefisso internazionale, bastavano da 5 secondi (Singapore) a 20 minuti (Stati Uniti) per identificare il numero completo.
Tecniche di evasione e strumenti utilizzati
Per eludere i controlli di Google, il ricercatore ha sfruttato il protocollo IPv6 generando milioni di IP unici tramite subnet /64. Questo ha reso inefficaci i limiti di rate-limiting normalmente imposti da Google su IPv4.
Inoltre, ha dimostrato che i token BotGuard provenienti dai form con JavaScript attivo potevano essere riutilizzati nel modulo No-JS, eliminando l’ostacolo dei CAPTCHA di Google. Lo script gpb, sviluppato ad hoc, usava la libreria libphonenumber per generare numeri validi in base al paese. Queste tecniche hanno permesso un brute-force estremamente veloce anche con server a basso costo.
Il rischio principale derivava dal fatto che il numero di telefono di recupero coincide quasi sempre con quello primario; pertanto, la violazione della privacy era diretta e potenzialmente devastante.
La risposta di Google
Il ricercatore ha notificato la falla a Google il 14 aprile 2025. L’azienda ha reagito inizialmente classificando il rischio come basso. Ulteriormente, ha rivalutato la gravità della vulnerabilità al livello “medio”, applicando mitigazioni temporanee. Definitivamente il modulo vulnerabile è stato deprecato il 6 giugno.
La ricompensa assegnata è stata di 5.000 dollari, cifra che riflette la gravità del rischio. Google ha affermato di non aver registrato attacchi reali confermati. Tuttavia, il fatto che l’attacco non lascia tracce è di per sé allarmante. L’incidente dimostra l’importanza di eseguire controlli di sicurezza anche su endpoint legacy, spesso dimenticati ma ancora attivi e vulnerabili.
Vulnerabilità in Google: conclusioni
Questo caso rappresenta un campanello d’allarme per tutte le grandi piattaforme che gestiscono dati sensibili. Le vulnerabilità nei sistemi apparentemente secondari possono avere conseguenze disastrose; un semplice modulo di recupero può diventare un vettore di attacco critico.
La vicenda evidenzia anche l’efficacia della ricerca indipendente nel rafforzare la sicurezza collettiva, grazie ai programmi di bug bounty. Tuttavia, la rapidità con cui un attacco può essere automatizzato con risorse minime sottolinea quanto sia sottile il confine tra sicurezza percepita e reale esposizione.
