Les pipelines d'intégration continue/développement continu (CI/CD) peuvent être la surface d'attaque potentielle la plus dangereuse de la chaîne d'approvisionnement logicielle, selon les chercheurs, alors que les cyberattaquants intensifient leur intérêt à rechercher les faiblesses.
La surface d'attaque augmente également : les pipelines CI/CD sont de plus en plus présents au sein des équipes de développement de logiciels d'entreprise, qui les utilisent pour créer, tester et déployer du code à l'aide de processus automatisés. Mais des autorisations excessives, un manque de segmentation du réseau et une mauvaise gestion des secrets et des correctifs entravent leur mise en œuvre, offrant aux criminels la possibilité de les compromettre pour passer librement d'un environnement sur site à un environnement cloud.
À Black Hat USA le mercredi 10 août, Iain Smart et Viktor Gazdag du cabinet de conseil en sécurité NCC Group monteront sur scène pendant «RCE-as-a-Service : leçons tirées de 5 ans de compromis sur le pipeline CI/CD dans le monde réel», pour discuter de la série d'attaques réussies de la chaîne d'approvisionnement qu'ils ont menées dans les pipelines de production CI/CD pour pratiquement toutes les entreprises testées par l'entreprise.
NCC Group a supervisé plusieurs dizaines de compromis réussis d'objectifs, allant des petites entreprises aux entreprises du Fortune 500. En plus de bogues de sécurité, les chercheurs affirment que de nouveaux abus des fonctionnalités prévues dans les pipelines automatisés leur ont permis de convertir les pipelines d'un simple utilitaire de développement en exécution de code à distance (RCE) en tant que service.
"J'espère que les gens donneront un peu plus d'amour à leurs pipelines CI/CD et appliqueront toutes ou au moins une ou deux recommandations de notre session", déclare Gazdag. "Nous espérons également que cela suscitera davantage de recherches sur la sécurité sur le sujet."
Tara Seals, rédactrice en chef de Dark Reading pour les nouvelles, s'est entretenue avec Viktor Gazdag, consultant en gestion de la sécurité du groupe NCC, pour en savoir plus.
Joints Tara : Quelles sont certaines des faiblesses de sécurité les plus courantes dans les pipelines CI/CD, et comment peuvent-elles être exploitées ?
Victor Gazdag : Nous constatons régulièrement trois failles de sécurité courantes qui nécessitent plus d'attention :
1) Informations d'identification codées en dur dans Version Control System (VCS) ou Source Control Management (SCM).
Ceux-ci incluent des scripts shell, des fichiers de connexion, des informations d'identification codées en dur dans des fichiers de configuration qui sont stockés au même endroit que le code (pas séparément ou dans des applications de gestion secrètes). On trouve aussi souvent des jetons d'accès à différents environnements cloud (développement, production) ou à certains services au sein du cloud tels que SNS, Database, EC2, etc.
Nous trouvons également toujours des identifiants pour accéder à l'infrastructure de support ou au pipeline CI/CD. Une fois qu'un attaquant a accès à l'environnement cloud, il peut énumérer ses privilèges, rechercher des erreurs de configuration ou essayer d'élever ses privilèges car il se trouve déjà dans le cloud. Avec l'accès au pipeline CI/CD, ils peuvent voir l'historique de construction, accéder aux artefacts et aux secrets qui ont été utilisés (par exemple, l'outil SAST et ses rapports sur les vulnérabilités ou les jetons d'accès au cloud) et dans le pire des cas, injecter du code arbitraire (backdoor, SolarWinds) dans l'application qui sera compilée, ou obtenir un accès complet à l'environnement de production.
2) Rôles trop permissifs.
Les développeurs ou les comptes de service ont souvent un rôle associé à leurs comptes (ou peuvent en assumer un) qui dispose de plus d'autorisations que nécessaire pour effectuer le travail requis.
Ils peuvent accéder à plus de fonctions, telles que la configuration du système ou des secrets étendus aux environnements de production et de développement. Ils pourraient être en mesure de contourner les contrôles de sécurité, tels que l'approbation par d'autres développeurs, ou de modifier le pipeline et de supprimer tout outil SAST qui aiderait à rechercher des vulnérabilités.
Comme les pipelines peuvent accéder aux environnements de déploiement de production et de test, s'il n'y a pas de segmentation entre eux, ils peuvent alors agir comme un pont entre les environnements, même entre sur site et dans le cloud. Cela permettra à un attaquant de contourner les pare-feu ou toute alerte et de se déplacer librement entre des environnements qui autrement ne seraient pas possibles.
3) Absence d'audit, de surveillance et d'alerte.
C'est le domaine le plus négligé, et 90 % du temps, nous avons constaté un manque de surveillance et d'alerte sur toute modification de configuration ou de gestion des utilisateurs/rôles, même si l'audit était activé ou activé. La seule chose qui peut être surveillée est la compilation ou la génération réussie ou non de la tâche.
Il existe également des problèmes de sécurité plus courants, tels que le manque de segmentation du réseau, la gestion des secrets et la gestion des correctifs, etc., mais ces trois exemples sont des points de départ d'attaques, nécessaires pour réduire le temps moyen de détection des violations, ou sont importants pour limiter rayon d'explosion d'attaque.
TS: Avez-vous des exemples spécifiques du monde réel ou des scénarios concrets que vous pouvez citer ?
VG : Certaines attaques dans l'actualité liées aux attaques CI/CD ou de pipeline incluent :
- Attaque CCleaner, 2018 Mars
- Homebrew, août 2018
- Asus ShadowHammer, 2019 Mars
- Violation par un tiers de CircleCI, septembre 2019
- SolarWinds, Décembre 2020
- Script de téléchargement bash de Codecov, avril 2021
- TravisCI accès non autorisé aux secrets, septembre 2021
TS: Pourquoi les faiblesses des pipelines automatisés posent-elles problème ? Comment caractériseriez-vous le risque pour les entreprises ?
VG : Il peut y avoir des centaines d'outils utilisés dans les étapes du pipeline et, à cause de cela, les connaissances considérables que quelqu'un doit connaître sont énormes. De plus, les pipelines ont un accès réseau à plusieurs environnements et plusieurs informations d'identification pour différents outils et environnements. Accéder aux pipelines revient à obtenir un laissez-passer gratuit qui permet aux attaquants d'accéder à tout autre outil ou environnement lié au pipeline.
TS: Quels sont certains des résultats d'attaque que les entreprises pourraient subir si un adversaire réussissait à subvertir un pipeline CI/CD ?
VG : Les résultats d'une attaque peuvent inclure le vol de code source ou de données intellectuelles, le détournement d'une application qui est déployée sur des milliers de clients (comme SolarWinds), l'accès à (et le déplacement libre entre) plusieurs environnements tels que le développement et la production, à la fois sur site ou dans le nuage, ou les deux.
TS: À quel point les adversaires doivent-ils être sophistiqués pour compromettre un pipeline ?
VG : Ce que nous présentons à Black Hat, ce ne sont pas des vulnérabilités zero-day (même si j'ai trouvé des vulnérabilités dans différents outils) ou de nouvelles techniques. Les criminels peuvent attaquer les développeurs via le phishing (détournement de session, contournement d'authentification multifacteur, vol d'informations d'identification) ou le pipeline CI/CD directement s'il n'est pas protégé et est accessible sur Internet.
NCC Group a même effectué des évaluations de sécurité où nous avons d'abord testé des applications Web. Ce que nous avons constaté, c'est que les pipelines CI/CD sont rarement enregistrés et surveillés avec des alertes, autres que le travail de création/compilation de logiciels, de sorte que les criminels n'ont pas besoin d'être aussi prudents ou sophistiqués pour compromettre un pipeline.
TS: Quelle est la fréquence de ces types d'attaques et quelle est l'étendue de la surface d'attaque des pipelines CI/CD ?
VG : Il existe plusieurs exemples d'attaques dans le monde réel dans les nouvelles, comme mentionné. Et vous pouvez toujours trouver, par exemple, Instances Jenkins avec Shodan sur Internet. Avec le SaaS, les criminels peuvent énumérer et essayer de forcer brutalement les mots de passe pour y accéder car ils n'ont pas d'authentification multifacteur activée par défaut ou de restrictions IP, et sont connectés à Internet.
Avec le travail à distance, les pipelines sont encore plus difficiles à sécuriser car les développeurs veulent y accéder de n'importe où et à tout moment, et les restrictions IP ne sont plus nécessairement réalisables car les entreprises évoluent vers des réseaux de confiance zéro ou ont des emplacements de réseau changeants.
Les pipelines ont généralement un accès réseau à plusieurs environnements (ce qu'ils ne devraient pas) et ont accès à plusieurs informations d'identification pour différents outils et environnements. Ils peuvent servir de pont entre les systèmes sur site et le cloud, ou les systèmes de production et de test. Cela peut être une surface d'attaque très large et les attaques peuvent provenir de plusieurs endroits, même ceux qui n'ont rien à voir avec le pipeline lui-même. Chez Black Hat, nous présentons deux scénarios dans lesquels nous avons initialement commencé avec des tests d'applications Web.
TS : Pourquoi les pipelines CI/CD restent-ils un angle mort de sécurité pour les entreprises ?
VG : Principalement à cause du manque de temps, parfois du manque de personnes et, dans certains cas, du manque de connaissances. Les pipelines CI/CD sont souvent créés par des développeurs ou des équipes informatiques disposant d'un temps limité et axés sur la rapidité et la livraison, ou les développeurs sont tout simplement surchargés de travail.
Les pipelines CI/CD peuvent être très ou extrêmement complexes et peuvent inclure des centaines d'outils, interagir avec plusieurs environnements et secrets, et être utilisés par plusieurs personnes. Certaines personnes ont même créé une représentation sous forme de tableau périodique des outils pouvant être utilisés dans un pipeline.
Si une entreprise consacre du temps à créer un modèle de menace pour le pipeline qu'elle utilise et les environnements de support, elle verra le lien entre les environnements, les limites et les secrets, et où les attaques peuvent se produire. La création et la mise à jour continue du modèle de menace doivent être faites, et cela prend du temps.
TS: Quelles sont les meilleures pratiques pour renforcer la sécurité des pipelines ?
VG : Appliquez la segmentation du réseau, utilisez le principe du moindre privilège pour la création de rôles, limitez la portée d'un secret dans la gestion des secrets, appliquez fréquemment des mises à jour de sécurité, vérifiez les artefacts, surveillez et alertez sur les changements de configuration.
TS: Y a-t-il d'autres pensées que vous aimeriez partager?
VG : Bien que les pipelines CI/CD cloud natifs ou basés sur le cloud soient plus simples, nous avons toujours constaté des problèmes identiques ou similaires, tels que des rôles trop permissifs, aucune segmentation, des secrets trop étendus et un manque d'alerte. Il est important que les entreprises se souviennent qu'elles ont également des responsabilités en matière de sécurité dans le cloud.
