1 pontos por GN⁺ 2025-02-13 | 1 comentários | Compartilhar no WhatsApp
  • Ao investigar a documentação interna da People API do Google, foi descoberto que, ao bloquear um usuário, são usados o “ID de perfil”, chamado de “Gaia ID ofuscado”, e um “nome alternativo”
  • Foi confirmado que, ao bloquear outro usuário no YouTube, o Gaia ID desse usuário pode aparecer em https://myaccount.google.com/blocklist, ficando exposto
  • Como esses Gaia IDs são identificadores de contas do Google, surgiu a possibilidade de usá-los para descobrir o endereço de e-mail do usuário

Possível expansão para todos os canais do YouTube

  • Além de ser possível verificar o Gaia ID de usuários no chat ao vivo, foi investigado se também seria possível obter essa informação para todos os canais do YouTube
  • Foi descoberto que, ao clicar no menu “Mais” de um canal no YouTube, uma solicitação específica é feita e inclui o Gaia ID do canal
  • Foi confirmado que é possível obter o Gaia ID do canal por meio dessas solicitações

Obtenção do endereço de e-mail via Pixel Recorder

  • Foi testado se seria possível converter um Gaia ID em endereço de e-mail por meio de um produto do Google chamado Pixel Recorder
  • Ao compartilhar uma gravação, foi confirmado que, ao inserir o Gaia ID do destinatário, o sistema retornava o respectivo endereço de e-mail
  • Com isso, foi confirmado que era possível converter um Gaia ID em endereço de e-mail

Obtenção do endereço de e-mail sem notificar o alvo

  • Havia um problema: ao compartilhar a gravação, um e-mail de notificação era enviado ao alvo
  • Foi descoberto um método para contornar isso, definindo um título de gravação extremamente longo para impedir o envio do e-mail de notificação

Composição da cadeia completa de ataque

  1. Obter o Gaia ID de um canal por meio do endpoint /get_item_context_menu do YouTube
  2. Usar o Pixel Recorder para compartilhar com o alvo uma gravação com título extremamente longo e, assim, converter o Gaia ID em endereço de e-mail
  3. Remover o alvo da lista de compartilhamento para apagar os rastros

Relato e recompensa

  • 15 de setembro de 2024: a vulnerabilidade foi reportada ao Google
  • 16 de setembro de 2024: o Google recebeu o relato e respondeu com o feedback “Nice catch!”
  • 5 de novembro de 2024: o painel de segurança do Google definiu uma recompensa de US$ 3.133
  • 12 de dezembro de 2024: foi concedida uma recompensa adicional de US$ 7.500, totalizando US$ 10.633
  • 12 de fevereiro de 2025: a vulnerabilidade foi divulgada publicamente

1 comentários

 
GN⁺ 2025-02-13
Opiniões no Hacker News
  • Achei este título confuso. Para quem não leu até o fim do artigo: os e-mails vazados não custaram nada para eles, e eles receberam uma recompensa de bug bounty de US$ 10.000

  • A cada terceira mensagem nesta thread aparece algo dizendo que o Google pagou pouco por esse bug. Alguns pontos básicos sobre avaliação de vulnerabilidades:

    • A avaliação de vulnerabilidades do lado do servidor é baixa. Porque os fornecedores não competem por elas
    • Bugs de cadeia completa, como Android/Chrome, são negociados por centenas de milhares de dólares. Porque o Google compete com um mercado cinza bem estabelecido
    • Comparar bug bounty com mercado cinza é comparar maçãs com laranjas. O Google paga muito menos do que o mercado cinza porque não precisa de um exploit confiável
    • Agentes de ameaça compram vulnerabilidades que se encaixam em processos de negócio já existentes. Eles não ficam especulando sobre o que poderiam fazer com uma vulnerabilidade nova
  • O pagamento de bounty normalmente não é uma avaliação da criatividade ou do quão interessante é o bug. Ainda assim, aqui US$ 10.000 parece um valor bem alto para um bug web do lado do servidor

  • A estratégia de negócio de quem encontra esse tipo de bug é achar muitos bugs. Não é como desenvolvimento de exploit para iOS, em que se investem meses em um único exploit

  • Isso é parecido com a pesquisa de vulnerabilidades que fiz recentemente na minha carreira. Mas, se houver pessoas que fazem esse trabalho profissionalmente, eu gostaria de ouvir a opinião delas

  • Há muita conversa sobre divulgação responsável, suas motivações e recompensas. Mas não há nenhuma história como contraponto de dados contra identidades permanentes centralizadas

  • Sempre que vejo um serviço dizendo que funciona apenas com um único vínculo à Real Identity™, isso me lembra que os fornecedores na verdade não têm interesse em proteger os usuários

  • Imagine chegar alguns passos mais perto de poder expor instantaneamente alguém com quem você interage no YouTube. Esse é o impacto real desse bug

  • É bom que esse bug tenha sido corrigido, mas esse tipo de bug não parece que vai desaparecer tão cedo. O que seria preciso fazer para que fornecedores e grandes empresas percebam que esse tipo de design é perigoso?

  • Ótima descoberta! Encontrar uma vulnerabilidade em um serviço tão famoso vai ficar muito bem no currículo. Parabéns

  • "Aplicado um ajuste de redução de 1 nível em relação ao valor base devido à complexidade necessária na cadeia de ataque" - isso é comum?

  • Participei apenas de alguns programas de vulnerabilidade, mas na maioria deles pagam menos quando a falha de segurança é muito simples

  • Um comentarista já explicou como o valor da bounty se relaciona com o valor no mercado negro. Agora muita gente pode achar que o Google não leva segurança a sério o suficiente

  • Para fins de segurança, deve-se pagar o mínimo possível. Pagar mais aumenta o incentivo para encontrar bugs, e o mercado negro também pode crescer

  • A estratégia GTO é bloquear o mercado negro com a menor quantidade de dinheiro possível

  • Eu estava procurando algo para pesquisar no Google e investigava a documentação descoberta da Internal People API (Staging). Isso deveria estar público?

  • Eu queria que houvesse uma forma de enviar e-mail para donos de canais no YouTube. A maioria não tem contato por e-mail, e é difícil falar com eles para patrocínios ou outros negócios

  • Fico me perguntando se o Google divulga vulnerabilidades de segurança quando elas não são corrigidas em até 90 dias. Neste caso, foi corrigida em 147 dias

  • Impedir que o sistema de e-mail dispare é um problema adicional. Uma empresa grande como o Google desenvolveu muitos produtos, mas "segurança" parece falsa. Cada linha de código pode se tornar uma vulnerabilidade em potencial