Falha parcial em alguns recursos do Google OAuth

• Em serviços que confiam no email claim do Google OAuth para determinar permissões de login, ex-funcionários podem continuar com acesso a apps como Slack e Zoom mesmo após serem removidos da organização Google da empresa
• É possível criar uma conta Google com um e-mail que não seja do Gmail, e usando aliases de e-mail e encaminhamento com plus addressing do e-mail corporativo, uma conta Google fora da organização pode enviar um email claim com o e-mail do domínio da empresa
• Essa conta não-Gmail não aparece na tela de administração nem na lista de usuários da organização Google da empresa, mas muitos serviços permitem login olhando apenas para o domínio no fim do e-mail
• Organizações podem mitigar o problema desativando o login com Google e aplicando SAML de forma estrita, mas alguns serviços ou apps internos podem não oferecer essa opção ou não suportar SAML
• O caso foi reportado ao Google em 4 de agosto, uma recompensa de $1337 foi paga em 5 de outubro, e a divulgação ocorreu em 16 de dezembro, 134 dias depois, mas até a data da publicação as mudanças de mitigação do Google ainda não haviam sido implantadas

---

Divulgação da vulnerabilidade e cronograma

• Uma vulnerabilidade no Google OAuth permite que funcionários desligados e removidos da organização Google da empresa mantenham indefinidamente o acesso a aplicações como Slack e Zoom
• Até o momento da divulgação, o Google não havia implantado mudanças para mitigar esse risco
• O cronograma é o seguinte
  • 4 de agosto: reportado ao Google, com aviso de que centenas de aplicações poderiam ser afetadas
  • 7 de agosto: o problema entrou em triagem
  • 5 de outubro: o Google pagou $1337 pelo problema
  • 25 de novembro: divulgação privada em lote para dezenas de aplicações afetadas, incluindo Zoom e Slack
  • 16 de dezembro: divulgação pública após 134 dias desde a notificação ao Google

O risco de usar o email claim como identificador

• O login do Forager, da Truffle Security, já havia sido afetado anteriormente pela vulnerabilidade no Microsoft OAuth da Descope
• Na época, ficou confirmado que a Microsoft podia enviar um Email claim que ela mesma não gerava nem validava diretamente, e que o email claim em geral não é um identificador confiável
• A documentação OIDC do Google também alerta para não usar Email como identificador principal
• O claim email_verified também foi tratado como um ponto peculiar, mas não foi identificado um método para gerar um email claim a partir de um e-mail não verificado
• Ainda assim, foram confirmados casos suficientes de abuso do próprio email claim

Contas Google não-Gmail e email claims duplicados

• É possível criar uma conta Google usando um endereço de e-mail já existente, sem que ele seja do Gmail
  • Por exemplo, é possível criar uma conta Google com um endereço do Yahoo
  • Essa conta pode enviar o email claim com esse e-mail não-Gmail configurado
• Um dos motivos pelos quais a documentação do Google recomenda não usar e-mail como identificador principal é que duas contas Google diferentes podem enviar o mesmo email claim
  • Depois de alterar o e-mail não-Gmail nas configurações
  • é possível criar uma nova conta com o e-mail anterior e obter o mesmo email claim

Contas que permanecem fora da organização Google da empresa

• A falha central é que, para e-mails da organização Google da empresa, é possível criar contas Google fora da organização usando aliases de e-mail e encaminhamento com plus addressing
• Endereços com plus addressing do e-mail corporativo podem ser encaminhados para a caixa de entrada do usuário original
• Nesse fluxo, é possível criar uma conta Google não-Gmail baseada em um endereço com plus addressing do e-mail corporativo, e essa conta não pode ser removida nem desativada no processo de offboarding pela organização
• Muitos serviços analisam esse e-mail e decidem se o login é permitido com base no domínio ao final do endereço
  • É possível se cadastrar no Zoom com essa conta
  • É possível se cadastrar no Slack com essa conta
• Como essas contas Google não-Gmail não são membros reais da organização Google, elas não aparecem nas configurações de administração nem na lista de usuários Google da empresa

Mitigações para organizações, provedores de serviço e Google

• Organizações podem mitigar o problema desativando o login com Google e exigindo SAML de forma estrita
  • Isso funciona na maioria dos provedores de serviço
  • Alguns serviços não oferecem essa opção
  • Aplicações internas desenvolvidas pela própria empresa podem ser afetadas e talvez não suportem SAML
