CICD-SEC-5 : contrôles d’accès du pipeline insuffisants

Cinquième entrée du Top 10 OWASP CI/CD, corollaire direct de l’exécution de pipeline empoisonnée. Libellé officiel : Insufficient PBAC, pour Pipeline-Based Access Controls. C’est l’entrée la plus importante pour dimensionner le risque, parce qu’elle ne décrit pas une façon d’entrer mais ce que l’on trouve une fois entré.

→ Lire l’explication complète de la marmotte

Le mécanisme : ce que le nœud atteint

Les nœuds qui exécutent les pipelines accèdent au code, le construisent, le testent, récupèrent des secrets depuis des variables d’environnement, des coffres et des services d’identité du fournisseur cloud, puis créent, modifient et déploient des artefacts. Le référentiel les appelle le cœur battant de la chaîne, et c’est juste au sens le plus désagréable : tout y passe.

Le terme PBAC désigne le contexte dans lequel chaque pipeline, et chaque étape de ce pipeline, s’exécute. Le document en découpe trois dimensions, et ce découpage est la partie utile :

ce que l’étape atteint dans son environnement d’exécution : le code, les secrets, les variables d’environnement, et les autres pipelines ;
ses permissions sur l’hôte sous-jacent et sur les autres nœuds, y compris sur le nœud contrôleur qui orchestre les tâches ;
ses filtres de flux entrants et sortants vers Internet.

L’objectif annoncé est de restreindre chaque étape au strict jeu de données et de ressources dont elle a besoin, afin que du code hostile fasse le moins de dégâts possible. La formulation admet l’échec : on ne cherche pas à empêcher l’exécution de code hostile dans un pipeline, on cherche à ce qu’elle ne mène nulle part. Même posture que celle du Top 10 LLM sur les modèles : construire autour du composant pour que sa compromission ne casse rien d’important.

Trois dispositifs de confort défont ce découpage, et ils sont la règle plutôt que l’exception. Le nœud partagé entre pipelines de sensibilité différente, qui met les secrets de production à portée d’une tâche de test. Le nœud persistant, non remis à son état initial entre deux exécutions, où ce qu’une tâche a laissé sert à la suivante. Et l’accès sortant libre, qui transforme la lecture d’un secret en exfiltration : sans sortie, un secret lu reste un secret lu.

Un quatrième cas contourne le coffre : les services d’identité du fournisseur cloud joignables depuis le nœud, qui délivrent des identifiants à qui les demande depuis la bonne machine. Même mécanisme que pour le jeton de compte de service monté par défaut dans un cluster : l’identité n’est pas dans un fichier, elle est dans le fait d’être là.

Ce que l’attaquant obtient

Les permissions complètes de l’étape où son code tourne, ni plus ni moins. Le référentiel en tire trois conséquences : l’exposition de données confidentielles, le mouvement latéral dans l’environnement d’intégration et au-delà, jusqu’à des serveurs extérieurs à cet environnement, et le déploiement d’artefacts malveillants en aval, y compris en production. Le site traite ces deux derniers points dans le mouvement latéral et la segmentation et sous l’angle adverse dans la tactique ATT&CK de mouvement latéral.

La phrase décisive du document est celle qui mesure : l’étendue des dégâts est déterminée par la granularité du PBAC. Un pipeline unique, détenant tous les secrets avec un accès sortant libre, transforme n’importe quel défaut des quatre premières entrées en compromission complète. Le même défaut, sur un nœud jetable sans secret et sans sortie, produit une construction en échec.

Les précédents cités par le référentiel illustrent les trois dimensions. Codecov d’abord, où la compromission d’un outil de couverture de code a servi à voler les variables d’environnement de milliers de constructions, dans de nombreuses entreprises : ce que l’étape atteint. La confusion de dépendances de CICD-SEC-3 ensuite, où le code hostile exécuté sur les nœuds a permis de se déplacer dans l’environnement : les permissions sur l’hôte et les autres nœuds. La faille de l’intégration continue de Teleport enfin, où un attaquant venu d’Internet a pu faire tourner un conteneur privilégié et obtenir les droits d’administration du nœud, d’où exfiltration de secrets et publication d’artefacts malveillants : les trois dimensions à la fois, et ce que vaut l’élévation de privilèges sur une machine de construction.

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

Le trafic sortant du nœud vers une destination inattendue. Comme pour l’entrée précédente, le signal le plus fiable, et il suppose la même condition : une liste de destinations légitimes, qui est ici un contrôle autant qu’une référence de détection. Dans le même registre, les demandes d’identifiants au service d’identité du fournisseur cloud sont journalisées de son côté et d’un volume stable : une étape de test qui réclame un jeton de déploiement est une anomalie lisible.

