Ataque de fuerza bruta contra los números de teléfono de usuarios de Google (Bruteforcing the phone number of any Google user)
(brutecat.com)- Es posible omitir el formulario de recuperación de cuenta de Google para verificar si existe un número de teléfono vinculado a un nombre de usuario específico
- Incluso en un entorno con JavaScript desactivado, se puede implementar un método de ataque que inserta intencionalmente un token de BotGuard para evadir los límites por IP
- En algunos países como Países Bajos, debido a las características del formato de los números telefónicos, existen menos de 1 millón de combinaciones, lo que hace viable una fuerza bruta a gran escala mediante rotación de proxies e IPv6
- El nombre para mostrar de una cuenta de Google puede exponerse fácilmente usando Looker Studio sin necesidad de ninguna acción por parte de la víctima
- Esta vulnerabilidad ya fue reportada a Google y corregida, y la cadena de ataque real permitía verificar números de teléfono en muy poco tiempo mediante automatización
Resumen
Este artículo detalla un caso real sobre cómo descubrir el número de teléfono de una cuenta de Google mediante un ataque de fuerza bruta, el proceso seguido y la respuesta defensiva. Normalmente, los formularios de búsqueda/recuperación de cuenta bloquean abusos usando un entorno con JavaScript y sistemas anti-bots. Sin embargo, aquí se demuestra que es posible evadir ese sistema en un entorno sin JS y con un patrón específico.
Contexto y método de investigación
- Se descubrió que el formulario de Google para encontrar el nombre de usuario funciona sin JavaScript
- El formulario permite verificar en 2 solicitudes HTTP si existe un número de teléfono vinculado a un nombre específico (Display Name)
- 1.ª solicitud: obtener el valor
ess(token de sesión) usando el número de teléfono - 2.ª solicitud: determinar si la cuenta existe usando
essy los parámetros del nombre (GivenName/FamilyName)
- 1.ª solicitud: obtener el valor
- Si la cuenta existe, responde con una redirección a
usernamerecovery/challenge; si no existe, redirige anoaccountsfound
Evasión de límites por IP (uso de proxies e IPv6)
- Al principio, la fuerza bruta no era posible debido al rate limit por IP y los CAPTCHA
- En el caso de números móviles de Países Bajos, hay 1 millón de combinaciones posibles (porque los primeros dígitos están definidos), así que con proxies resulta viable
- Usando bloques /64 de IPv6 de nubes como AWS/Vultr, es posible rotar a una dirección distinta en cada solicitud, y el servidor también soporta IPv6
Evasión del token de BotGuard
- El formulario con JS requiere un token de BotGuard
- Si en el formulario sin JS se inserta un token recolectado desde el formulario con JS en lugar del parámetro
bgresponse=js_disabled, se habilitan envíos ilimitados - Se creó una herramienta multihilo capaz de ingresar grandes volúmenes de números telefónicos y detectar rápidamente cuentas existentes
Filtrado de falsos positivos
- Debido a la condición del mismo nombre y los últimos 2 dígitos del número, existe la posibilidad de que coincidan varias personas
- Se añadió una lógica para filtrar automáticamente falsos positivos repitiendo la prueba con un apellido aleatorio
Formatos telefónicos por país y recolección de nombres
- El formulario de recuperación solo proporciona parcialmente el formato enmascarado del número telefónico
- Los patrones de números por país (national format) pueden identificarse investigando la información de
libphonenumbersde Google - El nombre para mostrar de la víctima podía obtenerse sin interacción del usuario abusando de la función de cambio de propiedad en Looker Studio
Optimización y automatización
- Se generó con
libphonenumbersun diccionario de prefijos, longitudes y reglas de validación por país - Se creó con
chromedpsobre Go una API de emisión automática de tokens de BotGuard, lo que hacía posible automatizar el ataque real
Procedimiento real del ataque
- Obtener el nombre de la víctima (Display Name) mediante la transferencia de propiedad en Looker Studio
- Recolectar el enmascaramiento parcial del número telefónico de ese correo dentro del flujo de “recuperar contraseña”
- Ejecutar el ataque de fuerza bruta con la herramienta
gpbusando el nombre, el enmascaramiento y el código de país
Tiempo y eficiencia
- En un servidor con 16 vCPU y 3000 hilos, se podían verificar unas 40 mil combinaciones por segundo
- Según la cantidad de combinaciones por país y la longitud de la pista, bastaban unos EE. UU. (20 minutos), Reino Unido (4 minutos), Países Bajos (15 segundos) y Singapur (5 segundos)
- Si otro servicio ofrece una pista completa (por ejemplo, PayPal), el tiempo puede reducirse aún más
Google y cronología del parche
- 2025.4.14: reporte enviado a Google; el 4.25 agradecimiento mostrado en el panel
- Mediados de 2025.5: pago de bug bounty de $5,000
- 2025.5: desactivación gradual del formulario sin JS y aplicación de medidas de respuesta
- 2025.6.9: divulgación oficial de la vulnerabilidad
Conclusión
Este caso muestra que una combinación de flujos de recuperación de cuenta, enmascaramiento de números telefónicos y nombres para mostrar, entre otros datos, puede habilitar ataques automatizados a gran escala. Google completó la respuesta reforzando las debilidades del procedimiento y cerrando los formularios relacionados.
Las consultas pueden hacerse por Signal/correo electrónico (ver el texto original)
1 comentarios
Opiniones de Hacker News
Lo interesante de este artículo es que, a pesar de que la mayoría de los proveedores de hosting o ISP ofrecen al menos un bloque IPv6 /64, la mayoría de los rate limits o bloqueos de IP todavía se aplican a una sola IP. En un entorno IPv6, creo que el rate limiting o el bloqueo debería hacerse tomando como base todo el bloque /64
Incluso empresas que tienen la responsabilidad de manejar este tipo de problemas o que ganan dinero con eso suelen responder de forma absurda en lo que respecta a la gestión de IPv6. La empresa donde trabajo usa un servicio CDN conocido, y a veces recibimos alertas de seguridad ridículas como "inicio de sesión desde una IP extraña" incluso cuando el acceso proviene del mismo bloque /64
Desde la llegada de IPv6, creo que los métodos tradicionales de bloqueo por IP quedaron bastante inutilizados. Incluso un usuario residencial común puede recibir automáticamente un bloque /56 o /48 mediante DHCPv6 Prefix Delegation. Por ejemplo, yo recibí un /56 a través de Comcast, y eso puede dividirse en hasta 65536 bloques /64. Para hacer filtrado de IP efectivo en IPv6, no basta con reemplazar el esquema tradicional basado en IP individual por /64
Poner rate limit por bloque /64 puede no ser suficiente. Conseguir un bloque /48 también es demasiado fácil. Para un control óptimo, hace falta clasificar por ASN y ajustar la granularidad considerando cómo distribuye IP cada proveedor
El rate limiting por /64 en IPv6 ya es algo bien conocido en la industria, y Google lo aplica en otros servicios. Me parece que esto es el resultado de no haber actualizado correctamente las políticas existentes al adoptar IPv6
Incluso proveedores de hosting baratos como BuyVM ofrecen direcciones a nivel /48 en su plan más económico ($2/mes, aunque ahora solo hay stock del de $7/mes). Por eso suelen ser populares entre operadores sospechosos
Hace tiempo intenté algo parecido en Facebook para encontrar el número de teléfono de una persona específica. Durante el proceso de restablecimiento de contraseña, Facebook mostraba casi todo el número, así que organicé esos números en un archivo vcard, los importé a mi teléfono y los comparé con las fotos. Ese método funcionó mejor de lo que esperaba
Hay una falla parecida en la foto de perfil de Google o en las apps de Google. Por ejemplo, si en una reseña de Google Maps aparece John Smith, puedes agregar a Hangouts varias variantes de correo (johnsmith@gmail.com, smithjohn@gmail.com, etc.) y revisar la foto de perfil para rastrear si es la misma persona
Por eso nunca doy mi número de teléfono real. Ni siquiera es realmente necesario para operar un servicio
Me impresionó que una sola persona pudiera lanzar 40 mil solicitudes por segundo durante tanto tiempo sin que los recursos se dispararan ni saltaran alarmas
Puede que sí hayan sonado alarmas, pero si la actividad se detuvo rápido o la situación se recuperó enseguida, para cuando un ingeniero abrió el dashboard tal vez ya todo estaba normal otra vez. 40 mil QPS no destacan tanto dentro del volumen de tráfico de Focus o de la API de Google, y si además se distribuyen entre varias IP y distintos bloques IPv6 /64, es fácil que pase desapercibido. Creo que el punto central de este caso no es el monitoreo, sino que el flujo con JS desactivado (usando un token tomado del flujo previo con JS activado) no tenía ningún rate limit
También me pregunto si habrá usado una botnet, aunque parece que cambiaba de IP en cada solicitud
Este tipo de bug bounty suele pagar cantidades ridículamente bajas. Es una lástima
Si siguen bajando las recompensas, al final se van a disparar en el pie
Pagar menos de 100 mil dólares por un problema de seguridad así es realmente miserable
A menudo siento que mantener y administrar páginas web legacy es una carga enorme. Muchos sitios tienen que seguir manteniendo código y páginas de hace décadas, y en la práctica es imposible probar todas las combinaciones. Si te metes en lo profundo de la configuración de Gmail, todavía puedes ver popups viejísimos con estilo de 2004
Los programas de bug bounty parecen una forma muy eficiente de usar el dinero. Con apenas unos miles de dólares puedes movilizar una fuerza voluntaria que encuentra edge cases extremos. Si hubieran usado personal interno, probablemente habría costado muchísimo más
Esta es exactamente la razón principal por la que las empresas intentan retirar agresivamente servicios y productos viejos. A la pregunta de “¿por qué no simplemente lo dejan ahí?”, la respuesta es que todos los servicios legacy terminan convirtiéndose en agujeros de seguridad. El único código realmente seguro es el código que no existe
Siempre me he preguntado quién estará a cargo de algo como la función “poke” de Facebook
Dentro de las grandes empresas también siguen corriendo infraestructuras legacy parecidas. Por ejemplo, un amigo mío mantiene una app interna para acortar enlaces en una multinacional global, y aunque el uso es altísimo, casi nunca llegan más de uno o dos tickets por razones muy simples como actualizar la versión de Node. Incluso cuando el monitoreo ni siquiera funciona bien, los reportes de bugs son rarísimos
Hace poco yo también me topé en Google con una página que todavía mostraba el logo antiguo de Catull (~2013)
Mencionaron “2025-05-15 – El panel otorgó $1,337 + swag. Justificación: baja probabilidad de explotación (lol)”, pero en realidad creo que la probabilidad de explotación es altísima. Puede que no sean tantas las personas afectadas cuyo número telefónico queda expuesto, pero estoy seguro de que, si lo necesitan, investigadores privados, criminales, agentes e investigadores realmente explotarán esta vulnerabilidad
Con este caso me di cuenta de nuevo de que dar parte del número telefónico como pista en el flujo de recuperación de contraseña en realidad es un riesgo de seguridad. Si varios servicios ofrecen pistas de teléfono o email enmascaradas en distinto orden, el riesgo aumenta aún más
No sé si sirva de consuelo, pero por 2FA y por muchas otras razones, cientos o miles de servicios ya recopilaron mi número de teléfono, y una gran parte ya se filtró sin importar si di mi consentimiento o no. La combinación nombre real-email-teléfono casi con seguridad ya está volcada en datos públicos
También existen bots de Telegram que encuentran este tipo de información. Cuando salen a la luz vulnerabilidades de fuerza bruta como esta, parece que hasta los usuarios que ya utilizaban herramientas automatizadas se sienten incómodos (el bot EoG es un buen ejemplo)
También existen desde hace mucho servicios de pago que recopilan automáticamente este tipo de información personal. Email, número de teléfono y otros datos se acumulan desde múltiples fuentes, y como los incentivos son suficientes a nivel global, atacan activamente fallas de seguridad en los servicios. Al final, la estructura siempre termina conectando con filtraciones masivas
En el pasado también hubo casos de ingeniería social donde alguien llamaba al centro de atención al cliente de una empresa, preguntaba por los últimos 4 dígitos de una tarjeta, y con eso luego superaba la verificación de identidad en otra empresa
También recuerdo haber escuchado, cuando estaba en la universidad, una presentación de un investigador de seguridad que decía que las tarjetas de crédito también podían usarse para obtener información de esa forma
En 2025, 2023 y 2021 se repiten los artículos de “no hay forma de evitarlo” junto con filtraciones masivas de datos. La versión de 2025, la versión de 2023 y la versión de 2021 siguen reapareciendo. Me pregunto cuál versión da más risa
Me parece que este caso fue muy creativo y genial. Brutecat lo logró otra vez
Google ya de verdad se siente como un barco fantasma. Un bug bounty de $5,000 es casi un insulto, y el simple hecho de que hayan empezado con una cantidad tan baja me parece una prueba clara de que Google no se toma en serio la protección de los datos de los usuarios