Qu'est-ce que l'exécution d'un pipeline empoisonné (EPP) ?

L'exemple d'attaque D-PPE illustré à la figure 1 se déroule selon la succession d'étapes suivante :

1. Un adversaire initie une nouvelle branche distante au sein du référentiel, modifiant le fichier de configuration du pipeline avec des instructions nuisibles pour récupérer les identifiants AWS stockés au sein de l'organisation GitHub et les transmettre à un serveur externe sous le contrôle de l'attaquant.
2. La poussée de code active un pipeline qui extrait le code, y compris le fichier de configuration du pipeline malveillant, du référentiel.
3. Le pipeline fonctionne selon le fichier de configuration, qui est maintenant entaché par l'attaquant. Les instructions malveillantes commandent le chargement en mémoire des informations d'identification AWS, stockées en tant que secrets de dépôt.
4. Suivant les instructions de l'attaquant, le pipeline transmet les informations d'identification AWS à un serveur contrôlé par l'attaquant.
5. En possession des informations d'identification volées, l'attaquant a la possibilité d'infiltrer l'environnement de production.

EPI indirect

Il y a EPI indirect lorsque la possibilité d'EPD n'est pas disponible pour un adversaire ayant accès à un référentiel SCM :

• Si le pipeline est configuré pour extraire le fichier de configuration CI d'une branche séparée et protégée dans le même dépôt.
• Si le fichier de configuration de l'IC est stocké dans un référentiels des codes séparés du code source, sans possibilité pour un utilisateur de le modifier directement.
• Si le build CI est défini dans le système CI lui-même - au lieu d'un fichier stocké dans le code source.

Dans ces scénarios, l'attaquant peut toujours empoisonner le pipeline en injectant du code malveillant dans les fichiers référencés par le fichier de configuration du pipeline, tels que les scripts référencés dans le fichier de configuration du pipeline, les tests de code ou les outils automatiques tels que les linters et les scanners de sécurité utilisés dans l'IC. Par exemple :

