From fa6a6ffe962aa566fd89d0f6da5c0b96ae7ecb7d Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 27 Apr 2026 23:29:20 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-ci-cd/pentesting-ci-cd-methodology.md'] --- .../pentesting-ci-cd-methodology.md | 117 +++++++++++------- 1 file changed, 69 insertions(+), 48 deletions(-) diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index cecdeeca6..ff06584ca 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -1,4 +1,4 @@ -# Pentesting CI/CD Metodologie +# Pentesting CI/CD Methodologie {{#include ../banners/hacktricks-training.md}} @@ -6,51 +6,51 @@ ## 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: +VCS staan vir **Version Control System**, hierdie stelsels laat ontwikkelaars toe om hul bronkode te **bestuur**. Die mees algemene een is **git** en jy sal gewoonlik maatskappye vind wat dit gebruik in een van die volgende **platforms**: - Github - Gitlab - Bitbucket - Gitea - Gitblit -- Cloud providers (hulle bied hul eie VCS-platforms aan) +- Cloud providers (they offer their own VCS platforms) ## 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. +CI/CD pipelines stel ontwikkelaars in staat om die **uitvoering van code** te **outomatiseer** vir verskeie doeleindes, insluitend die bou, toets, en ontplooiing van toepassings. Hierdie geoutomatiseerde werkvloeie word **geaktiveer deur spesifieke aksies**, soos code pushes, pull requests, of geskeduleerde take. Hulle is nuttig om die proses van ontwikkeling tot produksie te stroomlyn. -Meg diestelsels moet egter **nerens uitgevoer word** en gewoonlik met **bevoorregte credentials om kode te ontplooi of sensitiewe inligting te bereik**. +However, these systems need to be **executed somewhere** and usually with **privileged credentials to deploy code or access sensitive information**. ## 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. +> Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code. -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: +Platforms that contains the source code of your project contains sensitive information and people need to be very careful with the permissions granted inside this platform. These are some common problems across VCS platforms that attacker could abuse: -- **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) +- **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**: If an attacker can **access to an account inside the VCS platform** he could gain **more visibility and permissions**. +- **Register**: Some platforms will just allow external users to create an account. +- **SSO**: Some platforms won't allow users to register, but will allow anyone to access with a valid SSO (so an attacker could use his github account to enter for example). +- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... there are several kind of tokens a user could steal to access in some way a repo. +- **Webhooks**: VCS platforms allow to generate webhooks. If they are **not protected** with non visible secrets an **attacker could abuse them**. +- If no secret is in place, the attacker could abuse the webhook of the third party platform +- If the secret is in the URL, the same happens and the attacker also have the secret +- **Code compromise:** If a malicious actor has some kind of **write** access over the repos, he could try to **inject malicious code**. In order to be successful he might need to **bypass branch protections**. These actions can be performed with different goals in mid: +- Compromise the main branch to **compromise production**. +- Compromise the main (or other branches) to **compromise developers machines** (as they usually execute test, terraform or other things inside the repo in their machines). +- **Compromise the pipeline** (check next section) ## 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. +The most common way to define a pipeline, is by using a **CI configuration file hosted in the repository** the pipeline builds. This file describes the order of executed jobs, conditions that affect the flow, and build environment settings.\ +These files typically have a consistent name and format, for example — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), and the GitHub Actions YAML files located under .github/workflows. When triggered, the pipeline job **pulls the code** from the selected source (e.g. commit / branch), and **runs the commands specified in the CI configuration file** against that code. -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**. +Therefore the ultimate goal of the attacker is to somehow **compromise those configuration files** or the **commands they execute**. > [!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: +> Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., "..") to ingest host files during build and exfiltrate secrets. See: > >{{#ref}} >docker-build-context-abuse.md @@ -58,57 +58,78 @@ Dus is die uiteindelike doel van die aanvaller om op een of ander manier daardie ### 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. +The Poisoned Pipeline Execution (PPE) path exploits permissions in an SCM repository to manipulate a CI pipeline and execute harmful commands. Users with the necessary permissions can modify CI configuration files or other files used by the pipeline job to include malicious commands. This "poisons" the CI pipeline, leading to the execution of these malicious commands. -Vir 'n kwaadwillige akteur om suksesvol 'n PPE-aanval uit te voer, moet hy: +For a malicious actor to be successful performing a PPE attack he needs to be able to: -- 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. +- Have **write access to the VCS platform**, as usually pipelines are triggered when a push or a pull request is performed. (Check the VCS pentesting methodology for a summary of ways to get access). +- Note that sometimes an **external PR count as "write access"**. +- Even if he has write permissions, he needs to be sure he can **modify the CI config file or other files the config is relying on**. +- For this, he might need to be able to **bypass branch protections**. -Daar is 3 PPE-smake: +There are 3 PPE flavours: -- **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**. +- **D-PPE**: A **Direct PPE** attack occurs when the actor **modifies the CI config** file that is going to be executed. +- **I-DDE**: An **Indirect PPE** attack occurs when the actor **modifies** a **file** the CI config file that is going to be executed **relays on** (like a make file or a terraform config). +- **Public PPE or 3PE**: In some cases the pipelines can be **triggered by users that doesn't have write access in the repo** (and that might not even be part of the org) because they can send a PR. +- **3PE Command Injection**: Usually, CI/CD pipelines will **set environment variables** with **information about the PR**. If that value can be controlled by an attacker (like the title of the PR) and is **used** in a **dangerous place** (like executing **sh commands**), an attacker might **inject commands in there**. ### 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: +Knowing the 3 flavours to poison a pipeline, lets check what an attacker could obtain after a successful exploitation: -- **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**. +- **Secrets**: As it was mentioned previously, pipelines require **privileges** for their jobs (retrieve the code, build it, deploy it...) and this privileges are usually **granted in secrets**. These secrets are usually accessible via **env variables or files inside the system**. Therefore an attacker will always try to exfiltrate as much secrets as possible. +- Depending on the pipeline platform the attacker **might need to specify the secrets in the config**. This means that is the attacker cannot modify the CI configuration pipeline (**I-PPE** for example), he could **only exfiltrate the secrets that pipeline has**. +- **Computation**: The code is executed somewhere, depending on where is executed an attacker might be able to pivot further. +- **On-Premises**: If the pipelines are executed on premises, an attacker might end in an **internal network with access to more resources**. +- **Cloud**: The attacker could access **other machines in the cloud** but also could **exfiltrate** IAM roles/service accounts **tokens** from it to obtain **further access inside the cloud**. +- **Platforms machine**: Sometimes the jobs will be execute inside the **pipelines platform machines**, which usually are inside a cloud with **no more access**. +- **Select it:** Sometimes the **pipelines platform will have configured several machines** and if you can **modify the CI configuration file** you can **indicate where you want to run the malicious code**. In this situation, an attacker will probably run a reverse shell on each possible machine to try to exploit it further. +- **Compromise production**: If you ware inside the pipeline and the final version is built and deployed from it, you could **compromise the code that is going to end running in production**. -## Meer relevante inligting +### Dependency & Registry Supply-Chain Abuse + +Compromising a CI/CD pipeline or stealing credentials from it can let an attacker move from **pipeline execution** to **ecosystem-wide code execution** by backdooring dependencies or release tooling: + +- **Install-time code execution via package hooks**: publish a package version that adds `preinstall`, `postinstall`, `prepare`, or similar hooks so the payload runs automatically on developer workstations and CI runners during dependency installation. +- **Secondary execution paths**: even if targets install with `--ignore-scripts`, a malicious package can still register a **common CLI name** in the `bin` field so the attacker-controlled wrapper is symlinked into `PATH` and executes later when the command is used. +- **Runtime bootstrapping**: a small installer can download a second runtime or toolchain during installation (for example Bun or a packed interpreter) and then launch the main payload with it, avoiding local dependency requirements. +- **Credential harvesting from build environments**: once code runs inside CI, check environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs, and local tooling such as `gh auth token`. On GitHub Actions, also look for runner-specific secrets and artifacts. +- **Workflow injection with stolen GitHub tokens**: a token with **`repo` + `workflow`** permissions is enough to create a branch, commit a malicious file inside `.github/workflows/`, trigger it, collect the produced artifacts/logs, and then delete the temporary branch/workflow run to reduce traces. +- **Wormable registry propagation**: stolen npm tokens should be validated for **publish** permissions and whether they bypass 2FA. If they do, enumerate writable packages, download their tarballs, inject a loader such as `setup.mjs`, set `preinstall` to execute it, bump the patch version, and republish. This turns one CI compromise into downstream auto-execution in other environments. + +#### Practical checks during an assessment + +- Review release automation for package-manager hooks added to `package.json`, unexpected `bin` entries, or version bumps that only modify the release artifact. +- Check whether CI stores long-lived registry credentials in plaintext files such as `~/.npmrc` instead of using short-lived OIDC or trusted publishing. +- Verify whether GitHub tokens available in CI can write workflow files or create branches/tags. +- If a compromised package is suspected, inspect the published tarball and not only the Git repository, because the malicious loader/runtime may exist only in the published artifact. +- Hunt for unexpected package-manager execution inside CI such as `npm install` instead of `npm ci`, unexpected Bun downloads/execution, or new workflow artifacts generated from transient branches. + +## More relevant info ### 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. +- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is an open-source tool for auditing your software supply chain stack for security compliance based on a new [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). The auditing focuses on the entire SDLC process, where it can reveal risks from code time into deploy time. ### 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/) +Check this interesting article about the top 10 CI/CD risks according to 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. +- On each platform that you can run locally you will find how to launch it locally so you can configure it as you want to test it - 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. +- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** is a static code analysis tool for 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) +- [The npm Threat Landscape: Attack Surface and Mitigations](https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/) +- [Checkmarx Security Update: April 22, 2026](https://checkmarx.com/blog/checkmarx-security-update-april-22/?p=108469) {{#include ../banners/hacktricks-training.md}}