IngressNightterror (CVE-2025-1974)

Vue d'ensemble

Ce dépôt contient mes recherches sur la vulnérabilité IngressNightmare. Il inclut des fichiers de déploiement Ingress vulnérables, l'exploit lui-même et la charge utile en objet partagé.

CVE

La liste des index CVE :

• CVE-2025-1974 - Vulnérabilité racine
• CVE-2025-24514 - injection d'annotation auth-url
• CVE-2025-1097 - injection d'annotation auth-tls-match-cn
• CVE-2025-1098 - abus de l'UID de l'image

Références

Quelques références :

• Article original de la recherche WIZ
• Issue GitHub de Kubernetes
• Article de blog Kubernetes
• Bulletin Amazon AWS
• Bulletin Google Cloud

Cause racine

La racine de cette vulnérabilité réside dans l'absence d'un assainissement correct des entrées. Lorsque vous envoyez une requête AdmissionReview, elle crée une configuration NGINX temporaire qui est ensuite testée pour sa validité à l'aide de la commande nginx -t. Voir le code source avec le bug atténué.

La possibilité de contrôler le contenu de la configuration testée nous permet d'utiliser un large éventail de champs de configuration pour injecter une configuration malformée :

• auth-url - n'est pas correctement assaini, ce qui nous permet d'ajouter un # et \n. Nous utiliserons ce point d'injection.
• auth-tls-match-cn - exige seulement que le champ commence par CN= et soit une regexp valide.
• ing.UID - l'UID est inséré tel quel dans la configuration.

Le fait que la configuration NGINX ne soit que testée réduit légèrement le nombre de directives que nous pouvons utiliser. L'une des directives restantes est ssl_engine, qui nous permet de charger des bibliothèques partagées. C'est un bon point d'entrée. Mais comment placer notre fichier .so dans le système de fichiers du pod ?

Les personnes ingénieuses de WIZ ont eu l'idée d'envoyer une requête avec notre objet .so comme corps, et s'il est assez volumineux, NGINX l'enregistre dans un fichier de procfs ! Nous pouvons aussi ajuster le Content-Length, ce qui fait attendre NGINX pour plus de données et le pousse à conserver le fichier dans procfs pendant un certain temps. Le PID et le numéro de FD réels devront être devinés.

Pour plus d'informations, lisez l'article d'analyse original de l'équipe de recherche WIZ.

Exploitation

Le code de l'exploit est assez explicite. Allez donc voir la source.

Mise en place du stand

1. Clonez le dépôt :

   root@kitploit:~

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

2. Démarrez une image docker k3s :

   root@kitploit:~

   cd stand
   docker compose up -d
   

3. Déployez l'Ingress NGINX :

   Si vous utilisez Linux/Mac, vous pouvez le déployer à l'aide du script :

   root@kitploit:~

   ./k8s/setup.sh
   

   ---

   Si vous êtes sous Windows, ou si vous voulez plus de contrôle sur le processus de déploiement, faites-le à la main :

   Déployez l'Ingress NGINX :

   root@kitploit:~

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

   Vous pouvez maintenant utiliser kubectl avec la configuration fournie dans ./output. N'oubliez pas d'utiliser le namespace ingress-nginx.

   Note importante : le fichier ingress.yaml est généré à partir de l'Ingress NGINX vulnérable

Charge utile (objet partagé)

La charge utile est un simple proxy inverse. N'oubliez pas de modifier le port et l'adresse IP avant de la construire avec :

make all

Il construira l'objet partagé en utilisant le conteneur docker gcc:latest.

Crédits

Grand respect à l'équipe de recherche WIZ qui a découvert la vulnérabilité à l'origine, ainsi qu'aux mainteneurs de NGINX Ingress.

produit par I3r1h0n.