# Pentesting CI/CD Methodology

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

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

## VCS

VCS sta per **sistema di controllo versione**, questo sistema permette agli sviluppatori di **gestire il codice sorgente**. Il più comune è **git** e di solito troverai le aziende che lo usano in una delle seguenti **piattaforme**:

- Github
- Gitlab
- Bitbucket
- Gitea
- Gitblit
- Cloud providers (offrono le proprie piattaforme VCS)


## CI/CD Pipelines

CI/CD pipelines permettono agli sviluppatori di **automatizzare l'esecuzione del codice** per diversi scopi, inclusi build, test e deployment delle applicazioni. Questi workflow automatizzati sono **attivati da azioni specifiche**, come push di codice, pull request o task schedulati. Sono utili per snellire il processo dallo sviluppo alla produzione.

Tuttavia, questi sistemi devono essere **eseguiti da qualche parte** e di solito con **credenziali privilegiate per deployare codice o accedere a informazioni sensibili**.

## VCS Pentesting Methodology

> [!NOTE]
> Anche se alcune piattaforme VCS permettono di creare pipeline per questa sezione analizzeremo solo potenziali attacchi al controllo del codice sorgente.

Le piattaforme che contengono il codice sorgente del tuo progetto contengono informazioni sensibili e le persone devono essere molto attente ai permessi concessi all'interno di questa piattaforma. Questi sono alcuni problemi comuni attraverso le piattaforme VCS che un attacker potrebbe abusare:

- **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**: Se un attacker può **accedere a un account all'interno della piattaforma VCS** potrebbe ottenere **maggiore visibilità e permessi**.
- **Register**: Alcune piattaforme permettono semplicemente a utenti esterni di creare un account.
- **SSO**: Alcune piattaforme non permettono la registrazione, ma consentono a chiunque di accedere con un SSO valido (quindi un attacker potrebbe usare il suo account github per entrare, per esempio).
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... esistono diversi tipi di token che un utente potrebbe rubare per accedere in qualche modo a un repo.
- **Webhooks**: Le piattaforme VCS permettono di generare webhooks. Se non sono **protetti** con secret non visibili un **attacker potrebbe abusarne**.
- Se non è presente alcun secret, l'attacker potrebbe abusare del webhook della piattaforma di terze parti
- Se il secret è nell'URL, accade la stessa cosa e l'attacker ottiene anche il secret
- **Code compromise:** Se un actor maligno ha qualche tipo di accesso in scrittura sui repo, potrebbe provare a **iniettare codice malevolo**. Per avere successo potrebbe aver bisogno di **bypassare le protezioni dei branch**. Queste azioni possono essere compiute con diversi obiettivi:
- Compromettere il main branch per **compromettere la production**.
- Compromettere il main (o altri branch) per **compromettere le macchine degli sviluppatori** (poiché di solito eseguono test, terraform o altre cose all'interno del repo sulle loro macchine).
- **Compromettere la pipeline** (vedi sezione successiva)

## Pipelines Pentesting Methodology

Il modo più comune per definire una pipeline è tramite un **file di configurazione CI ospitato nel repository** che la pipeline builda. Questo file descrive l'ordine dei job eseguiti, le condizioni che influenzano il flusso e le impostazioni dell'ambiente di build.\
Questi file tipicamente hanno un nome e un formato consistente, per esempio — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), e i file YAML di GitHub Actions situati sotto .github/workflows. Quando viene triggerata, la job della pipeline **pulls the code** dalla source selezionata (es. commit / branch), e **esegue i comandi specificati nel CI configuration file** su quel codice.

Quindi l'obiettivo finale dell'attacker è in qualche modo **compromettere quei file di configurazione** o i **comandi che essi eseguono**.

> [!TIP]
> Alcuni hosted builders permettono ai contributor di scegliere il contesto di build Docker e il percorso del Dockerfile. Se il contesto è controllato dall'attacker, puoi impostarlo al di fuori del repo (es., "..") per ingerire file dell'host durante la build ed esfiltrare secret. Vedi:
>
>{{#ref}}
>docker-build-context-abuse.md
>{{#endref}}

### PPE - Poisoned Pipeline Execution

La Poisoned Pipeline Execution (PPE) sfrutta i permessi in un repository SCM per manipolare una CI pipeline ed eseguire comandi dannosi. Utenti con i permessi necessari possono modificare i file di configurazione CI o altri file usati dalla job di pipeline per includere comandi malevoli. Questo "avvelena" la CI pipeline, portando all'esecuzione di tali comandi malevoli.

Perché un actor maligno abbia successo eseguendo un attacco PPE deve essere in grado di:

- Avere **accesso in scrittura alla piattaforma VCS**, poiché di solito le pipeline sono triggerate quando viene effettuato un push o una pull request. (Vedi la VCS pentesting methodology per un riepilogo dei modi per ottenere accesso).
- Nota che a volte una **PR esterna conta come "accesso in scrittura"**.
- Anche se ha permessi di scrittura, deve essere sicuro di poter **modificare il CI config file o altri file su cui il config si basa**.
- Per questo, potrebbe aver bisogno di essere in grado di **bypassare le protezioni dei branch**.

Ci sono 3 varianti di PPE:

- **D-PPE**: Un attacco **Direct PPE** avviene quando l'actor **modifica il CI config** file che verrà eseguito.
- **I-DDE**: Un attacco **Indirect PPE** avviene quando l'actor **modifica** un **file** su cui il CI config che verrà eseguito **si appoggia** (come un makefile o una configurazione terraform).
- **Public PPE or 3PE**: In alcuni casi le pipeline possono essere **triggerate da utenti che non hanno accesso in scrittura nel repo** (e che potrebbero non far parte nemmeno dell'organizzazione) perché possono inviare una PR.
- **3PE Command Injection**: Di solito, CI/CD pipelines impostano **variabili d'ambiente** con **informazioni sulla PR**. Se quel valore può essere controllato da un attacker (come il titolo della PR) e viene **usato** in un **punto pericoloso** (come eseguire comandi sh), un attacker può **iniettare comandi lì dentro**.

### Exploitation Benefits

Conoscendo le 3 varianti per avvelenare una pipeline, vediamo cosa un attacker potrebbe ottenere dopo una sfruttamento riuscito:

- **Secrets**: Come menzionato in precedenza, le pipeline richiedono **privilegi** per i loro job (recuperare il codice, buildarlo, deployarlo...) e questi privilegi sono di solito **conservati in secrets**. Questi secret sono generalmente accessibili tramite **env variables o file all'interno del sistema**. Pertanto un attacker cercherà sempre di esfiltrare quanti più secret possibile.
- A seconda della piattaforma di pipeline l'attacker **potrebbe dover specificare i secret nella config**. Questo significa che se l'attacker non può modificare la pipeline CI configuration (**I-PPE** per esempio), potrebbe **esfiltrare solo i secret che quella pipeline possiede**.
- **Computation**: Il codice viene eseguito da qualche parte; a seconda di dove viene eseguito un attacker potrebbe essere in grado di pivotare ulteriormente.
- **On-Premises**: Se le pipeline sono eseguite on-premises, un attacker potrebbe trovarsi in una **rete interna con accesso a ulteriori risorse**.
- **Cloud**: L'attacker potrebbe accedere **ad altre macchine nel cloud** ma anche **esfiltrare** token di ruoli IAM/service accounts per ottenere **ulteriore accesso all'interno del cloud**.
- **Platforms machine**: A volte i job vengono eseguiti nelle **macchine della piattaforma pipelines**, che di solito sono in un cloud senza accessi aggiuntivi.
- **Select it:** A volte la **piattaforma pipeline ha configurato diverse macchine** e se puoi **modificare il CI configuration file** puoi **indicare dove vuoi far girare il codice malevolo**. In questa situazione, un attacker probabilmente eseguirà una reverse shell su ogni macchina possibile per tentare un ulteriore sfruttamento.
- **Compromise production**: Se sei all'interno della pipeline e la versione finale è buildata e deployata da essa, potresti **compromettere il codice che finirà in esecuzione in produzione**.

## More relevant info

### Tools & CIS Benchmark

- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) è uno strumento open-source per auditare la tua software supply chain stack per compliance di sicurezza basata su un nuovo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). L'audit si concentra sull'intero processo SDLC, dove può rivelare rischi dal codice fino al deploy.

### Top 10 CI/CD Security Risk

Consulta questo interessante articolo sui top 10 rischi CI/CD secondo Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)

### Labs

- Su ogni piattaforma che puoi eseguire localmente troverai come avviarla localmente così puoi configurarla come vuoi per testarla
- 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** è uno strumento di static code analysis per 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}}
