Bugbunny-Research

O servidor de API descompacta arquivos de pipeline carregados sem limitar adequadamente os dados expandidos ao localizar ou ler o arquivo de pipeline. Isso pode permitir que um pequeno arquivo ZIP ou tar compactado com gzip consuma memória desproporcionalmente grande, esgotando os recursos do servidor de API. No processamento de upload de pipeline e versão de pipeline multipart, a descompactação ocorre antes da autorização do namespace, portanto, um chamador acessível não precisa de uma decisão de autorização de criação de pipeline bem-sucedida. Por outro lado, os manipuladores de importação de URL autorizam antes de buscar e descompactar um arquivo remoto.

O servidor de API não autoriza os chamadores ao recuperar logs através do endpoint 'GET /apis/v1alpha1/runs/{run id}/nodes/{node id}/log'. Um invasor com acesso ao backend que conheça um `run id` de vítima e um `node id` válido pode ler logs ao vivo ou arquivados usando as permissões do servidor de API. No caso de logs ao vivo, o `node id` é aceito como um nome de pod sem verificar sua associação com a execução solicitada, permitindo potencialmente a leitura de logs do container principal de pods não relacionados dentro do namespace selecionado. O manipulador carece de autenticação interna, dependendo de gateways externos ou políticas de rede para controle de acesso. Isso pode levar à exposição de dados de carga de trabalho sensíveis ou credenciais.

Quando o `Echo.IPExtractor` não é definido explicitamente, a função `Context.RealIP()` recorre à leitura dos cabeçalhos `X-Forwarded-For` ou `X-Real-IP` fornecidos pelo cliente sem validar a origem do proxy. Como o middleware `RateLimiter()` padrão utiliza o `Context.RealIP()` para identificar clientes, um invasor remoto pode rotacionar valores arbitrários nesses cabeçalhos para obter novos buckets de limite de taxa. Isso permite que o invasor ignore o controle de tráfego baseado em IP usado para proteção de volume de requisições e controles de segurança, como a prevenção de força bruta em endpoints de login ou redefinição de senha. Detalhes técnicos incluem: - **Endpoints de API:** Qualquer endpoint protegido pelo middleware `RateLimiter()`. - **Parâmetros ou Variáveis Vulneráveis:** Cabeçalhos HTTP `X-Forwarded-For` e `X-Real-IP`. - **Nomes de Funções:** `Context.RealIP()` e `RateLimiter()`.

No middleware de Proxy, a estrutura pode preservar um cabeçalho `X-Real-IP` fornecido por um invasor e encaminhá-lo para um serviço upstream quando o `Echo.IPExtractor` não está configurado. Isso ocorre porque a função `ProxyConfig.ToMiddleware()` não sobrescreve o cabeçalho se ele já estiver presente e nenhum extrator estiver definido. Um cliente remoto pode falsificar seu endereço de cliente, o que pode ser usado para burlar controles de acesso baseados em IP, limitação de taxa, restrições geográficas ou poluir logs de auditoria que confiam na identidade encaminhada.

O middleware `MethodOverride` permite que uma requisição POST seja reescrita para um método HTTP seguro (como `GET`, `HEAD`, `OPTIONS` ou `TRACE`). Quando este middleware é registrado antes do middleware `CSRF` na cadeia de pós-roteamento, o método da requisição é alterado antes que o middleware `CSRF` o avalie. Consequentemente, o middleware `CSRF` ignora a validação do token e as verificações `Sec-Fetch-Site` para o que ele percebe como um método seguro, enquanto o manipulador POST de alteração de estado original ainda é executado. Isso permite que uma vítima autenticada seja enganada para realizar operações de alteração de estado via requisição cross-site. O problema originou-se na função `MethodOverrideConfig.ToMiddleware()` em `middleware/method override.go`, que carece de uma lista de permissões para métodos de destino, e na função `CSRFConfig.ToMiddleware()` em `middleware/csrf.go`, que confia no método reescrito.

