Login com Google OAuth não consegue se proteger quando alguém compra o domínio de uma startup que faliu

• Uma falha de segurança no Google OAuth cria uma vulnerabilidade grave no processo de autenticação do "Sign in with Google"
  • Após comprar o domínio de uma startup que faliu, é possível recriar contas de e-mail desse domínio e fazer login em serviços SaaS
  • É possível acessar serviços com dados sensíveis:
    • Slack, ChatGPT, Notion, Zoom, sistemas de RH (incluindo número de seguridade social)
  • O Google recusou a correção no relatório inicial, dizendo que era um "comportamento intencional"
• Causa raiz do problema: o Google OAuth não detecta mudanças na propriedade do domínio
  • Quando o domínio muda de dono, o novo proprietário pode entrar em contas de ex-funcionários com as mesmas credenciais (claims)
• Informações básicas de credencial usadas:
  • hd (domínio hospedado): inclui a informação do domínio (ex.: example.com)
  • email: inclui o endereço de e-mail do usuário (ex.: [e-mail])
• Se o provedor de serviço depender dessas duas informações, a mudança de propriedade do domínio permite acesso à mesma conta
• Escala do problema
  • 6 milhões de pessoas nos EUA trabalham em startups
  • 90% das startups fracassam
  • 50% das startups que fracassam usam Google Workspace
• Cerca de 100.000 domínios de startups que faliram estão disponíveis para compra
• Em média, 10 funcionários e 10 serviços SaaS por domínio → mais de 10 milhões de contas podem conter dados sensíveis

Propostas de solução e resposta do Google

• Soluções propostas ao Google:
  1. ID único do usuário: adicionar um identificador de usuário exclusivo que não muda com o tempo
  2. ID único do Workspace: adicionar um identificador exclusivo do Workspace vinculado ao domínio
• Resposta inicial do Google:
  • Relatório em setembro de 2024 → encerrado como "não corrigível"
  • Após a apresentação na conferência Shmoocon em dezembro de 2024, o Google voltou a revisar o problema
  • Pagamento de bug bounty de US$ 1.337 e início do trabalho de correção
• No momento, sem uma correção do Google, não é possível resolver a causa raiz do problema
• Alguns serviços retornam a lista de todos os usuários quando o domínio coincide, o que agrava ainda mais a vulnerabilidade
• Mesmo usando senha em vez de login do Google, ainda seria possível redefini-la
  • Startups costumam impor SSO e 2FA em vez de autenticação por senha
  • Provedores de serviço devem exigir verificação adicional na redefinição de senha (código por SMS, confirmação de cartão de crédito)

Conclusão: um problema estrutural na segurança do Google OAuth

• Uma falha na implementação de OAuth do Google permite sequestro de contas quando a propriedade do domínio muda
• O trabalho de correção do Google começou, mas a solução definitiva ainda não está concluída
• No momento, os dados e as contas de milhões de americanos estão em risco

[sixmen]

Tenho a impressão de que isso é um erro do usuário, que usou um e-mail com domínio como meio de autenticação, depois abriu mão do domínio e não desativou corretamente os SaaS relacionados; mesmo assim, isso também deveria ser considerado uma falha de segurança?

[kargnas]

No serviço que estou criando, eu já tinha bloqueado esse problema de antemão, mas ainda assim concordo com essa opinião.
Se isso é um problema, então temos que considerar que login e cadastro comuns por e-mail também são problemáticos. Afinal, todos usam o e-mail como identificador único, e a verificação de posse na recuperação de senha também é sempre feita por e-mail.

Levando isso ao extremo, se assumirmos que um domínio famoso como gmail.com ou hotmail.com foi comprometido e a permissão para alterar as configurações de DNS do domínio passou para um invasor, é muito natural que as contas de todos os SaaS do mundo fiquem em risco.

[GN⁺]

Comentários no Hacker News

• A situação em que a DankStartup encerra as atividades e o domínio é adquirido por outra pessoa, permitindo acesso a contas existentes, parece ser uma questão de responsabilidade da DankStartup, Microsoft e OpenAI

  • Não é apropriado descrever isso como uma vulnerabilidade do OAuth

• Na implementação de OpenID do Google, a forma correta é autenticar usando a claim sub

  • É necessário haver um fluxo para o caso de a claim sub mudar
  • O "ID de usuário único imutável" proposto não é diferente da claim sub

• É um problema fundamental de abordagens que dependem de DNS: depois que o domínio expira, o novo proprietário pode herdar os privilégios do proprietário anterior

  • Esse é um problema que pode ocorrer em sistemas de autenticação que dependem de endereço de e-mail ou DNS

• Não há vulnerabilidade no Google OAuth, e ao adquirir um domínio você passa a ser dono de todos os endereços de e-mail desse domínio

  • O mesmo resultado pode acontecer mesmo sem usar Google OAuth

• Relato de experiência passada com o caso do thehunt.com, em que após adquirir o domínio foi possível acessar todos os serviços

  • Sugestão de ideia de startup para monitorar o status de domínios e prevenir ameaças de segurança

• O problema está em serviços que não usam o campo sub; é preciso usar o campo sub para identificar usuários

  • É possível ganhar dinheiro enviando relatórios de vulnerabilidade para serviços que não usam o campo sub

• Proposta de implementar dois identificadores imutáveis no OpenID Connect do Google

  • A claim sub e um ID exclusivo de Workspace vinculado ao domínio

• Casos em que a claim sub muda no Google OAuth são raros, e o problema provavelmente está na implementação do serviço

• Relato de um caso de acesso a e-mail após aquisição de domínio

  • O problema foi resolvido por meio de uma conexão interna com o Google

• A alegação de "milhões de contas" se baseia na suposição de que startups que falharam não desativam suas contas de SaaS