Hackear o Google com IA para ganhar R$ 7 milhões

• Caso de um pesquisador de segurança que fez uma IA cutucar automaticamente as APIs do Google sem parar e, como resultado, obteve US$ 500 mil em bug bounty em 3 meses
• Ao combinar chaves de API coletadas de mais de 60.000 apps Android com os documentos de especificação de API (discovery document) do Google, ele reuniu mais de 1.500 APIs para teste, incluindo APIs pouco conhecidas externamente
• Conectou uma IA baseada em Claude a uma ferramenta de teste de API, configurando-a para enviar requisições como uma pessoa e encontrar automaticamente vulnerabilidades de controle de acesso em que faltava verificação de permissão
• Encontrou várias falhas graves, incluindo tomada de conta do Google Voice, vazamento de vídeos privados do YouTube, exposição de chaves do Widevine DRM e rastreamento da identidade de donos de dispositivos Nest
• A maioria não veio de ataques sofisticados, mas de erros básicos e recorrentes como falta de checagem de permissões, APIs sem autenticação e ambientes de teste expondo dados reais

---

Ponto de partida da pesquisa

• Em outubro de 2025, após um convite para a bugSWAT Mexico, ele voltou a focar em pesquisas contra o Google, motivado pelo fato de poder examinar parte do código-fonte da empresa
• Ao longo do último ano, enquanto criava pequenos projetos com Claude, concluiu que havia grande potencial em usar IA para testar automaticamente APIs do Google em larga escala
• O ponto central de entrada era o discovery document — a versão do Google de um documento Swagger, que descreve endpoints, parâmetros e métodos de forma legível por máquina
  • Alguns são públicos, como a YouTube Data API, mas também existem para APIs internas como a Internal People API
  • Alguns podem ser acessados diretamente, mas a maioria exige uma chave de API válida

Coletando chaves de API

• Muitas vezes, uma chave encontrada em um serviço também está ativada para várias outras APIs do mesmo projeto GCP, então quanto mais chaves forem reunidas, maior será o alcance de APIs acessíveis
• A coleta foi feita em colaboração com o amigo Michael
  • Baixaram e descompactaram 61.200 APKs Android, incluindo todas as versões de todos os apps do Google, para procurar chaves de API
  • Com uma extensão baseada na Chrome Debugger API, interceptaram tráfego ao visitar mais de 2.800 domínios web conhecidos do Google, coletando chaves em requisições em tempo real
  • Também analisaram apps iOS do Google (IPA) descriptografados e binários do Google que conseguiram obter

• Filtrando apenas chaves do Google

  • Para respeitar o escopo do VRP, usaram a Cloud Marketplace API para consultar informações do projeto ligado à chave e remover chaves que não fossem do Google
  • Ao usar uma chave em uma API sem permissão, a mensagem de erro expõe o número do projeto (ex.: "...in project 244648151629...")
  • Consultando esse número, o campo company revela o domínio do dono do projeto, então descartaram qualquer chave que não fosse de google.com (e também nest.com, fitbit.com, wing.com etc., de empresas adquiridas)

Encontrando domínios de APIs Google ativos

• Reuniram domínios candidatos combinando os domínios registrados pela extensão, geração por força bruta baseada em palavras-chave e logs de transparência de certificados (certificate transparency)
• Ao enviar requisições a cada domínio, se o header Server fosse ESF, GSE ou scaffolding on HTTPServer2, ele era classificado como uma API Google ativa e válida

Extraindo até especificações ocultas

• Em julho de 2025, o Google removeu o caminho /$discovery/rest da maioria das APIs, mas em alguns casos ainda era possível contornar isso

• Endpoints ocultos com Visibility Label

  • Alguns projetos têm visibility label ativado, e só é possível acessar endpoints ocultos visíveis com o parâmetro labels
  • Ao obter a especificação da Service Management API sem label, o tamanho era 253 KB; com ?labels=GOOGLE_INTERNAL, subia para 329 KB, expondo grande quantidade de documentação oculta
  • Como só é possível receber um label por vez, foi necessário um volume enorme de requisições para testar todas as combinações de labels, chaves e APIs
• Assim, foram obtidas especificações de mais de 1.500 APIs e, somando com documentos reunidos em pesquisas anteriores, o ambiente ficou pronto para testes automáticos com IA

Resolvendo o problema de autenticação

