Protéger ses systèmes CI/CD n’est pas une mince affaire, mais c’est une tâche importante. Pour commencer, voici d’une manière succincte cinq façons dont les attaquants peuvent tirer parti d’un CI/CD pour accéder à d’autres systèmes.

#1 : Quand quelqu’un peut trouver des informations d’identification
Dans un rapport du NCC Group sur 10 attaques réalisées, la première attaque commence par un bucket S3 dont les autorisations sont mal gérées. Ce dernier contenait un script avec un identifiant Git codé en dur. À partir de là, il suffisait de quelques étapes pour accéder à l’environnement CI/CD et obtenir d’autres informations d’identification auxquelles les processus CI/CD avaient accès... Échec et Mat !

Il y a des millions de secrets codés en dur dans les dépôts Git, mais les secrets peuvent se trouver n’importe où : les buckets S3, les captures d’écran, etc. L’hygiène des secrets devrait être respectée partout. Et étant donné le nombre d’attaques qui ont commencé dans des buckets S3 mal configurés, il faut l’utiliser correctement.

#2 Quand GitHub détient des identifiants AWS
Bien que les variables d’environnement soient considérées comme un standard minimum pour garder les secrets hors du code, si le code qui les utilise est compromis ou mal configuré, il peut commencer à les révéler à travers des fichiers de logs.

GitHub et AWS disposent en fait d’une solution de contournement ingénieuse, utilisant OpenID Connect (OIDC). Dans ce cas, AWS utilise GitHub comme fournisseur d’identité (IDP) pour un rôle de gestion de l’identité et de l’accès (IAM). Ce rôle IAM n’est accessible que par un dépôt, qui peut être limiter à une branche spécifique. GitHub et AWS négocient entre eux des tokens temporaires et aucun mot de passe n’est stocké.

Lorsqu’aucun mot de passe n’est stocké par le système, aucun mot de passe ne peut être révélé par le système.

#3 Quand l’accès est mal géré
Le deuxième point du Top 10 des risques de sécurité CI/CD de l’OWASP traite également de l’IAM. Il décrit un certain nombre de façons dont l’accès doit être géré. Pour citer l’OWASP : "Il n’est pas trivial de s’assurer que chaque identité humaine et applicative n’a reçu que les permissions requises et qu’elle n’a accès qu’aux dépôts auxquels elle a besoin d’accéder."

Ce problème ne se limite pas non plus au service qu’AWS appelle "IAM". La gestion des identités et des accès concerne tout, de la carte d’accès à la porte du bâtiment à la politique d’accès attribuée à une branche spécifique d’un dépôt Git. Il est essentiel de s’assurer que les processus CI/CD ne peuvent toucher que ce qu’ils sont censés toucher et voir ce qu’ils sont censés voir.

En outre, le nombre de personnes ayant accès au logging CI/CD et la manière dont elles peuvent y accéder sont importants. Si le processus CI/CD laisse filtrer des informations d’identification dans les logs et que le login d’un sous-traitant est volé, le compte à rebours d’une prise de contrôle complète commence à tourner.

#4 Obscurcir ses informations d’identification
De nombreux systèmes de logs CI/CD disposent d’une méthode d’identification et d’expurgation des informations d’identification dans les logs. Mais si on fait en sorte que les filtres d’expurgation ne puissent pas repérer les informations d’identification, alors qu’un humain expérimenté peut le faire, le risque de piratage est important.

Dans de nombreuses démonstrations d’attaques de pipelines (avec introduction de code néfaste dans un processus CI/CD), les pirates font en sorte que code néfaste génère des mots de passe en base 64. Par exemple, PASSWORD=’LetMeIn’ en base 64 est UEFTU1dPUkQ9J0xldE1lSW4n. Bien que les filtres de rédaction soient de plus en plus performants pour repérer ce genre de choses, les filtres de rédaction de certains systèmes se résument à une poignée de modèles d’expressions régulières. Convertir des secrets dans un autre format peut aider à les faire passer inaperçus aux yeux des détecteurs qui sont là pour pour protéger les entreprises.

Dans les conseils sur le renforcement de la sécurité de GitHub, l’un des principaux points d’orientation pour les secrets est de "ne jamais utiliser de données structurées comme secret". Packager les secrets en XML, JSON, ou YAML peut mettre les robots détecteurs de secrets sur une fausse piste et laisser ces secrets s’échapper dans vos logs.
#5 Quand chaque fichier a les mêmes permissions d’écriture

GitHub propose une fonctionnalité appelée CODEOWNERS, qui offre une application pratique qui peut être transposée à d’autres systèmes.

Avec CODEOWNERS, il est possible de définir les permissions sur un répertoire .github/workflows de telle sorte que chaque fois que quelqu’un essaie de changer quelque chose dans ce répertoire (créant ainsi un "pipeline empoisonné"), un administrateur spécifié par CODEOWNERS est non seulement alerté, mais doit également approuver le changement.

En fonction des systèmes, il est possible de verrouiller des fichiers ou des répertoires importants dans un environnement de développement et de s’assurer que seules les personnes qui ont besoin de modifier les scripts de build ou les configurations peuvent le faire. Qu’il s’agisse d’une version locale ou d’un serveur principal, cela permet de s’assurer qu’une entreprise n’est pas victime d’un sabotage accidentel ou intentionnel de la part d’une personne de l’intérieur.

Que peut-on faire en plus ?
Comprendre comment une entreprise peut être compromise permet de prendre les actions, mais il y aussi des actions proactives qui peuvent changer la donne notamment en ce qui concerne le Shift Left.

Shift left
Le code doit être testé avant d’arriver dans le pipeline CI/CD. Les tests ont besoin d’accès et génèrent des logs, et s’ils sont exécutés dans des environnements de développement, ils ne fournissent pas une surface d’attaque supplémentaire au niveau CI/CD.

En outre, il faut scanner, scanner et encore scanner. Il existe de nombreux points, d’un hook de pré-commit dans un environnement de développement à l’analyse des logs et des artefacts d’une exécution CI/CD, où il est possible d’intégrer un scanner de vulnérabilités.

Utilisation de vaults
AWS et GitHub peuvent communiquer sans que GitHub n’ait accès à un secret AWS. Cela n’est pas limité au cas où l’on pousse des builds vers une instance EC2 ou S3. On peut également extraire des secrets pour d’autres ressources à partir d’AWS Secrets Manager, de sorte qu’ils ne soient jamais stockés dans GitHub. Si une entreprise n’utilise pas AWS ou GitHub, elle peut explorer comment ses outils CI/CD préférés et son vault favori peuvent s’intégrer afin qu’elle ne stocke pas de secrets dans ses scripts de build, ses outils de build ou les artefacts qu’ils produisent.