A função `Context.Scheme` confia incondicionalmente nos cabeçalhos de esquema encaminhados de qualquer cliente. Isso permite que um cliente que se conecte via HTTP simples alegue um esquema HTTPS, ignorando o mecanismo HTTPSRedirect ao fazer com que a requisição pareça segura. Além disso, quando utilizado atrás de um proxy de terminação TLS que encaminha cabeçalhos controlados por um invasor, um esquema HTTP alegado pode suprimir o cabeçalho Strict-Transport-Security, mesmo que o navegador receba a resposta via HTTPS. Isso ocorre porque o framework carece de uma configuração de fonte confiável para esses cabeçalhos.

Ocorre a injeção de template no lado do servidor porque os campos de mensagem controlados pelo usuário não são validados antes da renderização do template, permitindo que expressões sejam executadas em um contexto irrestrito. Atacantes autenticados com uma função operacional comum podem injetar expressões de template para ler e gravar dados arbitrários no banco de dados, excluir documentos, enviar solicitações externas do servidor e enviar e-mails do site.

A falta de validação de entrada em alguns endpoints permite que atacantes autenticados com baixos privilégios realizem SQL injection, que é uma técnica usada para manipular consultas ao banco de dados. Ao enviar requisições especialmente elaboradas, um atacante pode extrair informações sensíveis do banco de dados.

Um problema de time-of-check time-of-use (TOCTOU) existe no componente `ImageConfig` dentro da função `Get()` do arquivo `pkg/xpkg/client.go`. Isso ocorre quando a verificação de assinatura de pacotes está habilitada e os pacotes são instalados usando referências de tag em vez de digests de registros não controlados pelo usuário. Um registro OCI malicioso poderia fornecer uma imagem corretamente assinada durante a etapa de verificação e, posteriormente, fornecer uma imagem não assinada ou maliciosa durante a etapa de instalação, pois a referência da tag é resolvida separadamente para cada ação. Isso permite a instalação remota de conteúdo de pacote não verificado.

Usuários autenticados podem realizar server-side request forgery (SSRF) ao enviar URLs manipuladas. Este problema ocorre na função `fetch url()` da classe `ScenarioImport`, permitindo que atacantes façam requisições HTTP arbitrárias. Isso pode ser utilizado para sondar serviços de rede interna, enumerar portas através de assinaturas de erro e acessar endpoints de metadados de nuvem para recuperar credenciais sensíveis.

O Pomerium é um proxy de acesso consciente de identidade e contexto. Em implantações de autenticação hospedadas ou stateless, o endpoint `/.pomerium/callback` é acessível sem credenciais e processa payloads criptografados via HPKE antes que a identidade do remetente seja validada. A função `decodeQueryStringV2` em `pkg/hpke/url.go` realiza a descompressão zstd de dados controlados por um invasor sem um limite de memória de saída. Um invasor não autenticado pode obter a chave pública do receptor em `/.well-known/pomerium/hpke-public-key`, fornecer uma chave de remetente correspondente e enviar um payload compactado (uma bomba de descompressão) para o endpoint `/.pomerium/callback`. Isso pode resultar na alocação de centenas de megabytes de memória por requisição, levando ao esgotamento da memória, travamentos do processo ou degradação de desempenho, bloqueando efetivamente o acesso aos aplicativos protegidos. Este problema não afeta implantações stateful, pois estas verificam uma assinatura HMAC antes da descriptografia e descompressão.

Um usuário autenticado pode clonar recursos para destinos pertencentes a outras equipes e acessar recursos entre locatários (cross-tenant). Isso ocorre porque a ação Livewire `cloneTo()` em ResourceOperations.php autoriza o recurso de origem, mas resolve os recursos de destino usando buscas Eloquent não escopadas, que são consultas ao banco de dados que não aplicam as restrições de propriedade ou locatário necessárias.

Existe um problema onde o auxiliar `executeInDocker()` envolve comandos em `bash -c '{$command}'` sem escapar aspas simples. Isso permite que os campos controlados pelo usuário `docker compose custom build command` e `docker compose custom start command` sejam interpolados diretamente, permitindo que um invasor use uma aspa simples para sair do argumento bash e executar comandos arbitrários no host do servidor gerenciado, ignorando o isolamento pretendido do contêiner Docker.

