Lucasdodgson

A interface de usuário Login V2 está suscetível a injeção de cabeçalho de host. Atacantes não autenticados podem envenenar links de redefinição de senha, convite e verificação de e-mail fornecendo valores não confiáveis nos cabeçalhos `x-zitadel-public-host`, `x-zitadel-forward-host` ou `x-forwarded-host`. Se um atacante souber o nome de login de uma vítima, poderá redirecionar links em e-mails legítimos para um host sob seu controle para coletar códigos de uso único e assumir contas, incluindo as de administradores da instância.

O Login V2 contém um problema de autorização ausente que permite que invasores aprovem autorizações de dispositivo OAuth 2.0 usando a sessão existente de uma vítima sem o seu consentimento. Ao enviar a um usuário conectado um link contendo o código de usuário do invasor, o invasor pode obter os tokens da vítima e ignorar as configurações de acesso ao projeto por meio da API de autorização de dispositivo OIDC.

Existe uma falha de bypass de autenticação na interface de usuário Login V2. Atacantes não autenticados podem obter tokens de sessão de outros usuários forjando cookies de sessão não assinados. Ao adivinhar IDs de sessão ordenados por tempo associados ao login de uma vítima e fornecer tokens vazios, os atacantes podem receber tokens rotacionados. Isso permite a invasão completa de contas, incluindo sessões de administradores que já completaram a Autenticação de Múltiplos Fatores (MFA), um processo de segurança que exige dois ou mais fatores de verificação.

Existe uma falha de bypass de autenticação nas interfaces de usuário (UIs) hospedadas Login V1 e Login V2. O sistema permite o registro de uma passkey ou outro autenticador durante sessões de login apenas para identificação, antes que qualquer fator primário seja verificado. Um invasor não autenticado que conheça o nome de login de uma vítima pode registrar um autenticador controlado pelo invasor para obter acesso não autorizado à conta, ignorando senhas e a autenticação de múltiplos fatores (MFA).

Existe um problema onde links são criados entre contas de usuário e provedores de identidade externos sem a verificação de um fator primário ou da permissão do solicitante. Isso ocorre durante sessões de Login V2 apenas para identificação e através do endpoint 'AddIDPLink' do User Service V2. Um invasor não autenticado que conheça o nome de login de uma vítima pode vincular sua própria identidade de provedor externo à conta da vítima para sequestrá-la e entrar como a vítima.

Uma falha de autenticação ausente existe na interface do usuário do Login V1 hospedado. Os manipuladores de inicialização e registro de segundo fator processam sessões apenas de identificação antes que o fator primário seja verificado. Um invasor que conheça o nome de login de uma vítima pode registrar fatores TOTP, OTP-SMS, OTP-Email ou U2F controlados pelo invasor, sobrescrever o número de telefone verificado e enumerar usuários através de mensagens de erro discrepantes.

Existe uma falha de bypass de autenticação no Login V2 que permite que atacantes não autenticados assumam o controle de contas. Atacantes que conheçam o nome de login de uma vítima cadastrada em OTP-Email e OTP-SMS podem obter códigos de senha de uso único (OTP) através do tipo de entrega `returnCode`, lendo-os das respostas de ação do servidor. Isso permite que o atacante estabeleça sessões autenticadas por MFA, incluindo a tomada de controle de contas de administrador.

O ZITADEL é uma plataforma de gerenciamento de identidade de código aberto. A partir da versão 2.31.0 e anteriores às versões 3.4.7 e 4.11.0, tokens de acesso OIDC opacos no formato v2 truncados para 80 caracteres são considerados válidos. O ZITADEL usa criptografia AES simétrica para tokens opacos, e a carga útil em texto simples inclui um ID de token e um ID de usuário. Os tokens da Versão 2 identificam o ID do token como `v2 <oidc session id>-at <access token id>`. Quando os tokens são truncados, o `user id` está ausente no texto simples. O back-end ainda aceita esses tokens truncados porque depende dos dados de sessão do banco de dados para identificação do usuário em tokens v2. A correção nas versões 4.11.0 e 3.4.7 resolve o problema verificando o `user id` do token em relação aos dados de sessão no banco de dados.