IngressNightmare: Vulnerabilidade e correção da execução remota de código CVE-2025-1974

O mês de maio de 2025 marcou a divulgação pública de uma vulnerabilidade de segurança crítica, CVE-2025-1974, apelidada de IngressNightmare, que afecta o controlador Kubernetes ingress-nginx amplamente implementado em infra-estruturas nativas da nuvem. Essa vulnerabilidade permite que invasores não autenticados injetem configurações arbitrárias no NGINX, potencialmente levando a RCE (execução remota de código) não autorizado e comprometimento total do cluster.

Como parte do programa OPSWAT Fellowship, os nossos bolseiros efectuaram uma análise técnica aprofundada para compreender melhor a sua causa principal, o caminho de exploração e as estratégias de mitigação em torno deste problema de elevada gravidade.

1. Cada configuração é analisada e passada para generateTemplate para ser formatada de acordo com modelos NGINX predefinidos.
2. Posteriormente, o testTemplate valida a configuração gerada em relação ao binário NGINX subjacente.

Todas as configurações do NGINX são baseadas em modelos predefinidos encontrados no ficheiro nginx.tmpl no código-fonte do ingress-nginx:

Na função generateTemplate, a configuração é processada como mostra o seguinte trecho de código:

No entanto, a validação e a higienização da entrada são insuficientes. Especificamente, o campo uid de um objeto Ingress é diretamente inserido no modelo de configuração do NGINX, criando um ponto de injeção. Um atacante pode explorar isto fornecendo uma entrada criada como uid="1234#;\n\n}\n}\n}\n injection_value".

Esta entrada maliciosa permite a injeção de âmbito global no modelo NGINX, permitindo aos atacantes desencadear diretivas NGINX arbitrárias e, potencialmente, obter RCE.

Para explorar a vulnerabilidade, um atacante precisa de identificar uma diretiva capaz de executar código malicioso. Inicialmente, os nossos colegas identificaram a diretiva load_module como potencialmente útil, porque esta diretiva permite ao NGINX carregar plugins externos. No entanto, esta diretiva só é permitida na fase inicial da análise da configuração, o que não corresponde ao nosso ponto de injeção.

Para resolver este desafio, continuámos a investigar mais, o que levou à diretiva ssl_engine, descrita como "O módulo pode ser carregado dinamicamente pelo OpenSSL durante o teste de configuração". Isso despertou curiosidade devido à sua capacidade de carregar módulos dinamicamente, exigindo uma análise mais profunda.

Na inicialização, o NGINX carrega seu estado inicial e, em seguida, analisa os arquivos de configuração linha por linha. Cada diretiva é tratada pela estrutura nginx_command_t, com a diretiva ssl_engine invocando diretamente o ngx_openssl_commands.

Ao analisar a função ngx_openssl_commands, nossos colegas descobriram que ela depende do suporte OpenSSL, especificamente a função ENGINE_by_id que é usada para módulos SSL acelerados por hardware.

E ao analisar a função ENGINE_by_id, determinámos que esta permite o carregamento dinâmico de bibliotecas partilhadas. Além disso, se a biblioteca for compilada com a extensão __attribute__ ((constructor)), a função associada pode ser executada imediatamente após o carregamento. Isto indica que, ao explorar a diretiva ssl_engine, um atacante pode carregar bibliotecas partilhadas arbitrárias no anfitrião, conduzindo potencialmente a RCE.

Por predefinição, quando um pedido de entrada excede 8 KB, o NGINX escreve o corpo do pedido num ficheiro temporário localizado em /tmp/nginx/client-body, utilizando um nome de ficheiro no formato cfg-{random_value}. Esses arquivos temporários são mantidos por até 60 segundos entre partes bem-sucedidas de uma mensagem recebida.

Depois de escrever um corpo de pedido parcial num ficheiro temporário, o NGINX adia a eliminação até que o corpo completo seja recebido. Se o pedido permanecer incompleto e não forem recebidos dados durante 60 segundos, o ficheiro é eventualmente eliminado. No entanto, ao reter intencionalmente a parte final dos dados, um atacante pode manter o ficheiro temporário em utilização, tornando-o explorável.

Embora o conteúdo do ficheiro carregado possa ser controlado, a sua localização no sistema de ficheiros é difícil devido ao nome de ficheiro aleatório. O caminho de armazenamento pode ser configurado usando client_body_temp_path, mas o nome do arquivo é gerado aleatoriamente em tempo de execução, tornando-o imprevisível. Essa aleatoriedade dificulta significativamente o acesso direcionado, mesmo por meio de força bruta. Para ultrapassar isto, a equipa aproveitou comportamentos inerentes ao sistema operativo Linux. Considere o seguinte exemplo:

This code opens a file and keeps it in an active state, closely mimicking the behavior of NGINX's client body buffer mechanism. Using /proc/{pid}/fd directory, attackers can find symbolic links created by the Linux kernel that map open file descriptors to their corresponding file paths. This route allows attackers to reduce the brute-force space to only two variables: the process ID (pid) and the file descriptor (fd).

Após a compilação, o tamanho da biblioteca compartilhada resultante excedeu confortavelmente 8 KB, permitindo que ela fosse armazenada em buffer pelo NGINX sem exigir preenchimento adicional.

Os nossos colegas criaram então um pedido com um valor de Content-Length inflacionado (por exemplo, 1MB) para introduzir uma incompatibilidade de tamanho. Isso fez com que o NGINX colocasse o corpo inteiro em buffer em vez de processá-lo imediatamente, garantindo que o objeto compartilhado fosse gravado em um local previsível.

O RCE bem-sucedido requer que a diretiva ssl_engine faça referência ao caminho correto para o arquivo armazenado em buffer. Isto pode ser conseguido através de um script automatizado de força bruta que itera sistematicamente sobre possíveis combinações de IDs de processos e descritores de ficheiros para identificar a ligação simbólica válida que aponta para o objeto partilhado em buffer.

Segue-se uma amostra do modelo NGINX gerado que acionou a exploração.

Após uma exploração bem-sucedida, o atacante poderia obter acesso ao shell sob o contexto do pod ingress-nginx, que por padrão tinha acesso a segredos sensíveis do cluster Kubernetes.