# Pentesting CI/CD Methodology

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

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

## VCS

VCS significa **Version Control System**, estos sistemas permiten a los desarrolladores **gestionar su source code**. El más común es **git** y normalmente encontrarás empresas usándolo en una de las siguientes **platforms**:

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


## CI/CD Pipelines

CI/CD pipelines permiten a los desarrolladores **automatizar la ejecución del code** para varios propósitos, incluyendo build, test y deploy de aplicaciones. Estos workflows automatizados se **disparan por acciones específicas**, como code pushes, pull requests, o tareas programadas. Son útiles para optimizar el proceso desde el desarrollo hasta production.

Sin embargo, estos sistemas necesitan ser **ejecutados en algún lado** y normalmente con **credenciales privilegiadas para deploy code o acceder a información sensible**.

## VCS Pentesting Methodology

> [!NOTE]
> Incluso si algunas VCS platforms permiten crear pipelines para esta sección vamos a analizar solo ataques potenciales al control del source code.

Las platforms que contienen el source code de tu proyecto contienen información sensible y la gente debe tener mucho cuidado con los permisos otorgados dentro de esa platform. Estos son algunos problemas comunes en VCS platforms que un atacante podría abusar:

- **Leaks**: Si tu code contiene leaks en los commits y el atacante puede acceder al repo (porque es público o porque tiene acceso), podría descubrir los leaks.
- **Access**: Si un atacante puede **acceder a una cuenta dentro de la VCS platform** podría obtener **más visibilidad y permisos**.
- **Register**: Algunas platforms simplemente permiten a usuarios externos crear una cuenta.
- **SSO**: Algunas platforms no permiten registro, pero permiten que cualquiera entre con un SSO válido (por ejemplo un atacante podría usar su cuenta de github para entrar).
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... hay varios tipos de tokens que un usuario podría robar para acceder de alguna forma a un repo.
- **Webhooks**: VCS platforms permiten generar webhooks. Si no están **protegidos** con secretos no visibles un **atacante podría abusar de ellos**.
- Si no hay un secret en su lugar, el atacante podría abusar del webhook de la plataforma de terceros
- Si el secret está en la URL, sucede lo mismo y el atacante además tendría el secret
- **Code compromise:** Si un actor malicioso tiene algún tipo de **write** access sobre los repos, podría intentar **inyectar código malicioso**. Para tener éxito podría necesitar **bypassear branch protections**. Estas acciones pueden realizarse con distintos objetivos:
- Comprometer la main branch para **comprometer production**.
- Comprometer la main (u otras branches) para **comprometer las máquinas de los developers** (ya que suelen ejecutar tests, terraform u otras cosas del repo en sus máquinas).
- **Comprometer el pipeline** (revisa la siguiente sección)

## Pipelines Pentesting Methodology

La forma más común de definir un pipeline es usando un **CI configuration file alojado en el repository** que el pipeline construye. Este archivo describe el orden de los jobs ejecutados, condiciones que afectan el flujo, y la configuración del build environment.\
Estos archivos típicamente tienen un nombre y formato consistente, por ejemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), y los GitHub Actions YAML files ubicados bajo .github/workflows. Cuando se dispara, el pipeline job **pulls the code** desde la fuente seleccionada (p. ej. commit / branch), y **ejecuta los comandos especificados en el CI configuration file** contra ese code.

Por lo tanto el objetivo final del atacante es de alguna manera **comprometer esos configuration files** o los **comandos que ejecutan**.

### PPE - Poisoned Pipeline Execution

El Poisoned Pipeline Execution (PPE) explota permisos en un SCM repository para manipular un CI pipeline y ejecutar comandos dañinos. Usuarios con los permisos necesarios pueden modificar CI configuration files u otros archivos usados por el pipeline job para incluir comandos maliciosos. Esto "envenena" el CI pipeline, llevando a la ejecución de esos comandos maliciosos.

Para que un actor malicioso tenga éxito realizando un PPE necesita poder:

- Tener **write access to the VCS platform**, ya que usualmente los pipelines se disparan cuando se realiza un push o un pull request. (Revisa la VCS pentesting methodology para un resumen de maneras de obtener acceso).
- Nota que a veces un **external PR cuenta como "write access"**.
- Incluso si tiene permisos de write, necesita estar seguro de que puede **modificar el CI config file u otros archivos de los que el config depende**.
- Para esto, podría necesitar poder **bypassear branch protections**.

Hay 3 sabores de PPE:

- **D-PPE**: Un ataque **Direct PPE** ocurre cuando el actor **modifica el CI config** file que se va a ejecutar.
- **I-DDE**: Un ataque **Indirect PPE** ocurre cuando el actor **modifica** un **file** del que el CI config que se va a ejecutar **depende** (como un make file o un terraform config).
- **Public PPE or 3PE**: En algunos casos los pipelines pueden ser **triggered por users que no tienen write access en el repo** (y que quizás ni siquiera forman parte de la org) porque pueden enviar un PR.
- **3PE Command Injection**: Usualmente, CI/CD pipelines **set environment variables** con **información sobre el PR**. Si ese valor puede ser controlado por un atacante (como el title del PR) y es **usado** en un **lugar peligroso** (como ejecutar sh commands), un atacante podría **inyectar comandos ahí**.

### Exploitation Benefits

Conociendo los 3 sabores para envenenar un pipeline, veamos qué podría obtener un atacante tras una explotación exitosa:

- **Secrets**: Como se mencionó previamente, los pipelines requieren **privilegios** para sus jobs (retrieve the code, build it, deploy it...) y estos privilegios usualmente se **otorgan en secrets**. Estos secrets suelen ser accesibles vía **env variables o files dentro del sistema**. Por lo tanto un atacante siempre intentará exfiltrar la mayor cantidad de secrets posible.
- Dependiendo de la plataforma de pipeline el atacante **podría necesitar especificar los secrets en el config**. Esto significa que si el atacante no puede modificar la CI configuration pipeline (**I-PPE** por ejemplo), podría **solo exfiltrar los secrets que ese pipeline tenga**.
- **Computation**: El code se ejecuta en algún lado; dependiendo de dónde se ejecute un atacante podría pivotar más.
- **On-Premises**: Si los pipelines se ejecutan On-Premises, un atacante podría terminar en una **red interna con acceso a más recursos**.
- **Cloud**: El atacante podría acceder a **otras máquinas en la cloud** pero también podría **exfiltrar** IAM roles/service accounts **tokens** de allí para obtener **más acceso dentro del cloud**.
- **Platforms machine**: A veces los jobs se ejecutan dentro de las **máquinas de la plataforma de pipelines**, que usualmente están en una cloud sin **acceso adicional**.
- **Select it:** A veces la **platform de pipelines tendrá varias máquinas configuradas** y si puedes **modificar el CI configuration file** puedes **indicar dónde quieres ejecutar el código malicioso**. En esta situación, un atacante probablemente ejecutará un reverse shell en cada máquina posible para intentar explotarla más.
- **Compromise production**: Si estás dentro del pipeline y la versión final se builda y deploya desde ahí, podrías **comprometer el code que terminará corriendo en production**.

## More relevant info

### Tools & CIS Benchmark

- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) es una herramienta open-source para auditar tu software supply chain stack por seguridad y cumplimiento basada en un nuevo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). La auditoría se enfoca en todo el SDLC, donde puede revelar riesgos desde code time hasta deploy time.

### Top 10 CI/CD Security Risk

Revisa este artículo interesante sobre los top 10 CI/CD risks según Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)

### Labs

- En cada platform que puedas ejecutar localmente encontrarás cómo lanzarla localmente para que puedas configurarla como quieras y probarla
- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)

### Automatic Tools

- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** es una herramienta de análisis estático para 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](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}}