Les secrets lus hors de leur étape. Si chaque secret est cadré sur une étape, toute lecture ailleurs est une erreur de configuration ou un incident, et l’on n’a pas à trancher pour alerter. Sans ce cadrage, il n’y a rien à comparer. De même, sur un nœud censé repartir de son état initial, la persistance d’un fichier ou d’un processus est anormale par construction : détection peu coûteuse quand les nœuds sont éphémères, impossible quand ils ne le sont pas.

Ce que le défenseur fait

Ne pas partager un nœud entre pipelines de sensibilité différente : les nœuds partagés sont réservés aux pipelines de confidentialité identique. C’est la mesure qui ferme la forme publique de CICD-SEC-4, où un dépôt ouvert expose les secrets des projets privés voisins.

Cadrer les secrets par pipeline et par étape, de sorte que chaque étape n’accède qu’à ce qui lui est nécessaire : sécuriser les secrets et permissions CI/CD, puis les identifiants CI/CD par OIDC, qui remplace le secret statique par un jeton court lié au dépôt et à la branche, approche détaillée dans les identifiants de chaîne d’intégration.

Remettre le nœud à son état initial après chaque exécution, autrement dit des nœuds jetables, ce que la sécurité des instances éphémères traite comme un sujet d’exploitation autant que de sécurité. Et isoler les scripts d’installation de paquets dans un contexte sans accès aux secrets des autres étapes : recommandation partagée mot pour mot avec CICD-SEC-3.

Appliquer le moindre privilège sur l’hôte : utilisateur système restreint, permissions limitées sur le nœud contrôleur, tâche sur un nœud dédié quand c’est possible, avec l’isolation en espaces de noms et groupes de contrôle et un fichier de construction d’image durci. Sur un existant, la difficulté est celle de l’écart entre moindre privilège théorique et pratique, avec son geste, moindre privilège sur un compte cloud existant.

Maintenir le nœud à jour, un nœud non corrigé offrant l’élévation de privilèges qui annule le reste, et segmenter son réseau pour qu’il n’atteigne que les ressources dont il a besoin, sans accès illimité vers Internet. Dans un cluster, ce travail prend la forme décrite par déployer des politiques réseau Kubernetes.

Sources

CICD-SEC-5: Insufficient PBAC, OWASP Top 10 CI/CD Security Risks, 2022 : définition du PBAC, trois dimensions, impact, recommandations.
Références citées par le document : la compromission de Codecov et le vol des variables d’environnement de constructions, les victimes de la confusion de dépendances dont les nœuds ont servi de pivot, et la faille de l’intégration continue de Teleport menant aux droits d’administration du nœud.

🐝 Ce qui arrive si on s’en passe

Sans restriction du contexte d’exécution, un fichier 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. La question « quels secrets cette étape pouvait-elle lire » n’a alors pas de réponse documentée, et la seule remédiation sûre est de tout renouveler.

Le second coût est l’impossibilité de borner l’incident. Sur un nœud partagé et persistant, rien ne distingue ce qui appartenait à la tâche compromise de ce qui appartenait aux autres : tout ce qui a transité par cette machine devient suspect, depuis une date qu’on ne connaît pas. Reconstruire le nœud, qui est l’opération simple, ne clôt rien, puisque les secrets qu’il détenait sont valides ailleurs. Et l’accès sortant n’étant pas filtré, la question « qu’est-ce qui est sorti » se pose au pare-feu, où l’on conserve des volumes plutôt que des contenus.

🦫 Explication de la marmotte 🍫

Les machines qui assemblent et installent un logiciel ne sont pas ordinaires : pour travailler, elles détiennent les mots de passe des serveurs de production, les clés des entrepôts de paquets et un droit d’écriture sur le code. Elles sont donc le point le plus concentré de l’informatique d’une entreprise, et elles ont longtemps été administrées comme un outil interne sans conséquence.

Le sujet n’est pas comment un attaquant entre dans ces machines, mais ce qu’il y trouve. Trois questions suffisent : que peut lire cette étape de travail, que peut-elle faire sur la machine qui l’exécute, et où peut-elle se connecter.

Trois commodités rendent presque toujours les réponses mauvaises. La machine partagée : tests et mises en production tournent au même endroit, donc les secrets de la production sont à portée des tests. La machine qui n’est pas remise à neuf entre deux travaux : ce qu’une tâche a laissé traîner sert à la suivante. Et la connexion libre vers Internet, qui transforme la lecture d’un mot de passe en envoi de ce mot de passe.

Le raisonnement du référentiel est inhabituel : il renonce à empêcher l’exécution de code hostile dans ces machines, trop difficile, et cherche à ce qu’elle ne serve à rien. Une machine jetable, qui ne détient que les mots de passe de sa tâche et ne joint que trois adresses, subit la même attaque sans dommage.

Pages voisines

La citent

CICD-SEC-5 : contrôles d'accès du pipeline insuffisants

Elle cite

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