Recompensa de US$ 10.000 por vulnerabilidade que expôs e-mails de usuários do YouTube

 (brutecat.com)
1 pontos por GN⁺ 2025-02-13 | 1 comentários | Compartilhar no WhatsApp
  • O identificador interno da conta Google de canais do YouTube, o obfuscated Gaia ID, podia ser exposto e vinculado a um endereço de e-mail pela API de compartilhamento do Pixel Recorder, criando um problema de privacidade para contas Google
  • A requisição Innertube do menu de bloqueio no chat ao vivo retornava o parâmetro moderateLiveChatEndpoint contendo o Gaia ID do canal alvo, mesmo sem realizar o bloqueio de fato
  • Ao trocar o ID do canal nos parâmetros da requisição, o alvo podia ser ampliado até mesmo para Topic Channels sem mensagens no chat ao vivo, mostrando que o problema não se limitava a participantes específicos
  • O WriteShareList do Pixel Recorder recebia o obfuscated Gaia ID do destinatário do compartilhamento e incluía o endereço de e-mail na resposta; também era possível impedir o envio do e-mail de notificação usando um título de gravação com 2,5 milhões de caracteres
  • Após receber o relato em 15 de setembro de 2024, o Google confirmou em 9 de fevereiro de 2025 a correção das duas vulnerabilidades e pagou uma recompensa total de US$ 10.633

Gaia ID exposto pelo recurso de bloqueio do YouTube

  • A documentação discovery de staging da Internal People API do Google confirmou que o objeto BlockedTarget usa obfuscated Gaia ID e fallbackName
    • profileId é o obfuscated Gaia ID do usuário bloqueado
    • fallbackName é o nome de exibição do usuário bloqueado
  • A ajuda da Conta Google informava que é possível bloquear contas no YouTube, e na prática, ao bloquear um usuário em uma live do YouTube, esse usuário aparece em myaccount.google.com/blocklist
  • Na lista de bloqueio, o nome do canal Mega Prime aparecia como fallbackName, e 107183641464576740691 era mostrado como profile ID
  • Partindo da premissa de que um canal do YouTube não deveria expor a conta Google subjacente, e como já houve bugs no passado que convertiam Gaia IDs em endereços de e-mail, começou-se a buscar um caminho adicional

Expansão do menu do chat ao vivo para todos os canais

  • Só de abrir o menu de três pontos no chat ao vivo do YouTube já era disparada uma requisição para /youtubei/v1/live_chat/get_item_context_menu
  • A resposta incluía moderateLiveChatEndpoint e o valor params, que levavam a /youtubei/v1/live_chat/moderate
  • Esses params eram um protobuf codificado em base64, comum em serviços do Google, e ao decodificá-los, continham o Gaia ID do usuário a ser bloqueado
    • A resposta de exemplo incluía 113907466537670370590 e identificadores relacionados ao canal
    • Era possível obter o Gaia ID do alvo sem realizar o bloqueio de fato
  • Ao decodificar os parâmetros da requisição get_item_context_menu, encontravam-se o channel ID do canal a ser bloqueado, o ID do vídeo da live e o ID do autor da live
  • Ao testar a troca do channel ID nos parâmetros da requisição por outros valores, também foi possível obter o Gaia ID 103261974221829892167 do Topic Channel gerado automaticamente pelo YouTube

Pixel Recorder virou caminho para conversão em e-mail

  • Ao procurar bugs ou falhas lógicas em produtos antigos do Google que permitissem converter Gaia IDs em e-mails, o pesquisador investigou o Pixel Recorder junto com nathan
  • Após criar uma gravação de teste em um telefone Pixel e sincronizá-la com a conta Google, foram usados os endpoints web de recorder.google.com
  • Ao compartilhar a gravação com um e-mail de teste, a requisição WriteShareList incluía o obfuscated Gaia ID na lista de destinatários do compartilhamento
  • A resposta de PlaybackService/WriteShareList em pixelrecorder-pa.clients6.google.com retornava o endereço de e-mail do destinatário do compartilhamento
    • A resposta de teste incluía vrptest2@gmail.com
    • Ao inserir o Gaia ID 107183641464576740691 obtido no experimento de bloqueio do YouTube, também era retornado redacted@gmail.com
  • Isso permitia montar uma cadeia de ataque na qual o Gaia ID obtido no YouTube era enviado para a API de compartilhamento do Pixel Recorder para descobrir o endereço de e-mail

