Méthodologie de Pentesting CI/CD

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

VCS

VCS signifie Version Control System, ce système permet aux développeurs de gérer leur code source. Le plus courant est git et vous le trouverez généralement utilisé par les entreprises sur l’une des plateformes suivantes :

  • Github
  • Gitlab
  • Bitbucket
  • Gitea
  • Gitblit
  • Cloud providers (ils proposent leurs propres plateformes VCS)

Pipelines CI/CD

Les pipelines CI/CD permettent aux développeurs d’automatiser l’exécution du code pour divers usages, notamment la construction, les tests et le déploiement d’applications. Ces workflows automatisés sont déclenchés par des actions spécifiques, comme des push de code, des pull requests ou des tâches planifiées. Ils sont utiles pour fluidifier le processus entre le développement et la production.

Cependant, ces systèmes doivent être exécutés quelque part et généralement avec des credentials privilégiés pour déployer du code ou accéder à des informations sensibles.

Méthodologie de Pentesting VCS

Note

Même si certaines plateformes VCS permettent de créer des pipelines, dans cette section nous allons analyser uniquement les attaques potentielles visant 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 dans cette plateforme. Voici quelques problèmes courants sur les plateformes VCS qu’un attaquant pourrait exploiter :

  • Leaks : Si votre code contient des leaks dans les commits et que l’attaquant peut accéder au repo (parce qu’il est public ou parce qu’il y a accès), il pourrait découvrir les leaks.
  • Access : Si un attaquant peut accéder à un compte sur la plateforme VCS, il pourrait obtenir davantage de visibilité et de permissions.
  • Register : Certaines plateformes autorisent simplement les utilisateurs externes à créer un compte.
  • SSO : Certaines plateformes n’autorisent pas l’enregistrement, mais permettent à n’importe qui d’accéder avec un SSO valide (donc un attaquant pourrait utiliser son compte github pour entrer par exemple).
  • Credentials : Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies… il existe plusieurs types de tokens qu’un utilisateur pourrait voler pour accéder d’une manière ou d’une autre à un repo.
  • 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 les exploiter.
  • Si aucun secret n’est en place, l’attaquant pourrait exploiter le webhook de la plateforme tierce
  • Si le secret est dans l’URL, le même problème se produit et l’attaquant a aussi le secret
  • Code compromise: Si un acteur malveillant dispose d’un certain type d’accès write sur les repos, il pourrait essayer d’injecter du code malveillant. Pour réussir, il pourrait devoir bypasser les branch protections. Ces actions peuvent être réalisé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 dans le repo 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 repository que le pipeline construit. Ce fichier décrit l’ordre des jobs exécutés, les conditions qui influencent le flux, ainsi que les paramètres de l’environnement de build.
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 GitHub Actions situés sous .github/workflows. Lorsqu’il est déclenché, le job du pipeline récupère le code depuis la source sélectionnée (par exemple le commit / la branche), et exécute les commandes spécifiées dans le fichier de configuration CI sur ce code.

Par conséquent, l’objectif ultime de l’attaquant est d’une manière ou d’une autre compromettre ces fichiers de configuration ou les commandes qu’ils exécutent.

Tip

Certains builders hébergés permettent aux contributeurs de choisir le Docker build context et le chemin du Dockerfile. Si le context est contrôlé par l’attaquant, vous pouvez le définir en dehors du repo (par exemple, “..”) pour ingérer des fichiers de l’hôte pendant le build et exfiltrer des secrets. Voir :

