Une vulnérabilité non corrigée d’Argo CD pourrait exposer des clusters Kubernetes à une prise de contrôle

Des chercheurs en sécurité affirment qu’une faille non corrigée du composant repo-server d’Argo CD pourrait permettre à un attaquant d’exécuter du code et de prendre potentiellement le contrôle d’un cluster Kubernetes, à condition de pouvoir atteindre le service sur le réseau interne.

Le problème a été identifié par Synacktiv, qui indique l’avoir signalé aux responsables de la maintenance d’Argo CD en janvier 2025. Après avoir attendu environ 18 mois sans correctif ni attribution de CVE, l’entreprise a rendu ses conclusions publiques afin d’alerter les utilisateurs. Selon son analyse, la faiblesse concerne l’interface gRPC de repo-server, qui n’exige pas d’authentification.

Fonctionnement de l’attaque

Argo CD utilise repo-server pour récupérer des dépôts Git et générer des manifestes Kubernetes. Synacktiv a découvert qu’une requête non authentifiée adressée au service GenerateManifest pouvait être spécialement conçue pour que kustomize reçoive l’instruction d’exécuter un script provenant d’un dépôt contrôlé par l’attaquant, à la place du binaire Helm attendu. Lorsque le service traite la requête, le script est exécuté.

L’exposition dépend fortement de l’accessibilité réseau. Argo CD propose des politiques réseau Kubernetes destinées à isoler repo-server et Redis du reste du cluster, mais Synacktiv souligne que l’installation courante basée sur Helm laisse ces protections désactivées par défaut. Dans cette configuration, un pod compromis ailleurs dans le cluster peut être en mesure de contacter repo-server et de déclencher la faille.

Pourquoi l’impact est grave

Obtenir la capacité d’exécuter du code sur repo-server peut suffire à progresser davantage dans l’environnement. Synacktiv a montré qu’un attaquant pouvait lire le mot de passe Redis dans l’environnement du composant, se connecter au cache Redis d’Argo CD et modifier les données de déploiement qui y sont stockées. Lors du cycle de synchronisation suivant, Argo CD déploierait le contenu fourni par l’attaquant.

Les chercheurs ont indiqué que cela ravivait également le risque associé à la CVE-2024-31989, une vulnérabilité précédente dans laquelle de faibles protections de Redis permettaient à un pod d’empoisonner l’état du déploiement. Bien qu’Argo CD ait ensuite ajouté un mot de passe Redis, les données du cache ne sont pas signées cryptographiquement ; les secrets récupérés depuis le service en fonctionnement peuvent donc toujours être exploités.

Mesures recommandées aux administrateurs

• Activez les politiques réseau Kubernetes pour les composants d’Argo CD, en particulier repo-server et Redis.
• Vérifiez les protections avec kubectl get networkpolicy -A.
• Confirmez que les politiques attendues sont présentes dans chaque espace de noms utilisé par Argo CD.

Synacktiv indique avoir créé un outil d’attaque appelé argo-cdown, mais retarde sa publication afin de laisser aux défenseurs le temps de sécuriser leurs déploiements. Tant qu’un correctif n’est pas disponible, l’entreprise recommande de considérer le réseau du cluster comme non fiable et de restreindre les accès autant que possible.