Des pipelines automatisés CI/CD (Continuous Integration/Continuous Delivery) sont utilisés pour accélérer le développement. C'est génial d'avoir des déclencheurs ou une planification qui prennent votre code, le fusionnent, le construisent, le testent et l'expédient automatiquement. Cependant, ayant été conçus pour être rapides et faciles à utiliser, la plupart des pipelines ne sont pas intrinsèquement construits dans un souci de sécurité. Étant donné que les pipelines doivent généralement avoir accès à Internet pour télécharger les dépendances et à vos différents secrets pour les télécharger dans votre environnement de production, cela signifie qu'une fois qu'un tel pipeline est compromis, l'attaquant dispose d'un large éventail d'options pour perturber vos opérations ou exfiltrer des informations ou des secrets.
Toutes les histoires présentées dans cet article décrivent des violations dans les principaux outils CI/CD. Le fait que la plupart des entreprises s'appuient sur de tels outils signifie que, comme beaucoup d'autres attaques de la chaîne d'approvisionnement logicielle, tout ce dont les mauvais acteurs ont besoin est de percer une seule cible pour obtenir un vaste rayon d'explosion.
Jetons un coup d'œil à quelques histoires marquantes des dernières années démontrant les vulnérabilités inhérentes à ce vecteur d'attaque. À la fin de l'article, je ne manquerai pas de proposer mes recommandations pour renforcer et protéger vos pipelines, quels que soient les outils que vous utilisez.
La brèche CircleCI
En janvier 2023, CircleCI, une plateforme d'intégration et de livraison continue, a divulgué un atteinte à la sécurité qui a permis à un attaquant d'obtenir un accès non autorisé à l'infrastructure de l'entreprise. L'attaque a été lancée par un e-mail de phishing qui a incité un employé à partager ses informations d'identification, que l'attaquant a ensuite utilisées pour accéder aux systèmes de l'entreprise. L'employé utilisait 2FA, mais l'attaquant a réussi à récupérer un cookie de session une fois que l'employé s'était déjà connecté au système, ce qui lui a permis de se faire passer pour l'employé et éventuellement d'accéder à un sous-ensemble des systèmes de production de CircleCI.
L'attaquant a accédé à certaines données client, notamment les noms, les adresses e-mail et les informations de facturation. La société a signalé qu'aucun code ou propriété intellectuelle n'avait été consulté et qu'aucun client n'avait signalé d'accès non autorisé à ses comptes ou à ses données.
CircleCI a réagi rapidement à la violation, en menant une enquête et en travaillant avec des experts en matière d'application de la loi et de cybersécurité pour identifier l'ampleur de l'attaque et corriger les vulnérabilités qui ont permis qu'elle se produise. L'entreprise a également réinitialisé tous les identifiants de ses employés et clients et mis en œuvre des mesures de sécurité supplémentaires, telles qu'une surveillance accrue de ses systèmes.
DevOps perturbé : la faille de sécurité Argo CD
Argo CD est un outil open source populaire pour le déploiement continu d'applications sur des clusters Kubernetes. En février 2022, un une nouvelle vulnérabilité a été découverte dans Argo CD qui permettait à des utilisateurs non authentifiés d'accéder à des informations sensibles sur les applications Kubernetes gérées par l'outil. La vulnérabilité était due à une mauvaise configuration du serveur API d'Argo CD qui permettait à des utilisateurs non autorisés d'exécuter des requêtes vers l'API et de récupérer des informations telles que des secrets, des configurations et des métadonnées d'application. Tant que l'attaquant avait l'autorisation de créer ou de mettre à jour des applications et connaissait ou pouvait deviner le chemin complet d'un fichier contenant un YAML valide, il pouvait créer un graphique Helm malveillant et continuer à consommer des fichiers YAML en tant que valeurs jusqu'à ce qu'il trouve une donnée juteuse qui serait normalement inaccessible.
La vulnérabilité s'est vu attribuer un score CVSS de 7.5 (gravité élevée) et affectait toutes les versions d'Argo CD jusqu'à la version 2.1.4 incluse. Argo CD a publié un correctif pour la vulnérabilité dans la version 2.1.5, et il a été conseillé aux utilisateurs de mettre à niveau vers cette version dès que possible.
La vulnérabilité a été jugée particulièrement préoccupante car Argo CD est souvent utilisé pour gérer des applications et des infrastructures critiques dans des environnements de production. La fuite d'informations sensibles aurait pu permettre à un attaquant d'accéder à des données sensibles ou de prendre d'autres actions malveillantes susceptibles d'avoir un impact sur la disponibilité ou la sécurité des applications.
Découvrir la violation de Codecove : leçons apprises
Codecov est un outil de suivi et d'analyse de la couverture de code utilisé dans les pipelines CI/CD qui permet aux développeurs de mesurer et d'analyser l'efficacité de leurs tests. Tel que publié dans Codecov mise à jour de sécurité:
« Le jeudi 1er avril 2021, nous avons appris qu'une personne avait obtenu un accès non autorisé à notre Téléchargeur Bash script et l'a modifié sans notre permission. L'acteur a obtenu l'accès en raison d'une erreur dans le processus de création d'image Docker de Codecov qui a permis à l'acteur d'extraire les informations d'identification requises pour modifier notre script Bash Uploader.
Le Bash Uploader est utilisé par les clients pour télécharger leurs rapports de couverture de code sur la plateforme Codecove. Avec cet accès, l'attaquant a modifié le script Bash Uploader en ajoutant du code malveillant qui collectait des variables d'environnement, des jetons d'authentification et d'autres données sensibles du système de l'utilisateur pendant le processus de téléchargement. Ces données ont ensuite été envoyées vers un serveur distant contrôlé par l'attaquant.
Selon Codecove, la violation a touché environ 1 % de sa clientèle, qui comprenait de grandes entreprises des secteurs de la technologie, de la finance et de la santé. La société a confirmé qu'aucun code client ou rapport de couverture de code n'a été modifié lors de la violation, mais que les jetons d'authentification des utilisateurs et d'autres informations sensibles peuvent avoir été compromis.
Codecove a pris des mesures immédiates pour supprimer le code malveillant et alerter les clients concernés afin qu'ils réinitialisent leurs jetons d'authentification et prennent d'autres mesures de sécurité. La société a également lancé une enquête sur l'incident et a collaboré avec des experts en matière d'application de la loi et de cybersécurité pour identifier la source de l'attaque.
Comment défendre votre pipeline ?
Ensembles de tours de refroidissement dans le bâtiment du centre de données.
Comme mentionné ci-dessus, les pipelines CI/CD sont conçus pour la vitesse et l'automatisation, pas nécessairement pour la sécurité. Le fait que trois grandes entreprises respectées aient toutes été victimes d'une sorte d'attaque, exposant potentiellement les informations de leurs clients, démontre la vulnérabilité de votre propre pipeline et de vos données.
Quels que soient les outils ou la plateforme CI/CD que vous utilisez, vous pouvez prendre certaines mesures pour améliorer votre sécurité et réduire les dommages possibles au cas où un acteur malveillant parviendrait à accéder à votre pipeline ou à votre réseau.
- Modélisation des menaces – La modélisation des menaces est une approche structurée permettant d'identifier les menaces de sécurité potentielles pour un système ou une application et de concevoir des contre-mesures appropriées pour atténuer ces menaces. À titre d'exercice, imaginez que quelqu'un ait accès à votre pipeline. À quels environnements peuvent-ils désormais accéder ? Quels secrets et clés peuvent-ils voir et utiliser ? Peuvent-ils modifier votre code ? Des tests d'influence ? Extraire des fichiers du Web ou exécuter un shell inversé ? Même si vous pensez avoir nettoyé votre pipeline et segmenté correctement l'accès au réseau, cela ne fait pas de mal d'imaginer puis de vérifier pour être conscient du pire des cas. Vous pourriez être surpris de voir quels secrets et options d'accès sont cachés à la vue de tous dans votre plate-forme ou vos outils de pipeline.
- Segmentation du réseau – La segmentation du réseau consiste à diviser un réseau plus vaste en sous-réseaux ou segments plus petits et plus sécurisés, chacun avec ses propres contrôles et politiques de sécurité. L'objectif de la segmentation du réseau est d'augmenter la sécurité de l'ensemble du réseau en limitant la portée d'une faille de sécurité potentielle et en minimisant l'impact potentiel d'une attaque. La division d'un réseau en segments plus petits limite les mouvements latéraux des attaquants et réduit le risque d'accès non autorisé ou de fuite de données.
Avec la popularité croissante des attaques de phishing, n’importe lequel de vos développeurs ou autres employés peut être victime d’une telle arnaque – nous sommes tous humains. En supposant que les informations d'identification de vos développeurs puissent être utilisées par des acteurs malveillants, vous devez vous assurer que l'écrasante majorité des développeurs ne devraient pas avoir le type d'accès qui leur permettrait d'exfiltrer à eux seuls des secrets, d'implanter du code malveillant dans une image de production, ou simplement pousser leur propre version d'un code de production sans contestation. S'assurer que chaque individu dispose du minimum d'accès nécessaire à son travail prend du temps, et la tentation de simplement donner à chacun un accès administrateur et d'en finir est forte. Ne vous laissez pas tenter par le côté obscur – suivez les règles du zéro confiance et des privilèges minimum. - Surveillance et alerte – Suite au dernier point, même si vous avez soigneusement incité vos développeurs à se méfier du phishing et autres escroqueries d’ingénierie sociale, une violation peut toujours se produire. Vous ne savez pas quand ni comment, mais vous devez au moins être prêt à le découvrir. Étant donné que la plupart des environnements de pipeline sont éphémères, cela signifie qu'une fois le travail terminé, il n'y a aucune trace de preuve de ce qui s'est passé, à moins que vous ne créiez de telles traces vous-même.
Assurez-vous de consigner tout ce qui se passe dans vos pipelines, à chaque PR, fusion, construction et test effectué. Assurez-vous que les informations des utilisateurs sont également enregistrées, pour être examinées au cas où un problème nécessiterait une telle vérification. Toute modification apportée aux fichiers de configuration ou à l'environnement lui-même doit également être enregistrée. L’objectif ici est de pouvoir faire un post-mortem clair sur une violation afin de pouvoir dire ce qui s’est passé et comment. Déterminez à l’avance quels événements doivent justifier une alerte et assurez-vous que les bonnes personnes reçoivent cette alerte. Veillez à ne pas inonder les gens d’alertes inutiles ou fausses – cela provoquerait une lassitude face aux alertes qui les amènerait simplement à ignorer les alertes ou à réagir beaucoup plus tard que prévu. Évidemment, aucun de ces journaux ne doit contenir de secrets ouverts ou de clés – ce qui nous amène au point suivant :
- Gestion des secrets – Assurez-vous que vous utilisez un outil de gestion des secrets. À tout le moins, cela faciliterait la rotation de vos secrets et mots de passe en cas de violation. Il devrait également effectuer le travail de suppression des secrets ouverts et des clés d'accès trouvés dans le pipeline à partir de toute journalisation effectuée sur le système. À aucun moment, une personne non autorisée ne devrait avoir accès à ces informations et elle ne devrait en aucun cas pouvoir les modifier.
La gestion des secrets devient de plus en plus importante à mesure que les organisations s'appuient de plus en plus sur des services basés sur le cloud, des applications conteneurisées et d'autres environnements distribués qui nécessitent le partage et la gestion sécurisés des secrets entre différents systèmes et applications. - Utiliser le principe RBAC combiné au moindre privilège – Le principe du contrôle d'accès basé sur les rôles (RBAC) est de fournir un accès aux ressources système en fonction du rôle ou de la fonction attribué à un utilisateur au sein d'une organisation. Dans RBAC, les utilisateurs se voient attribuer des rôles qui définissent les autorisations et les droits d'accès dont ils disposent sur diverses ressources système, telles que des fichiers, des dossiers ou des applications. Le principe du moindre privilège, quant à lui, est la pratique consistant à accorder aux utilisateurs le niveau minimum d'accès et de privilèges nécessaires pour exercer leurs fonctions professionnelles. Cela signifie que les utilisateurs n’ont accès qu’aux ressources dont ils ont besoin pour effectuer leurs tâches spécifiques, et pas plus. RBAC et Least Privilege sont souvent utilisés ensemble comme principes de sécurité complémentaires. Dans RBAC, les utilisateurs se voient attribuer des rôles qui disposent du niveau d'accès approprié aux ressources dont ils ont besoin pour exécuter leurs fonctions, et le principe du moindre privilège garantit que les utilisateurs n'ont accès qu'au niveau minimum de ressources nécessaire pour effectuer leurs tâches spécifiques. Ensemble, ces principes contribuent à maintenir un système sécurisé et bien géré avec un risque minimal d'accès non autorisé ou de violations de données. Pour plus de sécurité, vous pouvez le configurer de manière à ce que les actions critiques dans le système nécessitent plusieurs autorisations d'utilisateur. Cette approche doit être prise avec précaution car elle risque de ralentir considérablement les travaux de développement. Cependant, pour les mises à jour critiques, telles que la suppression d'une branche principale ou la modification d'une liste de dépendances, vous devez faire en sorte qu'au moins deux personnes disposant de l'accès approprié doivent l'approuver.
Regarder vers l'avenir
Personne ne cessera d'utiliser le CI/CD et d'autres outils d'automatisation pour accélérer son travail. Nous vivons dans un monde où nous nous efforçons constamment d’obtenir des mises à jour de code de plus en plus rapides. Nous devons simplement nous assurer que nous le faisons dans le respect de la sécurité et que nous ne compromettons pas notre code et notre environnement de production en cours de route.
L’une des choses les plus importantes que vous puissiez faire est simplement de réfléchir à ce qui pourrait arriver si des personnes non autorisées y accèdent. Une fois que vous aurez pris conscience du danger et des différents endroits vulnérables de vos pipelines et de votre réseau, j'espère que vous serez en mesure de prendre les mesures appropriées pour colmater les fuites potentielles.
Scribe est une société de sécurité de la chaîne d'approvisionnement logicielle dont la plateforme est conçue pour vous offrir une transparence sur ce qui se passe dans votre processus et votre pipeline de développement. Pour en savoir plus sur la façon dont Scribe peut vous aider à sécuriser vos pipelines Nous contacter.
Ce contenu vous est proposé par Scribe Security, l'un des principaux fournisseurs de solutions de sécurité de bout en bout pour la chaîne d'approvisionnement logicielle, offrant une sécurité de pointe aux artefacts de code ainsi qu'aux processus de développement et de livraison de code tout au long des chaînes d'approvisionnement logicielles. En savoir plus.
articles similaires
