Sécuriser votre pipeline CI/CD : explorer les dangers de soi

Accueil » Security Bloggers Network » Sécurisation de votre pipeline CI/CD : Explorer les dangers des agents auto-hébergés

Les pipelines d'intégration continue/déploiement continu (CI/CD) sont devenus cruciaux pour les pratiques modernes de développement de logiciels. Les pipelines CI/CD peuvent améliorer considérablement l'efficacité du développement et la qualité des logiciels en automatisant le processus de création, de test et de déploiement du code. La plupart des plates-formes CI/CD modernes (comme les actions GitHub, Circle CI, etc.) offrent une option pour exécuter le processus de pipeline sur un runner auto-hébergé - un agent hébergé par l'utilisateur au lieu de la plate-forme CI/CD, pour exécuter des travaux sur leurs propres infrastructures.

Avec les runners auto-hébergés, vous pouvez créer des configurations matérielles personnalisées qui répondent à vos besoins en matière de puissance de traitement ou de mémoire pour exécuter des travaux plus volumineux. De plus, vous pouvez installer des logiciels disponibles sur votre réseau local et choisir un système d'exploitation non proposé par la plateforme. Les runners auto-hébergés peuvent être physiques, virtuels, dans un conteneur, sur site ou dans un environnement cloud. L'alternative consiste à utiliser un exécuteur de build-as-a-service proposé par la plate-forme SaaS CI/CD où l'utilisateur n'a aucun contrôle sur l'environnement.

On peut utiliser des runners auto-hébergés pour plusieurs raisons :

Conformité et confidentialité : de nombreuses organisations sont liées par des réglementations strictes qui les empêchent de créer et d'envoyer des données sensibles aux services de création SaaS. Par exemple, les organisations des secteurs financier ou gouvernemental préfèrent souvent exécuter la version sur leurs serveurs internes.

Spécifications spéciales : lors de la création de logiciels pour des systèmes d'exploitation peu courants ou des architectures différentes, le processus de création nécessite une machine dont les spécifications correspondent à leurs besoins. C'est également le cas dans de nombreuses applications embarquées, IoT ou côté client.

Réduction des coûts : les organisations disposant d'une infrastructure cloud / cloud privé existante peuvent réduire leurs coûts si elles choisissent d'utiliser des runners auto-hébergés et de gérer elles-mêmes les pools de ressources.

Compte tenu des raisons ci-dessus, les coureurs auto-hébergés ont gagné en popularité dans de nombreuses organisations. Cependant, les exécuteurs auto-hébergés peuvent poser des risques de sécurité importants, en particulier si des flux de travail non fiables s'y exécutent. Des programmes malveillants peuvent compromettre la machine de construction et s'échapper du bac à sable de l'exécuteur, exposant l'accès au réseau de la machine, ses secrets, etc.

L'utilisation d'un runner auto-hébergé peut offrir des avantages, tels que des performances améliorées et un contrôle environnemental accru. Cependant, il existe également des risques de sécurité qui y sont associés :

Les coureurs auto-hébergés nécessitent des serveurs dédiés ou des machines virtuelles (VM) pour fonctionner. La sécurité de ces serveurs est cruciale. Si le serveur hébergeant le coureur n'est pas correctement sécurisé, il peut devenir un point d'entrée potentiel pour les attaquants.

Les exécuteurs auto-hébergés nécessitent généralement un accès privilégié au référentiel et au système sur lequel ils sont installés. Il est important de gérer soigneusement le contrôle d'accès et de restreindre les autorisations accordées au coureur. Un accès non autorisé à l'exécuteur pourrait entraîner des violations de données potentielles ou l'exécution de code malveillant.

Le fait de ne pas isoler les runners auto-hébergés des systèmes critiques et des données sensibles augmente le risque qu'un runner compromis entraîne un accès non autorisé et des violations de données potentielles. Sans une isolation adéquate, les attaquants qui prennent le contrôle du coureur peuvent être en mesure de se déplacer latéralement au sein du réseau, compromettant potentiellement d'autres systèmes et données.

Négliger de mettre à jour et de surveiller régulièrement le logiciel d'exécution auto-hébergé expose le système à des vulnérabilités connues et le rend vulnérable aux attaques. Sans correctifs et mises à jour de sécurité en temps opportun, les attaquants peuvent exploiter les faiblesses connues du logiciel d'exécution. Une surveillance insuffisante augmente les risques d'activités malveillantes non détectées et de retards dans la réponse aux incidents de sécurité, ce qui peut entraîner des périodes prolongées d'accès non autorisé ou de dommages.

