Les chercheurs de Synacktiv ont trouvé une faille dans Argo CD, un outil populaire de développement pour Kubernetes. Elle affecte le composant « repo-server » qui récupère du contenu à partir de dépôts Git et génère les manifestes Kubernetes utilisés pour déployer des ressources dans un cluster. « Argo CD nécessite des privilèges importants au sein du cluster », a déclaré Synacktiv. « De plus, il a accès à des dépôts Git privés, ce qui en fait une cible de choix pour les attaquants », a souligné la société.

Une faille toujours non corrigée

Le problème porte sur le point de terminaison gRPC GenerateManifest du serveur de dépôt, qui ne nécessite aucune authentification. Les experts ont expliqué qu’un attaquant capable d’accéder à ce point de terminaison pourrait fournir des options Kustomize dans une requête de génération de manifeste et exploiter les options de compilation liées à Helm de Kustomize pour exécuter des commandes contrôlées par le pirate. L’exploitation nécessite un accès à la fois au port gRPC du serveur de référentiels et au port de la base de données Redis, qui ne devraient pas être exposés aux utilisateurs. Argo CD fournit des politiques réseau Kubernetes qui empêchent ce scénario, mais ces protections ne sont pas activées par défaut dans les déploiements via Helm Chart, selon Synacktiv. Dans de tels déploiements, la compromission d’un seul pod au sein du cluster pourrait suffire à fournir à un attaquant l’accès interne nécessaire pour exploiter la vulnérabilité.

Les chercheurs disent avoir pu utiliser cette faille pour obtenir le mot de passe Redis de l’environnement du serveur de dépôt et accéder à la base de données Redis d’Argo CD. Ils  ont ensuite manipulé les données de déploiement mises en cache, ce qui a permis le déploiement automatique d’un manifeste malveillant lorsque la fonctionnalité Auto Sync d’Argo CD était activée. Si Auto Sync n’est pas activée, il faudrait, pour exploiter la faille, qu’un utilisateur synchronise manuellement l’application. Synacktiv a rendu publics les détails le 1ᵉʳ juillet après avoir signalé le problème aux responsables d’Argo CD en janvier 2025. La vulnérabilité n’a toujours pas fait l’objet d’un correctif, et la société a recommandé l’application de politiques réseau Kubernetes strictes afin d’empêcher les pods non fiables d’accéder au serveur de dépôt et aux services Redis jusqu’à l’arrivée d’un correctif.

Évaluation de l’exposition du cluster

Pour les RSSI, la question essentielle n’est pas seulement de savoir si Argo CD est exposé à Internet, mais aussi de savoir si d’autres charges de travail au sein du cluster Kubernetes peuvent accéder à ses services internes. « Étant donné que le service gRPC du serveur repo n’impose aucune authentification, tout pod capable d’y accéder équivaut à un attaquant authentifié », a déclaré Devashri Datta, chercheuse en cybersécurité. « Dans un cluster classique, cela signifie que tout pod d’application compromis, tout service mesh mal configuré ou toute charge de travail adjacente autorisant l’exécution de code local peut interroger directement le point de terminaison GenerateManifest ou accéder au cache Redis, sans avoir besoin d’une exposition à Internet. »

Les entreprises ne doivent pas croire qu’un cluster « non exposé à Internet » présenterait « peu de risques », car les attaques modernes commencent souvent par la compromission d’une charge de travail interne, a fait remarquer Sakshi Grover, responsable senior de la recherche sur les services de cybersécurité chez IDC Asie-Pacifique. « Les RSSI doivent donc évaluer quelles charges de travail peuvent communiquer avec le plan de contrôle d’Argo CD, si le trafic est-ouest est correctement segmenté, et s’il existe des relations de confiance inutiles entre les charges de travail applicatives et l’infrastructure GitOps », a expliqué Mme Grover. « L’évaluation doit se concentrer sur les voies d’attaque plutôt que sur l’exposition du périmètre. »

Gouverner l'infrastructure GitOps

Cette faille souligne également le rôle que jouent les plateformes GitOps dans le contrôle du déploiement logiciel au sein de l’infrastructure d’entreprise. « Les moteurs GitOps ne sont pas de simples services utilitaires, ce sont des composants de tier de niveau zéro du plan de contrôle », a rappelé Mme Datta. « Par sa conception, Argo CD dispose d’un accès en lecture aux dépôts privés, d’un accès en synchronisation/écriture aux clusters cibles et de la garde des secrets de déploiement. Il se situe précisément à la croisée du code source, de la gestion de la configuration et de l’infrastructure en production. »  

Ce niveau d’accès signifie qu’une compromission d’Argo CD pourrait avoir des répercussions au-delà d’une seule application. Un attaquant pourrait transformer la plateforme utilisée pour déployer des applications en un canal de diffusion de manifestes malveillants, tout en interférant avec le comportement de synchronisation automatique et en extrayant les identifiants mis en cache dans des systèmes auxiliaires tels que Redis. Une compromission de ces plateformes pourrait influencer la livraison logicielle à grande échelle, ce qui en fait des actifs stratégiques qui doivent être soumis à une gouvernance plus stricte et à des contrôles d’accès privilégiés similaires à ceux appliqués aux plateformes d’identité et autres systèmes de gestion critiques.