Quatro vulnerabilidades foram identificadas no controlador de ingress do Kubernetes, ingress-nginx, permitindo a execução de código em servidores de sistemas em nuvem que utilizam a plataforma Kubernetes, resultando em acesso total privilegiado ao cluster Kubernetes. As questões foram classificadas com um nível crítico de severidade (9.8 em 10). Os pesquisadores que identificaram os problemas deram às vulnerabilidades o codinome IngressNightmare e observaram que as falhas afetam cerca de 43% dos ambientes em nuvem. As vulnerabilidades foram corrigidas nas versões ingress-nginx 1.11.5 e 1.12.1.
O controlador de ingress atua como um gateway e é utilizado no Kubernetes para gerenciar o acesso da rede externa aos serviços dentro do cluster. O controlador ingress-nginx é o mais popular e aplica servidor NGINX para encaminhar solicitações ao cluster, roteando solicitações externas e balanceando carga. O projeto Kubernetes oferece controladores de ingress básicos para AWS, GCE e nginx, sendo que este último não está relacionado ao controlador kubernetes-ingress, que é mantido pela empresa F5/NGINX (as vulnerabilidades discutidas não afetam projetos desenvolvidos pelos desenvolvedores do NGINX, e a menção ao nginx no nome ingress-nginx está apenas relacionada ao uso do nginx como proxy).
As vulnerabilidades permitem que um atacante não autenticado consiga executar seu código no contexto do controlador ingress-nginx, ao ter a capacidade de enviar uma solicitação ao manipulador web Admission. Durante a varredura de rede, mais de 6500 clusters Kubernetes vulneráveis foram detectados, utilizando controladores vulneráveis públicos com o manipulador Admission acessível a solicitações externas.
Na configuração padrão, o código executado pelo atacante pode acessar as configurações do objeto Ingress, nas quais, entre outras coisas, estão armazenadas as credenciais para acessar os servidores Kubernetes, permitindo assim o acesso privilegiado a todo o cluster. Como uma medida de proteção alternativa, é recomendável desativar no ingress-nginx a função 'Validating Admission Controller'.
O controlador Admission é iniciado em um ambiente de pod separado e realiza a verificação de objetos ingress recebidos antes de sua implantação. Por padrão, o manipulador web Admission aceita solicitações sem autenticação da rede pública. Durante a verificação, o controlador Admission cria uma configuração para o servidor http nginx com base no conteúdo do objeto ingress recebido e verifica sua validade.
As vulnerabilidades identificadas permitem a inserção de configurações personalizadas no nginx através do envio de um objeto ingress formatado especificamente diretamente para o controlador Admission. Os pesquisadores descobriram que algumas propriedades das solicitações de verificação, especificadas no campo “.request.object.annotations”, são diretamente inseridas na configuração do nginx. Nesse caso, a configuração gerada não é aplicada, mas somente testada através da execução do arquivo executável “nginx” com a opção “-t”.
Em particular, a inserção de dados externos na configuração ocorre para os parâmetros “mirror-target”, “mirror-host” (CVE-2025-1098), “auth-tls-match-cn” (CVE-2025-1097) e “auth-url” (CVE-2025-24514). Por exemplo, na linha de configuração “set $target {{ $externalAuth.URL }};” em vez de “{{ $externalAuth.URL }}” é inserido o URL especificado no parâmetro “auth-url”. Observa-se que a validade do URL não é verificada. Consequentemente, um atacante pode fornecer um valor de URL como “http://example.com/#; n configurações” e inserir suas próprias configurações no arquivo de configuração.
Para executar código arbitrário durante a verificação da configuração com o comando “nginx -t”, os pesquisadores se aproveitaram do fato de que, além de verificar a sintaxe, o nginx carrega bibliotecas com módulos e abre arquivos mencionados na configuração para avaliar sua disponibilidade. Entre outras coisas, ao processar a diretiva ssl_engine, ocorre o carregamento da biblioteca compartilhada especificada na diretiva para SSL-o mecanismo.
Para carregar sua própria biblioteca no servidor Kubernetes, os pesquisadores utilizaram (CVE-2025-1974) a exploração do fato de que, ao processar grandes solicitações, o nginx salva o corpo da solicitação em um arquivo temporário, que é imediatamente excluído, mas na estrutura de arquivos “/proc”, um descritor de arquivo para esse arquivo permanece aberto. Assim, pode-se simultaneamente enviar solicitações para salvar o arquivo temporário e iniciar a verificação da configuração, na qual a diretiva “ssl_engine” especifica o caminho para o descritor na estrutura de arquivos “/proc”.
Para que o descritor de arquivo permaneça acessível por um longo tempo, o valor de "Content-Length" na solicitação pode ser definido deliberadamente maior do que os dados realmente transmitidos (o servidor aguardará a recepção dos dados restantes). Uma complexidade adicional é a necessidade de adivinhar o PID do processo e o número do descritor de arquivo associado à biblioteca compartilhada carregada, mas como geralmente um número mínimo de processos é executado no contêiner, os valores necessários são adivinhados por tentativas. Se for bem-sucedido e a biblioteca compartilhada for carregada, o atacante pode obter acesso aos parâmetros armazenados dentro do ambiente pod, suficientes para controlar todo o cluster.
Para verificar o uso do ingress-nginx vulnerável, você pode executar o comando: kubectl get pods —all-namespaces —selector app.kubernetes.io/name=ingress-nginx
Fonte: opennet.ru
