Hackear a Google con IA para ganar 700 millones de wones

• Caso de un investigador de seguridad que puso a una IA a probar automáticamente las API de Google de forma constante y logró 500 mil dólares en recompensas de bug bounty en 3 meses
• Al combinar claves API recolectadas de más de 60,000 apps de Android con los documentos de especificación de API de Google (discovery document), consiguió más de 1,500 APIs para probar, incluidas algunas poco conocidas fuera de la empresa
• Conectó a una IA basada en Claude con una herramienta de pruebas de API para que enviara solicitudes como si fuera una persona y encontrara automáticamente vulnerabilidades de control de acceso por falta de verificación de permisos
• Descubrió múltiples fallas graves, como toma de cuentas de Google Voice, filtración de videos privados de YouTube, exposición de claves de Widevine DRM y rastreo de identidad de dueños de dispositivos Nest
• La mayoría no surgió de ataques sofisticados, sino de errores básicos repetidos como falta de revisión de permisos, APIs sin autenticación y entornos de prueba que exponían datos reales

---

Punto de partida de la investigación

• En octubre de 2025, a raíz de una invitación a bugSWAT Mexico, volvió a concentrarse en investigar a Google; le resultó especialmente atractivo poder revisar parte del código fuente de Google
• Tras crear pequeños proyectos con Claude durante el último año, concluyó que había mucho potencial para usar IA para probar automáticamente a gran escala las APIs de Google
• El punto de entrada clave fue el discovery document: la versión de Google de un documento tipo Swagger, que describe de forma legible por máquina todos los endpoints, parámetros y métodos
  • Algunos son públicos, como YouTube Data API, pero también existen para APIs internas como Internal People API
  • Algunos pueden consultarse tal cual, pero la mayoría requiere una clave API válida

Recolección de claves API

• A menudo una clave encontrada en un servicio también está habilitada para varias otras APIs del mismo proyecto de GCP, así que mientras más claves se junten, mayor es el alcance de APIs accesibles
• Realizó la recolección junto con su amigo Michael
  • Descargaron y descomprimieron 61,200 APK de Android, incluidas todas las versiones de todas las apps de Google, y buscaron claves API
  • Con una extensión basada en la Chrome Debugger API, interceptaron tráfico mientras visitaban en tiempo real más de 2,800 dominios web conocidos de Google para recolectar claves de las solicitudes
  • También trabajaron en paralelo con el descifrado de apps iOS de Google (IPA) y el análisis de binarios de Google disponibles públicamente

• Filtrar solo las claves de Google

  • Para respetar el alcance del VRP, usaron la Cloud Marketplace API para consultar la información del proyecto asociado a cada clave y descartar claves que no fueran de Google
  • Si se usa una clave en una API sin permisos, el error devuelto expone el número de proyecto (por ejemplo: "...in project 244648151629...")
  • Al consultar ese número, el campo company revela el dominio del propietario del proyecto, por lo que descartaron las claves fuera de google.com y de compañías adquiridas como nest.com, fitbit.com y wing.com

Encontrar dominios activos de APIs de Google

• Obtuvieron dominios candidatos combinando los dominios registrados por la extensión, generación masiva basada en palabras clave y logs de certificate transparency
• Enviaban solicitudes a cada dominio y, si el encabezado Server era ESF, GSE o scaffolding on HTTPServer2, lo clasificaban como una API válida y activa de Google

Extraer hasta las especificaciones ocultas

• En julio de 2025, Google eliminó la ruta /$discovery/rest de la mayoría de las APIs, pero en algunos casos aún era posible rodear esa limitación

• Endpoints ocultos con Visibility Label

  • Algunos proyectos tienen activada una visibility label, y solo al enviar el parámetro labels se puede acceder a endpoints ocultos
  • Si se pedía la especificación de Service Management API sin etiqueta, pesaba 253 KB; al agregar ?labels=GOOGLE_INTERNAL, aumentaba a 329 KB, exponiendo una gran cantidad de documentación oculta
  • Solo se puede solicitar una etiqueta a la vez, así que hubo que probar una cantidad enorme de combinaciones entre todas las etiquetas, todas las claves y todas las APIs
• Así lograron obtener especificaciones de más de 1,500 APIs y, al sumarlas con documentos recolectados en investigaciones anteriores, quedó lista la base para las pruebas automáticas con IA

Resolver el problema de autenticación

• Las claves API resolvían el tema de los "permisos", pero muchos endpoints también exigían por separado autenticación para confirmar quién hace la llamada
• Los tokens Bearer están ligados a un proyecto de GCP, por lo que al mezclarlos con una clave API aparecía un error de "proyectos distintos"; no conocían una forma de evitarlo

• First Party Authentication (FPA)

  • Muchas APIs soportan FPA, un esquema de autenticación propio de Google que funciona junto con una clave API
  • Las solicitudes web incluyen la Cookie de sesión y un valor Authorization calculado a partir de ella, y se envían al host *.clients6.google.com
  • Algunas APIs, como drivefrontend-pa, exigen un encabezado más completo de FPA v2, que incorpora a un hash identificadores del usuario como el correo electrónico
  • Michael encontró un sourcemap que Google expuso por error durante un tiempo, lo que permitió obtener en la librería interna gapix el código que genera los encabezados de FPA v2

• Estructura del token y Gaia ID

  • El formato del token es <timestamp>_<hash>_<claveIdentificadora>, y la entrada de SHA1 es "email:gaiaId timestamp sessionCookie origin"
  • La clave identificadora solo puede ser e (correo), u (Gaia ID ofuscado) o a (dominio de Workspace); el backend ignora otras letras
  • Gaia significa "Google Accounts and ID Administration", y cada cuenta tiene un Gaia ID secuencial no ofuscado (por ejemplo, 131337133377) y otro ID largo ofuscado

• Lista blanca de Origin y restricciones de clave

  • Muchas APIs mantienen una lista de Origin permitidos, y si se usa uno no autorizado devuelven el error SESSION_COOKIE_INVALID, que puede hacer pensar erróneamente en un problema de cookies
  • Las claves tienen cuatro tipos de restricción: Server, Browser, Android e iOS; Browser requiere Referer, iOS requiere X-Ios-Bundle-Identifier y Android requiere coincidencia entre X-Android-Package y la huella del certificado
  • Al recolectar claves, también guardaron esos valores e integraron la fuerza bruta al mismo programa
  • Los origin *.corp.google.com no tienen restricción, por lo que es muy probable que esas APIs fueran internas y no pensadas para exposición pública; además solían tener muchos bugs. Un caso pagó $9,000 por una falla de control de acceso

Mapa del flujo de solicitudes y herramienta propia de pruebas

• Crearon un programa para clasificar en qué etapa se rechazaba una solicitud —resolución del método, validez de la clave, restricción de clave, autenticación, revisión de origin, label, etc.— y así construir un mapa de qué claves funcionaban con qué APIs
• Como el API Explorer de Google solo soporta APIs públicas y además es privado, desarrollaron durante aproximadamente una semana su propio explorador de APIs con soporte hasta FPA v2
  • Parsea las especificaciones del lado del cliente para construir automáticamente JSON válidos de solicitud y respuesta, y ofrece una interfaz para probar rápidamente payloads arbitrarios
  • El endpoint mostrado en la demo filtraba assignedTams (administradores técnicos de cuenta) por una falla de control de acceso, lo que les valió $6,000

Configuración de pruebas automáticas con IA

• El objetivo era que la IA encontrara automáticamente problemas básicos de control de acceso, y luego que una persona los escalara a vulnerabilidades más graves
• Conectaron el código frontend de parseo JSON a la IA como una herramienta MCP, para que probara APIs como lo haría una persona

• Más a fondo, más silenciosamente

  • Al inicio la IA hacía unos pocos intentos y terminaba demasiado pronto, así que la forzaron con un Ralph Wiggum loop a no finalizar hasta haber probado al menos una vez todos los endpoints
  • Primero clasificaban los endpoints en grupos lógicos y luego los probaban por grupo, compartiendo a los grupos posteriores los hallazgos de los anteriores
  • Simplificaron la entrada de probe_api para centrarse en endpoint, path y body; la autenticación compleja de FPA quedaba resuelta por el backend, así la IA se concentraba solo en escribir payloads
  • Como la respuesta podía variar según la clave, enviaban automáticamente la misma solicitud con todas las claves y agrupaban por hash las respuestas idénticas
  • Errores confusos como "Method not found" se traducían a etiquetas como MISSING_REQUIRED_VISIBILITY_LABEL para evitar que la IA se confundiera

• Resolver ruido y validación

  • Al principio, los bugs reales quedaban enterrados bajo un 90% de ruido, así que surgieron dos problemas principales: la dificultad para validar y los falsos positivos excesivos
  • Incluyeron en los reportes un operation ID que apuntaba a la solicitud real, de modo que podía reproducirse con el botón "Play" desde el frontend y quedar evidencia no manipulable
  • Durante más de un mes ajustaron el system prompt para dejar claro el criterio de reporte: solo contaban acceso a datos de otros usuarios o respuestas 2xx donde debería haber 4xx; la simple enumeración de existencia se excluía como vulnerabilidad
  • Después de eso, la IA empezó a encontrar bugs en volumen con una precisión superior al 50%, y la única limitación real pasó a ser la cantidad de claves API disponibles

Principales vulnerabilidades encontradas

• En menos de 3 meses encontraron bugs valorados en $500,000; abajo aparecen algunos casos representativos ya corregidos

• Toma de cuentas de Google Voice

  • gfibervoice-pa no tenía absolutamente ningún control de acceso, así que con una sola línea de curl sin autenticación y con solo conocer el Gaia ID no ofuscado de la víctima era posible volcar por completo PII como número telefónico y direcciones de notificación
  • La respuesta incluso permitía ver el número de recuperación de cuenta de Google de la víctima (solo se expone bajo ciertas condiciones, que Google no reveló)
  • También existía un endpoint para asignar a la fuerza un número de Voice a cualquier cuenta; aunque devolvía error 500, el número sí se añadía en la práctica. Además encontraron un endpoint con posible uso para SIM swap
  • Se clasificó como P0/S0, fue corregido en pocas horas y pagó $20,000
  • Justo después del parche encontraron exposición de zhandler solo para intranet, como /btz; si se alcanzaba /flagz, era posible extraer claves API del servicio en ejecución

• Toma de cuentas de AdExchange

  • Descubrieron un endpoint que con una sola solicitud hacía un volcado de la lista completa de cuentas de AdExchange
  • Un endpoint de cuentas bloqueado en producción funcionaba sin control de acceso en staging, y ese staging apuntaba a datos reales de producción
  • También era posible agregarse a uno mismo como ADMIN de cualquier cuenta; por ambos reportes recibieron un total de $30,000

• eldar.corp.google.com

  • La API de Eldar, un sitio interno solo para Googlers usado para gestionar evaluaciones internas de privacidad, estaba expuesta al exterior, permitiendo que personas ajenas a Google consultaran información sensible como solicitudes de acceso a logs internos
  • Después del bloqueo, avisaron adicionalmente que aún podía alcanzarse por otras direcciones sandbox, y en total recibieron $26,674

• Filtración de videos privados de YouTube

  • Como el nombre del asset generado al subir un video seguía el formato Auto generated asset - <video_id>, bastaba con buscar para filtrar el ID de videos privados y verlos
  • Consultándolo cada 30 segundos era posible obtener un feed en tiempo real de videos privados subidos por partners; dado que empresas suelen subir con antelación videos de anuncios de productos, existía una amenaza real de usar eso para apostar con información privilegiada en mercados predictivos
  • Recibieron $12,000 por este hallazgo (con reconocimiento a la calidad del reporte)

• Exposición de claves de Widevine DRM

  • La API del portal de partners de Widevine, el enorme sistema DRM usado por Disney, Netflix y otros, era accesible públicamente
  • Se podía volcar la lista completa de organizaciones, consultar y descifrar las claves PGP y AES de una organización específica, e incluso agregarse a uno mismo a una organización arbitraria para administrar dispositivos
  • Este reporte obtuvo $16,004.40 (también con reconocimiento por la calidad del informe)

• plx.corp.google.com

  • La API subyacente de DataHub del sistema interno para empleados PLX estaba expuesta, permitiendo consultar metadatos de tablas con información de empleados activos
  • En la API de staging era posible usar setIamPolicy para autoasignarse como admin del dataset y después volcar datos confidenciales de YouTube, incluidas tablas de hasta 2.1 PB
  • Ambos fallos fueron reconocidos como P0/S0 en menos de una hora, con $12,000 por cada vulnerabilidad

Vulnerabilidad cross-tenant en Translation Hub

