Les pipelines d’intégration et de développement continus (CI/CD) constituent la surface d’attaque potentielle la plus dangereuse de la chaîne d’approvisionnement logicielle, selon des chercheurs de NCC.
La présentation donnée lors de la conférence de sécurité Black Hat de la semaine dernière par Iain Smart et Viktor Gazdag, de NCC, et intitulée « RCE-as-a-Service: Lessons Learned from 5 Years of Real-World CI/CD Pipeline Compromise », s’appuie sur les travaux précédents menés par les chercheurs de NCC sur les pipelines CI/CD compromis.
Un pipeline CI/CD est fondamentalement une exécution de code à distance (RCE), et il existe de nombreux moyens de le compromettre, quelle que soit la taille de l’entreprise.
Comme les organisations accordent trop de confiance à leurs pipelines, compromettre ces canaux constitue généralement une bonne voie pour les hackers : ils pourraient ainsi obtenir un accès non autorisé à des données critiques, voire élever leurs privilèges pour mener d’autres attaques.
Voir les meilleurs outils de gestion des risques liés aux tiers (TPRM)
Les approches CI/CD créent des risques
CI signifie « intégration continue » et CD « livraison continue ». La combinaison de ces deux pratiques permet d’automatiser et de superviser le développement pendant tout le cycle de vie.
L’intégration continue permet aux développeurs d’automatiser les processus lors des modifications du code. Généralement, des scripts s’exécutent lorsqu’une modification est fusionnée dans certaines branches du projet afin de tester, compiler et déployer le code.
L’objectif est de réduire les efforts nécessaires au déploiement de nouveau code dans tous les environnements, ce qui concerne non seulement les développeurs, mais aussi les équipes métier. Comme l’amélioration du déploiement fait partie de l’application à douze facteurs, un ensemble de principes qui orientent les applications SaaS modernes, des approches comme le CI/CD sont censées rendre le processus moins risqué.
Le serveur d’automatisation open source Jenkins est par exemple l’une des solutions les plus populaires du marché. De nombreuses entreprises, y compris de grandes organisations, l’utilisent pour gérer leurs opérations DevOps. Lors de leurs tests, les chercheurs sont parvenus à compromettre des environnements Jenkins de différentes manières, en tirant parti de mauvaises configurations dans des compartiments S3 ou dans l’environnement lui-même.
En effet, les organisations utilisent des solutions tierces comme Jenkins pour accélérer leurs processus, mais des configurations trop permissives finissent par entraîner une élévation de privilèges.
À lire aussi : Comment les hackers compromettent la chaîne d’approvisionnement logicielle
Les solutions tierces rendent les pipelines CI/CD vulnérables
Les chercheurs ont identifié des voies d’attaque dans des plateformes populaires offrant des fonctionnalités CI/CD avancées, comme GitLab. Ils ont exploité des fonctionnalités sensibles de GitLab Runners pour élever leurs privilèges et récupérer des secrets.
Une fois encore, des configurations trop permissives permettent à tout utilisateur disposant des droits nécessaires pour valider du code d’accéder à des mots de passe et à des secrets, par exemple lorsque les données sont stockées en clair dans des variables d’environnement.
Les chercheurs ont également exploité des processus et des conteneurs privilégiés (par exemple dans Docker et Kubernetes) qui s’exécutent notamment avec les droits root, alors que certaines solutions prennent en charge les builds sans privilèges root.
Ces attaques peuvent sembler assez classiques, et une configuration robuste empêcherait de telles élévations de privilèges, mais en réalité, de nombreuses organisations appliquent de mauvaises pratiques et privilégient la commodité au détriment de la sécurité. Certaines équipes peuvent même ignorer l’existence de paramètres de sécurité supplémentaires ou les juger incompatibles avec leurs délais.
Les chercheurs ont fait état de résultats intéressants dans leurs 10 scénarios. Le dernier consistait à faire croire « vous avez compromis l’ordinateur portable d’un développeur ». Après avoir enchaîné plusieurs exploits, ils sont parvenus à accéder au nœud maître Jenkins et à extraire toutes les variables, ce qui leur a finalement donné un accès complet à l’environnement de production, le pipeline de déploiement disposant de trop nombreuses autorisations.
À lire aussi : Une nouvelle initiative open source de sécurité dédiée aux attaques contre la chaîne d’approvisionnement
Comment sécuriser votre pipeline CI/CD
Les pipelines CI/CD sont des environnements critiques que les hackers attaqueront dès qu’ils en auront l’occasion. En raison de leur complexité et du temps nécessaire à leur configuration correcte, de nombreuses équipes accordent tous les privilèges à des outils tiers qui ne sont pas censés en disposer d’autant.
Voici quelques mesures de sécurité pratiques :
- L’approche du moindre privilège (partout dans la chaîne) est la bonne direction à suivre ici. Accordez aux personnes et aux outils tiers le minimum de droits nécessaires. Cela prend certes plus de temps à configurer et peut même déclencher des bugs dans les tests et ailleurs, mais cela en vaut la peine.
- Activez l’authentification à deux facteurs (2FA) et l’authentification multifacteur (MFA) chaque fois que possible, en particulier pour les comptes administrateur.
- N’utilisez jamais, au grand jamais, de variables d’environnement pour stocker des identifiants ou, à défaut, chiffrez-les.
- Identifiez les points les plus faibles de vos pipelines qui nécessitent des mesures de sécurité supplémentaires.
- Mettez en place des contrôles de sécurité, en particulier pour les personnes qui valident le code.
- Adoptez une politique solide vis-à-vis des fournisseurs. Le déploiement continu met en production du code que vos équipes ne gèrent pas, ce qui rend les attaques contre la chaîne d’approvisionnement attrayantes pour les hackers.
La phase de configuration est particulièrement critique. Soyez extrêmement vigilants lors des premières étapes de vos projets, car c’est généralement à ce moment que vous repérez les instances mal configurées susceptibles d’entraîner une élévation de privilèges.
Le moindre privilège, ou les principes de confiance zéro, occupent une place centrale dans les travaux de Smart et Gazdag, mais ceux-ci recommandent également des contrôles supplémentaires, comme la segmentation du réseau et la gestion des correctifs.
Pour aller plus loin :