CICD-SEC-4 : exécution de pipeline empoisonnée

Quatrième entrée du Top 10 OWASP CI/CD, et la plus développée du référentiel. Libellé officiel : Poisoned Pipeline Execution, abrégé PPE. Le principe : un attaquant qui a des droits sur le gestionnaire de code source, et aucun sur l’environnement de construction, fait exécuter ses commandes par cet environnement. Il n’a pas besoin d’entrer dans la machine de construction : il lui suffit de modifier ce qu’elle va lire.

→ Lire l’explication complète de la marmotte

Le mécanisme : trois formes

Quiconque peut modifier la configuration de l’intégration continue, ou les autres fichiers dont la tâche dépend, peut y placer ses commandes. Les pipelines déclenchés par une demande de fusion y sont les plus exposés : par construction, ils traitent du code non relu.

La forme directe modifie le fichier de configuration du pipeline lui-même, par un envoi sur une branche non protégée ou une demande de fusion depuis une branche ou une copie du dépôt. L’exécution étant déclenchée par l’envoi, et son contenu défini par ce fichier, les commandes de l’attaquant tournent dans le nœud dès le déclenchement.

La forme indirecte s’applique quand la configuration est hors de portée : branche protégée distincte, autre dépôt, ou définition dans l’outil d’intégration. L’attaquant injecte alors son code dans les fichiers que cette configuration référence, et la liste du référentiel est plus longue qu’on ne l’imagine : un Makefile, un script appelé depuis la configuration, les fichiers des tests (le cadre de test exécute du code stocké dans le dépôt de l’application), et la configuration des outils automatiques, analyseurs de style ou de sécurité, dont beaucoup chargent du code externe désigné par leur propre fichier.

Elle déplace la question : non plus qui peut modifier le pipeline, mais de quels fichiers il dépend. La liste n’est presque jamais écrite, et elle inclut des fichiers que personne ne tient pour du code exécutable, dont ceux du code d’infrastructure, que certains fournisseurs exécutent dès la planification.

La forme publique, notée 3PE, ne demande aucun droit préalable : les dépôts publics acceptent les contributions de n’importe qui et les construisent comme celles des projets privés. Le document souligne la conséquence découverte le plus tard : quand ce pipeline partage son instance avec des projets privés, il expose aussi leurs secrets.

Ce que l’attaquant obtient

Exactement les capacités de la tâche de construction. La liste du référentiel explique pourquoi cette entrée est la plus citée du document :

tout secret accessible à la tâche, en variable d’environnement ou dans le système d’intégration, lequel détient couramment des dizaines d’identifiants de grande valeur : fournisseur cloud, registres d’artefacts, gestionnaire de code source lui-même ;
les ressources joignables par le nœud : son système de fichiers, les identifiants cloud accessibles via l’hôte ;
le droit de livrer du code et des artefacts en aval, sous l’apparence d’une construction légitime : le pont vers CICD-SEC-9 ;
le réseau du nœud, donc d’autres hôtes : mouvement latéral et segmentation.

Au sens du catalogue CWE, c’est une injection de commande dont le canal d’entrée est un fichier versionné, et la tactique d’exécution d’ATT&CK en décrit le versant adversaire. Le cas se distingue en ceci que le code hostile emprunte le mécanisme normal de l’organisation, et que son exécution est attendue.

La leçon de fond est désagréable à entendre dans une organisation qui a travaillé ses revues : un pipeline déclenché sur du code non relu exécute du code non relu. La revue protège ce qui part en production, pas ce qui s’exécute pour décider si ça peut partir : deux contrôles, deux endroits. La revue de code au-delà du linter dit ce qu’elle sait faire ; ceci en est la limite.

Ce qu’on peut détecter, et par quoi

Le trafic sortant du nœud. Le signal le plus fiable, l’exfiltration d’un secret supposant une sortie. Un nœud dont les destinations légitimes sont connues rend toute autre destination remarquable ; sans cette liste, il n’y a rien à détecter.

La modification des fichiers dont dépend le pipeline. Une fois la liste établie, l’alerte sur toute modification dans une demande de fusion est triviale à écrire. Seule détection qui couvre la forme indirecte, et elle suppose l’inventaire.

Les constructions déclenchées depuis une copie du dépôt : rares, nominatives, à fort enjeu, donc une alerte par occurrence reste tenable. Les écarts de durée et de volume ont révélé le minage sur des pipelines publics. Encore faut-il que ces journaux quittent le système d’intégration : un pipeline compromis noie ses traces, ce que traite CICD-SEC-10.

Ce que le défenseur fait

