Livio-A

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 UI do Login V2 que permite que atacantes não autenticados assumam o controle de contas de usuários que ainda não configuraram nenhum método de autenticação. Ao computar um cookie `verificationCheck` válido usando o ID do usuário e a impressão digital do navegador, um atacante pode definir uma senha, registrar uma passkey ou vincular um provedor de identidade para a conta alvo.

Um problema de escalonamento de privilégios existe no processo de troca de tokens OIDC. Esta falha permite que usuários com as funções `IAM END USER IMPERSONATOR` ou `ORG END USER IMPERSONATOR` ignorem a verificação `admin.impersonation`. Consequentemente, esses usuários podem se passar por administradores, incluindo aqueles com a função `IAM OWNER`, e entrar em aplicações dependentes com funções e reivindicações administrativas.

Existe uma falha de bypass de autenticação no callback de intenção do provedor de identidade SAML. O sistema verifica a assinatura da asserção usando o provedor especificado na URL da requisição, mas resolve o usuário a partir da intenção de login sem verificar se eles coincidem. Isso permite que atacantes com permissões de administrador de organização registrem um provedor SAML com sua própria chave de assinatura para obter sessões autenticadas como qualquer usuário vinculado a outro provedor SAML na instância, inclusive em outras organizações.

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.

Usuários autenticados podem adulterar seus próprios tokens de intenção de IdP devido ao uso de criptografia maleável e não autenticada. Isso permite que um usuário modifique um token para que ele seja aceito para a intenção de login externo de outro usuário. Um invasor que preveja o identificador de intenção em trânsito de uma vítima e vença uma corrida de tempo (timing race) pode usar os endpoints '/v2/idp intents' ou '/v2/sessions' para roubar tokens de IdP ou sequestrar uma sessão.

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.

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).

A autenticação Login V2 não verifica o estado inativo de uma organização, validando apenas o status do usuário individual. Isso permite que usuários de uma organização desativada façam login, criem sessões e obtenham ou renovem tokens caso possuam credenciais válidas, uma sessão existente ou um token de atualização.

Existe um problema onde o servidor pode ser coagido a fazer requisições a recursos internos durante a verificação HTTP do domínio da organização. Isso ocorre porque o processo de busca de desafio utiliza a função `http.Get` padrão do Go em vez de um cliente protegido. Atacantes podem registrar domínios que redirecionam para endereços de loopback, internos ou de metadados de nuvem, permitindo a varredura de portas e o mapeamento de redes internas. Trata-se de um server-side request forgery (SSRF), que é uma falha que permite a um atacante induzir a aplicação do lado do servidor a fazer requisições para um local não pretendido.

Existe uma falha de bypass de autenticação na interface de usuário Login V1 hospedada. O problema ocorre porque o endpoint de registro para contas externas não encontradas confia em campos de identidade externa fornecidos pelo cliente sem a necessidade de um callback de Provedor de Identidade (IdP) concluído. Um invasor não autenticado pode enviar valores forjados de `IDPConfigID` e `ExternalUserID` para pré-criar uma conta vinculada à identidade de IdP externo de uma vítima. Quando a vítima posteriormente realiza um login externo legítimo, ela é autenticada na conta pré-criada.

Existe uma falha de autorização incorreta na API do User Service. O sistema verifica a permissão `user.read` em relação à organização do chamador, em vez da organização proprietária do usuário alvo. Um membro autenticado com permissões `user.read` com escopo de organização pode utilizar o endpoint 'GET /v2/users/{userId}/authentication methods' para identificar os tipos de métodos de autenticação registrados por usuários de outras organizações.

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.

Nome do Software Vulnerável e Versões Afetadas ZITADEL versões anteriores a 3.4.7 ZITADEL versões anteriores a 4.11.1 Descrição O ZITADEL, uma plataforma de gerenciamento de identidade de código aberto, possuía uma falha em seu recurso de autogerenciamento. Isso permitia que os usuários marcassem falsamente seus e-mails e telefones como verificados sem concluir o processo de verificação. O problema foi resolvido ao aplicar verificações adequadas de permissões ao definir a flag de verificação e restringir o autogerenciamento ao próprio endereço de e-mail e/ou número de telefone. Recomendações Atualize para a versão 3.4.7 do ZITADEL ou posterior. Atualize para a versão 4.11.1 do ZITADEL ou posterior. Se não for possível atualizar, utilize uma ação (v2) para impedir a definição da flag de verificação nas contas de usuário.

A API de gerenciamento de sessão do ZITADEL possui uma falha na qual um usuário autenticado pode atualizar uma sessão conhecendo apenas o seu ID, devido à ausência de uma verificação de permissão. Isso permite o sequestro de sessão, possibilitando que um atacante se passe por outro usuário e acesse recursos sensíveis.

O mecanismo de desativação de contas de usuário do Zitadel não funcionava corretamente com contas de serviço. As contas de serviço desativadas mantinham a capacidade de solicitar tokens, o que poderia levar ao acesso não autorizado a aplicativos e recursos.

O Zitadel é uma plataforma de gerenciamento de identidade de código aberto. O mecanismo de desativação de concessões de usuário não funcionava corretamente, permitindo que concessões de usuário desativadas fossem fornecidas em tokens. Isso poderia levar ao acesso não autorizado a aplicativos e recursos. A API de gerenciamento e autenticação sempre retornava o estado como ativo ou não fornecia nenhuma informação sobre o estado.

O Zitadel é um sistema de gerenciamento de identidades de código aberto. O sistema possui uma configuração chamada “Ignorar nomes de usuário desconhecidos”, que ajuda a mitigar ataques que tentam adivinhar ou enumerar nomes de usuário. Se ativada, o Zitadel exibirá a solicitação de senha mesmo que o usuário não exista e informará “Nome de usuário ou senha inválida”. No entanto, devido a uma alteração na implementação para evitar deadlocks ao acessar o banco de dados, o sinalizador não seria respeitado corretamente em todos os casos, e um invasor obteria informações se uma conta existisse no Zitadel, já que a mensagem de erro exibe “objeto não encontrado” em vez da mensagem de erro genérica.