IngressNightterror (CVE-2025-1974)

Visão Geral

Este repositório contém minha pesquisa sobre a vulnerabilidade IngressNightmare. Inclui arquivos de deploy do Ingress vulnerável, o próprio exploit e um payload de objeto compartilhado.

CVE

A lista de índices CVE:

• CVE-2025-1974 - Vulnerabilidade raiz
• CVE-2025-24514 - Injeção na anotação auth-url
• CVE-2025-1097 - Injeção na anotação auth-tls-match-cn
• CVE-2025-1098 - Abuso de UID de imagem

Referências

Apenas algumas referências:

• Post original da pesquisa WIZ
• Issue do Kubernetes no GitHub
• Post do blog do Kubernetes
• Boletim da Amazon AWS
• Boletim do Google clound

Causa raiz

A raiz desta vulnerabilidade reside na falta de sanitização adequada de entrada. Quando você envia uma requisição AdmissionReview, ela cria uma configuração NGINX temporária que posteriormente é testada quanto à validade usando o comando nginx -t. Veja o código fonte com o bug mitigado.

A capacidade de controlar o conteúdo da configuração sendo testada nos permite utilizar uma ampla gama de campos de configuração para injetar configuração malformada:

• auth-url - não passa por sanitização adequada, permitindo adicionar # e \n. Usaremos este ponto de injeção.
• auth-tls-match-cn - apenas requer que o campo comece com CN= e seja uma regex válida.
• ing.UID - o UID entra na configuração como está.

O fato de a configuração do NGINX ser apenas testada reduz ligeiramente o número de diretivas que podemos usar. Uma das diretivas que resta é ssl_engine, que nos permite carregar bibliotecas compartilhadas. Este é um bom ponto de entrada. Mas como podemos colocar nosso arquivo .so no sistema de arquivos do pod?

Os engenhosos pesquisadores da WIZ tiveram a ideia de enviar uma requisição com nosso objeto .so como corpo, e se ele for grande o suficiente, o NGINX o salva em um arquivo no procfs! Também podemos ajustar o Content-Length, fazendo o NGINX esperar por mais dados, fazendo com que ele mantenha o arquivo no procfs por algum tempo. O PID e o número do FD reais serão adivinhados.

Para mais informações, leia o artigo de análise original pela equipe de pesquisa da WIZ.

Exploração

O código do exploit é bastante autoexplicativo. Então vá ver a fonte.

Configuração do Ambiente

1. Clone o repositório:

   root@kitploit:~

   git clone https://github.com/I3r1h0n/IngressNightterror
   cd IngressNightterror
   

2. Inicie uma imagem docker k3s:

   root@kitploit:~

   cd stand
   docker compose up -d
   

3. Faça o deploy do NGINX Ingress:

   Caso esteja usando Linux/Mac, você pode fazer o deploy usando o script:

   root@kitploit:~

   ./k8s/setup.sh
   

   ---

   Se você estiver no Windows, ou quiser mais controle sobre o processo de deploy, faça estes passos manualmente:

   Faça o deploy do NGINX Ingress:

   root@kitploit:~

   kubectl --kubeconfig=./output/kubeconfig.yaml apply -f ./k8s/ingress.yaml
   

   Agora você pode usar kubectl com o config fornecido em ./output. Não se esqueça de usar o namespace ingress-nginx.

   Nota importante: o ingress.yaml é feito a partir do NGINX Ingress vulnerável

Objeto compartilhado do payload

O payload é um simples proxy reverso. Não se esqueça de editar a porta e o endereço IP antes de compilá-lo com:

make all

Ele irá compilar o objeto compartilhado usando o contêiner docker gcc:latest.

Créditos

Grande respeito à Equipe de Pesquisa da WIZ que originalmente descobriu a vulnerabilidade, e aos mantenedores do NGINX Ingress.

produzido por I3r1h0n.