• Provedores de serviço podem usar o HD claim do Google OAuth
  • O HD claim envia o domínio da organização Google à qual a conta está vinculada
  • Contas que não pertencem a uma organização Google não incluem o HD claim
  • A maioria dos provedores testados usava o email claim em vez do HD
• O HD claim ainda tem limitações importantes
  • HD não é um identificador único, e sim apenas um domínio
  • Se uma organização Google for excluída e o domínio for abandonado, outra pessoa pode registrar esse domínio e criar uma nova organização Google
  • Um exemplo é quando a empresa A é adquirida pela empresa B, B encerra os serviços de A e deixa de renovar o domínio antigo
  • Se alguém na internet comprar o domínio da empresa A, poderá fazer login nas contas antigas de serviços da empresa A
• Provedores de serviço podem deixar de permitir criação de conta JIT como recurso padrão e migrar para provisionamento apenas por convite ou baseado em grupos LDAP
• O Google poderia mitigar amplamente o problema proibindo contas Google criadas com domínios já usados por organizações Google existentes
  • O Google já proíbe internamente contas google.com
  • A mesma proteção poderia ser estendida a outras organizações
• Outras mitigação possíveis por parte do Google incluem proibir cadastro de contas Google com plus addressing, proibir cadastro com aliases de e-mail do Google e oferecer melhores configurações administrativas para que organizações possam ajustar essas regras

Impacto adicional: e-mails de suporte e fluxos com magic link

• Mesmo sem acesso inicial, pode ser tecnicamente possível entrar no Zoom ou Slack de uma organização
• Esse fluxo aproveita pesquisas de vulnerabilidades que outros pesquisadores encontraram em fluxos de login por magic link
• Alguns sistemas de suporte e tickets, como o Zendesk, permitem criar tickets por e-mail
  • É possível criar uma conta Google usando o endereço de e-mail do ticket de suporte
  • Pode haver uma forma de concluir a criação da conta consultando o conteúdo do ticket
  • Depois disso, é possível tentar login via OAuth com esse endereço de e-mail de suporte
• Não é seguro manter a função email to support no domínio principal, e uma alternativa é configurar o e-mail de suporte do Zendesk como endereço de e-mail alternativo

Objetivo da divulgação e problemas restantes

• O problema de ex-funcionários manterem acesso em plataformas como Slack e Zoom decorre de uma falha no sistema do Google OAuth
• O Google tem capacidade para aplicar correções amplas que mitiguem esse problema
• O objetivo da divulgação é incentivar mudanças reais, e não apenas pequenas alterações na documentação
• O Google fez a triagem rapidamente, mas, ao contrário de sua prática interna de melhorias em 90 dias, o problema foi divulgado no 134º dia

[GN⁺]

Comentários do Hacker News

• Trabalho nessa área e, nos últimos 3 a 4 anos, já lidei mais de 20 vezes com variações dessa vulnerabilidade em vários provedores de login e empresas de SaaS. O post do blog está correto, mas acho que o problema central já foi longe demais para ser corrigido. A autenticação delegada na internet como um todo é uma bagunça completa e, como já conversei bastante com engenheiros do Google e da Microsoft, tenho certeza de que eles já conhecem essa classe de problemas. Só que mudar o comportamento agora quebraria serviços existentes demais e implementações corporativas de login com décadas de idade
  A “correção” neste momento é simples. Se um site usa “Sign in with XYZ”, ele não deve confiar no endereço de e-mail enviado pelo provedor. Não conceda privilégios especiais apenas com base no domínio do e-mail e sempre envie um e-mail de verificação próprio antes de marcar algo como verificado no banco de dados. Os principais provedores de OAuth também atualizaram a documentação para deixar isso explícito, e o próprio texto aponta isso. Por isso, o fato de ter havido recompensa é até surpreendente

  • Parece consequência de as organizações não entenderem direito o quanto essa área é complexa na prática. Observando a adoção de OAuth2 + OIDC em várias empresas, isso sempre foi vendido como um recurso, tipo “entrar com x”, e não sob uma perspectiva de segurança em primeiro lugar. Mesmo ao tentar tornar o fluxo mais seguro com coisas como PKCE, vira um jogo de whack-a-mole porque cada plataforma se comporta de forma bagunçada em compartilhamento de cookies, tratamento de redirecionamentos etc. A base do OAuth2 de 3 partes é sólida e há muitos precedentes como CAS, mas a OpenID Foundation merece muitas críticas pela forma como comercializou e vendeu o OIDC
  • O método de “não conceder privilégios especiais apenas com base no domínio do e-mail e sempre enviar um e-mail de verificação próprio antes de marcar algo como verificado no banco de dados” não falha se o usuário registrou uma conta no Google usando um endereço com plus addressing e entrou no serviço com essa conta do Google antes de ser expulso? A menos que se envie um e-mail de verificação a cada login
  • Neste caso específico, o invasor realmente consegue receber o e-mail de verificação, então não vejo qual seria o sentido desse procedimento de verificação
  • “Sempre enviar um e-mail de verificação próprio antes de marcar algo como verificado no banco de dados” torna o recurso de entrar com x inútil do ponto de vista do usuário
  • O Google não poderia ter impedido cadastros usando domínios de clientes do Google Apps? Isso não parece que quebraria muita coisa

