Leçons tirées de la vulnérabilité zero-day d’Argo CD (CVE-2022-24348)

Le 30 janvier 2022, l’équipe Argo CD a été contactée par des chercheurs d’Apiiro au sujet d’une vulnérabilité qu’ils avaient découverte dans la plateforme de livraison continue très utilisée. Celle-ci pouvait permettre à des acteurs malveillants de dérober des informations sensibles issues de déploiements. L’équipe Argo CD a rapidement développé des correctifs pour ses trois versions actuellement prises en charge et les a publiés à l’intention de ses utilisateurs dans les 48 heures. Dans son article de blog consacré à la CVE, Dan Garfield, cofondateur de CodeFresh et responsable de la maintenance du projet Argo, attribue cette réaction rapide à l’importance accordée à la sécurité à l’échelle de la plateforme au cours des 18 derniers mois.

Dans cet article, nous aborderons cette vulnérabilité ainsi que ses implications plus larges pour vous protéger contre le type d’attaque de la chaîne d’approvisionnement qu’elle aurait pu entraîner.

Qu’est-ce que la vulnérabilité d’Argo CD ?

À la base, CVE-2022-24348 est une vulnérabilité de traversée de répertoires/chemins qui permet à un attaquant d’utiliser un graphique Helm conçu à des fins malveillantes pour accéder aux données d’autres applications. Cela peut entraîner une élévation des privilèges et une exploitation plus étendue du cluster Kubernetes sur lequel Argo CD s’exécute.

Comment savoir si nous sommes vulnérables ?

Si vous utilisez Argo CD 0.5.0 à 2.1.12, 2.2.7 ou 2.3.1, vous êtes vulnérable et devez immédiatement passer aux dernières versions. Au 24 mars 2022, il s’agit des versions suivantes :

• 2.3.2

• 2.2.8

• 2.1.14

Quel est le risque ?

Voici un nouvel exemple parmi la liste grandissante des attaques de la chaîne d’approvisionnement, où les acteurs malveillants cherchent à infiltrer les logiciels pendant leur développement, plutôt que de prendre d’assaut les portes d’entrée après leur publication. Parmi les exemples récents figurent les attaques visant CodeCov, l’App Store iOS et, plus célèbre encore, SolarWinds. Dans ce dernier incident, un attaquant pouvait créer un graphique Helm malveillant exploitant la vulnérabilité afin d’accéder aux données sensibles d’autres applications stockées dans le reposerver d’Argo CD.

Les détails du fonctionnement de cette vulnérabilité figurent dans la divulgation originale de la CVE ; nous ne les répéterons donc pas ici. En bref, en créant un graphique Helm contenant un URI avec un chemin de fichier absolu, précis et prévisible, un attaquant pouvait exfiltrer les données sensibles du système de fichiers à cet emplacement dans le reposerver d’Argo, y compris les données relevant du périmètre d’autres applications ou utilisateurs.

Quelle est la solution ?

Si vous cherchez comment corriger CVE-2022-24348 dans vos clusters, c’est simple : arrêtez votre lecture et mettez immédiatement à niveau vos déploiements Argo CD ! Ensuite, revenez poursuivre votre lecture pour découvrir les enjeux plus larges.

C’est fait ? Parfait ! Parlons maintenant des enjeux plus vastes de la sécurité de la chaîne d’approvisionnement logicielle.

Comment atténuer les attaques de la chaîne d’approvisionnement

Comment nous protéger contre la prochaine vulnérabilité zero-day de ce type ? Puisque cette vulnérabilité est spécifique à l’application Argo CD, il n’existe pas de réponse simple ou universelle. Toutefois, vous pouvez mettre en place quelques pratiques à un niveau plus général pour empêcher dès le départ que des fichiers conçus à des fins malveillantes (comme le graphique Helm de cet incident) pénètrent dans vos systèmes :

1. Privilégiez des commits petits et faciles à examiner

La pratique agile qui consiste à apporter de petits changements itératifs n’est pas seulement une bonne méthode pour produire du code propre : elle permet aussi de repérer plus facilement les modifications non sécurisées ou douteuses lors de leur soumission. Nous ne prétendons pas que quelqu’un dans votre organisation copierait du code douteux depuis StackOverflow, mais il serait bien plus facile de le repérer lors d’une revue de code s’il n’était pas enfoui dans un commit de mille lignes.

2. Traitez tous vos systèmes SDLC comme des environnements de production

Nous sommes trop nombreux à traiter nos serveurs de build — surtout ceux que nous assemblons nous-mêmes — comme des jouets. Vous voyez le genre : ce serveur Jenkins, GitLab ou RunDeck installé sur un vieil ordinateur dans le local réseau, avec un mot de passe administrateur connu, quelques centaines de plug-ins et les identifiants d’un développeur quelconque pour se connecter à des services externes ? Oui… celui-là ! (Nous ne ciblons pas spécifiquement ces projets : tout outil mal géré est une cible facile pour un attaquant.)