Um token de atualização (refresh token) roubado persiste após o fluxo de esquecimento de senha, permitindo que seja usado para gerar novos JSON Web Tokens (JWTs) mesmo depois que o usuário redefine sua senha. Enquanto as funções `passwordChange()` e `passwordReset()` excluem os tokens de atualização do usuário, a função `passwordForgot()` apenas rotaciona a variável `token version` e revoga tokens OAuth, falhando em chamar `UserRefreshToken.deleteAllUserToken(user.id)`. Consequentemente, um invasor com um cookie de atualização capturado pode trocá-lo por um novo token de acesso após a vítima concluir o processo de recuperação, resultando em acesso não autorizado persistente.

Quando `NC SECURE ATTACHMENTS` está definido como `true`, um uploader autenticado pode enviar anexos `.html` ou `.svg` que o navegador renderiza inline a partir da origem do NocoDB em vez de forçar o download. Isso ocorre porque o manipulador de anexos assinados armazena as substituições de cabeçalho de resposta usando chaves em PascalCase (`ResponseContentDisposition`, `ResponseContentType`), enquanto o controlador que serve o arquivo espera nomes em letras minúsculas com hífen (`response-content-disposition`). Essa incompatibilidade faz com que o cabeçalho `Content-Disposition: attachment` seja descartado, permitindo que o Express renderize esses arquivos inline automaticamente. Isso resulta em Stored Cross-Site Scripting (XSS), onde um script executado no navegador da vítima pode ler o JWT de autenticação do `localStorage`.

Tokens de acesso e de atualização OAuth não são revogados quando um usuário altera, redefine ou recupera sua senha. Isso ocorre porque a função `revokeAllOAuthTokensByUser()` no serviço de usuários era um stub vazio chamado por `passwordChange()`, `passwordForgot()` e `passwordReset()`. Consequentemente, uma concessão OAuth emitida por um invasor permanece válida mesmo depois que o usuário realiza essas ações de segurança para bloquear partes não autorizadas, permitindo acesso não autorizado persistente.

Um usuário autenticado com acesso de Leitor (Reader) pode recuperar o recurso `ImportedClusterSecrets` durante o processo de importação de clusters Talos independentes. Este recurso contém o pacote completo de segredos da CA, incluindo a CA do Kubernetes, a CA do etcd e as chaves de conta de serviço. Um invasor com essas chaves privadas pode assinar certificados para qualquer usuário ou grupo do Kubernetes, como `system:masters`, obtendo acesso total de administrador do cluster às APIs do Kubernetes, Talos e etcd, independentemente do plano de controle do Omni. Isso permite o controle total sobre as cargas de trabalho, credenciais e segredos do Kubernetes dentro do cluster importado afetado.

Uma condição de corrida TOCTOU (Time-of-Check to Time-of-Use) existe na função `SAML.getSession` em `internal/pkg/auth/interceptor/saml.go`. O sistema verifica a flag `Used` de um recurso `SAMLAssertion` e, posteriormente, marca-o como usado em duas operações separadas. Como essas ações não são atômicas, requisições simultâneas usando o mesmo token `saml-session` podem passar pela validação. Isso permite que um invasor que interceptou um token `saml-session` válido se autentique como o proprietário do token múltiplas vezes, ignorando a garantia de uso único. Isso pode resultar em replay de sessão, na confirmação de múltiplas chaves públicas controladas pelo invasor através da função `ConfirmPublicKey` para estabelecer acesso persistente e acesso não autorizado a endpoints gRPC protegidos pelo interceptor SAML.

Existe um problema em que o caminho de upload por URL não aplica o limite `NC ATTACHMENT FIELD SIZE` ao `Content-Length` anunciado do arquivo remoto ou ao comprimento decodificado de uma URI `data:`. Isso permite que usuários autenticados com permissões de upload ignorem os limites de tamanho de arquivo configurados, potencialmente excedendo as cotas de armazenamento e largura de banda.

Tokens de API excluídos continuam a autenticar solicitações até que a entrada do cache expire, pois o cache de autenticação não é invalidado pelo valor do token no momento da exclusão. O processo de exclusão remove a linha do banco de dados, mas não remove a entrada indexada pelo valor do token do cache. Consequentemente, o middleware de autenticação continua a aceitar o token excluído até que a entrada do cache expire, criando uma janela de até três dias entre a exclusão e a revogação real. Isso compromete a garantia de segurança de que a exclusão do token é imediata.