• Relacionado a isso, mais provedores de serviço deveriam parar de usar e-mail como identificador principal, como recomenda a documentação do Google. Quando mudamos nomes de usuário no Google Apps, gastei bastante tempo lidando com problemas no Slack, Datadog, GoLinks etc.

  • O que os provedores deveriam usar? Sempre pensei que o e-mail fosse o identificador global mais estável para um usuário, mas parece que essa suposição está errada
  • Discordo. Esse tipo de orientação apenas empurra a responsabilidade para os desenvolvedores de aplicações, e a maioria provavelmente não fará nada ou implementará cada uma do seu jeito
    O caminho certo aqui é oferecer uma API adequada às necessidades da aplicação que será usada e que minimize responsabilidades adicionais. Neste caso, acho que o Google deveria ter definido email_verified como false, para que a aplicação ou o IdP subordinado soubesse que seria necessária verificação adicional

• Se user@domain já é tratado pelos servidores de e-mail do Google e, portanto, as regras de roteamento com sinal de mais são aplicadas, não entendo por que é possível criar uma nova conta do Google com um e-mail como user+suffix@domain. Mesmo sem abuso, parece perfeito para criar uma configuração de e-mail confusa

  • Domínios podem migrar livremente de servidor de e-mail. O Google trata [e-mail] de uma determinada forma, mas outro servidor pode não tratar. No fim, os dois são endereços de e-mail únicos diferentes e também deveriam ser tratados assim na internet como um todo
  • Esse recurso de alias parece ter ficado complexo demais para o próprio bem. Especialmente na escala do Google
  • É pior do que user+suffix@domain. Pelo menos +XYZ está especificado nas RFCs de e-mail. O Google foi além e decidiu que pontos dentro do nome também contam como e-mail canônico. Por exemplo, [e-mail] é o mesmo que [e-mail], e todos os e-mails são roteados para este último
  • É porque o sistema de autenticação do Google é um legado muito antigo. Uma “Conta do Google” é apenas uma string

• Sobre o trecho “fiquei surpreso ao saber que a Microsoft envia claims de e-mail que não foram criados nem verificados pela Microsoft, e que, em geral, claims de e-mail não são considerados confiáveis”, mesmo que essa tenha sido a intenção original, acho muito útil que o OIDC possa ser mais flexível. Por exemplo, opero um provedor de login gratuito[0], que verifica a identidade por meio de um OIDC superior ou de e-mail direto, usando um provedor de identidade (IdP) como quarta parte, e cria uma barreira de privacidade entre o app e esse IdP. Ou seja, impede que o Google rastreie todos os apps em que o usuário faz login
  Poder trazer seu próprio e-mail para o Google significa obter a segurança e a experiência de usuário do OIDC do Google junto com a privacidade de e-mail+senha, mas com a grande ressalva de que agora você precisa confiar no LastLogin em vez do Google. Também estamos trabalhando em protocolos para reduzir essa dependência. Discordo totalmente do trecho “a documentação do Google, na verdade, alertava para não usar e-mail como identificador”. E-mail é a única identidade federada real que as pessoas de fato usam. Até que uma alternativa melhor seja amplamente implantada, acredito que endereços de e-mail devam ser tratados como identidade
  [0]: https://lastlogin.io

  • Discordo de “endereços de e-mail devem ser tratados como identidade”. Há dois motivos
    Fora do Ocidente, celulares são mais comuns que computadores e a UI costuma ser mais fácil, então é mais provável que números de telefone sejam a identidade. Além disso, fazer isso significa entregar totalmente a identidade ao provedor de e-mail. Organizações sem rosto como o Google podem bloquear o acesso sem aviso ou processo de contestação — e de fato fazem isso —, então você pode perder tudo. Para contextualizar: lancei os produtos OAuth e OIDC da Okta, criei cursos relacionados no LinkedIn e agora faço isso de novo na Pangea Cyber
  • “Endereços de e-mail devem ser tratados como identidade” pressupõe que ninguém compartilha endereço de e-mail e que e-mail é muito seguro?
    Dá para esperar para sempre, ou então começar a criar uma solução
  • Há uma diferença importante entre um identificador de e-mail dentro do seu próprio sistema e o e-mail como identificador de uma conta Google conectada. Concordo que, dentro de um sistema que você controla, e-mail funciona razoavelmente como identidade, mas, ao conectar com sistemas externos, é uma abordagem péssima, como o Google diz. É temporário, pode estar vinculado a várias contas e, quando existe um ID real que pode ser usado, não há motivo para não usá-lo
  • Seria muito bom ver uma comparação entre LastLogin e Dex. Como ambos são em Go, fico especialmente curioso. Também queria saber se vocês avaliaram o Dex
    Mexi um pouco com Portier e com o antigo Mozilla Persona, mas no fim lidar com a normalização de e-mails pareceu uma batalha perdida, ou difícil demais. Quase aceitei que morreria antes de uma boa solução ser desbravada e voltei minha atenção para outra coisa

• Isso é realmente um problema do Google OAuth, ou é uma falha de muitos provedores de serviço em validar corretamente as claims do token OAuth antes de conceder acesso? Parece mais a segunda opção

  • O problema parece ser que esses provedores de serviço seguem as regras de alias do Google, mas ignoram o fato de que e-mail não deve ser usado como identificador principal [1]. O curioso é que, se tivessem seguido melhor a especificação, estaria tudo bem; e, inversamente, se tivessem seguido menos a especificação e tratado aliases como e-mails diferentes, pelo menos teria sido mais seguro
    [1] https://developers.google.com/identity/openid-connect/openid...
  • Acho que o OAuth está se comportando como esperado. user@domain e user+wildcard@domain ainda são endereços de e-mail que o usuário “possui” e que foram verificados, portanto fornecem autenticação e identidade válidas para esse endereço de e-mail
    O problema está no lado do site de organizações do Google. Um administrador não consegue revogar credenciais de contas ou e-mails que não consegue ver. O trecho “essas contas Google não-Gmail não aparecem nas configurações do administrador nem na lista de usuários do Google porque, na prática, não são membros da organização Google” é o ponto central

• Seguindo esse fluxo, alguém poderia criar uma conta Google com o endereço de e-mail de tickets de suporte, potencialmente ver o conteúdo do ticket para concluir a criação da conta e então fazer login via OAuth em vários serviços usando esse endereço de suporte. Isso pode afetar muitas empresas pequenas

• A maior conclusão aqui é que autenticação na web ainda é uma bagunça terrível

  • Porque as pessoas não leem a documentação e simplesmente presumem que as coisas funcionam do jeito que elas imaginam
  • Se você se pergunta por que pessoas sensatas e pragmáticas ainda usam e exigem autenticação por senha simples, é porque senhas funcionam corretamente

• A especificação OIDC diz que e-mail não deve ser usado como identificador único. Como nome de usuário da aplicação, devem ser usados os campos iss e sub
  O primeiro motivo é que é óbvio que o endereço de e-mail de um usuário pode ser reutilizado. Se um contratado trabalha tanto para a Empresa A quanto para a Empresa B, e ambas criam uma conta de usuário para essa pessoa no serviço de autenticação, do ponto de vista de uma plataforma SaaS não dá para mapear um único endereço de e-mail a um único cliente B2B. Em segundo lugar, endereços de e-mail mudam. Empresas são adquiridas, mudam de nome e passam por fusões; nomes de pessoas também mudam por casamento, divórcio ou escolha pessoal. Implementar SSO em uma startup foi realmente difícil no começo. É difícil fazer corretamente, e é preciso entender bem os conceitos gerais, OIDC e OAuth2 antes de usar. A Auth0 tem um bom livro sobre isso. Se você não entender, é bem provável que acabe implementando autenticação por password grant por toda parte e tornando a aplicação insegura

  • Às vezes, ler textos assim reduz um pouco a síndrome do impostor que vai se acumulando. Faz pensar: “se estou integrando com um sistema de terceiros para representar algum ator abstrato, preciso de um identificador confiável, estável e que não seja só uma string qualquer”. Na prática, a especificação também é muito clara nessa parte, e isso está além das considerações básicas ao criar qualquer sistema minimamente robusto