L'utilisation d'un exécuteur auto-hébergé sans restreindre l'accès aux utilisateurs autorisés permet à quiconque d'exploiter des ressources de calcul pour des activités telles que l'extraction de crypto-monnaies et d'autres activités pouvant infliger des dommages financiers.

Les actions GitHub ont été largement adoptées ces dernières années en tant que puissant outil d'automatisation CI/CD pour le développement de logiciels. Avec GitHub Actions, les développeurs peuvent automatiser des tâches telles que la création, le test et le déploiement de logiciels, ce qui leur permet de se concentrer sur des tâches plus importantes. GitHub Actions offre un large éventail d'options de personnalisation, y compris des actions prédéfinies, des actions créées par la communauté et la possibilité de créer vos propres actions. Alors que de plus en plus d'organisations adoptent GitHub Actions, il devient un outil de plus en plus important pour le développement de logiciels modernes.

GitHub offre également la possibilité d'utiliser des runners auto-hébergés. Vous pouvez ajouter des exécuteurs auto-hébergés à différents niveaux de la hiérarchie de gestion, y compris des exécuteurs au niveau du référentiel dédiés à un seul référentiel, des exécuteurs au niveau de l'organisation qui peuvent traiter des travaux pour plusieurs référentiels dans une organisation et des exécuteurs au niveau de l'entreprise qui peuvent être affectés à plusieurs organisations dans un compte d'entreprise.

Au cours de nos recherches, nous avons scanné plus detrois millions de référentiels publics. Pour chaque référentiel, nous avons inspecté les différents fichiers GitHub Actions et extrait le runner utilisé par chaque tâche. Nous avons appris que sur 3 106 445 référentiels publics vérifiés, 43 803 utilisent des runners auto-hébergés. L'utilisation d'un runner auto-hébergé dans un référentiel public augmente considérablement les risques susmentionnés, car n'importe quel utilisateur GitHub dans le monde pourrait lancer une attaque.

GitHub offre aux organisations plusieurs options pour configurer leurs runners auto-hébergés. Les utilisateurs doivent vérifier que leur organisation suit les meilleures pratiques de configuration pour prévenir les risques potentiels.

Groupes d'exécuteurs : lorsqu'un exécuteur auto-hébergé est défini au niveau de l'organisation ou de l'entreprise, GitHub peut planifier des flux de travail à partir de plusieurs référentiels sur le même exécuteur. Par conséquent, un compromis de sécurité dans ces environnements peut avoir un impact important. Pour aider à réduire la portée d'un compromis, vous pouvez créer des limites en organisant vos coureurs auto-hébergés en groupes séparés.

Interdire les référentiels publics : si vous utilisez des exécuteurs auto-hébergés avec des référentiels publics et que vous ne configurez pas correctement les contrôles d'accès, un attaquant peut potentiellement accéder à votre machine d'exécution auto-hébergée en créant une demande d'extraction qui exécute un flux de travail malveillant. Cela peut permettre à l'attaquant d'exécuter du code arbitraire sur votre machine, d'accéder à des données sensibles ou d'effectuer d'autres actions malveillantes, selon le niveau d'accès dont dispose votre machine d'exécution auto-hébergée.

Par exemple, un attaquant pourrait modifier le code dans une demande d'extraction pour exécuter des commandes qui installent des logiciels malveillants sur votre machine d'exécution auto-hébergée ou voler des données sensibles de votre organisation. Cela peut entraîner de graves conséquences, notamment des violations de données, la perte de propriété intellectuelle et des atteintes à la réputation de votre organisation.

Pour éviter ce risque, il est conseillé d'utiliser des runners auto-hébergés uniquement avec des référentiels privés. Vous pouvez limiter la surface d'attaque et réduire le risque d'accès non autorisé à votre machine d'exécution auto-hébergée.

Contrôle d'accès : vous pouvez restreindre les organisations et les référentiels qui peuvent accéder aux groupes de coureurs. De plus, vous pouvez limiter les exécuteurs à des workflows spécifiques. Pour plus d'informations, voir "Gestion de l'accès aux runners auto-hébergés à l'aide de groupes".

