Méthodologie de Pentesting CI/CD

Reading time: 9 minutes

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

VCS

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

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

CI/CD Pipelines

Les pipelines CI/CD permettent aux développeurs d'automatiser l'exécution du code pour divers usages, notamment la compilation, les tests et le déploiement des applications. Ces workflows automatisés sont déclenchés par des actions spécifiques, comme des pushes de code, des pull requests, ou des tâches planifiées. Ils servent à rationaliser le processus 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 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, pour 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 hébergent des informations sensibles et il faut être très prudent quant aux permissions accordées au sein de cette plateforme. Voici quelques problèmes courants sur les plateformes VCS que des attaquants pourraient exploiter :

  • Leaks : Si votre code contient des leaks dans les commits et que l'attaquant peut accéder au dépôt (parce qu'il est public ou parce qu'il a accès), il pourrait découvrir les leaks.
  • Access : Si un attaquant peut accéder à un compte au sein de la plateforme VCS il pourrait obtenir plus de visibilité et de permissions.
  • Inscription : Certaines plateformes permettent simplement aux utilisateurs externes de créer un compte.
  • SSO : Certaines plateformes n'autorisent pas l'inscription, mais permettent à quiconque de se connecter avec un SSO valide (donc un attaquant pourrait utiliser par exemple son compte github pour entrer).
  • 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 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, il en va de même et l'attaquant possède aussi le secret.
  • Code compromise : Si un acteur malveillant dispose d'une forme d'accès en écriture sur les dépôts, il pourrait tenter d'injecter du code malveillant. Pour réussir, il pourrait devoir contourner les protections de branche. 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 souvent des tests, terraform ou d'autres choses depuis le dépôt sur leurs machines).
    • Compromettre le pipeline (voir section suivante)

Pipelines Pentesting Methodology

La façon 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 jobs exécutés, les conditions qui affectent le flux, et les paramètres de l'environnement de build.
Ces fichiers portent généralement un nom et un format constants, 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 ex. commit / branch), et exécute les commandes spécifiées dans le fichier de configuration CI contre ce code.

Ainsi, l'objectif ultime de l'attaquant est en quelque sorte de compro­mettre ces fichiers de configuration ou les commandes qu'ils exécutent.

tip

Certains builders hébergés laissent les contributeurs 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

La Poisoned Pipeline Execution (PPE) exploite des permissions dans un repository SCM pour manipuler un pipeline CI et exécuter des commandes malveillantes. Les utilisateurs disposant des 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 malicieuses. Cela « empoisonne » le pipeline CI, entraînant 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 lors d'un push ou d'une pull request. (Voir la méthodologie VCS pour un résumé des moyens d'obtenir un accès).
  • Noter que parfois une PR externe compte comme un "accès en écriture".
  • Même s'il dispose de permissions en écriture, il doit s'assurer qu'il peut modifier le fichier de config CI ou d'autres fichiers sur lesquels le config s'appuie.
  • Pour cela, il pourrait devoir être capable de contourner les protections de branche.

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é se repose (comme un makefile 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 d'accès en écriture au dépôt (et qui peuvent même ne pas faire partie de l'organisation) parce qu'ils peuvent envoyer une PR.
  • 3PE Command Injection : 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 (par exemple pour exécuter des commandes sh), un attaquant peut injecter des commandes.

Exploitation Benefits

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 nécessitent des privilèges pour leurs jobs (récupérer le code, le builder, le déployer...) et ces privilèges sont généralement fourni via des secrets. Ces secrets sont souvent accessibles via des env variables ou des fichiers à l'intérieur du système. Par conséquent, un attaquant cherchera toujours à exfiltrer autant de secrets que possible.
  • Selon la plateforme de pipeline, l'attaquant pourrait devoir spécifier les secrets dans la config. Cela signifie que si l'attaquant ne peut pas modifier la configuration du pipeline (I-PPE par exemple), il pourrait ne pouvoir exfiltrer que les secrets que ce pipeline possède.
  • Computation : Le code est exécuté quelque part ; selon l'endroit d'exécution, un attaquant peut être en mesure de pivoter plus loin.
  • On-Premises : Si les pipelines s'exécutent on-premises, 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 aussi pourrait exfiltrer des tokens de rôles IAM / service accounts pour obtenir un accès plus large dans le cloud.
  • Machines de la plateforme : Parfois les jobs seront exécutés à l'intérieur des machines de la plateforme de pipelines, qui sont généralement dans un cloud sans accès supplémentaire.
  • Sélectionner la cible : Parfois la plateforme de pipelines proposera plusieurs machines et si vous pouvez modifier le fichier de config CI 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 de l'exploiter davantage.
  • Compromettre la production : Si vous êtes à l'intérieur du pipeline et que la version finale est buildée et déployée à partir de celui-ci, vous pourriez compromettre le code qui sera exécuté en production.

More relevant info

Tools & CIS Benchmark

  • Chain-bench est un outil open-source pour auditer votre stack de software supply chain en matière de conformité sécurité, basé sur 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 temps du code jusqu'au déploiement.

Top 10 CI/CD Security Risk

Consultez cet article intéressant sur les top 10 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 pour infrastructure-as-code.

References

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks