Dans le projet en développement du contrôleur d'ingress Kubernetes ingress-nginx, quatre vulnérabilités ont été identifiées, permettant l'exécution de code arbitraire sur les serveurs des systèmes cloud utilisant la plateforme Kubernetes, ainsi qu'un accès privilégié complet au cluster Kubernetes. Ces problèmes ont été classés avec un niveau de gravité critique (9.8 sur 10). Les chercheurs ayant découvert les problèmes ont attribué aux vulnérabilités le nom de code IngressNightmare et ont noté qu'elles touchent environ 43 % des environnements cloud. Les vulnérabilités ont été corrigées dans les versions ingress-nginx 1.11.5 et 1.12.1.
Le contrôleur d'ingress agit comme une passerelle et est utilisé dans Kubernetes pour organiser l'accès des réseaux externes aux services à l'intérieur du cluster. Le contrôleur ingress-nginx est le plus populaire et utilise serveur NGINX pour le routage des requêtes vers le cluster, la gestion des demandes externes et l'équilibrage de charge. Le projet Kubernetes fournit des contrôleurs d'ingress de base pour AWS, GCE et nginx, ce dernier n'étant pas lié au contrôleur kubernetes-ingress, qui est entretenu par la société F5/NGINX (les vulnérabilités en question n'affectent pas les projets développés par les développeurs de NGINX, la mention de nginx dans le nom ingress-nginx étant uniquement liée à l'utilisation de nginx comme proxy).
Les vulnérabilités permettent à un attaquant non authentifié d'exécuter son code dans le contexte du contrôleur ingress-nginx, avec la capacité d'envoyer une requête au gestionnaire web Admission. Lors du scan du réseau, plus de 6500 clusters Kubernetes vulnérables utilisant des contrôleurs publics exposés avec un gestionnaire Admission accessible aux requêtes externes ont été identifiés.
Dans la configuration par défaut, le code exécuté par l'attaquant peut accéder aux paramètres de l'objet Ingress, où, entre autres, sont stockées les informations d'identification pour accéder aux serveurs Kubernetes, ce qui permet d'obtenir un accès privilégié à l'ensemble du cluster. En guise de contournement de protection, il est recommandé de désactiver dans ingress-nginx la fonctionnalité « Validating Admission Controller ».
Le contrôleur Admission s'exécute dans un environnement de pod séparé et effectue une opération de vérification des objets ingress entrants avant leur déploiement. Par défaut, le gestionnaire web Admission accepte des requêtes non authentifiées provenant du réseau public. Lors de la vérification, le contrôleur Admission crée une configuration pour le serveur http nginx en fonction du contenu de l'objet ingress reçu et vérifie sa validité.
Les vulnérabilités identifiées permettent d'injecter des configurations personnalisées dans nginx en envoyant un objet ingress spécialement formaté directement au contrôleur Admission. Les chercheurs ont découvert que certaines propriétés des requêtes de vérification, définies dans le champ « .request.object.annotations », sont directement insérées dans la configuration de nginx. Cependant, la configuration générée n'est pas appliquée, elle est seulement testée en exécutant le fichier exécutable « nginx » avec l'option « -t ».
En particulier, l'injection de données externes dans la configuration se produit pour les paramètres « mirror-target », « mirror-host » (CVE-2025-1098), « auth-tls-match-cn » (CVE-2025-1097) et « auth-url » (CVE-2025-24514). Par exemple, dans la ligne de configuration « set $target {{ $externalAuth.URL }}; », au lieu de « {{ $externalAuth.URL }} », l'URL spécifiée dans le paramètre « auth-url » est insérée. La validité de l'URL n'est pas vérifiée. Par conséquent, un attaquant peut transmettre une valeur d'URL telle que « http://example.com/#; configurations » et injecter ses propres paramètres dans le fichier de configuration.
Pour exécuter du code arbitraire lors de la vérification de la configuration avec la commande « nginx -t », les chercheurs ont exploité le fait qu'en plus de vérifier la syntaxe, nginx charge des bibliothèques avec des modules et ouvre des fichiers mentionnés dans la configuration pour évaluer leur disponibilité. Parmi autres, lors du traitement de la directive ssl_engine, la bibliothèque partagée spécifiée dans la directive est chargée pour SSL-le moteur.
Pour charger leur bibliothèque sur le serveur Kubernetes, les chercheurs ont exploité (CVE-2025-1974) le fait que lors du traitement de grandes requêtes, nginx conserve le corps de la requête dans un fichier temporaire, qui est immédiatement supprimé, mais un descripteur de fichier ouvert reste dans le système de fichiers « /proc » pour ce fichier. Ainsi, il est possible d'envoyer simultanément des requêtes pour sauvegarder le fichier temporaire et initier la vérification de la configuration, dans laquelle le chemin du descripteur dans le système de fichiers « /proc » est spécifié dans la directive « ssl_engine ».
Pour qu'un descripteur de fichier reste accessible pendant longtemps, la valeur « Content-Length » dans la requête peut être spécifiée comme étant délibérément plus grande que les données réellement transmises (le serveur attendra la réception des données restantes). Une complexité supplémentaire réside dans la nécessité de deviner le PID du processus et le numéro du descripteur de fichier associé à la bibliothèque partagée chargée, mais comme un nombre minimal de processus est généralement exécuté dans le conteneur, les valeurs nécessaires peuvent être devinées par essais et erreurs. En cas de succès et de chargement de la bibliothèque partagée substituée, l'attaquant peut accéder aux paramètres stockés à l'intérieur de l'environnement pod, suffisants pour contrôler l'ensemble du cluster.
Pour vérifier l'utilisation de l'ingress-nginx vulnérable, vous pouvez exécuter la commande : kubectl get pods —all-namespaces —selector app.kubernetes.io/name=ingress-nginx
Source : opennet.ru
