Pentesting CI/CD Methodology
VCS
VCS signifie Version Control System, ces systèmes permettent aux développeurs de gérer leur code source. Le plus courant est git et vous trouverez généralement des entreprises qui l'utilisent sur l'une des plateformes suivantes :
Github
Gitlab
Bitbucket
Gitea
Fournisseurs de cloud (ils offrent leurs propres plateformes VCS)
Pipelines
Les pipelines permettent aux développeurs d'automatiser l'exécution du code (pour la construction, les tests, le déploiement...) après certaines actions : un push, une PR, un cron... Ils sont extrêmement utiles pour automatiser toutes les étapes du développement à la production.
Cependant, ces systèmes doivent être exécutés quelque part et généralement avec des identifiants privilégiés pour déployer le code.
Méthodologie de Pentesting VCS
Même si certaines plateformes VCS permettent de créer des pipelines, pour cette section, nous allons analyser uniquement les attaques potentielles sur le contrôle du code source.
Les plateformes qui contiennent le code source de votre projet contiennent des informations sensibles et il faut être très prudent avec les permissions accordées à l'intérieur de cette plateforme. Voici quelques problèmes courants sur les plateformes VCS que les attaquants pourraient exploiter :
Fuites : Si votre code contient des fuites dans les commits et que l'attaquant peut accéder au dépôt (parce qu'il est public ou parce qu'il y a accès), il pourrait découvrir les fuites.
Accès : Si un attaquant peut accéder à un compte à l'intérieur de la plateforme VCS, il pourrait obtenir plus de visibilité et de permissions.
Inscription : Certaines plateformes permettront simplement aux utilisateurs externes de créer un compte.
SSO : Certaines plateformes n'autoriseront pas les utilisateurs à s'inscrire, mais permettront à quiconque d'accéder avec un SSO valide (donc un attaquant pourrait utiliser son compte github pour entrer par exemple).
Identifiants : Nom d'utilisateur+Mot de passe, tokens personnels, clés ssh, tokens Oauth, cookies... il existe plusieurs types de tokens qu'un utilisateur pourrait voler pour accéder d'une manière ou d'une autre à un dépôt.
Webhooks : Les plateformes VCS permettent de générer des webhooks. S'ils ne sont pas protégés par des secrets non visibles, un attaquant pourrait en abuser.
Si aucun secret n'est en place, l'attaquant pourrait abuser du webhook de la plateforme tierce
Si le secret est dans l'URL, la même chose se produit et l'attaquant a aussi le secret
Compromission du code : Si un acteur malveillant a un certain type d'accès en écriture sur les dépôts, il pourrait essayer d'injecter du code malveillant. Pour réussir, il pourrait avoir besoin de contourner les protections de branche. Ces actions peuvent être effectuées avec différents objectifs en tête :
Compromettre la branche principale pour compromettre la production.
Compromettre la branche principale (ou d'autres branches) pour compromettre les machines des développeurs (car ils exécutent généralement des tests, terraform ou d'autres choses à l'intérieur du dépôt sur leurs machines).
Compromettre le pipeline (voir la section suivante)
Méthodologie de Pentesting des Pipelines
La manière la plus courante de définir un pipeline est d'utiliser un fichier de configuration CI hébergé dans le dépôt que le pipeline construit. Ce fichier décrit l'ordre des tâches exécutées, les conditions qui affectent le flux et les paramètres de l'environnement de construction. Ces fichiers ont généralement un nom et un format cohérents, par exemple — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), et les fichiers YAML de GitHub Actions situés sous .github/workflows. Lorsqu'il est déclenché, le travail du pipeline récupère le code de la source sélectionnée (par exemple, commit / branche), et exécute les commandes spécifiées dans le fichier de configuration CI contre ce code.
Par conséquent, l'objectif ultime de l'attaquant est de compromettre d'une manière ou d'une autre ces fichiers de configuration ou les commandes qu'ils exécutent.
PPE - Exécution de Pipeline Empoisonné
Le chemin d'Exécution de Pipeline Empoisonné (PPE) exploite les permissions dans un dépôt SCM pour manipuler un pipeline CI et exécuter des commandes nuisibles. Les utilisateurs disposant des permissions nécessaires peuvent modifier les fichiers de configuration CI ou d'autres fichiers utilisés par le travail du pipeline pour inclure des commandes malveillantes. Cela "empoisonne" le pipeline CI, conduisant à l'exécution de ces commandes malveillantes.
Pour qu'un acteur malveillant réussisse une attaque PPE, il doit être capable de :
Avoir un accès en écriture à la plateforme VCS, car généralement les pipelines sont déclenchés lorsqu'un push ou une pull request est effectué. (Voir la méthodologie de pentesting VCS pour un résumé des moyens d'obtenir l'accès).
Notez que parfois, une PR externe compte comme un "accès en écriture".
Même s'il a des permissions d'écriture, il doit être sûr de pouvoir modifier le fichier de configuration CI ou d'autres fichiers sur lesquels la configuration repose.
Pour cela, il pourrait avoir besoin de pouvoir contourner les protections de branche.
Il existe 3 saveurs de PPE :
D-PPE : Une attaque PPE Directe se produit lorsque l'acteur modifie le fichier de configuration CI qui va être exécuté.
I-DDE : Une attaque PPE Indirecte se produit lorsque l'acteur modifie un fichier sur lequel le fichier de configuration CI qui va être exécuté repose (comme un fichier make ou une configuration terraform).
PPE Public ou 3PE : Dans certains cas, les pipelines peuvent être déclenchés par des utilisateurs qui n'ont pas d'accès en écriture dans le dépôt (et qui pourraient même ne pas faire partie de l'organisation) parce qu'ils peuvent envoyer une PR.
Injection de Commande 3PE : Habituellement, les pipelines CI/CD vont définir des variables d'environnement avec des informations sur la PR. Si cette valeur peut être contrôlée par un attaquant (comme le titre de la PR) et est utilisée dans un endroit dangereux (comme l'exécution de commandes sh), un attaquant pourrait injecter des commandes là-dedans.
Avantages de l'Exploitation
Connaissant les 3 saveurs pour empoisonner un pipeline, examinons ce qu'un attaquant pourrait obtenir après une exploitation réussie :
Secrets : Comme mentionné précédemment, les pipelines nécessitent des privilèges pour leurs tâches (récupérer le code, le construire, le déployer...) et ces privilèges sont généralement accordés dans des secrets. Ces secrets sont généralement accessibles via des variables d'environnement ou des fichiers à l'intérieur du système. Par conséquent, un attaquant essaiera toujours d'exfiltrer autant de secrets que possible.
Selon la plateforme de pipeline, l'attaquant pourrait avoir besoin de spécifier les secrets dans la configuration. Cela signifie que si l'attaquant ne peut pas modifier la configuration du pipeline CI (I-PPE par exemple), il pourrait seulement exfiltrer les secrets que ce pipeline possède.
Calcul : Le code est exécuté quelque part, selon l'endroit où il est exécuté, un attaquant pourrait être en mesure de pivoter davantage.
Sur site : Si les pipelines sont exécutés sur site, un attaquant pourrait se retrouver dans un réseau interne avec accès à plus de ressources.
Cloud : L'attaquant pourrait accéder à d'autres machines dans le cloud mais pourrait également exfiltrer des tokens de rôles IAM/comptes de service à partir de celui-ci pour obtenir un accès plus approfondi dans le cloud.
Machine de la plateforme : Parfois, les tâches seront exécutées à l'intérieur des machines de la plateforme de pipelines, qui sont généralement dans un cloud avec pas plus d'accès.
Sélectionnez-le : Parfois, la plateforme de pipelines aura configuré plusieurs machines et si vous pouvez modifier le fichier de configuration CI, vous pouvez indiquer où vous voulez exécuter le code malveillant. Dans cette situation, un attaquant exécutera probablement un shell inversé sur chaque machine possible pour essayer de l'exploiter davantage.
Compromettre la production : Si vous êtes à l'intérieur du pipeline et que la version finale est construite et déployée à partir de celui-ci, vous pourriez compromettre le code qui va finir par s'exécuter en production.
Plus d'infos pertinentes
Outils & Benchmark CIS
Chain-bench est un outil open-source pour auditer votre pile de chaîne d'approvisionnement logicielle pour la conformité à la sécurité basée sur un nouveau benchmark CIS Software Supply Chain. L'audit se concentre sur l'ensemble du processus SDLC, où il peut révéler des risques du temps de code au temps de déploiement.
Top 10 des Risques de Sécurité CI/CD
Consultez cet article intéressant sur les 10 principaux risques CI/CD selon Cider : https://www.cidersecurity.io/top-10-cicd-security-risks/
Labs
Sur chaque plateforme que vous pouvez exécuter localement, vous trouverez comment la lancer localement afin de pouvoir la configurer comme vous le souhaitez pour la tester
Gitea + Jenkins lab : https://github.com/cider-security-research/cicd-goat
Outils Automatiques
Checkov : Checkov est un outil d'analyse statique de code pour l'infrastructure en tant que code.
Références
Dernière mise à jour