• Encontraron múltiples problemas de control de acceso en Translation Hub, un producto para gestionar traducción de documentos a gran escala
• ListOperations funcionaba sin token OAuth y filtraba nombres de cuentas de servicio internas, nombres de buckets de GCS y nombres de tablas internas
• Con solo el bearer token de cualquier cuenta de Google era posible consultar datos de otros proyectos, como correos de traductores y nombres de archivos confidenciales de trabajo
• Al cambiar con UpdateProjectConfig la configuración de la víctima a una ruta arbitraria de GCS, podían abusar de los permisos de una cuenta de servicio compartida para extraer objetos privados de GCS en base64
• La suma de estos tres bugs pagó $36,500

YouTube TV CMS

• En una API de cuentas de YouTube CMS que permite hacer strike, claim o monetizar videos arbitrarios, el endpoint de campañas no revisaba en absoluto la relación del llamador con el recurso
• GET /v1/campaigns hacía un volcado global de todas las campañas del sistema sin scoping, y también se podían modificar, copiar o borrar con solo conocer el ID
• Como efecto secundario, se filtraron correos sensibles de cuentas CMS, y el hallazgo pagó $24,000 (con reconocimiento por la calidad del reporte)

Vertex AI Search for Commerce

• En este producto de búsqueda y recomendación para retail, conversationalSearchCustomizationConfig permitía leer y modificar la configuración de proyectos arbitrarios sin control de acceso
• Al leerla, exponía el system prompt del cliente (preamble del modelo) y ejemplos de clasificación con notas internas de políticas
• Al escribirla, era posible inyectar payloads de prompt injection en el system prompt del buscador con IA de cara al cliente, lo que pagó $30,000

GraphQL de Cloud Console

• Incluso servicios internos no publicados en internet podían alcanzarse indirectamente por una superficie proxy; Cloud Console (nombre clave Pantheon) usa GraphQL como proxy hacia backends gRPC

• Bypass de verificación de firma

  • Cada solicitud valida una firma de consulta (querySignature), lo que dificulta manipularla, pero descubrieron que las consultas no autenticadas en staging no validaban la firma
  • Con introspection extrajeron 3,448 esquemas, los archivaron en GitHub e integraron GraphQL a su infraestructura de fuzzing con IA introduciendo el concepto de "query path"

• Logs de solicitudes de App Engine

  • GetDashboardAppStats devolvía 24 horas de logs de App Engine de cualquier proyecto sin verificar IAM, e incluso sin requerir autenticación
  • Como las URLs de solicitud podían incluir enlaces de restablecimiento de contraseña y tokens, esto pagó $18,000 y recibió el identificador CVE-2026-8934

• Vertex Assistant

  • Tras analizar 5 GB de JavaScript frontend, identificaron una función experimental oculta llamada Vertex Assistant y forzaron su activación con feature flags desde DevTools
  • Todas las consultas relacionadas funcionaban sin autenticación y solo con userId, de modo que con solo conocer el correo del objetivo se podían consultar y modificar listas de sesión y conversaciones completas, lo que pagó $30,000

• Créditos de facturación de Maps Platform

  • ListBillingAccountCredits funcionaba sin revisar permisos y devolvía con comodines información de créditos de múltiples clientes
  • La PII de clientes escrita por empleados de Google al aprobar solicitudes quedaba expuesta tal cual en el campo justification, y el hallazgo pagó $12,000

Cierre y aprendizajes

• En 3 meses, esta configuración consiguió más de $500,000 en recompensas, y lo publicado es solo una parte
• La mayoría de los bugs de Google no requerían exploits sofisticados sino paciencia: el mismo patrón roto se repetía por todas partes — falta de chequeos IAM, GraphQL sin autenticación, endpoints de depuración en producción y sandboxes apuntando a datos reales
• El rol de la IA no fue la creatividad, sino verificar una y otra vez lo obvio sin cansarse sobre una superficie demasiado amplia para que una persona la cubra completa
• Ideas clave
  • El sistema de reproducción por operation_id fue el elemento decisivo para volver productivo el flujo de trabajo: sin validación con un clic, la salida de la IA no es más que ruido inútil
  • Si se consiguen discovery docs, GraphQL SDL o proto, la IA puede inferir entradas con sentido para probar
  • La superficie server-side de Google está muy estandarizada, así que al abstraer las particularidades de infraestructura fuera de la IA, esta puede concentrarse mucho mejor en la prueba real de APIs

[j2sus91]

Vaya, esto sí que es un concepto totalmente nuevo de ganancias con vibe coding.