From 671b8ffbfdfef26829cb1e323259190230dc62f7 Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 27 Apr 2026 23:29:06 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-ci-cd/pentesting-ci-cd-methodology.md'] --- .../pentesting-ci-cd-methodology.md | 119 ++++++++++-------- 1 file changed, 70 insertions(+), 49 deletions(-) diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index 100aa55f6..ba8f1d29c 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 Methodology +# Mbinu ya Pentesting ya CI/CD {{#include ../banners/hacktricks-training.md}} @@ -6,51 +6,51 @@ ## VCS -VCS inamaanisha **Version Control System**, mfumo huu unawawezesha waendelezaji **kusimamia source code yao**. Ile inayotumika sana ni **git** na kawaida utapata makampuni wakitumia moja ya **platforms** zifuatazo: +VCS inasimamia **Version Control System**, mfumo huu unawawezesha wasanidi programu **kusimamia source code yao**. Ya kawaida zaidi ni **git** na kwa kawaida utaona kampuni zikikitumia kwenye mojawapo ya **platforms** zifuatazo: - Github - Gitlab - Bitbucket - Gitea - Gitblit -- Cloud providers (wanatoa VCS platforms zao wenyewe) +- Cloud providers (zinatoa VCS platforms zao wenyewe) ## CI/CD Pipelines -CI/CD pipelines zinawezesha waendelezaji **ku-automate utekelezaji wa code** kwa madhumuni mbalimbali, ikiwa ni pamoja na ku-build, ku-test, na ku-deploy applications. Hizi workflows zilizo-automated huanzishwa kwa vitendo maalum, kama vile code pushes, pull requests, au tasks zilizopangwa. Zinasaidia kurahisisha mchakato kutoka development hadi production. +CI/CD pipelines huwawezesha wasanidi programu **ku-automate utekelezaji wa code** kwa madhumuni mbalimbali, ikiwemo ku-build, ku-test, na ku-deploy applications. Workflows hizi za ki-automate **huchochewa na actions maalum**, kama vile code pushes, pull requests, au scheduled tasks. Ni muhimu kwa kurahisisha mchakato kutoka development hadi production. -Hata hivyo, systems hizi zinahitaji **kuendeshwa mahali fulani** na kawaida kwa **credentials zenye privileges ili ku-deploy code au kupata taarifa nyeti**. +Hata hivyo, mifumo hii inahitaji **kutekelezwa mahali fulani** na kwa kawaida kwa **privileged credentials ili ku-deploy code au kufikia taarifa nyeti**. ## VCS Pentesting Methodology > [!NOTE] -> 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. +> Hata kama baadhi ya VCS platforms huruhusu kuunda pipelines, kwa sehemu hii tutaangalia tu attacks zinazowezekana dhidi ya udhibiti wa source code. -Platforms ambazo zina source code ya project yako zina taarifa nyeti na watu wanapaswa kuwa waangalifu sana na permissions zinazotolewa ndani ya platform hiyo. Hizi ni baadhi ya matatizo ya kawaida kwenye VCS platforms ambayo mshambuliaji anaweza kuyatumia: +Platforms zinazohifadhi source code ya project yako zina taarifa nyeti na watu wanahitaji kuwa makini sana na permissions zinazopewa ndani ya platform hii. Haya ni baadhi ya matatizo ya kawaida kwenye VCS platforms ambayo attacker anaweza kuyatumia vibaya: -- **Leaks**: Ikiwa code yako ina leaks katika commits na mshambuliaji anaweza kufikia repo (kwa sababu ni public au kwa sababu ana access), anaweza kugundua leaks hizo. -- **Access**: Ikiwa mshambuliaji anaweza **kupata account ndani ya VCS platform** anaweza kupata **uwazi zaidi na permissions**. -- **Register**: Baadhi ya platforms zinaruhusu watumiaji wa nje tu kuunda account. -- **SSO**: Baadhi ya platforms hazitaruhusu watumiaji kujisajili, lakini zitaruhusu mtu yeyote kuingia kwa SSO halali (kwa hivyo mshambuliaji anaweza kutumia github account yake kuingia kwa mfano). -- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... kuna aina kadhaa za tokens mtumiaji anaweza kuiba ili kupata access kwa repo kwa njia fulani. -- **Webhooks**: VCS platforms zinaweza kuunda webhooks. Ikiwa hazilindwa kwa secrets ambazo hazioniwi, **mshambuliaji anaweza kuzitumia**. -- Ikiwa hakuna secret iliyowekwa, mshambuliaji anaweza kutumia webhook ya platform ya tatu -- Ikiwa secret iko kwenye URL, hivyo ndivyo na mshambuliaji pia atakuwa na secret -- **Code compromise:** Ikiwa mtu mbaya ana aina ya access ya **write** juu ya repos, anaweza kujaribu **kuingiza malicious code**. Ili kufanikiwa anaweza kuhitaji **kupitisha branch protections**. Vitendo hivi vinaweza kufanywa kwa malengo mbalimbali: -- Kufanya compromise main branch ili **kudanganya production**. -- Kufanya compromise main (au matawi mengine) ili **kudanganya machines za developers** (kwa kuwa mara nyingi wanatekeleza tests, terraform au vitu vingine ndani ya repo kwenye machines zao). -- **Compromise the pipeline** (angalia sehemu inayofuata) +- **Leaks**: Ikiwa code yako ina leaks kwenye commits na attacker anaweza kufikia repo (kwa sababu ni public au kwa sababu ana access), anaweza kugundua leaks hizo. +- **Access**: Ikiwa attacker anaweza **kufikia account ndani ya VCS platform**, anaweza kupata **mwonekano na permissions zaidi**. +- **Register**: Baadhi ya platforms huruhusu tu external users kuunda account. +- **SSO**: Baadhi ya platforms hazitaruhusu users ku-register, lakini zitamruhusu mtu yeyote kufikia kwa SSO halali (hivyo attacker anaweza kutumia github account yake kuingia, kwa mfano). +- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... kuna aina kadhaa za tokens ambazo user anaweza kuiba ili kwa namna fulani kufikia repo. +- **Webhooks**: VCS platforms huruhusu kuunda webhooks. Ikiwa hazijalindwa **kwa non visible secrets** an **attacker could abuse them**. +- Ikiwa hakuna secret imewekwa, attacker anaweza kutumia vibaya webhook ya third party platform +- Ikiwa secret ipo kwenye URL, jambo lile lile hutokea na attacker pia anapata secret +- **Code compromise:** Ikiwa malicious actor ana aina fulani ya access ya **write** kwenye repos, anaweza kujaribu **ku-inject malicious code**. Ili kufanikiwa huenda akahitaji **kupitia branch protections**. Actions hizi zinaweza kufanywa kwa malengo tofauti akilini: +- Kuharibu main branch ili **kuharibu production**. +- Kuharibu main (au branches nyingine) ili **kuharibu developer machines** (kwa kawaida hu-run test, terraform au mambo mengine ndani ya repo kwenye machines zao). +- **Kuharibu pipeline** (angalia sehemu inayofuata) ## Pipelines Pentesting Methodology -Njia ya kawaida ya kuielezea pipeline ni kwa kutumia **CI configuration file iliyohifadhiwa kwenye repository** ambayo pipeline inajenga. File hii inaeleza mfuatano wa jobs zinazotekelezwa, masharti yanayoathiri flow, na settings za build environment.\ -Files hizi kawaida zina jina na format thabiti, kwa mfano — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), na GitHub Actions YAML files ziko chini ya .github/workflows. Wakati zinapoanzishwa, pipeline job **inavuta code** kutoka kwenye source iliyochaguliwa (mfano commit / branch), na **inaendesha amri zilizobainishwa kwenye CI configuration file** dhidi ya code hiyo. +Njia ya kawaida zaidi ya kufafanua pipeline ni kwa kutumia **CI configuration file iliyohostiwa ndani ya repository** ambayo pipeline hui-build. File hii inaeleza mpangilio wa jobs zinazoendeshwa, conditions zinazobadilisha flow, na build environment settings.\ +Files hizi kwa kawaida huwa na jina na format thabiti, kwa mfano — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), na GitHub Actions YAML files zilizo chini ya .github/workflows. Inapochochewa, pipeline job **hukokota code** kutoka source iliyochaguliwa (k.m. commit / branch), na **hu-run commands zilizobainishwa kwenye CI configuration file** dhidi ya code hiyo. -Kwa hivyo lengo la mwisho la mshambuliaji ni kwa namna fulani **kuharibu configuration files** hizo au **amri wanazotekeleza**. +Kwa hiyo lengo la mwisho la attacker ni kwa namna fulani **kuharibu configuration files hizo** au **commands wanazotekeleza**. > [!TIP] -> 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: +> Baadhi ya hosted builders huwaruhusu contributors kuchagua Docker build context na Dockerfile path. Ikiwa context inadhibitiwa na attacker, unaweza kuiweka nje ya repo (k.m. "..") ili kusoma host files wakati wa build na kutoa secrets nje. Angalia: > >{{#ref}} >docker-build-context-abuse.md @@ -58,57 +58,78 @@ Kwa hivyo lengo la mwisho la mshambuliaji ni kwa namna fulani **kuharibu configu ### PPE - Poisoned Pipeline Execution -The Poisoned Pipeline Execution (PPE) path inatumia permissions katika SCM repository kuharibu CI pipeline na kuendesha amri zenye madhara. Watumiaji walio na permissions zinazohitajika wanaweza kubadilisha CI configuration files au files nyingine zinazotumika na pipeline job ili kujumuisha amri hatarishi. Hii "inafanya pipeline kuwa poisonous", ikisababisha utekelezaji wa amri hizi hatarishi. +Poisoned Pipeline Execution (PPE) hutumia permissions ndani ya SCM repository ili kubadilisha CI pipeline na kuendesha commands hatari. Users walio na permissions zinazohitajika wanaweza kurekebisha CI configuration files au files nyingine zinazotumiwa na pipeline job ili kujumuisha commands za kihalifu. Hii "huchafua" CI pipeline, na kusababisha utekelezaji wa commands hizo za kihalifu. -Ili mshambuliaji afanikiwe kufanya shambulio la PPE anatakiwa: +Ili malicious actor afanikiwe kutekeleza PPE attack anahitaji kuwa na uwezo wa: -- Kuwa na **write access kwenye VCS platform**, kwa kawaida pipelines huanzishwa wakati push au pull request inafanywa. (Angalia VCS pentesting methodology kwa muhtasari wa njia za kupata access). -- Kumbuka kwamba wakati mwingine **external PR inaweza kuhesabiwa kama "write access"**. -- Hata kama ana write permissions, anatakiwa kuhakikisha anaweza **kubadilisha CI config file au files nyingine ambazo config inategemea**. -- Kwa hili, anaweza kuhitaji kuwa anaweza **kupitisha branch protections**. +- Kuwa na **write access kwenye VCS platform**, kwa kawaida pipelines huchochewa wakati push au pull request inapofanywa. (Angalia VCS pentesting methodology kwa muhtasari wa njia za kupata access). +- Kumbuka kwamba wakati mwingine **external PR huhesabika kama "write access"**. +- Hata akiwa na write permissions, anahitaji kuhakikisha anaweza **kurekebisha CI config file au files nyingine ambazo config inategemea**. +- Kwa hili, huenda akahitaji kuwa na uwezo wa **kupitia branch protections**. -Kuna aina 3 za PPE: +Kuna flavours 3 za PPE: -- **D-PPE**: A **Direct PPE** attack hutokea wakati mshambuliaji **anabadilisha CI config** file ambayo itatekelezwa. -- **I-DDE**: An **Indirect PPE** attack hutokea wakati mshambuliaji **anabadilisha** **file** ambayo CI config inategemea (kama make file au terraform config). -- **Public PPE or 3PE**: Katika baadhi ya matukio pipelines zinaweza **kuanzishwa na watumiaji wasiokuwa na write access kwenye repo** (na ambao huenda hata sio sehemu ya org) kwa sababu wanaweza kutuma PR. -- **3PE Command Injection**: Kawaida, CI/CD pipelines zitaweka **environment variables** zenye **tafsiri kuhusu PR**. Ikiwa thamani hiyo inaweza kudhibitiwa na mshambuliaji (kama title ya PR) na inatumiwa katika sehemu hatari (kama kutekeleza **sh commands**), mshambuliaji anaweza **kuingiza amri ndani yake**. +- **D-PPE**: Attack ya **Direct PPE** hutokea wakati actor **anakibadilisha CI config** file ambacho kitaendeshwa. +- **I-DDE**: Attack ya **Indirect PPE** hutokea wakati actor **anabadilisha** **file** ambayo CI config file litakalotekelezwa **linategemea** (kama make file au terraform config). +- **Public PPE or 3PE**: Katika baadhi ya hali pipelines zinaweza **kuchochewa na users ambao hawana write access katika repo** (na ambao huenda hata si sehemu ya org) kwa sababu wanaweza kutuma PR. +- **3PE Command Injection**: Kwa kawaida, CI/CD pipelines huweka **environment variables** zenye **taarifa kuhusu PR**. Ikiwa value hiyo inaweza kudhibitiwa na attacker (kama title ya PR) na **inatumika** mahali **hatari** (kama kutekeleza **sh commands**), attacker anaweza **ku-inject commands hapo**. -### Exploitation Benefits +### Faida za Exploitation -Ukijua aina 3 za kuosha pipeline, tuchunguze kile mshambuliaji anaweza kupata baada ya exploitation yenye mafanikio: +Tukijua flavours 3 za kuharibu pipeline, tuone attacker anaweza kupata nini baada ya exploitation kufanikiwa: -- **Secrets**: Kama ilivyotajwa awali, pipelines zinahitaji **privileges** kwa jobs zao (kuvuta code, kuijenga, ku-deploy...) na privileges hizi kawaida **hutolewa kama secrets**. Secrets hizi kwa kawaida zinapatikana kupitia **env variables au files ndani ya system**. Kwa hivyo mshambuliaji ataendelea kujaribu kutoa secrets nyingi iwezekanavyo. -- Kulingana na pipeline platform mshambuliaji **anaweza kuhitaji kueleza secrets kwenye config**. Hii inamaanisha ikiwa mshambuliaji hawezi kubadilisha CI configuration pipeline (**I-PPE** kwa mfano), anaweza **kutoa tu secrets ambazo pipeline ina**. -- **Computation**: Code inaendeshwa mahali fulani, kutegemea wapi inatekelezwa mshambuliaji anaweza kuweza pivot zaidi. -- **On-Premises**: Ikiwa pipelines zinaendeshwa on premises, mshambuliaji anaweza kuingia kwenye **internal network yenye access kwa rasilimali zaidi**. -- **Cloud**: Mshambuliaji anaweza kufikia **machines nyingine katika cloud** lakini pia anaweza **kutoa** IAM roles/service accounts **tokens** kutoka humo ili kupata **access zaidi ndani ya cloud**. -- **Platforms machine**: Wakati mwingine jobs zitaendeshwa ndani ya **machines za pipelines platform**, ambazo kwa kawaida ziko ndani ya cloud na **hazina access zaidi**. -- **Select it:** Wakati mwingine **pipelines platform itakuwa ime-configure machines kadhaa** na ikiwa unaweza **kubadilisha CI configuration file** unaweza **onyesha wapi ungependa kuendesha malicious code**. Katika hali hii, mshambuliaji huenda akaendesha reverse shell kwenye kila machine inayowezekana ili kujaribu kuizidisha. -- **Compromise production**: Ukiwa ndani ya pipeline na version ya mwisho inajaribiwa na ku-deploy kutoka kwake, unaweza **kuharibu code itakayokwenda kuendesha production**. +- **Secrets**: Kama ilivyotajwa hapo awali, pipelines huhitaji **privileges** kwa jobs zake (kuchukua code, kuibuild, kuideploy...) na privileges hizi kwa kawaida **hutolewa ndani ya secrets**. Secrets hizi kwa kawaida hupatikana kupitia **env variables au files ndani ya system**. Kwa hiyo attacker atajaribu kila mara kutoa nje secrets nyingi kadiri iwezekanavyo. +- Kulingana na pipeline platform attacker **huenda akahitaji kubainisha secrets kwenye config**. Hii ina maana kwamba ikiwa attacker hawezi kurekebisha CI configuration pipeline (**I-PPE** kwa mfano), ataweza **tu kutoa nje secrets ambazo pipeline ina nazo**. +- **Computation**: Code inatekelezwa mahali fulani, kulingana na mahali inapoendeshwa attacker huenda akaweza pivot zaidi. +- **On-Premises**: Ikiwa pipelines zinatekelezwa on premises, attacker huenda akaishia kwenye **internal network yenye access zaidi ya resources**. +- **Cloud**: Attacker anaweza kufikia **other machines in the cloud** lakini pia anaweza **kutoa nje** IAM roles/service accounts **tokens** kutoka humo ili kupata **access zaidi ndani ya cloud**. +- **Platforms machine**: Wakati mwingine jobs zitaendeshwa ndani ya **machines za pipelines platform**, ambazo kwa kawaida ziko ndani ya cloud yenye **hakuna access zaidi**. +- **Select it:** Wakati mwingine **pipelines platform itakuwa imesanidi machines kadhaa** na ukiweza **kurekebisha CI configuration file** unaweza **kubainisha unapotaka kuendesha malicious code**. Katika hali hii, attacker huenda akaendesha reverse shell kwenye kila machine linalowezekana ili kujaribu kulishambulia zaidi. +- **Kuharibu production**: Ikiwa uko ndani ya pipeline na final version inajengwa na ku-deployed kutoka humo, unaweza **kuharibu code ambayo itaishia ikitekelezwa production**. -## More relevant info +### Dependency & Registry Supply-Chain Abuse + +Kuharibu CI/CD pipeline au kuiba credentials kutoka humo kunaweza kumruhusu attacker kuhama kutoka **pipeline execution** kwenda **ecosystem-wide code execution** kwa ku-backdoor dependencies au release tooling: + +- **Install-time code execution via package hooks**: publish package version linaloongeza `preinstall`, `postinstall`, `prepare`, au hooks zinazofanana ili payload iendeshwe ki-automati kwenye developer workstations na CI runners wakati wa dependency installation. +- **Secondary execution paths**: hata kama targets wan-install kwa `--ignore-scripts`, malicious package bado inaweza kusajili **common CLI name** kwenye `bin` field ili wrapper inayodhibitiwa na attacker i-symlinkwe ndani ya `PATH` na iendeshwe baadaye wakati command inapotumiwa. +- **Runtime bootstrapping**: installer ndogo inaweza kupakua second runtime au toolchain wakati wa installation (kwa mfano Bun au packed interpreter) kisha ku-launch main payload nayo, hivyo kuepuka local dependency requirements. +- **Credential harvesting from build environments**: mara code inapoendeshwa ndani ya CI, angalia environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs, na local tooling kama `gh auth token`. Kwenye GitHub Actions, pia tafuta runner-specific secrets na artifacts. +- **Workflow injection with stolen GitHub tokens**: token yenye permissions za **`repo` + `workflow`** inatosha kuunda branch, commit malicious file ndani ya `.github/workflows/`, kuichochea, kukusanya artifacts/logs zilizozalishwa, kisha kufuta temporary branch/workflow run ili kupunguza traces. +- **Wormable registry propagation**: npm tokens zilizoibiwa zinapaswa kuthibitishwa kwa permissions za **publish** na kama zinapita 2FA. Ikiwa zinapita, orodhesha packages zinazoweza kuandikwa, pakua tarballs zao, ingiza loader kama `setup.mjs`, weka `preinstall` kuitekeleza, ongeza patch version, na republish. Hii hugeuza CI compromise moja kuwa downstream auto-execution kwenye mazingira mengine. + +#### Ukaguzi wa vitendo wakati wa assessment + +- Kagua release automation kwa package-manager hooks zilizoongezwa kwenye `package.json`, unexpected `bin` entries, au version bumps zinazobadilisha tu release artifact. +- Angalia kama CI huhifadhi long-lived registry credentials kwenye plaintext files kama `~/.npmrc` badala ya kutumia short-lived OIDC au trusted publishing. +- Thibitisha kama GitHub tokens zinazopatikana ndani ya CI zinaweza kuandika workflow files au kuunda branches/tags. +- Ikiwa suspected compromised package ipo, kagua published tarball na si Git repository pekee, kwa sababu malicious loader/runtime huenda ipo tu kwenye published artifact. +- Tafuta unexpected package-manager execution ndani ya CI kama `npm install` badala ya `npm ci`, unexpected Bun downloads/execution, au workflow artifacts mpya zinazotokana na transient branches. + +## Taarifa zaidi muhimu ### Tools & CIS Benchmark -- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ni zana ya open-source ya kufanya auditing ya software supply chain stack yako kwa security compliance kulingana na mpya [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Auditing inazingatia mchakato mzima wa SDLC, ambapo inaweza kufichua hatari kutoka wakati wa code hadi wakati wa deploy. +- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ni open-source tool ya kukagua software supply chain stack yako kwa security compliance kulingana na [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf) mpya. Ukaguzi unalenga SDLC process nzima, ambapo unaweza kufichua risks kutoka code time hadi deploy time. ### Top 10 CI/CD Security Risk -Tazama makala hii ya kuvutia kuhusu top 10 CI/CD risks kulingana na Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) +Angalia article hii ya kuvutia kuhusu top 10 CI/CD risks kulingana na Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) ### Labs -- Kwenye kila platform ambayo unaweza kuendesha kwa local utapata jinsi ya kuilanzisha local ili uweze kui-configure kama unavyotaka kuijaribu +- Kwenye kila platform unayoweza kui-run locally utaona jinsi ya kui-launch locally ili uweze kui-configure unavyotaka kuitegemea katika testing - 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** ni zana ya static code analysis kwa infrastructure-as-code. +- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** ni static code analysis tool ya 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}}