B0B0Haha

O componente de autenticação BasicAuth da plataforma de orquestração de fluxo de trabalho Kestra OSS armazena senhas usando SHA-512, que possui alta velocidade de computação. Um invasor com acesso de leitura ao banco de dados PostgreSQL pode realizar um ataque de força bruta offline para recuperar a senha do administrador. Em implantações de Kubernetes, isso pode levar à escalada vertical de privilégios, permitindo que o invasor leia o ServiceAccount Token do cluster e todos os K8s Secrets.

Existe uma autorização incorreta na interface experimental `/v2`.

Uma falha de verificação de autorização na API DataSource permite que usuários não autenticados exponham metadados arbitrários de fontes de dados. Isso ocorre porque a API não exige login para acessar informações sensíveis de metadados.

O Capsule Controller é executado com privilégios de cluster-admin. Existe uma falha na função `HandleSection()` dentro do arquivo `internal/controllers/resources/processor.go`, onde a lógica de processamento de `RawItems` do `TenantResource` não valida adequadamente os escopos dos recursos. Embora o controlador tente definir um namespace usando `obj.SetNamespace()`, essa ação é ignorada pela API do Kubernetes para recursos de escopo de cluster. Consequentemente, usuários com privilégios de Tenant Owner podem aproveitar as permissões elevadas do controlador para criar recursos de escopo de cluster, como `ClusterRole` e `ValidatingWebhookConfiguration`, que não estão autorizados a criar diretamente. Isso pode levar à escalada de privilégios entre tenants, ataques em nível de cluster, roubo de dados sensíveis de todos os tenants via webhooks maliciosos ou negação de serviço em todo o cluster.

Usuários autorizados em um namespace do Kubernetes podem criar um recurso de Build para controlar a geração de Pods em um namespace de sua escolha, incluindo o namespace do operador. Essa falha de cross-namespace permite que usuários sequestrem pods em namespaces seguros por meio de uma referência externamente controlada a um recurso em outra esfera e bypass de autorização via chave controlada pelo usuário.

Um usuário malicioso com permissões para editar o ConfigMap `local-path-config` no namespace `local-path-storage` pode manipular o template `helperPod.yaml`. Este template é usado para criar HelperPods durante as operações de provisionamento e limpeza de PVC, mas não é suficientemente validado antes do uso. Um invasor pode injetar campos sensíveis de segurança, como `securityContext.privileged`, volumes `hostPath` e capacidades do Linux no template. Quando uma operação de PVC dispara a criação de um HelperPod, o provisionador utiliza o template controlado pelo invasor, resultando potencialmente em um pod privilegiado executando no nó de destino com o sistema de arquivos raiz do host montado. Isso permite que o invasor acesse arquivos confidenciais do host, leia tokens de ServiceAccount de outros pods no mesmo nó, acesse dados de volume de local-path de outros locatários ou modifique arquivos no nó host.

O WebSocket do servidor de interface do usuário aceita conexões de todas as origens por padrão, expondo vários endpoints. Um site malicioso visitado por um desenvolvedor usando um navegador pode estabelecer uma conexão WebSocket de origem cruzada para 'ws://127.0.0.1:8090'. Isso permite o acesso não autorizado aos seguintes endpoints: - '/api/logs' para transmitir logs de pods em tempo real - '/api/enter' para abrir um shell interativo dentro do pod em execução - '/api/command' para executar comandos de pipeline predefinidos

O recurso de Cookie Rewriting está suscetível à injeção de código Lua. Um invasor com permissões de RBAC para criar ou modificar recursos HTTPProxy pode fornecer valores maliciosos nas variáveis `spec.routes[].cookieRewritePolicies[].pathRewrite.value` ou `spec.routes[].services[].cookieRewritePolicies[].pathRewrite.value`, resultando na execução de código arbitrário no proxy Envoy. Isso ocorre porque valores controlados pelo usuário são interpolados no código-fonte Lua usando Go text/template sem a sanitização suficiente. Embora o código injetado seja executado apenas na própria rota do invasor, ele pode ser usado para ler credenciais de cliente xDS do Envoy no sistema de arquivos — expondo potencialmente certificados TLS e chaves privadas de outros locatários — ou causar a negação de serviço para outros locatários que compartilham a instância do Envoy.

Um problema de server-side request forgery (SSRF) existe no recurso APICall. O campo `URL` na configuração ServiceCall de uma Política não é validado, permitindo que um usuário com permissões de criação de Política em nível de namespace direcione o sistema a fazer requisições HTTP para recursos internos arbitrários, como endpoints de metadados de nuvem ou recursos de outros locatários. Trata-se de um problema de Confused Deputy, onde o sistema utiliza sua ServiceAccount de alta permissão em todo o cluster para executar as requisições. Consequentemente, dados sensíveis, incluindo credenciais de IAM de nuvem e segredos de outros locatários, podem ser retornados no PolicyReport e acessados pelo atacante, comprometendo o isolamento multi-tenant.