Historiquement, les serveurs de build et de déploiement ont été considérés comme peu prioritaires et insuffisamment protégés contre les attaques. Les attaques SolarWinds et CodeCov, par exemple, prouvent que ces systèmes doivent être traités avec autant de sérieux que les serveurs de production qui hébergent les données de vos utilisateurs.

• N’utilisez pas d’identifiants partagés.

• N’utilisez pas de plug-ins, d’actions ou de modules personnalisés qui n’ont pas été vérifiés.

• Veillez toujours à utiliser un contrôle d’accès RBAC centralisé et correctement configuré pour limiter les accès de façon appropriée.

3. Connaissez votre chaîne d’approvisionnement

Il est essentiel de connaître l’origine des artefacts générés par vos systèmes et leur contenu. La mise en place d’une chaîne d’approvisionnement sécurisée est un sujet qui pourrait remplir des volumes entiers. Des conférences entières lui sont même consacrées ! Voici quelques aspects clés auxquels vous devez prêter attention :

• Ne faites pas aveuglément confiance aux images de conteneurs, aux paquets de système d’exploitation, aux bibliothèques de code — ni aux graphiques Helm — provenant de sources que vous ne contrôlez pas. Des dépôts privés et gérés, contenant des artefacts vérifiés et signés, sont essentiels pour garantir la fiabilité des dépendances de vos applications. Pour ce scénario, une approche couramment mise en œuvre avec succès consiste à utiliser un dépôt de « quarantaine » dans lequel les équipes peuvent importer les artefacts nouvellement acquis afin que les équipes de sécurité les vérifient et effectuent des tests fonctionnels. Les artefacts peuvent ensuite être transférés vers un dépôt auquel les développeurs et les systèmes de build ont un accès général. Bien entendu, ces vérifications doivent tenir compte de la nécessité pour les équipes d’avancer rapidement : le processus doit donc être adapté au contexte de l’entreprise et prendre la forme de garde-fous. Les équipes doivent également analyser ces artefacts pour détecter les vulnérabilités, y compris, dans la mesure du possible, dans les fichiers de configuration IaC. Il est également important de procéder à des analyses régulières, au cas où de nouvelles vulnérabilités seraient découvertes. Snyk peut vous aider à détecter et à corriger les vulnérabilités et les erreurs de configuration.

• Mettez en place une nomenclature logicielle (SBoM) pour vos applications. Ce domaine évolue rapidement et bénéficie, heureusement, d’une grande attention grâce aux exigences définies dans un décret présidentiel américain de 2021.

• Autre sujet intéressant : les commits Git signés, qui €Œ vous permettraient de détecter toute modification de code provenant de parties externes non vérifiées. Pour être honnête, je n’ai pas vu cette pratique largement adoptée et elle n’est pas la solution miracle qu’elle peut sembler être. Dan Lorenc, expert dans ce domaine, présente très bien leurs avantages et leurs inconvénients dans son article de blog de juillet 2021 : Faut-il signer les commits Git ?

Tout repose sur DevSecOps

Les outils et pratiques présentés ici mettent tous en évidence un fait essentiel : pour sécuriser nos chaînes d’approvisionnement, toute l’équipe doit s’impliquer, des développeurs aux SRE, en passant par tous les autres. Plus nous donnons aux développeurs les moyens d’agir et leur fournissons des outils et des processus qui les incluent au lieu de simplement les restreindre ou de les encadrer, mieux nous réussirons à protéger nos applications. En intégrant des outils comme Snyk au SDLC, nous permettons aux développeurs de détecter facilement les vulnérabilités dans leur travail, avant même la publication d’une version ! C’est tout l’objectif du shift left et de DevSecOps ; cela me ramène aux propos de Dan sur l’importance accordée à la sécurité par l’équipe Argo CD. Même si je ne connais pas de l’intérieur le fonctionnement de leur équipe, il est évident que leur réactivité et leur transparence dans les échanges au sujet de cette vulnérabilité ont directement contribué à la rapidité de sa résolution.

Dans notre rapport 2021 sur l’état de la sécurité des applications cloud-native, nous avons constaté que les entreprises qui automatisent largement les tests dans leur SDLC sont deux fois plus susceptibles de mettre en œuvre des tests de sécurité. Plus de 72 % d’entre elles indiquent un délai moyen de correction des vulnérabilités inférieur à une semaine, et pour 36 % d’entre elles, il est d’un jour ou moins ! D’après la documentation du projet Argo, l’équipe applique clairement ces pratiques. Sa réactivité face à ce problème en témoigne.

Pour aller plus loin

Voici quelques ressources supplémentaires sur les sujets abordés :

• En savoir plus sur les vulnérabilités de traversée de répertoires

• Sécuriser votre chaîne d’approvisionnement logicielle moderne

• Prévenir les paquets malveillants et les attaques de la chaîne d’approvisionnement avec Snyk

• SnykCon 2021 : sécurité de la chaîne d’approvisionnement, avenir de la cybersécurité, automatisation comme levier, et bien plus