Le mois de mai 2025 a marqué la divulgation publique d'une vulnérabilité de sécurité critique, CVE-2025-1974, surnommée IngressNightmare, affectant le contrôleur Kubernetes ingress-nginx largement déployé dans les infrastructures natives du cloud. Cette vulnérabilité permet à des attaquants non authentifiés d'injecter des configurations arbitraires dans NGINX, ce qui peut potentiellement conduire à une exécution de code à distance (RCE) non autorisée et à la compromission complète du cluster.
Dans le cadre du programme de bourses OPSWAT , nos boursiers ont effectué une analyse technique approfondie afin de mieux comprendre la cause première, la voie d'exploitation et les stratégies d'atténuation de ce problème d'une grande gravité.
Vue d'ensemble de CVE-2025-1974
CVE-2025-1974 est une vulnérabilité critique d'injection de modèle identifiée dans les versions d'ingress-nginx jusqu'à 1.11.4 et plus particulièrement 1.12.0. Les attaquants ayant un accès de niveau nœud à un cluster Kubernetes peuvent exploiter cette faille pour exécuter du code arbitraire par RCE via le contrôleur ingress-nginx qui, par défaut, dispose de privilèges étendus, y compris l'accès à des secrets critiques au sein du cluster.
Le Comité de Réponse à la Sécurité de Kubernetes a attribué à cette vulnérabilité un score CVSS v3.1 de 9.8 (gravité critique) :
Principaux éléments de cette analyse
Aperçu de Kubernetes
Kubernetes (K8s) est une plateforme open-source permettant d'automatiser le déploiement, la mise à l'échelle et la gestion opérationnelle des applications conteneurisées. Les clusters Kubernetes se composent généralement de plusieurs machines, qui peuvent inclure à la fois du matériel physique et des machines virtuelles, travaillant collectivement pour fournir des environnements d'application hautement disponibles, évolutifs et gérables.
Contrôleur d'entrée NGINX
Le contrôleur d'entrée NGINX (ingress-nginx) est un contrôleur d'entrée open-source construit au-dessus du serveur web NGINX. Il fonctionne au sein d'un cluster Kubernetes, fonctionnant principalement comme un proxy inverse et un équilibreur de charge. Ce contrôleur interprète les ressources Ingress définies par les utilisateurs et les traduit en configurations NGINX exploitables pour acheminer le flux de trafic vers et au sein du cluster.
L'examen d'admission et son rôle
Ingress-nginx s'intègre à Kubernetes à l'aide d'un service webhook appelé AdmissionReview. Ce service est essentiel pour traiter les objets Ingress natifs de Kubernetes et les traduire en configurations NGINX validées et syntaxiquement correctes. Bien qu'AdmissionReview garantisse l'exactitude de la configuration, il fonctionne indépendamment du contrôleur ingress-nginx et ne dispose généralement pas de contrôles d'authentification stricts. Ce manque d'authentification stricte est un facteur clé qui a contribué à l'exploitabilité de CVE-2025-1974.
Exploitation des vulnérabilités et analyse technique
Mécanisme d'exploitation
L'exploitation de CVE-2025-1974 commence par une requête malveillante. Les attaquants créent une requête malveillante vers le webhook AdmissionReview, forçant NGINX à charger dynamiquement une bibliothèque partagée au moment de l'exécution. Sur la base de ce mécanisme, nos collègues ont analysé à la fois le webhook AdmissionReview et le flux de travail de NGINX pour comprendre ce chemin d'exploitation.
Vulnérabilité de l'injection de modèles
Dans le webhook AdmissionReview, lors du traitement des requêtes entrantes, la fonction `CheckIngress` transforme les objets Ingress de Kubernetes en fichiers de configuration NGINX valides. Le processus se déroule comme suit :
- Chaque configuration est analysée, puis transmise à la fonction `generateTemplate` afin d'être mise en forme selon des modèles NGINX prédéfinis.
- Par la suite, testTemplate vérifie la conformité de la configuration générée avec le binaire NGINX sous-jacent.
Toutes les configurations NGINX sont basées sur des modèles prédéfinis qui se trouvent dans le fichier nginx.tmpl du code source d'ingress-nginx :
Au sein de la fonction `generateTemplate`, la configuration est traitée comme le montre l'extrait de code suivant :
Cependant, la validation et la désinfection des données d'entrée sont insuffisantes. Plus précisément, le champ « uid » d'un objet Ingress est directement inséré dans le modèle de configuration NGINX, ce qui crée un point d'injection. Un attaquant peut exploiter cette faille en fournissant des données d'entrée spécialement conçues, telles que « uid="1234#;\n\n}\n}\n}\n injection_value" ».
Cette entrée malveillante permet l'injection de portée globale dans le modèle NGINX, ce qui permet aux attaquants de déclencher des directives NGINX arbitraires et d'obtenir potentiellement un RCE.
De l'injection de modèle à l'exécution de code à distance
Explication de la fonction testTemplate()
Une fois la configuration NGINX générée par la fonction `generateTemplate`, la fonction `testTemplate` crée un fichier de configuration temporaire et exécute la bibliothèque NGINX à l'aide de la commande `nginx -c {config_file} -t`. Cela oblige le binaire NGINX à analyser et à valider la configuration.
Pour exploiter cette vulnérabilité, un attaquant doit identifier une directive permettant d'exécuter du code malveillant. Dans un premier temps, nos collègues ont identifié la directive `load_module` comme potentiellement utile, car elle permet à NGINX de charger des plugins externes. Cependant, cette directive n'est autorisée que lors de la phase initiale d'analyse de la configuration, ce qui ne correspond pas à notre point d'injection.
Pour relever ce défi, nous avons poursuivi nos recherches, ce qui nous a conduits à la directive `ssl_engine`, décrite comme suit : « Le module peut être chargé dynamiquement par OpenSSL lors des tests de configuration. » Cette capacité à charger dynamiquement des modules a éveillé notre curiosité et a nécessité un examen plus approfondi.
Comprendre la directive ssl_engine
Afin de mieux comprendre comment NGINX gère la directive `ssl_engine`, et de déterminer dans quelles conditions NGINX autorise le chargement dynamique de modules supplémentaires via cette directive, nous avons examiné le code source de NGINX.
Au démarrage, NGINX charge son état initial, puis analyse les fichiers de configuration ligne par ligne. Chaque directive est gérée par la structure `nginx_command_tstructure`, la directive `ssl_engine` appelant directement les commandes `ngx_openssl_commands`.
En analysant la fonction `ngx_openssl_commands`, nos collègues ont découvert qu'elle s'appuie sur le support OpenSSL, et plus précisément sur la fonction `ENGINE_by_id`, qui est utilisée pour les modules SSL bénéficiant d'une accélération matérielle.
En analysant la fonction ENGINE_by_id, nous avons constaté qu'elle permettait le chargement dynamique de bibliothèques partagées. De plus, si la bibliothèque est compilée avec l'extension __attribute__((constructor)), la fonction associée peut être exécutée dès son chargement. Cela signifie qu'en exploitant la directive ssl_engine, un attaquant pourrait charger des bibliothèques partagées arbitraires sur l'hôte, ce qui pourrait conduire à une exécution de code à distance (RCE).
Ciblage des bibliothèques partagées et stratégie d'attaque
Pour faciliter l'exécution du code de manière fiable, l'étape suivante consiste à identifier une bibliothèque partagée. Plutôt que de s'appuyer sur des bibliothèques externes, une approche plus viable et contrôlée émerge du comportement même de NGINX : le mécanisme de tampon du corps du client. Cette fonctionnalité permet à NGINX de décharger les requêtes entrantes volumineuses dans des fichiers temporaires, ce qui ouvre des possibilités d'exploitation basées sur un comportement prévisible en matière de traitement des fichiers.
Par défaut, lorsqu'une requête entrante dépasse 8 Ko, NGINX écrit le corps de la requête dans un fichier temporaire situé dans /tmp/nginx/client-body, en utilisant un nom de fichier au format cfg-{valeur_aléatoire}. Ces fichiers temporaires sont conservés jusqu'à 60 secondes entre les morceaux réussis d'un message reçu.
Après avoir écrit un corps de requête partiel dans un fichier temporaire, NGINX reporte la suppression jusqu'à ce que le corps entier soit reçu. Si la requête reste incomplète et qu'aucune donnée n'est reçue pendant 60 secondes, le fichier est finalement purgé. Cependant, en retenant intentionnellement le dernier morceau de données, un attaquant peut maintenir le fichier temporaire en usage, le rendant ainsi exploitable.
Bien que le contenu du fichier téléchargé puisse être contrôlé, il est difficile de le localiser dans le système de fichiers en raison du nom de fichier aléatoire. Le chemin de stockage peut être configuré à l’aide de `client_body_temp_path`, mais le nom de fichier est généré de manière aléatoire lors de l’exécution, ce qui le rend imprévisible. Ce caractère aléatoire entrave considérablement l’accès ciblé, même par une attaque par force brute. Pour surmonter cette difficulté, l’équipe a tiré parti des comportements inhérents au système d’exploitation Linux. Prenons l’exemple suivant :
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).
Simuler l'exploitation
Sur la base de l'analyse ci-dessus, une approche pratique de l'exploitation du RCE dans le pod Ingress-NGINX est la suivante :
- Télécharger une bibliothèque partagée malveillante en utilisant le mécanisme de tampon du corps du client de NGINX pour la stocker temporairement sur le système de fichiers.
- Utiliser l'injection de modèle pour initier une tentative de force brute qui force NGINX à charger la bibliothèque partagée précédemment téléchargée via des directives vulnérables.
Élaboration de la charge utile contenant la bibliothèque partagée
Pour garantir l'exécution du code lors du chargement, une fonction de point d'entrée avec extension de constructeur est définie dans la bibliothèque partagée malveillante. Cette fonction est exécutée au chargement par NGINX et est conçue pour établir une connexion shell inversée avec un hôte distant.
Après compilation, la taille de la bibliothèque partagée résultante dépassait largement les 8 Ko, ce qui lui permettait d'être mise en mémoire tampon par NGINX sans nécessiter de rembourrage supplémentaire.
Nos collègues ont ensuite élaboré une requête avec une valeur « Content-Length » surévaluée (par exemple, 1 Mo) afin de créer un décalage de taille. Cela a conduit NGINX à mettre en mémoire tampon l'intégralité du corps de la requête plutôt que de le traiter immédiatement, garantissant ainsi que l'objet partagé serait écrit à un emplacement prévisible.
Déclenchement de la bibliothèque partagée par injection
Une fois la bibliothèque partagée mise en place, nous avons ensuite injecté une directive malveillante dans la configuration de NGINX en exploitant le champ « uid » vulnérable. Cette directive comprenait la directive `ssl_engine` pointant vers le chemin d'accès du fichier mis en mémoire tampon :
Pour que l'attaque RCE aboutisse, la directive `ssl_engine` doit faire référence au chemin d'accès correct vers le fichier mis en mémoire tampon. Cela peut être réalisé à l'aide d'un script automatisé de force brute qui passe systématiquement en revue toutes les combinaisons possibles d'identifiants de processus et de descripteurs de fichiers afin d'identifier le lien symbolique valide pointant vers l'objet partagé mis en mémoire tampon.
Vous trouverez ci-dessous un exemple du modèle NGINX généré qui a déclenché l'exploit.
En cas d'exploitation réussie, l'attaquant peut obtenir un accès shell dans le contexte du pod ingress-nginx, qui par défaut a accès aux secrets sensibles du cluster Kubernetes.
Atténuation et remédiation
Pour atténuer efficacement les risques associés à CVE-2025-1974, les entreprises ont besoin d'une solution qui offre une visibilité et un contrôle sur leurs composants open-source.
OPSWAT SBOM, une technologie fondamentale de la plateforme MetaDefender®, répond à ce besoin en fournissant un inventaire de tous les composants logiciels, bibliothèques, conteneurs Docker et dépendances utilisés. Il permet aux organisations de suivre, sécuriser et mettre à jour leurs composants de manière proactive.
Dans l'exemple ci-dessus, la technologie SBOM de MetaDefender Core™ a analysé le paquet nginx-ingress-controller qui contenait la vulnérabilité CVE-2025-1974. Le système a automatiquement signalé le problème comme étant critique et a fourni des indications sur les versions corrigées disponibles, ce qui a permis aux équipes de hiérarchiser et de corriger rapidement la vulnérabilité avant qu'elle ne puisse être exploitée.
OPSWAT SBOM est disponible dans MetaDefender Core et MetaDefender Software Supply Chain™, permettant aux équipes de sécurité d'identifier les vulnérabilités et d'agir plus rapidement. Avec OPSWAT SBOM, les équipes de sécurité peuvent :
- Localiser rapidement les composants vulnérables - Identifier immédiatement les composants open-source affectés par les attaques de désérialisation. Cela permet d'agir rapidement en apportant des correctifs ou en remplaçant les bibliothèques vulnérables.
- Assurer des correctifs et des mises à jour proactifs - Surveiller en permanence les composants open-source grâce à OPSWAT SBOM pour rester à l'affût des vulnérabilités liées à la désérialisation. OPSWAT SBOM peut détecter les composants obsolètes ou non sécurisés, ce qui permet d'effectuer des mises à jour en temps voulu et de réduire l'exposition aux attaques.
- Maintenir la conformité et le reporting - OPSWAT OM aide les organisations à répondre aux exigences de conformité, car les cadres réglementaires imposent de plus en plus de transparence dans les chaînes d'approvisionnement en logiciels.