• Parece uma pequena miniatura. Essa coisa chamada OAuth2 na verdade não existe. OAuth2 é apenas uma forma de grandes empresas implementarem seus próprios sistemas de autenticação arbitrários e proprietários. Não é um sistema de autenticação, é uma caixa de ferramentas para criar sistemas de autenticação. Por isso, OAuth2 deveria virar um padrão, mas, na prática, acabamos num mundo em que cada grande empresa tem uma implementação incompatível com as outras. Claro que as pessoas vão desenvolver de acordo com os casos de uso das grandes empresas, mas aí o “padrão” acaba virando algo como o jeito que o Google faz
  E cada um tem esses pequenos bugs. Precisamos voltar ao OAuth1. Aquilo era um padrão de verdade, não uma caixa de ferramentas para criar padrões

  • Isto é menos um bug e mais um efeito colateral infeliz da combinação de certos componentes: nomes de domínio cuja propriedade pode mudar, trazer seu próprio e-mail, e-mail de backup e origem do e-mail, aceitação generosa de aliases com sinal de mais, e implementadores de serviços que não leem a documentação. Os implementadores provavelmente copiaram a solução de um vídeo ou de um exemplo em que partes foram omitidas por concisão
    Se você está projetando um circuito com alguns componentes de PCB e precisa colocar resistores e transistores de acordo com os requisitos de tensão e corrente, não deveria esperar que a pessoa lesse o datasheet? Se ela simplesmente chutar a partir de um exemplo simples e seguir em frente, em muitos casos o circuito pode até funcionar, e talvez funcione com alguns testes de bancada e medições. Mas ele pode ser ineficiente, ou componentes podem entrar em curto, reduzindo o tempo médio até a falha e deixando clientes insatisfeitos. No pior caso, a bateria pode pegar fogo e causar dano real. Nesse caso, o dispositivo falhar prematuramente é culpa do fabricante dos módulos de PCB ou responsabilidade do fabricante do dispositivo, que deveria ter lido o datasheet? Não tenho expectativas tão rigorosas para todo software, mas, se estiver lidando com autenticação e autorização, acho que o dono do serviço precisa ser minucioso. O texto original também diz que, se a documentação for seguida, o problema não existe. Como a Alphabet pagou uma recompensa de bug, ela reconheceu a fraqueza; então talvez forneça controles para que administradores de empresas gerenciem aliases com sinal de mais ou funções inexistentes por listas de permissão/bloqueio, ou restrinja que e-mails relacionados ao Apps sejam transferidos para claims fora da organização. Provavelmente estão medindo o impacto, ou definindo a prioridade dessa medição, mas acho que a prioridade será baixa, porque é um problema de clientes que presumem que uma claim de e-mail é mais autoritativa e permanente do que realmente é. A definição de “bug” depende muito de como se define “comportamento esperado” e de quem espera esse comportamento, mas, no mínimo, não vejo isso como um desvio do comportamento pretendido, nem como algo inesperado para quem entendeu corretamente a documentação
  • Hum... vamos aceitar isso. A compatibilidade entre provedores tem relação com este artigo sobre a segurança do Google OAuth2?

• Estou deixando passar alguma coisa? Tirando o sistema de suporte/Zendesk mencionado no artigo e o método de domínios antigos abandonados, ao criar uma nova conta Google como [e-mail], é exigida verificação. Então qual é a viabilidade real de exploração?

  • O ponto principal é preparar isso enquanto você ainda tem acesso legítimo, e depois perder esse acesso
    Por exemplo, digamos que exista legitimamente uma conta Google [e-mail]. Você pode criar uma nova conta Google com um endereço de e-mail verificado usando um alias como [e-mail]; então, ao fazer “Login com Google”, o Google enviará a claim de e-mail [e-mail]. Depois, se você for demitido de mydomain.com, não poderá mais fazer login na conta vinculada ao [e-mail] real, porque o administrador a desativou. Mas a nova conta Google [e-mail] não está vinculada à organização, então você continua conseguindo fazer login. Só que, na minha visão, isso só se torna problema quando o provedor faz autorização apenas com base na claim de e-mail. Já usei OIDC antes, e você não deve conceder acesso a recursos parseando o texto da claim de endereço de e-mail. Entendo por que o autor achou isso contraintuitivo, mas o próprio texto diz que a documentação alerta para não fazer isso. No original está escrito: “a maioria dos provedores de serviço que testei não usava HD e usava a claim de e-mail”; tudo bem, mas “usava” para quê? Esse truque funciona em algum serviço real no mundo real? Se funciona, deveriam divulgar os nomes para que sejam criticados. Mesmo que alguém presuma erroneamente que esse valor é único e imutável, isso por si só não necessariamente concede algum acesso