O endpoint '/registercrd' no componente kubeconfiggenerator está suscetível a injeção de comando. O problema ocorre porque o componente utiliza a função `subprocess.Popen()` com o parâmetro `shell=True` para executar comandos de shell, concatenando diretamente o parâmetro `chartName` fornecido pelo usuário na string de comando sem a devida sanitização ou validação. Isso permite que um invasor execute comandos de shell arbitrários ao fornecer um valor malicioso para a variável `chartName`.

KubePlus versions 4.1.4 contain a Server-Side Request Forgery (SSRF) issue within the mutating webhook and kubeconfiggenerator components when handling the `chartURL` field of ResourceComposition resources. The `chartURL` field is URL-encoded without proper validation of the target address. Specifically, when the kubeconfiggenerator component uses `wget` to download charts, the `chartURL` is directly incorporated into the command, enabling attackers to inject `wget`'s `--header` option and achieve arbitrary HTTP header injection. The API endpoint used for chart downloads is not specified. The vulnerable parameter is `chartURL`.

A SQL Injection issue exists in SchemaHero version 0.23.0. The issue is due to a flaw in the `mysqlColumnAsInsert` function within the `plugins/mysql/lib/column.go` file, specifically related to the `column` parameter. This allows for potential manipulation of SQL queries. The `column` parameter is vulnerable.

A SQL Injection issue exists in SchemaHero version 0.23.0. The issue is located in the `columnAsInsert` function within the `plugins/postgres/lib/column.go` file, specifically through the `column` parameter. The vulnerability allows for potential manipulation of SQL queries through the `column` parameter.

Kube-router's proxy module does not validate externalIPs or loadBalancer IPs before programming them into the node's network configuration. This impacts multi-tenant clusters where untrusted users have namespace-scoped permissions to create or modify Services. The `buildServicesInfo()` function copies IPs from `Service.spec.externalIPs` and `status.loadBalancer.ingress` without validating them against the `--service-external-ip-range` parameter. An attacker can bind arbitrary VIPs on all cluster nodes or cause denial of service to critical cluster services such as kube-dns. The `--service-external-ip-range` parameter is only used by the netpol module and is not checked by the proxy module. This allows attackers to potentially hijack traffic or disrupt DNS services. The vulnerability can be exploited by creating a Service with an externalIP matching the kube-dns ClusterIP, redirecting all DNS queries to attacker-controlled pods. The issue is not unique to kube-router, as the upstream Kubernetes project identified a similar issue as CVE-2020-8554.

O componente Shell Runtime do Nuclio contém um problema de injeção de comando. Quando uma função é invocada via HTTP, o runtime lê o cabeçalho `X-Nuclio-Arguments` e incorpora diretamente seu valor em comandos de shell sem validação ou sanitização. Isso permite que invasores com permissões de invocação de função injetem comandos maliciosos, potencialmente executando código arbitrário com privilégios de root em contêineres de função, roubando Tokens de ServiceAccount com permissões de nível cluster-admin e, finalmente, obtendo controle completo sobre o cluster Kubernetes. A vulnerabilidade decorre da falta de validação ao processar argumentos fornecidos pelo usuário na função `getCommandArguments` e da subsequente execução desses argumentos usando `sh -c`. Os invasores podem explorar isso criando payloads maliciosos no cabeçalho `X-Nuclio-Arguments`, aproveitando metacaracteres de shell como ponto e vírgula, pipes e crases para injetar comandos arbitrários. A vulnerabilidade afeta todas as versões que incluem o componente Shell Runtime. Uma exploração bem-sucedida pode levar ao comprometimento completo do cluster, incluindo violações de dados, ataques à cadeia de suprimentos e implantação de ransomware.

O Kruise permite o gerenciamento automatizado de aplicativos no Kubernetes. Existe uma falha na funcionalidade PodProbeMarker onde a validação do webhook não restringe o campo 'Host' em configurações de sondagem personalizadas utilizando manipuladores TCPSocket ou HTTPGet. Como o kruise-daemon é executado com hostNetwork habilitado, ele executa sondagens a partir do namespace de rede do nó. Um invasor com permissão para criar PodProbeMarkers pode especificar valores arbitrários para 'Host' para acionar Falsificação de Solicitação do Lado do Servidor (SSRF) a partir do nó, realizar varredura de portas e receber feedback de resposta através das mensagens de status do NodePodProbe. A vulnerabilidade permite o acesso a serviços locais do nó, metadados da nuvem e recursos de rede internos. A sondagem `tcpSocket` permanece vulnerável, enquanto as sondagens `httpGet` são rejeitadas pelo webhook no OpenKruise v1.8.0. O componente vulnerável é o `PodProbeMarker` e a função afetada é `newTCPSocketProber`.

