Dorakemon

**Nome do Software Vulnerável e Versões Afetadas** Vaultwarden versões anteriores a 1.35.5 **Descrição** O fluxo de autenticação WebAuthn na função `validate webauthn login()` atualiza metadados persistentes de credenciais, especificamente as flags `backup eligible` e `backup state`, usando `authenticatorData` não verificado antes que a validação da assinatura seja realizada. Um invasor que possua a senha de um usuário pode modificar permanentemente essas flags de backup armazenadas, mesmo sem uma assinatura WebAuthn válida, pois as atualizações do banco de dados não são revertidas caso a verificação da assinatura falhe. Isso resulta em uma negação de serviço persistente da autenticação de dois fatores WebAuthn para as credenciais afetadas. **Recomendações** Atualize para a versão 1.35.5.

**Nome do Software Vulnerável e Versões Afetadas** versões anteriores à 5.2.4 do web-auth/webauthn-lib **Descrição** O processo de validação de origem do software, ao utilizar a configuração `allowed origins`, reduz valores semelhantes a URL ao seu componente de host, aceitando correspondências com base apenas no host. Isso impede a implementação de políticas de origem exatas, já que diferenças de esquema e porta são ignoradas. Especificamente, o componente `CheckAllowedOrigins` utiliza `parse url()` para extrair o host tanto das origens permitidas configuradas quanto da `clientDataJSON.origin` recebida. Essa redução permite que solicitações com esquemas ou portas diferentes contornem a validação de origem pretendida. Esse problema afeta implantações que utilizam a configuração `allowed origins` e contorna a verificação de origem exata exigida pelos padrões WebAuthn. O componente vulnerável é o `CheckAllowedOrigins.php`. O parâmetro vulnerável é o `clientDataJSON.origin`. **Recomendações** Atualize para a versão 5.2.4 ou posterior para resolver este problema.

**Nome do Software Vulnerável e Versões Afetadas** Versões do Pocket ID anteriores à 2.4.0 **Descrição** O Pocket ID é um provedor OIDC suscetível à troca de código entre clientes e à reutilização de código expirado. O endpoint de token OIDC valida incorretamente os códigos de autorização, rejeitando-os apenas quando tanto o ID do cliente está incorreto quanto o código está expirado. Essa falha permite que um atacante troque códigos de autorização emitidos para um cliente pelas credenciais de outro cliente, potencialmente obtendo tokens para usuários que não autorizaram o cliente malicioso. Códigos de autorização expirados também podem ser reutilizados até que um processo de limpeza seja executado. O problema reside no arquivo `backend/internal/service/oidc service.go`, especificamente na linha 407, onde um `E` lógico (`&&`) deveria ser um `OU` lógico (`||`) na lógica de validação do código de autorização. O código vulnerável é: `if authorizationCodeMetaData.ClientID != input.ClientID && authorizationCodeMetaData.ExpiresAt.ToTime().Before(time.Now())`. Um atacante pode explorar isso usando um código de autorização válido destinado a um cliente com o ID do cliente de outro cliente para obter tokens de acesso. O endpoint da API envolvido é `/api/oidc/token`, utilizando o parâmetro `grant type` definido como `authorization code`, o parâmetro `code` contendo o código de autorização e os parâmetros `client id` e `client secret` para autenticação do cliente. **Recomendações** Versões anteriores à 2.4.0 devem ser atualizadas para a versão 2.4.0 ou posterior.

**Nome do Software Vulnerável e Versões Afetadas** Versões do OneUptime 10.0.11 e anteriores **Descrição** A implementação de autenticação WebAuthn não armazena o desafio no lado do servidor. Em vez disso, o desafio é retornado ao cliente e aceito de volta a partir do corpo da requisição do cliente durante a verificação, violando a especificação WebAuthn. Isso permite que um atacante que tenha obtido uma asserção WebAuthn válida (por exemplo, via XSS, MitM ou exposição de logs) a reutilize indefinidamente, contornando a autenticação de segundo fator. O servidor gera um desafio usando a função `generateAuthenticationOptions()` em `Common/Server/Services/UserWebAuthnService.ts`. O servidor lê o `expectedChallenge` diretamente do corpo da requisição em `/api/identity/authentication/login`. O método `verifyAuthentication()` então passa esse desafio fornecido pelo cliente para o `verifyAuthenticationResponse()` do `@simplewebauthn/server`. Isso permite que um atacante reutilize uma asserção capturada enviando uma requisição contendo o e-mail, a senha e o desafio e credencial capturados da vítima. **Recomendações** Versões anteriores à 10.0.11 devem ser atualizadas quando uma correção estiver disponível. Como solução temporária, considere desativar a autenticação WebAuthn até que um patch esteja disponível.