Exécuter le code non relu sur des nœuds isolés, sans secrets ni environnements sensibles. Mesure centrale, qui accepte le fait plutôt que de l’empêcher : non pas interdire l’exécution de code hostile dans un pipeline de test, mais faire qu’elle ne mène nulle part, par l’isolation en espaces de noms et groupes de contrôle.

Décider si les contributions extérieures doivent déclencher quelque chose : ne pas construire ce qui vient d’une copie du dépôt, exiger une approbation manuelle. Un projet ouvert doit tester ses contributions ailleurs que là où vivent ses secrets.

Faire correspondre les déclencheurs et les protections. Sur un pipeline sensible, chaque branche déclenchante doit avoir sa règle de protection : l’écart entre ces deux listes est la définition du risque, et il se calcule. Prolongement de CICD-SEC-1. De même, relire la configuration avant exécution ou la gérer sur une branche protégée séparée du code construit : efficace contre la forme directe, sans effet sur l’indirecte.

Retirer les permissions excédentaires sur les dépôts, puisque c’est d’elles que tout part : CICD-SEC-2 et les permissions Git en entreprise. Et ne donner à chaque pipeline que les identifiants de sa fonction : sécuriser les secrets et permissions CI/CD, dont la forme aboutie supprime les secrets statiques par identité fédérée OIDC, que détaille aussi la page sur les identifiants CI/CD.

Sources

CICD-SEC-4: Poisoned Pipeline Execution, OWASP Top 10 CI/CD Security Risks, 2022 : définition, trois formes, impact, recommandations.
Références citées par le document : les travaux de Daniel Krivelevich et Omer Gil qui ont nommé le vecteur, la forme indirecte trouvée par xssfox sur la chaîne de construction d’un site d’AWS, l’exécution de commandes lors de la planification d’infrastructure (Hiroki Suezawa, Alex Kaskasoli), et la faille de l’intégration continue de Teleport.

🐝 Ce qui arrive si on s’en passe

Un Makefile modifié dans une demande de fusion exécute du code avec tous les secrets du pipeline et un accès sortant libre. Les identifiants partent, et le journal montre une construction réussie : même durée, même conclusion, même auteur apparent. L’organisation apprend l’incident plus tard, par l’usage fait des identifiants ailleurs, ce qui déplace la détection vers le fournisseur cloud et allonge le délai de semaines. Faute d’avoir établi la liste des secrets de cette étape, la remédiation consiste à tout renouveler, soit à mener à chaud l’opération que personne n’a répétée à froid.

🦫 Explication de la marmotte 🍫

Entre l’écriture d’une ligne de code et le moment où elle tourne chez les clients, une machinerie automatique l’assemble, la teste et l’installe, avec les clés de tout : code source, mots de passe des serveurs, droit d’installer des programmes. L’attaque décrite ici porte un nom imagé, l’empoisonnement du pipeline, et son élégance tient à ce qu’elle n’entre pas dans la machinerie : l’attaquant modifie un fichier que la machinerie va lire et exécuter. Comme elle se déclenche dès qu’un fichier change, et comme elle exécute ce qu’elle lit, le code de l’attaquant tourne avec tous ses droits, sans que personne l’ait relu, puisque la relecture vient après.

Trois façons d’y arriver. La plus simple modifie la fiche d’instructions de la machinerie, quand on a le droit d’écrire dans le dépôt. La deuxième sert quand cette fiche est protégée : on modifie un des fichiers qu’elle désigne, un script, un fichier de test, le réglage d’un outil d’analyse ; la fiche reste intacte, et c’est elle qui lance le code modifié. La troisième ne demande aucun droit : sur un projet ouvert, la machinerie construit la proposition d’un inconnu pour vérifier qu’elle fonctionne, donc avant que quiconque l’ait lue.

Ce qui rend l’affaire sérieuse n’est pas l’exécution mais ce qu’elle emporte : tous les mots de passe dont dispose cette étape, le réseau joignable depuis cette machine, et le droit d’envoyer un paquet en aval comme s’il sortait normalement de la chaîne. Dans le journal, l’opération apparaît comme une construction réussie.

La bonne réponse n’est donc pas d’empêcher cette exécution, très difficile, mais de faire en sorte qu’elle ne serve à rien : construire le code non relu sur des machines séparées, sans secret, qui ne joignent presque rien et sont remises à neuf après chaque usage.

Pages voisines

La citent

CICD-SEC-4 : exécution de pipeline empoisonnée

Elle cite

: les deux pages se citent l’une l’autre.

CICD-SEC-4 : exécution de pipeline empoisonnée

CICD-SEC-4 : exécution de pipeline empoisonnée

Le mécanisme : trois formes

Ce que l’attaquant obtient

Ce qu’on peut détecter, et par quoi

Ce que le défenseur fait

Sources

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines