20 pontos por kuroneko 2023-10-27 | 3 comentários | Compartilhar no WhatsApp
  • A Salt Labs descobriu que, por meio de vulnerabilidades em implementações de OAuth, era possível sequestrar contas em serviços gigantes usados por centenas de milhões de pessoas, como Booking.com, Grammarly, Vidio, Bukalapak, além do framework mobile Expo.
  • O OAuth é, em essência, um protocolo seguro, mas isso mostra que implementações incorretas podem criar vulnerabilidades críticas.
  • Booking.com
    • Havia um problema na implementação do OAuth do Facebook que permitia alterar o redirect_uri para outro caminho dentro do mesmo host.
    • Dentro do booking.com, existia um endpoint que redirecionava para um endereço fornecido em formato base64.
    • Combinando esses dois pontos, era possível manipular o fluxo para que o token do OAuth fosse enviado para outro endereço.
    • Na versão web, não havia vulnerabilidade porque o redirect_uri era validado durante o login, mas na versão mobile também era possível manipular o redirect_uri, permitindo o sequestro de conta.
    • Ou seja, era uma vulnerabilidade em que o usuário clicava em um link que parecia totalmente legítimo e, ao concluir normalmente o fluxo de OAuth, tinha a conta sequestrada.
  • Expo
    • Vulnerabilidade encontrada na implementação embutida de OAuth do framework mobile Expo.
    • Nessa implementação, o returnUrl deveria conter um link exclusivo do app Expo no formato exp://~~, mas era possível inserir um endereço web como hTTps://~~.
      • A entrada de https:// era bloqueada, mas bastava mudar maiúsculas e minúsculas para contornar a restrição.
    • Nesse caso, a informação de returnUrl era salva em um cookie chamado RU, e depois da conclusão do OAuth, o servidor OAuth do Expo lia esse cookie e fazia o redirecionamento.
    • No entanto, antes de ir do Expo para o Facebook, aparecia um aviso dizendo algo como confiar em https://~~..., e o usuário precisava aceitá-lo.
    • Para contornar isso, foi usado um método que abria automaticamente 2 links.
      • O primeiro link era aberto e fechado imediatamente apenas para definir o cookie RU.
      • O segundo link fornecia diretamente o link de OAuth do Facebook, ignorando a mensagem de aviso do RU.
    • Com esse método, foi possível sequestrar contas do Codecademy.com.
    • A vulnerabilidade recebeu o identificador CVE-2023-28131, e a equipe do Expo corrigiu o problema poucas horas após o primeiro reporte.
  • Grammarly, Vidio, Bukalapak
    • Nos 3 sites, o sequestro de conta era possível por meio do mesmo método.
    • Primeiro, era criado um site legítimo para coletar tokens de login do Facebook.
    • Depois, em Vidio e Bukalapak, bastava fornecer o token emitido pelo Facebook (gerado para outro site) e o login era aceito normalmente.
      • Essa vulnerabilidade acontecia porque o App ID do token do Facebook não era verificado. (ataque de reutilização de token)
    • O Grammarly era um pouco diferente e usava código em vez de token, então essa vulnerabilidade específica não existia.
    • Porém, foi confirmado que, se em vez de "code" fosse enviado um token com o nome "access_token" para a API que recebe o código, o login era concluído.
    • Portanto, nos 3 sites, bastava fazer a integração com o Facebook em outro site legítimo para que a conta pudesse ser sequestrada imediatamente.
  • Ao implementar OAuth, é necessário identificar os pontos em que vulnerabilidades de segurança podem surgir e validar cuidadosamente todas as etapas do processamento para evitar esse tipo de falha.

3 comentários

 
ironlung 2023-10-28

Isso realmente alerta a gente. Vou tomar muito cuidado mesmo.

 
[Este comentário foi ocultado.]
 
kuroneko 2023-10-27

Pelo visto, mais sites enormes do que eu imaginava tinham muitas vulnerabilidades.
Definitivamente parece ser uma funcionalidade que precisa ser tratada com muito cuidado.

Até dá vontade de pensar que o melhor é usar uma biblioteca de autenticação...,
mas, vendo o caso do Expo, acho que mesmo assim isso também precisa de validação própria.