Tanguy Snoeck

Instâncias configuradas para exigir o registro de TOTP via `Security.otp required` aplicavam a autenticação de dois fatores obrigatória apenas a solicitações de navegador padrão. Usuários autenticados que ainda não haviam se registrado no TOTP poderiam ignorar essa exigência emitindo qualquer tipo de solicitação que não fosse de navegador, incluindo chamadas AJAX/XHR, solicitações de API REST, URLs no formato `.json`, consultas `restSearch` ou ações de automação. Isso ocorre porque essas solicitações legíveis por máquina não podem seguir o redirecionamento para a página de registro de TOTP, permitindo que o usuário mantenha acesso total à instância sem concluir a configuração do segundo fator.

Uma falha existe no fluxo de autenticação de senha de uso único (OTP) que permite a repetição de um token HMAC-based One-Time Password (HOTP) já consumido e o retrocesso do contador de tokens. O problema ocorre porque a lógica de verificação compara o token enviado com um valor de contador armazenado em cache na sessão do usuário, em vez de utilizar o contador autoritativo no banco de dados. Como o contador em cache não é atualizado após o uso de um token, um invasor com uma sessão válida (onde a senha já foi enviada, mas o OTP está pendente) pode reutilizar um token previamente usado para ignorar o segundo fator de autenticação e obter acesso não autorizado. Esse processo também corrompe o estado do contador HOTP, o que pode invalidar tokens legítimos futuros.

Uma falha no processo de verificação de autenticação de dois fatores (TOTP) permite que um código de uso único válido seja aceito múltiplas vezes dentro de sua janela de validade temporal, geralmente 30 segundos. Isso ocorre porque o sistema não registra se um período TOTP específico já foi consumido. Um invasor que intercepte um código legítimo durante o login de um usuário pode reproduzi-lo para estabelecer uma segunda sessão não autorizada como esse usuário, comprometendo potencialmente funções administrativas e dados de inteligência de ameaças.

Existe uma falha de isolamento de locatários (tenant isolation bypass) na camada de cache semântico devido a uma incompatibilidade de chave de metadados entre as funções ` get semantic cache tenant scope()` e ` get metadata variable name()`. Usuários autenticados com uma chave virtual válida podem explorar isso enviando prompts semanticamente semelhantes para os endpoints '/v1/responses' e '/bedrock/*'. Isso permite que um invasor recupere respostas em cache pertencentes a outros locatários, expondo potencialmente informações de identificação pessoal, dados financeiros ou código-fonte. Além disso, isso pode levar à execução de chamadas de ferramentas fornecidas pelo invasor sob as credenciais da vítima, caso payloads de `function call` ou `tool calls` em cache sejam retornados a um principal diferente.

Um problema de desserialização insegura existe no servidor de registro que permite que atacantes não autenticados ou não autorizados alcancem a execução remota de código. Ao enviar uma solicitação gRPC manipulada, um atacante pode explorar o campo `user defined function.body` de uma especificação OnDemandFeatureView. Este campo é decodificado de base64 e passado para a função `dill.loads()` antes que qualquer verificação de autorização seja realizada. Isso permite a incorporação de um objeto Python serializado malicioso com um método ` reduce ` arbitrário para executar comandos do sistema operacional sob os privilégios da conta de serviço do feast.

Existe um problema onde atacantes não autenticados podem restaurar e herdar sessões de usuários autenticados. Isso ocorre durante a restauração de sessão WebSocket quando um `sessionId` válido é apresentado sem a verificação de propriedade através do caminho 'restore existing session'. A exploração bem-sucedida permite que um atacante assuma as permissões e funções de uma vítima, levando ao acesso não autorizado a dados restritos e à capacidade de invocar ferramentas.