{{#ref}} docker-build-context-abuse.md {{#endref}}

PPE - Poisoned Pipeline Execution

Le chemin Poisoned Pipeline Execution (PPE) exploite les permissions dans un repository SCM pour manipuler un pipeline CI et exécuter des commandes malveillantes. Les utilisateurs ayant les permissions nécessaires peuvent modifier les fichiers de configuration CI ou d’autres fichiers utilisés par le job du pipeline pour y inclure des commandes malveillantes. Cela “empoisonne” le pipeline CI, ce qui conduit à l’exécution de ces commandes malveillantes.

Pour qu’un acteur malveillant réussisse une attaque PPE, il doit être capable de :

  • Avoir un write access à la plateforme VCS, car généralement les pipelines sont déclenchés lors d’un push ou d’une pull request. (Voir la méthodologie de pentesting VCS pour un résumé des moyens d’obtenir l’accès).
  • Noter qu’une external PR peut parfois compter comme un “write access”.
  • Même s’il a des permissions de write, il doit s’assurer de pouvoir modifier le fichier de config CI ou d’autres fichiers sur lesquels la config s’appuie.
  • Pour cela, il peut avoir besoin de pouvoir bypasser les branch protections.

Il existe 3 variantes de PPE :

  • D-PPE : Une attaque Direct PPE se produit lorsque l’acteur modifie le fichier de config CI qui va être exécuté.
  • I-DDE : Une attaque Indirect PPE se produit lorsque l’acteur modifie un fichier sur lequel le fichier de config CI qui va être exécuté s’appuie (comme un make file ou une config terraform).
  • Public PPE or 3PE : Dans certains cas, les pipelines peuvent être déclenchés par des utilisateurs qui n’ont pas de write access dans le repo (et qui ne font même pas forcément partie de l’org) parce qu’ils peuvent envoyer une PR.
  • 3PE Command Injection : En général, les pipelines CI/CD vont définir des variables d’environnement contenant 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 à un endroit dangereux (comme l’exécution de commandes sh), un attaquant peut y injecter des commandes.

Bénéfices de l’exploitation

En connaissant les 3 variantes pour empoisonner un pipeline, voyons 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 jobs (récupérer le code, le builder, le déployer…). Ces privilèges sont généralement accordés via des secrets. Ces secrets sont généralement accessibles via des variables d’env ou des fichiers dans le système. Par conséquent, un attaquant essaiera toujours d’exfiltrer autant de secrets que possible.
  • Selon la plateforme du pipeline, l’attaquant pourrait devoir spécifier les secrets dans la config. Cela signifie que si l’attaquant ne peut pas modifier la configuration CI du pipeline (I-PPE par exemple), il pourrait seulement exfiltrer les secrets que ce pipeline possède.
  • Computation : Le code est exécuté quelque part ; selon l’endroit, un attaquant pourrait être en mesure de pivoter davantage.
  • On-Premises : Si les pipelines sont exécutés on premises, un attaquant pourrait se retrouver dans un réseau interne avec accès à davantage de ressources.
  • Cloud : L’attaquant pourrait accéder à d’autres machines dans le cloud mais pourrait aussi exfiltrer des tokens IAM roles/service accounts à partir de celles-ci pour obtenir un accès supplémentaire dans le cloud.
  • Platforms machine : Parfois, les jobs seront exécutés sur les machines de la plateforme des pipelines, qui se trouvent généralement dans un cloud avec pas plus d’accès.
  • Select it: Parfois, la plateforme des 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 lancera probablement un reverse shell sur chaque machine possible pour essayer d’aller plus loin.
  • Compromise production : Si vous êtes dans le pipeline et que la version finale en est construite puis déployée, vous pourriez compromettre le code qui va finir par s’exécuter en production.

Dependency & Registry Supply-Chain Abuse

Compromettre un pipeline CI/CD ou lui voler des credentials peut permettre à un attaquant de passer de l’exécution dans le pipeline à une exécution de code à l’échelle de l’écosystème en backdoorant des dépendances ou des outils de release :

  • Install-time code execution via package hooks : publier une version de package qui ajoute preinstall, postinstall, prepare, ou des hooks similaires afin que le payload s’exécute automatiquement sur les postes des développeurs et sur les runners CI pendant l’installation des dépendances.
  • Secondary execution paths : même si les cibles installent avec --ignore-scripts, un package malveillant peut toujours enregistrer un nom de CLI courant dans le champ bin afin que le wrapper contrôlé par l’attaquant soit symlinked dans PATH et s’exécute plus tard lorsque la commande est utilisée.
  • Runtime bootstrapping : un petit installer peut télécharger un second runtime ou toolchain pendant l’installation (par exemple Bun ou un interpreter packé) puis lancer le payload principal avec celui-ci, évitant ainsi les dépendances locales requises.
  • Credential harvesting from build environments : une fois le code exécuté dans CI, vérifiez les variables d’environnement, ~/.npmrc, ~/.git-credentials, les clés SSH, les configs des cloud CLIs et les outils locaux comme gh auth token. Sur GitHub Actions, recherchez aussi les secrets et artifacts spécifiques au runner.
  • Workflow injection with stolen GitHub tokens : un token avec les permissions repo + workflow suffit pour créer une branche, commit un fichier malveillant dans .github/workflows/, le déclencher, collecter les artifacts/logs produits, puis supprimer la branche temporaire / le workflow run pour réduire les traces.
  • Wormable registry propagation : les tokens npm volés doivent être validés pour les permissions publish et pour vérifier s’ils contournent la 2FA. Si oui, énumérez les packages modifiables, téléchargez leurs tarballs, injectez un loader comme setup.mjs, définissez preinstall pour l’exécuter, augmentez la version patch, puis republiez. Cela transforme une compromission CI en auto-exécution en aval dans d’autres environnements.

Vérifications pratiques pendant une assessment

  • Passez en revue l’automatisation de release pour détecter des hooks de package-manager ajoutés à package.json, des entrées bin inattendues, ou des bumps de version qui ne modifient que l’artifact de release.
  • Vérifiez si CI stocke des credentials de registry longue durée dans des fichiers en clair comme ~/.npmrc au lieu d’utiliser des OIDC à courte durée ou trusted publishing.
  • Vérifiez si les tokens GitHub disponibles dans CI peuvent écrire des fichiers workflow ou créer des branches/tags.
  • Si un package compromis est suspecté, inspectez le tarball publié et pas seulement le Git repository, car le loader/runtime malveillant peut exister uniquement dans l’artifact publié.
  • Cherchez une exécution inattendue de package-manager dans CI comme npm install au lieu de npm ci, des téléchargements/exécutions Bun inattendus, ou de nouveaux artifacts de workflow générés à partir de branches transitoires.

Plus d’infos pertinentes

Tools & CIS Benchmark

  • Chain-bench est un outil open-source pour auditer la sécurité de votre supply chain logicielle selon un nouveau CIS Software Supply Chain benchmark. L’audit se concentre sur l’ensemble du processus SDLC, où il peut révéler des risques depuis le code time jusqu’au deploy time.

Top 10 CI/CD Security Risk

Consultez cet article intéressant sur les 10 principaux risques CI/CD selon Cider : https://www.cidersecurity.io/top-10-cicd-security-risks/

Labs

Automatic Tools

  • Checkov: Checkov est un outil d’analyse statique de code pour l’infrastructure-as-code.

References

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks