# Pentesting CI/CD Metodologie

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

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

## VCS

VCS staan vir Version Control System; hierdie stelsels laat ontwikkelaars toe om hul bronkode te bestuur. Die mees algemene is **git** en jy sal gewoonlik maatskappye vind wat dit op een van die volgende **platforms** gebruik:

- Github
- Gitlab
- Bitbucket
- Gitea
- Gitblit
- Cloud providers (hulle bied hul eie VCS-platforms aan)


## CI/CD Pipelines

CI/CD pipelines maak dit vir ontwikkelaars moontlik om die uitvoering van kode te **outomatiseer** vir verskeie doeleindes, insluitend bou, toetsing en ontplooiing van toepassings. Hierdie geoutomatiseerde workflows word **getrigger deur spesifieke aksies**, soos code pushes, pull requests of geskeduleerde take. Hulle help om die proses van ontwikkeling na produksie te stroomlyn.

Meg diestelsels moet egter **nerens uitgevoer word** en gewoonlik met **bevoorregte credentials om kode te ontplooi of sensitiewe inligting te bereik**.

## VCS Pentesting Methodology

> [!NOTE]
> Selfs al laat sommige VCS-platforms toe om pipelines te skep, gaan ons in hierdie afdeling slegs potensiële aanvalle op die beheer van die bronkode ontleed.

Platforms wat die bronkode van jou projek bevat, hou sensitiewe inligting en mense moet baie versigtig wees met die permissies wat binne daardie platform gegee word. Dit is sommige algemene probleme oor VCS-platforms wat 'n aanvaller kan misbruik:

- **Leaks**: As jou kode leaks in die commits bevat en die aanvaller toegang tot die repo het (omdat dit publiek is of omdat hy toegang het), kan hy die leaks ontdek.
- **Access**: As 'n aanvaller toegang tot 'n rekening binne die VCS-platform kry, kan hy **meer sigbaarheid en permissies** bekom.
- **Register**: Sommige platforms sal net buitegebruikers toelaat om 'n rekening te skep.
- **SSO**: Sommige platforms sal nie gebruikers toelaat om te registreer nie, maar sal enigiemand toelaat om met 'n geldige SSO in te gaan (so 'n aanvaller kan byvoorbeeld sy github-rekening gebruik om in te gaan).
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... daar is verskeie soorte tokens wat 'n gebruiker kan steel om op een of ander manier toegang tot 'n repo te kry.
- **Webhooks**: VCS-platforms laat toe om webhooks te genereer. As hulle **nie beskerm** is met nie-sigbare secrets nie, kan 'n **aanvaller hulle misbruik**.
- As geen geheim ingestel is nie, kan die aanvaller die webhook van die derdeparty-platform misbruik.
- As die geheim in die URL is, gebeur dieselfde en die aanvaller het ook die geheim.
- **Code compromise:** As 'n kwaadwillige akteur 'n soort **skryf** toegang oor die repos het, kan hy probeer om **kwaadaardige kode in te voeg**. Om suksesvol te wees mag hy die **branch protections** moet omseil. Hierdie aksies kan vir verskeie doelwitte uitgevoer word:
  - Kompromitteer die main branch om **produksie te kompromitteer**.
  - Kompromitteer die main (of ander branches) om **ontwikkelaars se masjiene te kompromitteer** (aangesien hulle gewoonlik teste, terraform of ander dinge binne die repo op hul masjiene uitvoer).
  - **Compromise the pipeline** (kyk volgende afdeling)

## Pipelines Pentesting Methodology

Die mees algemene manier om 'n pipeline te definieer, is deur gebruik te maak van 'n **CI configuration file gehost in die repository** wat die pipeline bou. Hierdie lêer beskryf die volgorde van uitgevoerde jobs, voorwaardes wat die vloei beïnvloed, en build-omgewinginstellings.\
Hierdie lêers het tipies 'n konsekwente naam en formaat, byvoorbeeld — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), en die GitHub Actions YAML-lêers onder .github/workflows. Wanneer dit getrigger word, **pulls die pipeline job die kode** van die gekose bron (bv. commit / branch), en **voer die opdragte wat in die CI-konfigurasielêer gespesifiseer is** teen daardie kode uit.

Dus is die uiteindelike doel van die aanvaller om op een of ander manier daardie konfigurasielêers of die opdragte wat hulle uitvoer, te **kompromitteer**.

> [!TIP]
> Sommige gehoste builders laat contributors toe om die Docker build context en Dockerfile path te kies. As die context deur die aanvaller beheer word, kan jy dit buite die repo stel (bv. "..") om host-lêers tydens build in te neem en secrets te eksfiltreer. Sien:
>
>{{#ref}}
>docker-build-context-abuse.md
>{{#endref}}

### PPE - Poisoned Pipeline Execution

Die Poisoned Pipeline Execution (PPE) path misbruik permissies in 'n SCM repository om 'n CI pipeline te manipuleer en kwaadaardige opdragte uit te voer. Gebruikers met die nodige permissies kan CI-konfigurasielêers of ander lêers wat deur die pipeline job gebruik word, wysig om kwaadwillige opdragte in te sluit. Dit "vergiftig" die CI-pipeline, wat lei tot die uitvoering van hierdie kwaadwillige opdragte.

Vir 'n kwaadwillige akteur om suksesvol 'n PPE-aanval uit te voer, moet hy:

- Heb **write access to the VCS platform**, aangesien pipelines gewoonlik getrigger word wanneer 'n push of 'n pull request uitgevoer word. (Kyk die VCS pentesting methodology vir 'n samevatting van maniere om toegang te kry).
- Let daarop dat soms 'n **external PR as "write access" tel**.
- Selfs as hy write-permissies het, moet hy seker wees dat hy die **CI config file of ander lêers waarop die config staatmaak** kan wysig.
- Hiervoor mag hy die **branch protections** moet kan omseil.

Daar is 3 PPE-smake:

- **D-PPE**: 'n **Direct PPE** aanval vind plaas wanneer die akteur die **CI config** lêer wysig wat uitgevoer gaan word.
- **I-DDE**: 'n **Indirect PPE** aanval gebeur wanneer die akteur 'n **lêer** wysig waarop die CI config lêer wat uitgevoer gaan word **berus** (soos 'n make-lêer of 'n terraform-konfig).
- **Public PPE or 3PE**: In sommige gevalle kan pipelines **getrigger word deur gebruikers wat nie write access in die repo het nie** (en wat dalk nie eers deel van die org is nie) omdat hulle 'n PR kan stuur.
- **3PE Command Injection**: Gewoonlik stel CI/CD pipelines **environment variables** met **inligting oor die PR**. As daardie waarde deur 'n aanvaller beheer kan word (soos die titel van die PR) en dit in 'n **gevaarlike plek** gebruik word (soos die uitvoering van **sh commands**), kan 'n aanvaller **opdragte daarin injekteer**.

### Exploitation Benefits

Deur die 3 smake om 'n pipeline te vergiftig te ken, kom ons kyk wat 'n aanvaller na 'n suksesvolle uitbuiting kan bekom:

- **Secrets**: Soos vroeër genoem, vereis pipelines **bevoegdhede** vir hul jobs (haal die kode, bou dit, ontplooi dit ...) en hierdie bevoegdhede word gewoonlik in **secrets** gehou. Hierdie secrets is gewoonlik toeganklik via **env variables of lêers binne die stelsel**. Daarom sal 'n aanvaller altyd probeer om soveel secrets as moontlik te eksfiltreer.
- Afhangend van die pipeline platform mag die aanvaller **die secrets in die config moet spesifiseer**. Dit beteken as die aanvaller nie die CI-konfigurasielêer kan wysig nie (**I-PPE** byvoorbeeld), kan hy **slegs die secrets eksfiltreer wat daardie pipeline het**.
- **Computation**: Die kode word êrens uitgevoer; afhangend van waar dit uitgevoer word, mag 'n aanvaller verder kan pivot.
- **On-Premises**: As die pipelines on-premises uitgevoer word, kan 'n aanvaller in 'n **interne netwerk met toegang tot meer hulpbronne** beland.
- **Cloud**: Die aanvaller kan toegang tot **ander masjiene in die cloud** kry, maar ook IAM roles/service accounts **tokens** daaruit eksfiltreer om **verdere toegang in die cloud** te verkry.
- **Platforms machine**: Soms word die jobs binne die **pipelines platform machines** uitgevoer, wat gewoonlik in 'n cloud is met **geen verdere toegang**.
- **Select it:** Soms het die **pipelines platform verskeie masjiene geconfigureer** en as jy die **CI config file** kan wysig, kan jy **aandui waar jy die kwaadwillige kode wil laat loop**. In daardie situasie sal 'n aanvaller waarskynlik 'n reverse shell op elke moontlike masjien laat loop om dit verder te probeer uitbuit.
- **Compromise production**: As jy binne die pipeline is en die finale weergawe daargebou en ontplooi word, kan jy die **kode wat in produksie gaan loop compromise**.

## Meer relevante inligting

### Tools & CIS Benchmark

- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is 'n open-source tool vir die ouditering van jou software supply chain stack vir sekuriteitskompliance gebaseer op 'n nuwe [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Die oudit fokus op die hele SDLC-proses, waar dit risiko's van code-time tot deploy-time kan onthul.

### Top 10 CI/CD Security Risk

Kyk hierdie interessante artikel oor die top 10 CI/CD risiko's volgens Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)

### Labs

- Op elke platform wat jy lokaal kan laat loop, sal jy instruksies vind oor hoe om dit plaaslik te begin sodat jy dit kan konfigureer soos jy wil om dit te toets.
- 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** is 'n static code analysis tool vir 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}}