O Kargo gerencia e automatiza a promoção de artefatos de software. Os endpoints de criação em lote de recursos tanto da API gRPC legada do Kargo quanto da mais recente API REST aceitam cargas úteis YAML com múltiplos documentos. Cargas úteis especialmente elaboradas podem permitir que um atacante injete recursos arbitrários no namespace subjacente de um Project existente, utilizando as próprias permissões do servidor da API, quando esse comportamento não é intencional. Isso pode ser explorado para elevar permissões, potencialmente levando à execução remota de código ou exfiltração de segredos. Credenciais exfiltradas de repositórios de artefatos podem ser usadas para ataques adicionais. Em algumas configurações de cluster Kubernetes, permissões elevadas podem permitir a execução remota de código ou exfiltração de segredos usando o `kubectl`. Os **Endpoints de API** afetados são os endpoints de criação em lote de recursos tanto da API gRPC legada quanto da mais recente API REST. O problema decorre da lógica desses endpoints ao processar cargas úteis YAML com múltiplos documentos. Um atacante pode explorar isso para injetar recursos em Projects existentes.

O Kargo gerencia e automatiza a promoção de artefatos de software. O modelo de autorização inclui um verbo "promote" destinado a controlar o acesso a pipelines de promoção. Embora corretamente aplicado na API gRPC, três endpoints da API REST omitem essa verificação, confiando apenas no RBAC padrão do Kubernetes. Isso permite que usuários com permissões padrão, mas sem acesso explícito ao "promote", contornem os limites de autorização pretendidos. Os **Endpoints de API** afetados são /v1beta1/projects/{project}/freight/{freight}/approve, /v1beta1/projects/{project}/stages/{stage}/promotions e /v1beta1/projects/{project}/stages/{stage}/promotions/downstream. O problema decorre da ausência de uma verificação de autorização para o verbo "promote" nesses endpoints.

O componente Air Traffic Controller (ATC) do Yoke não possui mecanismos adequados de autenticação para seus endpoints de webhook. Isso permite que qualquer pod dentro da rede do cluster envie solicitações AdmissionReview diretamente para o webhook, contornando a autenticação do Servidor de API do Kubernetes. Atacantes podem explorar isso para acionar a execução de módulos WASM no contexto do controlador ATC sem autorização. Os endpoints vulneráveis incluem '/validations/{airway}', '/validations/resources', '/validations/flights.yoke.cd', '/validations/airways.yoke.cd' e '/crdconvert/{airway}'. O problema decorre da ausência de verificação de certificado cliente TLS, validação da origem da solicitação ou qualquer forma de middleware de autenticação na implementação do manipulador HTTP. Um atacante pode enviar solicitações AdmissionReview elaboradas para esses endpoints, potencialmente levando à execução não autorizada de WASM e, combinado com outras falhas, à criação de recursos Kubernetes arbitrários. O impacto inclui riscos potenciais à confidencialidade, integridade e disponibilidade.

O componente Air Traffic Controller (ATC) do Yoke contém uma falha que permite que usuários com permissões de criação/atualização de Recursos Personalizados (CR) executem código WASM arbitrário. Isso é feito injetando uma URL maliciosa por meio da anotação `overrides.yoke.cd/flight`. O controlador ATC faz o download e executa o módulo WASM sem validar a URL, possibilitando que atacantes criem recursos arbitrários do Kubernetes ou eleve privilégios. A vulnerabilidade está no processamento da anotação `overrides.yoke.cd/flight`, onde o controlador usa diretamente a URL fornecida pelo usuário sem validação adequada. A verificação de permissão apenas confirma a permissão `update` em recursos `airways`, falhando em impedir a execução de código WASM arbitrário. Um Proof of Concept (PoC) demonstra a criação de um módulo WASM malicioso que gera um ConfigMap chamado `stolen-credentials` no cluster, comprovando a execução de código arbitrário. A vulnerabilidade é categorizada como Remote Code Execution (RCE) / Injeção de Código. Atacantes com permissões de criação/atualização de CR e acesso à rede para hospedar WASM malicioso podem explorar essa falha. O impacto inclui o comprometimento potencial da confidencialidade, integridade e disponibilidade.