• A chave de API resolvia a questão de "permissão", mas muitos endpoints também exigiam separadamente autenticação (authentication) para confirmar quem era o chamador
• Tokens Bearer ficam vinculados a projetos GCP e, se misturados com uma chave de API, geram erro de "projetos diferentes"; não havia bypass conhecido

• First Party Authentication (FPA)

  • Muitas APIs suportavam a autenticação proprietária do Google chamada FPA, que funciona junto com chave de API
  • As requisições web incluem Cookie de sessão e um valor Authorization calculado a partir dele, enviados ao host *.clients6.google.com
  • Algumas APIs, como drivefrontend-pa, exigem um header mais completo de FPA v2, que inclui no hash identificadores do usuário, como e-mail
  • Michael encontrou um sourcemap que o Google havia exposto por engano durante algum tempo e, com isso, obteve o código de geração de headers FPA v2 da biblioteca interna gapix

• Estrutura do token e Gaia ID

  • O formato do token é <timestamp>_<hash>_<chave_identificadora>, e a entrada do SHA1 é "email:gaiaId timestamp sessionCookie origin"
  • Existem apenas três chaves identificadoras: e (e-mail), u (Gaia ID ofuscado) e a (domínio Workspace); outras letras são ignoradas pelo backend
  • Gaia significa "Google Accounts and ID Administration", e toda conta possui um Gaia ID não ofuscado e sequencial (ex.: 131337133377) e um ID ofuscado longo

• Whitelist de Origin e restrições de chave

  • Muitas APIs mantêm uma lista de Origin permitido e, se um origin não autorizado for usado, retornam SESSION_COOKIE_INVALID, um erro fácil de confundir com problema de cookie
  • As chaves têm quatro tipos de restrição: Server, Browser, Android e iOS; Browser exige Referer, iOS exige X-Ios-Bundle-Identifier, e Android exige correspondência entre X-Android-Package e a impressão digital do certificado
  • Esses valores também foram armazenados durante a coleta de chaves, integrando tudo ao mesmo sistema de força bruta
  • Origens *.corp.google.com não têm restrição; por isso, APIs desse tipo tendem a ser internas e não destinadas ao público, além de apresentarem mais bugs — um caso rendeu US$ 9 mil por uma falha de controle de acesso

Mapeando o fluxo de requisições e criando ferramenta própria de teste

• Foi criado um programa para classificar em que etapa a requisição era bloqueada (interpretação do método → validade da chave → restrições da chave → autenticação → checagem de origin → label etc.), produzindo um mapa de quais chaves funcionam em quais APIs
• Como o API Explorer do Google só suporta APIs públicas e não podia ser usado diretamente para isso, foi criado ao longo de cerca de uma semana um API Explorer próprio com suporte até a FPA v2
  • A especificação é analisada no cliente para montar automaticamente JSONs válidos de requisição/resposta, além de uma interface para testar rapidamente payloads arbitrários
  • O endpoint mostrado na demo vazava assignedTams (technical account managers) por uma falha de controle de acesso e rendeu US$ 6 mil

Estrutura de testes automáticos com IA

• O objetivo era fazer a IA encontrar automaticamente problemas básicos de controle de acesso, para depois um humano expandi-los em falhas mais graves
• O código de parsing JSON do frontend foi ligado à IA como ferramenta MCP, permitindo que ela testasse APIs como uma pessoa

• Mais completo, mais silencioso

  • No início, a IA tentava algumas vezes e encerrava cedo demais, então foi imposta uma Ralph Wiggum loop: o processo só termina depois de testar pelo menos uma vez todos os endpoints
  • Os endpoints foram primeiro classificados em grupos lógicos, testados por grupo, com os achados dos grupos anteriores compartilhados com os posteriores
  • A entrada de probe_api foi simplificada em endpoint, path e body, enquanto a autenticação FPA complexa passou a ser tratada pelo backend, deixando a IA focar apenas na criação do payload
  • Como a resposta podia variar por chave, a mesma requisição era enviada automaticamente com todas as chaves, e respostas iguais eram agrupadas por hash
  • Erros confusos como Method not found foram traduzidos para mensagens como MISSING_REQUIRED_VISIBILITY_LABEL, evitando que a IA se confundisse

• Resolvendo ruído e validação

  • No começo, bugs reais ficavam soterrados sob 90% de ruído, e os dois problemas centrais passaram a ser a dificuldade de validação e os falsos positivos em excesso
  • Os relatórios passaram a incluir o operation ID da requisição real, para permitir reprodução pelo frontend com o botão "Play" e gerar evidência não manipulável
  • Depois de mais de um mês refinando o prompt de sistema, os critérios de reporte ficaram claros — só entravam acesso a dados de outros usuários ou respostas 2xx em casos onde deveria haver 4xx; simples enumeração de existência (existence enumeration) era excluída
  • A partir daí, a IA passou a encontrar bugs em massa com mais de 50% de precisão, sendo o único limite a quantidade de chaves de API disponíveis

Principais vulnerabilidades descobertas

• Em menos de 3 meses de operação, foram encontrados bugs equivalentes a US$ 500 mil; abaixo estão alguns casos representativos já corrigidos

• Tomada de conta do Google Voice

  • gfibervoice-pa não tinha nenhum controle de acesso, e com uma única linha de curl sem autenticação era possível despejar todos os PII da vítima, como número de telefone e endereço de notificação, bastando conhecer seu Gaia ID não ofuscado
  • A resposta também podia revelar o telefone de recuperação da conta Google da vítima (apenas em certas condições, que o Google não divulgou)
  • Havia também um endpoint capaz de forçar a atribuição de um número Voice a qualquer conta (mesmo com erro 500, o número era adicionado de fato), além de outro com potencial para SIM swap
  • Classificado como P0/S0, foi corrigido em poucas horas e rendeu US$ 20 mil
  • Logo após o patch, foi descoberta a exposição de zhandlers de intranet, como /btz; ao alcançar /flagz, era possível extrair chaves de API do serviço em execução

• Tomada de conta do AdExchange

  • Foi encontrado um endpoint capaz de despejar, com uma única requisição, a lista completa de contas do AdExchange
  • Um endpoint de contas bloqueado em produção ainda funcionava sem controle de acesso no ambiente de staging, que apontava para dados reais de produção
  • Também era possível se adicionar como ADMIN a qualquer conta; os dois relatórios renderam US$ 30 mil no total

• eldar.corp.google.com

  • A API do Eldar, site interno usado por Googlers para gerenciar avaliações de privacidade, ficou exposta externamente, permitindo que não-Googlers consultassem informações sensíveis, como pedidos de acesso a logs internos
  • Mesmo após o bloqueio, foi informado adicionalmente que o serviço seguia acessível por outro endereço de sandbox, totalizando US$ 26.674

• Vazamento de vídeos privados do YouTube

  • Como o nome do asset criado no upload seguia o formato Auto generated asset - <video_id>, bastava pesquisar para vazar IDs de vídeos privados e assisti-los
  • Com uma requisição a cada 30 segundos, era possível obter um feed em tempo real de vídeos privados enviados por parceiros — uma ameaça concreta que poderia ser usada para apostas com informação privilegiada em mercados de previsão, aproveitando o fato de empresas subirem vídeos de anúncios de produtos com antecedência e em modo privado
  • Rendeu US$ 12 mil (alta qualidade do relatório)

• Exposição de chaves do Widevine DRM

  • A API do portal de parceiros do Widevine, um dos maiores DRMs do mundo e usado por Disney, Netflix e outros, estava acessível publicamente
  • Era possível despejar a lista completa de organizações, consultar e descriptografar chaves PGP e AES de uma organização específica, e até se adicionar a uma organização arbitrária para gerenciar dispositivos
  • Rendeu US$ 16.004,40 (alta qualidade do relatório)

• plx.corp.google.com

  • A API DataHub por trás da plataforma interna de análise PLX, usada por funcionários, estava exposta, permitindo consultar metadados de tabelas com informações de funcionários ativos
  • Em uma API de staging, era possível usar setIamPolicy para se adicionar como admin do dataset, o que permitia despejar dados confidenciais do YouTube, incluindo tabelas de até 2,1 PB
  • Em 1 hora, o caso foi reconhecido como P0/S0, e as duas falhas renderam US$ 12 mil cada

Vulnerabilidade cross-tenant no Translation Hub

