Pentesting CI/CD Méthodologie

Reading time: 8 minutes

VCS

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

• Github
• Gitlab
• Bitbucket
• Gitea
• Gitblit
• Cloud providers (they offer their own VCS platforms)

CI/CD Pipelines

Les CI/CD pipelines permettent aux développeurs d'automatiser l'exécution du code pour diverses finalités : build, tests et déploiement d'applications. Ces workflows automatisés sont déclenchés par des actions spécifiques, comme des pushes, pull requests ou tâches planifiées. Ils servent à rationaliser le processus du développement vers la production.

Cependant, ces systèmes doivent être exécutés quelque part et le plus souvent avec des privileged credentials pour déployer du code ou accéder à des informations sensibles.

VCS Pentesting Methodology

Les platforms qui contiennent le source code de votre projet renferment des informations sensibles ; il faut donc être très vigilant sur les permissions accordées au sein de cette platform. Voici quelques problèmes communs sur les VCS que les attaquants peuvent exploiter :

• Leaks: If your code contains leaks in the commits and the attacker can access the repo (because it's public or because he has access), he could discover the leaks.
• Access: Si un attaquant peut accéder à un compte dans la VCS platform il peut obtenir plus de visibilité et de permissions.
• Register: Certaines platforms permettent simplement à des utilisateurs externes de créer un compte.
• SSO: Certaines platforms n'autorisent pas l'inscription, mais permettent l'accès via un SSO valide (un attaquant pourrait par exemple utiliser son compte github).
• Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... il existe plusieurs types de tokens qu'un utilisateur peut voler pour accéder d'une manière ou d'une autre à un repo.
• Webhooks: Les VCS platforms permettent de générer des webhooks. S'ils ne sont pas protégés par des secrets non visibles, un attaquant peut les abuser.
• If no secret is in place, the attacker could abuse the webhook of the third party platform
• If the secret is in the URL, the same happens and the attacker also have the secret
• Code compromise: Si un acteur malveillant dispose d'un accès en write sur les repos, il peut tenter d'injecter du code malveillant. Pour réussir, il devra parfois bypass branch protections. Ces actions peuvent viser différents objectifs :
  • 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 souvent des tests, terraform ou d'autres choses depuis le repo sur leurs machines).
  • Compromettre le pipeline (voir section suivante)

Pipelines Pentesting Methodology

La manière la plus courante de définir un pipeline est d'utiliser un CI configuration file hébergé dans le repository que le pipeline build. Ce fichier décrit l'ordre des jobs exécutés, les conditions qui affectent le flux et les settings de l'environnement de build.
Ces fichiers ont typiquement 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 pulls the code depuis la source sélectionnée (ex. commit / branch), et exécute les commandes spécifiées dans le CI configuration file contre ce code.

L'objectif ultime de l'attaquant est donc de compromettre ces fichiers de configuration ou les commandes qu'ils exécutent.

PPE - Poisoned Pipeline Execution

Le chemin Poisoned Pipeline Execution (PPE) exploite des permissions dans un SCM repository pour manipuler un CI pipeline et exécuter des commandes malveillantes. Des utilisateurs disposant des permissions nécessaires peuvent modifier les CI configuration files ou d'autres fichiers utilisés par le job du pipeline pour y inclure des commandes malveillantes. Cela "empoisonne" le CI pipeline, provoquant l'exécution de ces commandes.

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

• Avoir write access to the VCS platform, car les pipelines sont généralement déclenchés lors d'un push ou d'un pull request. (Voir la VCS pentesting methodology pour un résumé des moyens d'obtenir cet accès).
• Notez que parfois une external PR compte comme "write access".
• Même avec des permissions de write, il doit s'assurer de pouvoir modifier le CI config file ou d'autres fichiers sur lesquels le config s'appuie.
• Pour cela, il peut être nécessaire de bypass branch protections.

Il existe 3 variantes de PPE :

• D-PPE: Une attaque Direct PPE se produit lorsque l'acteur modifie le CI config file qui va être exécuté.
• I-DDE: Une attaque Indirect PPE se produit lorsque l'acteur modifie un file sur lequel le CI config file qui va être exécuté se repose (par exemple un make file ou un terraform config).
• Public PPE or 3PE: Dans certains cas, les pipelines peuvent être déclenchés par des users qui n'ont pas de write access in the repo (et qui peuvent ne même pas faire partie de l'org) parce qu'ils peuvent envoyer un PR.
• 3PE Command Injection: Habituellement, les pipelines CI/CD vont set des environment variables avec des informations sur le PR. Si cette valeur peut être contrôlée par un attaquant (comme le title du PR) et est utilisée dans un endroit dangereux (par ex. l'exécution de sh commands), un attaquant peut injecter des commandes.

Exploitation Benefits

En connaissant les 3 variantes pour empoisonner un pipeline, voyons ce qu'un attaquant peut obtenir après une exploitation réussie :

• Secrets: Comme mentionné précédemment, les pipelines requièrent des privileges pour leurs jobs (récupérer le code, le builder, le déployer...) et ces privileges sont généralement stockés dans des secrets. Ces secrets sont souvent accessibles via des env variables ou des files sur le système. Un attaquant cherchera donc à exfiltrer un maximum de secrets.
• Selon la plateforme de pipeline, l'attaquant pourrait avoir besoin de spécifier les secrets dans le config. Cela signifie que si l'attaquant ne peut pas modifier la configuration CI pipeline (I-PPE par exemple), il pourrait seulement exfiltrer les secrets que le pipeline possède.
• Computation: Le code est exécuté quelque part ; selon l'endroit d'exécution, un attaquant peut être en mesure de pivot further.
• On-Premises: Si les pipelines s'exécutent on premises, un attaquant peut se retrouver sur un réseau interne avec accès à plus de ressources.
• Cloud: L'attaquant pourrait accéder à d'autres machines dans le cloud mais aussi exfiltrer des IAM roles/service accounts tokens afin d'obtenir un accès plus large dans le cloud.
• Platforms machine: Parfois les jobs s'exécutent dans les machines de la plateforme pipelines, qui sont généralement dans un cloud et sans accès additionnel.
• Select it: Parfois la pipelines platform aura configuré plusieurs machines et si vous pouvez modifier le CI configuration file vous pouvez indiquer où vous voulez exécuter le code malveillant. Dans ce cas, un attaquant lancera probablement un reverse shell sur chaque machine possible pour tenter d'exploiter davantage.
• Compromise production: Si vous êtes dans le pipeline et que la version finale est buildée et déployée depuis celui-ci, vous pouvez compromettre le code qui finira en production.

More relevant info

Tools & CIS Benchmark

• Chain-bench est un outil open-source pour auditer votre software supply chain stack pour la conformité sécurité, basé sur un nouveau CIS Software Supply Chain benchmark. L'audit se concentre sur l'ensemble du SDLC, et peut révéler des risques depuis le code jusqu'au deploy.

Top 10 CI/CD Security Risk

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

Labs

• Sur chaque platform que vous pouvez lancer localement vous trouverez comment la démarrer localement pour la configurer comme vous le souhaitez afin de la tester
• Gitea + Jenkins lab: https://github.com/cider-security-research/cicd-goat

Automatic Tools

• Checkov: Checkov est un outil d'analyse statique pour infrastructure-as-code.

References

• https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422