Título de gravação com 2,5 milhões de caracteres bloqueou o e-mail de notificação

  • Ao compartilhar uma gravação do Pixel Recorder com a vítima, era enviado um e-mail de notificação para ela, o que poderia reduzir o impacto do ataque
  • O pop-up de compartilhamento não tinha opção para desativar notificações, e mesmo ao analisar o protobuf da requisição com req2proto, não foi encontrado nenhum campo para desabilitar o envio
  • A estrutura WriteShareListRequest tinha os seguintes campos
    • recording_id
    • delete_obfuscated_gaia_ids
    • update_shared_users
    • sharing_message
  • Mesmo ao adicionar e remover usuários ao mesmo tempo, o e-mail continuava sendo enviado
  • Aproveitando o fato de que o título da gravação era incluído no assunto do e-mail de notificação, concluiu-se que tornar o título extremamente longo poderia fazer o envio falhar
  • Foi criado e testado um script Python que alterava o título da gravação para 2,5 milhões de caracteres pelo endpoint UpdateRecordingTitle, e não havia limite de tamanho no lado do servidor
  • Depois de definir o título com 2,5 milhões de caracteres, ao compartilhar com outro usuário de teste, o e-mail de notificação não foi enviado

PoC final e cronograma de tratamento

  • A cadeia de ataque completa era composta de três etapas
    • Obter o obfuscated Gaia ID do canal alvo pelo endpoint Innertube /get_item_context_menu do YouTube
    • Compartilhar com o alvo uma gravação do Pixel Recorder com título extremamente longo para converter o Gaia ID em endereço de e-mail
    • Remover esse usuário da lista de compartilhamento da gravação do Pixel Recorder para limpar os rastros
  • O vídeo PoC foi disponibilizado em um vídeo no YouTube

Recompensa do Google e cronograma da correção

  • 2024-09-15: relato enviado ao fornecedor
  • 2024-09-16: o fornecedor fez a triagem do relatório e respondeu Nice catch!
  • 2024-10-03: o painel marcou o caso como duplicado de um bug já rastreado e aplicou uma correção incompleta para a exposição inicial do obfuscated Gaia ID no YouTube
  • 2024-10-03: foi explicado novamente ao fornecedor que o próprio Pixel Recorder também era vulnerável
    • O obfuscated Gaia ID também podia ser exposto em avaliadores do Google Maps e do Google Play
    • Também foi fornecido um método alternativo para voltar a vazar o obfuscated Gaia ID de canais do YouTube
  • 2024-11-05: o painel pagou US$ 3.133 de recompensa
    • Justificativa: explorabilidade média
    • Classificação: metodologia de abuso de alto impacto
  • 2024-12-03: a equipe do produto reenviou o relatório ao painel para revisar uma recompensa adicional e coordenou a data de divulgação para 2025-02-03
  • 2024-12-12: o painel pagou US$ 7.500 adicionais
    • Justificativa: alta explorabilidade
    • Classificação: metodologia de abuso de alto impacto
    • Houve redução de um nível no valor-base devido à complexidade da cadeia de ataque
  • 2025-01-29: o fornecedor pediu prorrogação da divulgação para 2025-02-02
  • 2025-02-09: foi confirmado que as duas partes da cadeia de ataque haviam sido corrigidas
    • Momento ocorrido 147 dias após o relato inicial
  • 2025-02-12: relatório publicado

Leituras relacionadas

1 comentários

 
GN⁺ 2025-02-13
Opiniões no Hacker News

  • O título me confundiu. Para quem não leu até o fim: não é que os e-mails vazados tenham gerado um custo; a pessoa investiu tempo e esperteza e recebeu uma bug bounty de US$ 10 mil

    • No começo, achei que significava que ofereciam um serviço para vazar e-mails de usuários por US$ 10 mil por usuário
    • Eu também achei que queria dizer que estavam oferecendo isso como um serviço de US$ 10 mil
    • Pode ser um título feito para atrair cliques
    • No início, achei que seria algo como custo computacional para fazer brute force de algum hash

  • Há muito ruído sobre divulgação responsável, motivação e recompensa, mas quase não vejo gente dizendo que este é mais um argumento contra uma identidade permanente centralizada
    Toda vez que um serviço afirma que funciona melhor quando está vinculado a uma única Real Identity™, fico com a impressão de que as empresas só se importam em proteger os usuários de forma abstrata — e mesmo assim só às vezes
    Imagine que qualquer pessoa com quem você interaja no YouTube possa ficar imediatamente três ou quatro passos mais perto de doxxar você; para mim, esse é o impacto real deste bug. Ainda bem que foi corrigido, mas não parece que esse tipo de bug vá desaparecer tão cedo. O que será necessário para que empresas e grandes corporações percebam que esse design é um campo minado prestes a explodir?

    • Em abstrato, concordo. Essas contas deveriam permitir certo grau de anonimato e descartabilidade. Afinal, são apenas uma linha em algum banco de dados
      Mas muita gente transaciona com essas empresas usando dinheiro de verdade. Por exemplo, assinantes do YouTube Premium ou criadores de conteúdo. Na prática, em algum lugar dessa conta descartável precisam ficar armazenados identificadores da identidade real. Por causa do risco de fraude e da realidade do sistema bancário, você acaba entregando sua identidade e endereço reais à empresa, e ela também os armazena
      Não forneço informações que me identifiquem a apps ou sites aleatórios, mas quem faz negócios comigo inevitavelmente sabe quem eu sou no mundo real e, em tese, vira um ponto por onde esses dados podem vazar
    • Eles não se importam porque não há consequências legais
      Se um prestador de serviços de saúde vazasse dados médicos, seria completamente destruído

  • “POC funcional do exploit: este vídeo foi removido por violar os Termos de Serviço do YouTube” — isso é engraçado

    • O autor do post original revelou o endereço de e-mail de um usuário real para a prova de conceito. No vídeo reenviado, o endereço de e-mail está desfocado
    • No começo também apareceu assim para mim, mas, ao abrir o texto de novo, parece que o vídeo aparece. Não sei se acabou de ser restaurado

  • Como a cada três comentários nesta thread alguém diz que o Google pagou pouco demais por esse bug, segue uma conversa básica sobre avaliação do valor de vulnerabilidades:
    Vulnerabilidades do lado do servidor têm valor baixo porque as empresas não competem por elas. Na prática, não existe um mercado cinza para vulnerabilidades do lado do servidor. É difícil um terceiro precificar um bug que o Google pode matar imediatamente, que praticamente não tem meia-vida a partir do momento em que é descoberto e que, se explorado, gera telemetria confiável no alvo.
    Em contrapartida, bugs como uma cadeia completa para Android/Chrome são vendidos por centenas de milhares de dólares porque o Google compete com um mercado cinza bem estabelecido. Um fornecedor pode pegar esse bug e vendê-lo para vários órgãos de um país europeu, potencialmente seis.
    Ainda assim, comparar bounties com o mercado cinza é comparar maçãs com laranjas. O Google precisa apenas de uma prova de que é possível escrever o exploit, não de um exploit altamente confiável, e não precisa arcar com custos de manutenção, então paga muito menos que o mercado cinza. O valor total do restante do mercado é dividido em várias etapas e vem com condições de risco, mas o Google pode oferecer um pagamento único atraente, mesmo com desconto.
    Atacantes compram vulnerabilidades que se encaixam em seus processos de negócio existentes. Em geral, eles não ficam imaginando especulativamente coisas legais que poderiam fazer com alguma nova vulnerabilidade e como ganhar dinheiro com isso. Coletar informações de pagamento e obter milhares de máquinas para uma botnet são processos de negócio existentes. Expor o nome real de uma conta do Google poderia virar um negócio? Talvez. Já existe? Provavelmente não.
    O valor pago em bounties normalmente não é um plebiscito sobre quão engenhoso ou interessante é o bug. Embora aqui isso seja um pouco verdade também: US$ 10 mil por um bug web do lado do servidor parece excepcionalmente alto.
    Para quem ganha a vida encontrando bugs desse tipo, a estratégia de negócio é ficar bom em encontrar muitos deles. É diferente do desenvolvimento de exploits para iOS, em que se passam meses em um único exploit confiável.
    A pesquisa de vulnerabilidades que fiz recentemente na minha carreira é mais próxima disso do que de muitas outras coisas, então estou bem confiante. Ainda assim, há gente no HN que trabalha em tempo integral com esse tipo de bounty, então ficaria feliz se alguém assim me corrigisse.

    • Na maioria das outras áreas, as pessoas não são remuneradas com base no valor de mercado negro do que produzem.
      Se essa análise fosse aplicada a outras coisas, o teto de preço de um som automotivo novo ou de uma bicicleta seria de cerca de 100 dólares, e o preço de todos os bens protegidos por copyright ficaria limitado ao custo de transmiti-los pela rede.
      Acho mais útil dividir o valor pago pelo Google pelo tempo gasto nesse trabalho e por todo o tempo gasto em tentativas de exploit que falharam desde o último bounty.
      A maior parte das pessoas nessa área provavelmente ganha menos do que o salário mínimo dos EUA em relação ao esforço, além de arcar com um custo de oportunidade anual de seis dígitos.
      Esse número mostra exatamente o quanto o Google valoriza a segurança e a privacidade dos usuários finais. É um número muito menor do que o que ele paga, várias ordens de magnitude acima, a outros engenheiros para roubar as informações pessoais dessas mesmas pessoas.
    • Não gosto que esta thread do HN seja majoritariamente sobre o valor do bounty, mas também é natural. A maioria das pessoas comentando aqui trabalha no setor de software e quer normalizar bounties muito altos.
      Para elas, isso é uma fonte extra de renda. Assim como engenheiros de software querem que a engenharia de software seja uma profissão bem remunerada, também querem que bug bounties paguem mais. É natural que trabalhadores peçam salários maiores para sua profissão, e nenhuma racionalização muda esse instinto.
    • Você diz que “atacantes compram vulnerabilidades que se encaixam em seus processos de negócio existentes”, mas não existe um mercado para esse tipo de coisa também? Por exemplo: “vamos descobrir quem é a pessoa por trás desta conta que critica nossa empresa/governo suspeito e neutralizá-la”.
      Também há incentivos separados do valor de mercado para atacantes. Uma pessoa violenta que faz stalking de uma celebridade online talvez não seja um cliente lucrativo no mercado de exploits zero-day, mas, se uma empresa pode expor por descuido a identidade do alvo a um stalker violento, essa vulnerabilidade ainda é uma responsabilidade e um risco ético.
      Pessoalmente, se estão pagando quantias enormes a artistas performáticos de LeetCode que produzem volumes imensos de código prestando atenção imperfeita à segurança, acho que também deveriam pagar bem às pessoas que ajudam a encontrar e corrigir os inúmeros erros deles antes que algo ruim aconteça.
    • O uso de bugs do lado do servidor por órgãos de aplicação da lei é uma área muito mais cinzenta, ou pode até ser efetivamente ilegal. Por outro lado, órgãos de aplicação da lei e agências de inteligência já têm procedimentos padrão para obter ordens judiciais que permitam explorar o dispositivo de um alvo específico, isto é, um celular ou notebook.

  • Diz que houve “rebaixamento de 1 nível em relação ao valor base devido à complexidade da cadeia de ataque necessária”; isso é comum?
    Só participei de alguns programas de vulnerabilidades, mas na maioria deles uma falha ridiculamente simples, porém grave, como expor o e-mail do usuário no código-fonte da página, na verdade recebia menos.

    • Entendi que, pelo contrário, houve desconto porque, para uma vulnerabilidade web, ela era relativamente complexa.
    • Isso me parece invertido. Na prática, a pessoa encontrou 2 bugs, então deveriam aumentar o valor base.

  • “Há algum tempo, enquanto procurava alvos de pesquisa no Google, eu estava fuçando a documentação de discovery da Internal People API (Staging)”; isso pode simplesmente ficar público assim?: https://staging-people-pa.sandbox.googleapis.com/$discovery/...

    • É apenas um arquivo de esquema convertido automaticamente a partir de definições internas .proto. O Google depende de criptografia de verdade, não de segurança por obscuridade.
      Além disso, o endpoint de discovery é documentado publicamente[0] e foi criado para usuários externos. Pessoas internas não leem o endpoint de discovery; elas veem diretamente os arquivos .proto pela busca de código.
      Pela minha experiência trabalhando no Google, para expor uma API publicamente era preciso lutar contra a burocracia por semanas. Não é como um bucket AWS S3 que ficou público por acidente. A equipe sabia que isso era público e provavelmente atravessou a burocracia para publicá-lo.
      [0]: https://developers.google.com/discovery/v1/getting_started

  • Pela linha do tempo do texto, o autor reportou à empresa em 2024-09-15; em 2025-01-29, a empresa pediu para estender a divulgação até 2025-02-12; em 2025-02-09, foi confirmado que ambos os lados do exploit haviam sido corrigidos; e em 2025-02-12 ele divulgou
    Então a falha ficou 136 dias sem correção e não foi o Google que pediu a extensão? Foram 147 dias até a correção e 150 dias até a divulgação
    Comparando com o prazo de divulgação antes da correção que o Google Project Zero dá a outras empresas, eles dizem: “Este bug está sujeito a um prazo de divulgação de 90 dias. Se uma correção for disponibilizada aos usuários antes do prazo de 90 dias, este relatório de bug será divulgado 30 dias depois da disponibilização da correção. Caso contrário, será divulgado no prazo”
    “Se houver expectativa de que um patch saia em até 14 dias após o fim do prazo, o Project Zero poderá conceder uma extensão… porém o período de carência de 14 dias se sobrepõe ao período de 30 dias para aplicação do patch, portanto vulnerabilidades corrigidas dentro do período de carência também serão divulgadas, no máximo, no 120º dia a partir do prazo original de 90 dias”
    “Se determinarmos que a correção não ficará pronta em até 14 dias, usamos o prazo original de 90 dias como data de divulgação. Ou seja, só concedemos a extensão de 14 dias quando o desenvolvedor se compromete a distribuir a correção dentro do período de carência de 14 dias”
    https://googleprojectzero.blogspot.com/p/vulnerability-discl...

    • Não acho essa comparação útil. Este é um bug do Google em software do Google, e entendo que os bugs que o Project Zero encontra normalmente são em softwares usados por muita gente, então a urgência de correção é maior

  • “Esses params são apenas protobuf codificado em base64, um formato de codificação bastante usado em todo o Google”: alguém precisa pagar uma bebida para o desenvolvedor do Google responsável por pegar um formato binário elegante de mensagens, codificá-lo em base64 e enfiá-lo à força dentro de um bloco de JSON
    Se você quer ver o futuro, imagine uma bota com “worse is better” gravado na sola pisoteando o rosto de um engenheiro para sempre

    • Isso existe em todo lugar e é péssimo. Às vezes fico pensando se não há mais bytes de protobuf representados em base64 dentro de JSON do que bytes reais de protobuf trafegando pelos cabos da internet, e aí pago uma bebida para mim mesmo
    • Internamente, provavelmente é um protobuf em base64 dentro de um campo protobuf
      A parte de JSON é uma conversão automática
    • Uma string JSON de protocol buffer codificado em base64; não importa qual empresa fez isso, dá para saber qual empresa fez isso

  • A cereja do bolo foi terem quebrado o sistema de e-mail de modo que os e-mails não fossem enviados. Em uma empresa gigante como o Google, que criou inúmeros produtos, segurança parece algo de faz de conta
    Se cada linha de código é uma vulnerabilidade em potencial, em milhões de linhas isso vira simplesmente inevitável. Parece não haver saída além de manter tudo simples, por exemplo aposentando o site do Recorder, mas mesmo assim não é fácil

    • Isso pode ser mais um motivo pelo qual o Google mata tantos produtos que tiveram sucesso, mas não sucesso suficiente para continuar vivos e seguros dentro do sistema geral do Google
    • Infelizmente, considerando a quantidade de usuários do Google, qualquer encerramento vai provocar gritos de dor e reações do tipo “eu dependo disso para aquecer meu computador com a barra de espaço”. Basta ver https://killedbygoogle.com/
    • Eu gostaria de ouvir exemplos de segurança que pareça “real” e de como isso ajuda
      A maioria dos produtos de software depende de stacks de software muito complexos, e acho uma mentalidade equivocada confiar 100% em todas as bibliotecas e sistemas operacionais usados. Até processadores tiveram bugs como o Meltdown. Segurança é uma luta contínua; você nunca sabe se venceu, só fica sabendo às vezes quando perdeu
    • No fundo, você está sugerindo algo como uma equação de Drake[1] para calcular o número de vulnerabilidades de segurança com base na quantidade de linhas de código. Que outros fatores entrariam nessa equação?
      [1] https://en.wikipedia.org/wiki/Drake_equation
    • O ponto central é que segurança é de faz de conta. Nenhum app é realmente seguro. Mesmo gastando milhões de dólares em segurança de aplicativos, um único erro de um usuário humano pode comprometer tudo

  • Eu também entendi o título errado, como se significasse algo tipo US$ 10 mil em custo de computação de GPU. Pelo fato de ele ter escolhido um produto antigo do Google e encontrado uma brecha logo de cara, parece que deve haver dezenas ou centenas de outros bugs desses

    • Não é assim que funciona, como se ele tivesse “escolhido um produto antigo do Google e encontrado uma brecha logo de cara”. É bem provável que o autor tenha investigado vários produtos por semanas ou meses até encontrar algo valioso
    • Eu também entendi errado, achando que significava vender endereços de e-mail de YouTubers por US$ 10 mil