• L'utilitaire make exécute les commandes définies dans le fichier Makefile.
• Les scripts référencés à partir du fichier de configuration du pipeline, qui sont stockés dans le même référentiels que le code source lui-même (par exemple, python myscript.py - où myscript.py serait manipulé par l'attaquant).
• Tests de code : Les référentiels de test fonctionnant sur le code de l'application dans le cadre du processus de construction s'appuient sur des fichiers dédiés, stockés dans le même référentiel que le code source. Les attaquants qui parviennent à manipuler le code responsable des tests peuvent alors exécuter des commandes malveillantes à l'intérieur de la construction.
• Outils automatiques : Les linters et les scanners de sécurité utilisés dans l'IC s'appuient généralement sur un fichier de configuration résidant dans le référentiel qui charge et exécute généralement du code externe à partir d'un emplacement défini dans le fichier de configuration.

Plutôt que d'empoisonner le pipeline par une attaque PPE directe, l'attaquant qui lance une attaque PPE indirecte injecte un code malveillant dans les fichiers référencés par le fichier de configuration. Le code malveillant est finalement exécuté sur le nœud du pipeline et exécute les commandes déclarées dans les fichiers.

Dans cet exemple d'attaque I-PPE, la chaîne des événements se déroule comme suit :

1. Un attaquant crée une demande d'extraction dans le dépôt, en ajoutant des commandes malveillantes au fichier Makefile.
2. Puisque le pipeline est configuré pour se déclencher sur tout PR contre le repo, le pipeline Jenkins est déclenché, récupérant le code du repo - y compris le Makefile malveillant.
3. Le pipeline s'exécute sur la base du fichier de configuration stocké dans la branche principale. Il arrive à l'étape de construction et charge les informations d'identification AWS dans les variables d'environnement - comme défini dans le fichier Jenkins d'origine. Il lance ensuite la commande make build, qui exécute la commande malveillante ajoutée dans Makefile.
4. La fonction de compilation malveillante définie dans le fichier Makefile est exécutée, envoyant les informations d'identification AWS à un serveur contrôlé par l'attaquant.
5. L'attaquant peut alors utiliser les informations d'identification volées pour accéder à l'environnement de production AWS.

EPI public

L'EPI public est un type d'attaque EPI exécutée par des attaquants anonymes sur l'internet. Les dépôts publics permettent souvent à n'importe quel utilisateur de contribuer, généralement en créant des demandes d'extraction. Si le pipeline d'IC d'un référentiel public exécute du code non revu suggéré par des utilisateurs anonymes, il est susceptible de faire l'objet d'une attaque EPI publique. L'EPI public peut également exposer des actifs internes, tels que des secrets de projets privés, dans les cas où le pipeline du référentiel public vulnérable fonctionne sur la même instance d'IC que des projets privés.

Importance de l'exécution sécurisée des pipelines dans CI/CD

L'exécution d'un code malveillant non revu dans l'IC par une attaque PPE réussie donne aux attaquants le même niveau d'accès et de capacité que le travail de construction :

• Accès aux secrets disponibles pour le travail de CI, tels que les secrets injectés en tant que variables d'environnement ou les secrets supplémentaires stockés dans le CI. Responsables de la construction du code et du déploiement des artefacts, les systèmes CI/CD contiennent généralement des dizaines d'informations d'identification et de jetons de grande valeur - par exemple vers un fournisseur de cloud, vers des registres d'artefacts et vers le SCM lui-même.
• Accès à des actifs externes sur lesquels le nœud de travail dispose d'autorisations, tels que des fichiers stockés dans le système de fichiers du nœud, ou des informations d'identification sur un environnement cloud accessible par l'intermédiaire de l'hôte sous-jacent.
• Possibilité d'envoyer du code et des artefacts plus loin dans le pipeline, sous l'apparence d'un code légitime construit par le processus de construction.
• Capacité d'accéder à des hôtes et à des actifs supplémentaires dans le réseau/l'environnement du nœud de travail.

Mais les organisations peuvent protéger leurs produits logiciels et leur infrastructure grâce à un pipeline d'exécution sécurisé qui garantit que tout le code compilé, testé et déployé est légitime et n'a pas été altéré.

Risques associés à l'exécution d'un pipeline empoisonné

Les conséquences de l'EPI peuvent être graves, allant de l'accès non autorisé aux données, à la compromission de l'intégrité des logiciels, aux interruptions de système, aux violations de données ou même à la prise de contrôle totale du système. Ces risques constituent des menaces importantes pour l'entreprise et ses clients, ce qui souligne l'importance de l'EPI.

Dans l'opération de compromission de la chaîne d'approvisionnement en huit étapes présentée dans la figure 3, l'attaquant accède au pipeline de CI et empoisonne les composants de l'application SaaS. Par l'intermédiaire du composant empoisonné, l'attaquant crée une fonctionnalité de porte dérobée dans l'application et envoie les plugins empoisonnés aux clients en aval. Comme les organisations en aval perçoivent probablement le progiciel empoisonné comme légitime, elles l'intègrent à leur infrastructure dans le cloud ou sur place.

À partir d'un seul pipeline d'informations critiques empoisonné, l'attaquant réalise des dommages collatéraux exponentiels, en créant des accès dérobés à d'innombrables organisations. C'est le cas de l'attaque SolarWinds.

LIRE LA SUITE : Anatomie d'une attaque sur le pipeline CI/CD

Prévention de l'exécution d'un pipeline empoisonné

La prévention et l'atténuation du vecteur d'attaque EPI impliquent de multiples mesures couvrant à la fois les systèmes SCM et CI :

• Veillez à ce que les pipelines exécutant du code non revu soient exécutés sur des nœuds isolés plutôt qu'exposés à des secrets et à des environnements sensibles.
• Évaluer la nécessité de déclencher des pipelines sur des dépôts publics provenant de contributeurs externes. Dans la mesure du possible, abstenez-vous d'exécuter des pipelines provenant de forks et envisagez d'ajouter des contrôles tels que l'exigence d'une approbation manuelle pour l'exécution des pipelines.
• Pour les pipelines sensibles, par exemple ceux qui sont exposés à des secrets, assurez-vous que chaque branche configurée pour déclencher un pipeline dans le système CI dispose d'une règle de protection de branche corrélative dans le SCM.
• Afin d'empêcher la manipulation du fichier de configuration de l'IC pour exécuter un code malveillant dans le pipeline, chaque fichier de configuration de l'IC doit être examiné avant l'exécution du pipeline. Le fichier de configuration de l'IC peut également être géré dans une branche distante, séparée de la branche contenant le code en cours de construction dans le pipeline. La branche distante doit être configurée comme protégée.
• Supprimez les permissions accordées sur le référentiel SCM aux utilisateurs qui n'en ont pas besoin.
• Chaque filière ne doit avoir accès qu'aux informations d'identification dont elle a besoin pour remplir sa mission. Les exigences doivent être assorties des privilèges minimums requis.

FAQ sur l'exécution des pipelines empoisonnés