- É possível contornar o formulário de encontrar conta do Google para verificar se existe um número de telefone vinculado a um nome de usuário específico
- Mesmo em um ambiente com JavaScript desativado, é possível implementar um método de ataque que contorna a limitação por IP ao inserir intencionalmente um token do BotGuard
- Em alguns países, como a Holanda, por causa das características do formato de número de telefone, existem menos de 1 milhão de combinações, o que torna viável uma força bruta em larga escala com rotação de proxies e IPv6
- O nome de exibição da conta do Google pode ser exposto facilmente com o uso do Looker Studio, sem qualquer ação da vítima
- Essa vulnerabilidade já foi reportada ao Google e corrigida, e a cadeia de ataque real permite verificar números de telefone em pouquíssimo tempo com automação
Visão geral
Este texto detalha um caso real que mostra como descobrir o número de telefone de uma conta do Google por meio de ataque de força bruta, além do processo e da resposta defensiva. Em geral, formulários de localização/recuperação de conta usam ambiente com JavaScript e mecanismos anti-bot para impedir abuso. No entanto, aqui se demonstra que é possível contornar esse sistema em um ambiente com JS desativado e com um padrão específico.
Contexto e método da investigação
- Foi descoberto que o formulário do Google para encontrar o nome de usuário da conta funciona sem JavaScript
- O formulário permite verificar com 2 requisições HTTP se existe um número de telefone vinculado a um nome específico (Display Name)
- 1ª requisição: obtenção do valor ess (token de sessão) com base no número de telefone
- 2ª requisição: verificação da existência da conta com os parâmetros ess e nome (GivenName/FamilyName)
- Se a conta existir, a resposta redireciona para
usernamerecovery/challenge; se não existir, redireciona paranoaccountsfound
Contorno da limitação por IP (uso de proxies e IPv6)
- No início, a força bruta era inviável por causa do rate limit por IP e CAPTCHA
- No caso de números móveis da Holanda, como há 1 milhão de combinações (com prefixo já definido), o uso de proxies torna o ataque viável
- Também é possível usar blocos /64 de IPv6 em nuvens como AWS/Vultr para rotacionar o endereço a cada requisição, e o servidor também oferece suporte a IPv6
Contorno com token do BotGuard
- No formulário com JS, é necessário um token do BotGuard
- No formulário sem JS, ao inserir um token coletado do formulário com JS no lugar do parâmetro
bgresponse=js_disabled, passa a ser possível fazer envios ilimitados - Foi criada uma ferramenta multithread capaz de inserir grandes volumes de números de telefone e detectar rapidamente contas existentes
Eliminando falsos positivos (filtragem)
- Dependendo do nome e dos 2 últimos dígitos do número, pode haver vários candidatos
- Foi adicionada uma lógica para filtrar automaticamente falsos positivos, repetindo o teste com um sobrenome aleatório
Formato de números por país e coleta de informações de nome
- O formulário de recuperação fornece apenas parte do formato mascarado do número de telefone
- Os padrões de número por país (national format) podem ser identificados analisando as informações do
libphonenumbersdo Google - O nome de exibição da vítima pode ser obtido sem ação do usuário ao explorar a função de transferência de propriedade no Looker Studio
Otimização e automação
- Com
libphonenumbers, foi criado um dicionário com prefixos, comprimento e regras de validação por país - Com
chromedpbaseado em Go, foi criada uma API para emissão automática de tokens do BotGuard, permitindo automação em ataques reais
Procedimento de ataque real
- Obter o nome da vítima (nome de exibição) via transferência de propriedade no Looker Studio
- Coletar, no fluxo de “esqueci a senha”, parte do número de telefone mascarado do email em questão
- Executar o ataque de força bruta com a ferramenta gpb, com base no nome, máscara e código do país
Tempo e eficiência
- Em um servidor com 16 vCPU e 3000 threads, é possível verificar cerca de 40 mil tentativas por segundo
- Dependendo da combinação de números e do tamanho da dica em cada país, bastariam EUA (20 min), Reino Unido (4 min), Holanda (15 s) e Singapura (5 s)
- Se outro serviço fornecer dica completa (ex.: PayPal), o tempo pode cair ainda mais
Google e cronograma do patch
- 2025.4.14: relatório enviado ao Google; em 4.25 houve agradecimento no painel
- 2025.5 (meados): pagamento de bug bounty de US$ 5.000
- 2025.5: desativação gradual do formulário sem JS e aplicação das medidas de resposta
- 2025.6.9: divulgação oficial da vulnerabilidade
Conclusão
Este caso mostra que a combinação de fluxo de recuperação de conta, mascaramento de número de telefone e nome de exibição já é suficiente para viabilizar ataques automatizados em larga escala. O Google concluiu a resposta ao reforçar o procedimento e encerrar os formulários relacionados.
Dúvidas podem ser enviadas por Signal/email (consulte o texto original)
1 comentários
Comentários do Hacker News
O ponto interessante deste texto é que, apesar de a maioria dos provedores de hospedagem ou ISPs fornecer pelo menos um bloco IPv6 /64, a maior parte dos rate limits e bloqueios de IP ainda é aplicada a um único IP. Em ambiente IPv6, acho que rate limiting e bloqueios deveriam ser feitos com base no bloco /64 inteiro
Vejo com frequência até empresas que deveriam ser responsáveis por gerenciar esse problema, ou que ganham dinheiro com isso, reagindo de forma completamente equivocada ao IPv6. A empresa em que trabalho usa um CDN conhecido, e às vezes recebemos alertas de segurança absurdos como "login feito de um IP estranho", mesmo quando o acesso veio do mesmo bloco /64
Acho que, desde a chegada do IPv6, os métodos tradicionais de bloqueio por IP perderam muito da eficácia. Mesmo um usuário comum de internet residencial pode receber automaticamente um bloco /56 ou /48 com DHCPv6 Prefix Delegation. Por exemplo, eu recebi um /56 da Comcast, e isso pode ser dividido em até 65536 blocos /64. Para fazer filtragem de IP eficaz em IPv6, não basta simplesmente trocar a base antiga de IP único por /64
Mesmo aplicar rate limit por bloco /64 pode não ser suficiente. É fácil demais conseguir um bloco /48. Para obter o melhor controle, é preciso classificar por ASN e até analisar como cada operadora distribui seus IPs, ajustando essa granularidade
Rate limiting por /64 em IPv6 já é algo bem conhecido no setor, e o Google já aplica isso em outros serviços. Entendo isso como resultado de não terem atualizado corretamente as políticas antigas ao adotar IPv6
Até provedores baratos como BuyVM oferecem endereços em bloco /48 no plano mais barato (US$ 2/mês; no momento só há estoque do de US$ 7/mês). Por isso tendem a ser muito usados por operadores suspeitos
No passado tentei um método parecido no Facebook para descobrir o número de telefone de uma pessoa específica. Durante o processo de redefinição de senha, o Facebook mostrava a maior parte do número, então organizei esses dígitos em um arquivo vcard, importei no meu celular e comparei pelas fotos. Funcionou melhor do que eu esperava
Existem brechas parecidas com a foto de perfil do Google ou nos apps do Google. Por exemplo, se no Google Maps Reviews aparece John Smith, dá para adicionar várias variações de e-mail (
johnsmith@gmail.com,smithjohn@gmail.cometc.) no Hangouts e verificar a foto de perfil para rastrear se é a mesma pessoaPor isso nunca informo meu número de telefone real. Nem é algo realmente necessário para operar o serviço
Impressiona que uma única pessoa tenha disparado 40 mil requisições por segundo durante um longo período sem que os recursos disparassem muito nem soassem alertas
Pode até ser que alertas tenham disparado, mas como a atividade parou rápido ou a situação se recuperou depressa, talvez quando o engenheiro abriu o dashboard já estivesse tudo normal de novo. 40 mil QPS não é algo tão fora da curva no volume de tráfego do Focus ou das APIs do Google, e se isso foi distribuído por vários IPs e blocos IPv6 /64, pode ter passado despercebido. O ponto central deste caso, na minha visão, não é o monitoramento, e sim o fato de o fluxo com JS desativado (usando tokens obtidos no fluxo anterior com JS ativado) não ter nenhum rate limit
Também pensei se foi usado um botnet, mas parece que o IP mudava a cada requisição
Esse tipo de bug bounty costuma pagar um valor ridiculamente baixo. É lamentável
Se continuarem reduzindo as recompensas, no fim vão acabar atirando no próprio pé
Pagar menos de US$ 100 mil por um problema de segurança desses é realmente mesquinho
Frequentemente sinto como manter e administrar páginas web legadas é um peso enorme. Muitos sites precisam continuar sustentando código e páginas com décadas de idade, e testar todas as combinações na prática é impossível. Se você cavar nas configurações do Gmail, ainda consegue encontrar pop-ups antigos com cara de 2004
Programas de bug bounty parecem um uso extremamente eficiente de custos. Mesmo com apenas alguns milhares de dólares, dá para mobilizar uma força voluntária para encontrar edge cases extremos. Se isso fosse feito com equipe interna, provavelmente custaria muito mais
Esse é exatamente o principal motivo pelo qual empresas tentam descontinuar agressivamente serviços e produtos antigos. Para a pergunta "não dava para simplesmente deixar como está?", a resposta é que todo serviço legado acaba virando um buraco de segurança. O único código realmente seguro é o código que não existe
Sempre fico pensando quem é que está encarregado de algo como o recurso “poke” do Facebook
Infraestruturas legadas parecidas continuam rodando dentro de grandes empresas também. Por exemplo, um amigo meu faz manutenção de um app interno de encurtamento de links em uma multinacional global, e mesmo com quase nenhuma utilização, sempre aparecem um ou dois tickets por motivos muito simples, como atualizar a versão do Node. É tão raro receber bug report que às vezes nem o monitoramento funcionando direito faz diferença
Recentemente eu também encontrei no Google uma página que ainda mostrava o antigo logo Catull (~2013)
Foi mencionado algo como “2025-05-15 – o painel concedeu US$ 1.337 + swag. Justificativa: baixa possibilidade de exploração (lol)”, mas eu sinceramente acho que a possibilidade real de exploração é muito alta. Talvez o número de pessoas afetadas diretamente não seja tão grande, mas, se houver necessidade, tenho certeza de que detetives particulares, criminosos, investigadores e outros usariam essa vulnerabilidade de verdade
Foi a primeira vez que percebi claramente que dar parte do número de telefone como dica no fluxo de recuperação de senha é, na prática, um risco de segurança. Se vários serviços fornecerem dicas mascaradas de telefone/e-mail em ordens diferentes, o risco fica ainda maior
Talvez não seja reconfortante, mas, por motivos como 2FA e outros, centenas ou milhares de serviços já coletaram meu número de telefone, e uma boa parte deles já vazou independentemente do meu consentimento. Combinações de nome real, e-mail e telefone praticamente com certeza já foram parar em dumps públicos
Existem até bots no Telegram que encontram esse tipo de informação. Quando vulnerabilidades de brute force como esta vêm à tona, parece que até usuários que já usavam ferramentas automatizadas se sentem incomodados (o bot EoG é um exemplo)
Também existem serviços pagos que agregam automaticamente esse tipo de informação pessoal há muito tempo. Dados como e-mail, telefone e outros são acumulados de várias fontes, e há incentivo suficiente no mundo inteiro para explorar agressivamente falhas de segurança desses serviços. No fim, a estrutura sempre acaba ligada a vazamentos em massa
No passado já houve caso de engenharia social em que alguém ligava para o atendimento de uma empresa, pedia os 4 últimos dígitos de um cartão e usava isso para quebrar a verificação de identidade em outra empresa
Também me lembro de ter ouvido, na época da faculdade, uma apresentação de um pesquisador de segurança dizendo que cartões de crédito também podiam ter informações obtidas desse jeito
Em 2025, 2023 e 2021 se repetem reportagens e grandes vazamentos dizendo “não há como prevenir isso”. A versão de 2025, a versão de 2023 e a versão de 2021 continuam se repetindo. Fico pensando qual delas é a mais engraçada
Acho este caso muito criativo e impressionante. O Brutecat mandou mais uma
O Google agora parece mesmo um navio fantasma. Um bug bounty de US$ 5.000 é quase um insulto, e o simples fato de terem começado com um valor tão baixo parece uma prova decisiva de que o Google não leva a sério a proteção dos dados dos usuários