# Méthodologie de Pentesting CI/CD

{{#include ../banners/hacktricks-training.md}}

<figure><img src="../images/CLOUD-logo-letters.svg" alt=""><figcaption></figcaption></figure>

## VCS

VCS signifie **Système de Contrôle de Version**, 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
- Fournisseurs de cloud (ils offrent leurs propres plateformes VCS)

## Pipelines CI/CD

Les pipelines CI/CD permettent aux développeurs d'**automatiser l'exécution du code** à diverses fins, y compris la construction, les tests et le déploiement d'applications. Ces flux de travail automatisés sont **déclenchés par des actions spécifiques**, telles que des envois de code, des demandes de tirage ou des tâches planifiées. Ils sont utiles pour 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, dans cette section, nous allons analyser uniquement les attaques potentielles sur le contrôle du code source.

Les plateformes contenant le code source de votre projet contiennent des informations sensibles et les gens doivent être très prudents avec les autorisations 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 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 d'autorisations**.
- **Enregistrement** : Certaines plateformes ne permettront qu'aux utilisateurs externes de créer un compte.
- **SSO** : Certaines plateformes ne permettront pas aux utilisateurs de 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, jetons personnels, clés ssh, jetons Oauth, cookies... il existe plusieurs types de jetons 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 a également le secret.
- **Compromission de 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 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 travaux exécutés, 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 des GitHub Actions situés sous .github/workflows. Lorsqu'il est déclenché, le travail du pipeline **tire 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 autorisations dans un dépôt SCM pour manipuler un pipeline CI et exécuter des commandes nuisibles. Les utilisateurs ayant les autorisations 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, entraînant l'exécution de ces commandes malveillantes.

Pour qu'un acteur malveillant réussisse à effectuer 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 envoi ou une demande de tirage est effectuée. (Consultez la méthodologie de pentesting VCS pour un résumé des moyens d'obtenir un accès).
- Notez que parfois une **PR externe compte comme "accès en écriture"**.
- Même s'il a des autorisations d'écriture, il doit s'assurer qu'il peut **modifier le fichier de configuration CI ou d'autres fichiers sur lesquels la configuration repose**.
- Pour cela, il pourrait avoir besoin de **contourner les protections de branche**.

Il existe 3 variantes de PPE :

- **D-PPE** : Une attaque **D-PPE directe** se produit lorsque l'acteur **modifie le fichier de configuration CI** qui va être exécuté.
- **I-DDE** : Une attaque **I-DDE indirecte** se produit lorsque l'acteur **modifie** un **fichier** sur lequel le fichier de configuration CI qui va être exécuté **s'appuie** (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) car ils peuvent envoyer une PR.
- **Injection de Commande 3PE** : En général, les pipelines CI/CD **définiront 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 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 travaux (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 le pipeline de configuration CI (**I-PPE** par exemple), il pourrait **seulement exfiltrer les secrets que ce pipeline a**.
- **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 jetons de rôles IAM/comptes de service **pour obtenir un accès supplémentaire à l'intérieur du cloud**.
- **Machines de plateforme** : Parfois, les travaux seront exécutés à l'intérieur des **machines de la plateforme des pipelines**, qui se trouvent généralement dans un cloud avec **aucun autre accès**.
- **Sélectionnez-le :** Parfois, la **plateforme des pipelines aura configuré plusieurs machines** et si vous pouvez **modifier le fichier de configuration CI**, vous pouvez **indiquer où vous souhaitez 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**.

## Informations plus pertinentes

### Outils & Benchmark CIS

- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) est un outil open-source pour auditer votre chaîne d'approvisionnement logicielle pour la conformité en matière de sécurité basé sur un nouveau [**benchmark CIS Software Supply Chain**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). L'audit se concentre sur l'ensemble du processus SDLC, où il peut révéler des risques depuis le temps de code jusqu'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/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)

### Laboratoires

- Sur chaque plateforme que vous pouvez exécuter localement, vous trouverez comment la lancer localement afin que vous puissiez la configurer comme vous le souhaitez pour la tester.
- Laboratoire Gitea + Jenkins : [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)

### Outils Automatiques

- [**Checkov**](https://github.com/bridgecrewio/checkov) : **Checkov** est un outil d'analyse de code statique pour l'infrastructure en tant que code.

## Références

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

{{#include ../banners/hacktricks-training.md}}