• Foram descobertos vários problemas de controle de acesso no Translation Hub, produto de gestão de tradução de documentos em larga escala
• ListOperations funcionava sem token OAuth e vazava nomes de contas de serviço internas, nomes de buckets GCS e nomes de tabelas internas
• Com apenas um bearer token de qualquer conta Google, era possível consultar dados de projetos alheios, incluindo e-mails de tradutores e nomes confidenciais de arquivos de trabalho
• Com UpdateProjectConfig, ao alterar a configuração da vítima para um caminho GCS arbitrário, era possível abusar das permissões de uma conta de serviço compartilhada para exfiltrar objetos privados de GCS em base64
• A soma das três falhas rendeu US$ 36.500

YouTube TV CMS

• Em uma API de contas do YouTube CMS, capaz de aplicar strike, claim ou monetização a vídeos arbitrários, o endpoint de campanha não verificava em nenhum momento a relação do chamador com o recurso
• GET /v1/campaigns fazia um dump global de todas as campanhas do sistema sem escopo, e também era possível modificar, copiar e excluir campanhas apenas com o ID
• Como efeito colateral, vazavam e-mails sensíveis de contas CMS; a falha rendeu US$ 24 mil (alta qualidade do relatório)

Vertex AI Search for Commerce

• Em um produto de busca e recomendação para varejo, conversationalSearchCustomizationConfig permitia ler e modificar configurações de projetos arbitrários sem controle de acesso
• Na leitura, expunha o prompt de sistema (preamble do modelo) do cliente e exemplos de classificação com notas internas de política
• Na escrita, permitia injetar payloads de prompt injection no prompt de sistema da IA de busca voltada ao cliente, rendendo US$ 30 mil

Cloud Console GraphQL

• Mesmo serviços internos não expostos diretamente à internet podiam ser acessados indiretamente por uma superfície de proxy; o Cloud Console (codinome Pantheon) usa GraphQL para fazer proxy para backends gRPC

• Bypass de verificação de assinatura

  • Cada requisição valida uma assinatura de consulta (querySignature), o que dificulta adulteração, mas foi descoberto que consultas sem autenticação no staging não validavam a assinatura
  • Usando introspection, foram coletados 3.448 schemas e arquivados no GitHub, além da introdução do conceito de "query path" para integrar GraphQL à infraestrutura de fuzzing com IA já existente

• Logs de requisição do App Engine

  • GetDashboardAppStats retornava 24 horas de logs do App Engine de projetos arbitrários sem validação IAM e sem sequer exigir autenticação
  • Como URLs de requisição podem conter links de redefinição de senha e tokens, a falha rendeu US$ 18 mil e recebeu o CVE-2026-8934

• Vertex Assistant

  • Após analisar 5 GB de JavaScript de frontend, foi identificado o recurso experimental oculto Vertex Assistant, com sua feature flag forçada manualmente no DevTools
  • Todas as queries relacionadas funcionavam sem autenticação apenas com userId, permitindo que qualquer pessoa com o e-mail do alvo consultasse e alterasse listas de sessão e histórico completo de conversas, rendendo US$ 30 mil

• Créditos de billing do Maps Platform

  • ListBillingAccountCredits funcionava sem checagem de permissão e, com wildcard, retornava informações de crédito de vários clientes
  • PII de clientes inseridos por funcionários do Google no momento da aprovação ficavam expostos em texto puro no campo justification, rendendo US$ 12 mil

Encerramento e lições

• Em 3 meses, essa configuração gerou mais de US$ 500 mil em recompensas, e o que foi publicado representa apenas uma parte
• A maioria dos bugs do Google não exigia exploits sofisticados; o fator principal era persistência, com os mesmos padrões quebrados se repetindo por toda parte — falta de checagem IAM, GraphQL sem autenticação, endpoints de debug em produção e sandboxes apontando para dados reais
• O papel da IA não foi o de ser criativa, mas o de verificar repetidamente o óbvio sem se cansar em uma superfície ampla demais para humanos cobrirem até o fim
• Principais conclusões
  • O sistema de reprodução via operation_id foi o elemento decisivo para tornar o fluxo produtivo — sem verificação em um clique, a saída da IA vira ruído inútil
  • Com discovery docs, GraphQL SDL e proto em mãos, a IA consegue entender quais entradas testar de forma útil
  • Como a superfície server-side do Google é altamente padronizada, abstrair peculiaridades da infraestrutura para a IA permite focar mais nos testes reais de API

[j2sus91]

Esse é realmente um novo conceito de lucro com vibe coding.