Dans un article de blog publié par @ryotkak, nous pouvons voir un exemple de la façon dont les coureurs auto-hébergés imposent des risques et, s'ils sont mal utilisés, peuvent conduire au vol d'informations sensibles. ryotkak montre un exemple de workflow créé par GitHub. Le flux de travail vulnérable fait partie du cadre d'actions lui-même. Dans des conditions spécifiques, le coureur auto-hébergé était accessible à n'importe quel attaquant. Le jeton volé dans cet exemple était un jeton appartenant à un développeur de GitHub lui-même, que les attaquants auraient pu exploiter pour mener une attaque à grande échelle sur la chaîne d'approvisionnement logicielle.

Dans cette démo, nous montrons comment nous avons créé un référentiel GitHub public avec un runner auto-hébergé. Cet exemple montre un collaborateur externe malveillant réalisant plusieurs attaques.

Dans la première image, nous pouvons voir que le coureur pwn_me est ajouté au pool du groupe de coureurs.

Notre prochaine étape consistait à configurer un flux de travail qui s'exécute sur notre runner auto-hébergé et est déclenché par le déclencheur pull_request :

Désormais, tout ce qu'un attaquant doit faire est de créer un fork avec un fichier de flux de travail modifié qui récupère les secrets et les informations sensibles de l'exécuteur. Un exemple de job créé par un contributeur malveillant :

Cette vidéo montre comment nous avons créé une demande d'extraction à partir d'un fork et obtenu l'accès au fichier /etc/passwd à titre d'exemple.

Les bonnes pratiques suivantes s'appliquent à toutes les plates-formes auto-hébergées CI/CD. Que vous utilisiez GitHub Actions Jenkins, GitLab ou toute autre plate-forme, ces directives vous aideront à assurer la sécurité de vos coureurs auto-hébergés et la sécurité de votre chaîne d'approvisionnement en logiciels :

Assurez-vous qu'aucune information sensible n'est stockée sur le coureur. Par exemple, les clés SSH privées et les jetons d'accès à l'API, entre autres.

Assurez-vous que l'exécuteur dispose d'un accès réseau minimal aux autres ressources internes. Par exemple, les consoles de gestion Azure ou AWS ou les services de métadonnées. Les consoles de gestion et les services de métadonnées sont des panneaux que le fournisseur de cloud fournit pour récupérer la gestion de l'environnement cloud ou exécuter des informations. Un attaquant ayant accès à ces ressources peut modifier la configuration cloud de la victime ou étendre sa surface d'attaque. La quantité d'informations sensibles dans cet environnement doit être minimale. Vous devez toujours garder à l'esprit que tout utilisateur capable d'appeler des workflows a accès à cet environnement.

Assurez-vous que tous les services à l'intérieur de l'exécuteur sont à jour et exempts de vulnérabilités connues.

Évitez la persistance - assurez-vous que chaque tâche s'exécute sur un conteneur d'agent/VM propre et frais

Si vous utilisez des conteneurs, exécutez-les avec des autorisations minimales.

Évitez d'exécuter des conteneurs en mode privilégié.

Assurez-vous que le conteneur est monté sur des appareils dédiés et ne partage pas de ressources avec l'hôte.

Exécutez un seul conteneur par hôte.

Utilisez HTTPS pour la communication : utilisez HTTPS pour crypter la communication entre votre runner auto-hébergé et GitHub, et évitez d'utiliser HTTP non crypté.

Dans l'ensemble, les pipelines CI/CD auto-hébergés peuvent être risqués s'ils ne sont pas correctement gérés. Pour minimiser les dangers potentiels, il est essentiel de suivre les meilleures pratiques de sécurité, telles que la mise à jour régulière des agents auto-hébergés, la mise en place de contrôles d'accès et la surveillance des activités suspectes. De plus, les organisations devraient envisager d'utiliser des services CI/CD basés sur le cloud qui peuvent offrir une meilleure sécurité et fiabilité que les solutions auto-hébergées.

La plate-forme Legit Security se connecte à votre environnement de construction pour détecter les tentatives d'attaque dans votre pipeline et bien plus encore. Nous identifions différentes configurations incorrectes, telles qu'un référentiel public qui utilise un exécuteur auto-hébergé. Si vous êtes préoccupé par ces risques de sécurité et d'autres dans votre chaîne d'approvisionnement logicielle, veuillez nous contacter pour demander une démonstration sur notre site Web.

*** Il s'agit d'un blog syndiqué du Security Bloggers Network de Legit Security Blog rédigé par Nadav Noy. Lisez le message original sur : https://www.legitsecurity.com/blog/securing-your-ci/cd-pipeline-exploring-the-dangers-of-self-hosted-agents