mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-04-28 12:03:08 -07:00
Translated ['', 'src/pentesting-ci-cd/pentesting-ci-cd-methodology.md']
This commit is contained in:
@@ -1,4 +1,4 @@
|
||||
# Pentesting CI/CD Metodologija
|
||||
# Pentesting CI/CD Methodology
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -6,51 +6,51 @@
|
||||
|
||||
## VCS
|
||||
|
||||
VCS означава **Version Control System**, овај систем омогућава програмерима да **управљају својим source code-ом**. Најчешћи је **git** и обично ћете фирме наћи да га користе на једној од следећих **платформи**:
|
||||
VCS znači **Version Control System**, ovaj systems omogućava developerima da **upravljaju svojim source code**. Najčešći je **git** i obično ćete naći kompanije koje ga koriste na jednoj od sledećih **platforms**:
|
||||
|
||||
- Github
|
||||
- Gitlab
|
||||
- Bitbucket
|
||||
- Gitea
|
||||
- Gitblit
|
||||
- Cloud providers (они нуде своје VCS платформе)
|
||||
- Cloud providers (they offer their own VCS platforms)
|
||||
|
||||
|
||||
## CI/CD Pipelines
|
||||
|
||||
CI/CD pipelines омогућавају програмерима да **аутоматизују извршавање code-а** у разне сврхе, укључујући build, testing и deploy апликација. Ови аутоматизовани токови рада се **активирају специфичним акцијама**, као што су пушеви у репо (push), pull requests или заказани задаци. Они помажу да се процес од development-а до production-а поједностави.
|
||||
CI/CD pipelines omogućavaju developerima da **automatizuju izvršavanje koda** za razne svrhe, uključujući build, testiranje i deployment aplikacija. Ovi automatizovani workflows se **pokreću određenim akcijama**, kao što su code push, pull requests ili zakazani tasks. Korisni su za pojednostavljivanje procesa od development do production.
|
||||
|
||||
Међутим, ти системи морају да се **извршавају негде** и обично то радију са **повлашћеним credentials-има да би деплојовали code или приступили осетљивим информацијама**.
|
||||
Međutim, ovi sistemi moraju da se **izvrše negde** i obično sa **privileged credentials** za deploy koda ili pristup sensitive information.
|
||||
|
||||
## VCS Pentesting Methodology
|
||||
|
||||
> [!NOTE]
|
||||
> Чак и ако неке VCS платформе дозвољавају креирање pipelines, за овај одељак ћемо анализирати само потенцијалне нападе на контролу source code-а.
|
||||
> Čak i ako neke VCS platforms omogućavaju kreiranje pipelines za ovaj section, ovde ćemo analizirati samo potencijalne napade na control source code.
|
||||
|
||||
Платформе које чувају source code вашег пројекта садрже осетљиве информације и људи морају бити веома опрезни са дозволама које дају унутар те платформе. Ово су неки уобичајени проблеми на VCS платформама које нападач може злоупотребити:
|
||||
Platforms koje sadrže source code vašeg projekta sadrže sensitive information i ljudi moraju biti veoma pažljivi sa permissions dodeljenim unutar ove platforme. Ovo su neki česti problemi širom VCS platforms koje attacker može abuse:
|
||||
|
||||
- **Leaks**: Ако ваш code садржи leaks у commit-овима и нападач може приступити repo-у (јер је public или зато што има приступ), може открити leaks.
|
||||
- **Access**: Ако нападач може да **приступи налогу на VCS платформи** могао би добити **већу видљивост и дозволе**.
|
||||
- **Register**: Неке платформе ће једноставно дозволити спољним корисницима да креирају налог.
|
||||
- **SSO**: Неке платформе неће дозволити регистровање корисника, али ће дозволити било коме да уђе са валидним SSO (на пример нападач може користити свој github налог да уђе).
|
||||
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... постоји више врста token-а које корисник може украсти да би на неки начин приступио repo-у.
|
||||
- **Webhooks**: VCS платформе омогућавају генерисање webhooks. Ако нису **заштићени** са невиђеним secrets нападач их може злоупотребити.
|
||||
- Ако нема секрета на месту, нападач може злоупотребити webhook треће стране платформе
|
||||
- Ако је secret у URL-у, исто се дешава и нападач има тај secret
|
||||
- **Code compromise:** Ако злонамерни актер има неки ниво **write** приступа над репо-овима, могао би покушати да **инјектује злонамерни код**. Да би био успешан можда ће морати да **заобиђе branch protections**. Ове акције се могу извршити са различитим циљевима:
|
||||
- Компромитовати main branch да **компромитује production**.
|
||||
- Компромитовати main (или друге brancheve) да **компромитује developer-ске машине** (јер они обично извршавају тестове, terraform или друге ствари из repo-а на својим машинама).
|
||||
- **Compromise the pipeline** (погледај следећи одељак)
|
||||
- **Leaks**: Ako vaš code sadrži leaks u commits i attacker može da pristupi repo (jer je javni ili zato što ima pristup), može otkriti leaks.
|
||||
- **Access**: Ako attacker može da **pristupi accountu unutar VCS platforme** može steći **više visibility i permissions**.
|
||||
- **Register**: Neke platforms će jednostavno dozvoliti external users da kreiraju account.
|
||||
- **SSO**: Neke platforms neće dozvoliti korisnicima da se registruju, ali će dozvoliti bilo kome da pristupi sa validnim SSO (tako da attacker može, na primer, da iskoristi svoj github account za ulaz).
|
||||
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... postoji nekoliko vrsta tokens koje user može ukrasti da bi na neki način pristupio repo.
|
||||
- **Webhooks**: VCS platforms dozvoljavaju generisanje webhooks. Ako nisu **protected** sa nevidljivim secrets, **attacker could abuse them**.
|
||||
- Ako nema secret, attacker može abuse webhook treće party platforme
|
||||
- Ako je secret u URL-u, isto se dešava i attacker takođe ima secret
|
||||
- **Code compromise:** Ako malicious actor ima neku vrstu **write** access nad repos, može pokušati da **inject malicious code**. Da bi uspeo, možda će morati da **bypass branch protections**. Ove akcije mogu se izvesti sa različitim ciljevima na umu:
|
||||
- Compromise main branch da bi se **compromise production**.
|
||||
- Compromise main (ili druge branches) da bi se **compromise developers machines** (jer oni obično izvršavaju test, terraform ili druge stvari unutar repo na svojim mašinama).
|
||||
- **Compromise the pipeline** (check next section)
|
||||
|
||||
## Pipelines Pentesting Methodology
|
||||
|
||||
Најчешћи начин да се дефинише pipeline је коришћењем **CI configuration file-а који се налази у repository-ју** који pipeline гради. Тај фајл описује редослед извршених job-ова, услове који утичу на ток и подешавања build окружења.\
|
||||
Ови фајлови обично имају конзистентно име и формат, на пример — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), и GitHub Actions YAML фајлови смештени под .github/workflows. Када се активира, pipeline job **повлачи code** из изабраног извора (нпр. commit / branch), и **извршава наредбе наведене у CI configuration фајлу** против тог code-а.
|
||||
Najčešći način definisanja pipeline-a je korišćenjem **CI configuration file hosted in the repository** koji pipeline build-a. Ovaj fajl opisuje redosled izvršenih jobs, uslove koji utiču na flow i build environment settings.\
|
||||
Ovi fajlovi obično imaju dosledan naziv i format, na primer — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), i GitHub Actions YAML fajlove smeštene pod .github/workflows. Kada se pokrene, pipeline job **pulls the code** iz izabranog source (npr. commit / branch), i **runs the commands specified in the CI configuration file** nad tim code.
|
||||
|
||||
Дакле, крајњи циљ нападача је на неки начин **компромитовати те configuration фајлове** или **наредбе које они извршавају**.
|
||||
Dakle, krajnji cilj attacker-a je da na neki način **compromise those configuration files** ili **commands they execute**.
|
||||
|
||||
> [!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:
|
||||
> Neki hosted builders omogućavaju contributor-ima da izaberu Docker build context i Dockerfile path. Ako je context attacker-controlled, možete ga postaviti van repo (npr. "..") da bi se tokom build-a učitali host fajlovi i exfiltrate secrets. Pogledajte:
|
||||
>
|
||||
>{{#ref}}
|
||||
>docker-build-context-abuse.md
|
||||
@@ -58,57 +58,78 @@ CI/CD pipelines омогућавају програмерима да **ауто
|
||||
|
||||
### PPE - Poisoned Pipeline Execution
|
||||
|
||||
Poisoned Pipeline Execution (PPE) пут експлоатише дозволе у SCM repository-ју да манипулише CI pipeline-ом и изврши штетне наредбе. Корисници са неопходним дозволама могу модификовати CI configuration фајлове или друге фајлове које pipeline job користи да укључе злонамерне наредбе. Ово „поји“ CI pipeline, што доводи до извршавања тих злонамерних наредби.
|
||||
Poisoned Pipeline Execution (PPE) path abuse permissions u SCM repository da bi manipulisao CI pipeline-om i izvršavao harmful commands. Users sa potrebnim permissions mogu modifikovati CI configuration files ili druge fajlove koje pipeline job koristi da uključe malicious commands. Ovo "poisons" CI pipeline, što vodi do izvršavanja ovih malicious commands.
|
||||
|
||||
Да би злонамерни актер био успешан у PPE нападу, мора:
|
||||
Da bi malicious actor bio uspešan u PPE attack-u, mora da može da:
|
||||
|
||||
- Имати **write access на VCS платформи**, јер се pipeline-ови обично активирају када се уради push или pull request. (Погледај VCS pentesting methodology за резиме начина добијања приступа).
|
||||
- Имајте на уму да понекад један **external PR може се сматрати "write access"**.
|
||||
- Чак и ако има write permission-e, мора бити сигуран да може **модификовати CI config file или друге фајлове на које config зависи**.
|
||||
- За ово може бити потребно да **заобиђе branch protections**.
|
||||
- Ima **write access to the VCS platform**, jer se pipelines obično pokreću kada se izvrši push ili pull request. (Pogledajte VCS pentesting methodology za pregled načina za dobijanje access.)
|
||||
- Napomena da se ponekad **external PR count as "write access"**.
|
||||
- Čak i ako ima write permissions, mora da bude siguran da može da **modify the CI config file or other files the config is relying on**.
|
||||
- Za ovo, možda će morati da može da **bypass branch protections**.
|
||||
|
||||
Постоје 3 PPE варијанте:
|
||||
Postoje 3 PPE varijante:
|
||||
|
||||
- **D-PPE**: Direct PPE напад се дешава када актер **модификује CI config** фајл који ће бити извршен.
|
||||
- **I-DDE**: Indirect PPE напад се дешава када актер **модификује** неки **фајл** на који CI config фајл који ће бити извршен **зависи** (нпр. make file или terraform конфигурацију).
|
||||
- **Public PPE or 3PE**: У неким случајевима pipeline-ови могу бити **активирани од корисника који немају write access у repo-у** (и који можда чак нису ни део организације) јер могу послати PR.
|
||||
- **3PE Command Injection**: Обично, CI/CD pipeline-ови ће **постављати environment variables** са **информацијама о PR-у**. Ако та вредност може бити контролисана од стране нападача (нпр. title of the PR) и **користи се** на **опасном месту** (нпр. извршавање sh commands), нападач може **инјектовати команде у њега**.
|
||||
- **D-PPE**: **Direct PPE** attack se dešava kada actor **modifies the CI config** fajl koji će biti izvršen.
|
||||
- **I-DDE**: **Indirect PPE** attack se dešava kada actor **modifies** a **file** na koji se CI config file koji će biti izvršen **relays on** (kao make file ili terraform config).
|
||||
- **Public PPE or 3PE**: U nekim slučajevima pipelines mogu biti **triggered by users that doesn't have write access in the repo** (i možda čak nisu deo org) jer mogu da pošalju PR.
|
||||
- **3PE Command Injection**: Obično će CI/CD pipelines **set environment variables** sa **information about the PR**. Ako attacker može da kontroliše tu vrednost (kao title of the PR) i ako se **used** na **dangerous place** (kao izvršavanje **sh commands**), attacker može **inject commands in there**.
|
||||
|
||||
### Exploitation Benefits
|
||||
|
||||
Познавање 3 варијанте пута да се poisoning pipeline омогућава преглед шта нападач може да добије након успешне експлоатације:
|
||||
Znajući 3 varijante za poison pipeline, pogledajmo šta attacker može da dobije nakon uspešne exploitation:
|
||||
|
||||
- **Secrets**: Као што је поменуто раније, pipeline-ови захтевају **повластице** за своје job-ове (повлачење code-а, build, deploy...) и те повластице су обично **чуване у secrets-има**. Ови secrets су обично приступачни преко **env variables или фајлова у систему**. Стога ће нападач увек покушати да извуче што више secrets-а.
|
||||
- У зависности од pipeline платформе нападач **можда мора да наведе secrets у config-у**. То значи да ако нападач не може да промени CI configuration pipeline-а (**I-PPE** на пример), он може **само исксфилтровати secrets које тај pipeline има**.
|
||||
- **Computation**: Code се извршава негде; у зависности где се извршава, нападач може да се помери даље.
|
||||
- **On-Premises**: Ако се pipeline-ови извршавају on-premises, нападач може завршити у **интерној мрежи са приступом више ресурса**.
|
||||
- **Cloud**: Нападач може приступити **другим машинама у cloud-у** али такође може **извести** IAM roles/service accounts токене из њега да би добио **даљи приступ у облаку**.
|
||||
- **Platforms machine**: Понекад job-ови ће се извршавати на **машинама платформе за pipeline-ове**, које обично налазе у cloud-у са **нема додатног приступа**.
|
||||
- **Select it:** Понекад **pipeline платформа има конфигурисане неколико машина** и ако можете **модификовати CI configuration file** можете **навести где желите да покренете злонамерни code**. У таквој ситуацији, нападач ће вероватно покренути reverse shell на свакој могућој машини да покуша да даље експлоатише.
|
||||
- **Compromise production**: Ако сте у pipeline-у и коначна верзија се гради и деплојује из ње, можете **компромитовати code који ће се наћи у production-у**.
|
||||
- **Secrets**: Kao što je ranije pomenuto, pipelines zahtevaju **privileges** za svoje jobs (preuzimanje code, build, deploy...) i ovi privileges su obično **granted in secrets**. Ovi secrets su obično dostupni preko **env variables ili fajlova unutar system**. Zato će attacker uvek pokušati da exfiltrate što više secrets.
|
||||
- U zavisnosti od pipeline platforme attacker **might need to specify the secrets in the config**. To znači da, ako attacker ne može da modifikuje CI configuration pipeline (**I-PPE** na primer), može **samo exfiltrate the secrets that pipeline has**.
|
||||
- **Computation**: Code se izvršava negde, i u zavisnosti od toga gde se izvršava attacker možda može dalje da pivot.
|
||||
- **On-Premises**: Ako se pipelines izvršavaju on premises, attacker može završiti u **internal network with access to more resources**.
|
||||
- **Cloud**: Attacker može pristupiti **other machines in the cloud** ali takođe može **exfiltrate** IAM roles/service accounts **tokens** sa njih da bi dobio **further access inside the cloud**.
|
||||
- **Platforms machine**: Ponekad će se jobs izvršavati unutar **pipelines platform machines**, koje su obično unutar cloud sa **no more access**.
|
||||
- **Select it:** Ponekad će **pipelines platform will have configured several machines** i ako možete da **modify the CI configuration file** možete **indicate where you want to run the malicious code**. U ovoj situaciji, attacker će verovatno pokrenuti reverse shell na svakoj mogućoj mašini da bi pokušao dalje exploitation.
|
||||
- **Compromise production**: Ako ste unutar pipeline-a i finalna verzija se odatle build-a i deploy-a, mogli biste da **compromise the code that is going to end running in production**.
|
||||
|
||||
### Dependency & Registry Supply-Chain Abuse
|
||||
|
||||
Compromising CI/CD pipeline ili krađa credentials iz njega može omogućiti attacker-u da pređe sa **pipeline execution** na **ecosystem-wide code execution** backdooring dependencies ili release tooling:
|
||||
|
||||
- **Install-time code execution via package hooks**: publish package version koja dodaje `preinstall`, `postinstall`, `prepare` ili slične hooks tako da payload radi automatski na developer workstations i CI runners tokom dependency installation.
|
||||
- **Secondary execution paths**: čak i ako targets instaliraju sa `--ignore-scripts`, malicious package i dalje može registrovati **common CLI name** u `bin` field tako da attacker-controlled wrapper bude symlinked u `PATH` i kasnije se izvrši kada se command koristi.
|
||||
- **Runtime bootstrapping**: mali installer može da preuzme drugi runtime ili toolchain tokom installation (na primer Bun ili packed interpreter) i zatim pokrene main payload sa njim, izbegavajući lokalne dependency requirements.
|
||||
- **Credential harvesting from build environments**: jednom kada code radi unutar CI, proverite environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs i lokalne tooling kao `gh auth token`. Na GitHub Actions, takođe tražite runner-specific secrets i artifacts.
|
||||
- **Workflow injection with stolen GitHub tokens**: token sa **`repo` + `workflow`** permissions je dovoljan da kreira branch, commit malicious file unutar `.github/workflows/`, triggeruje ga, prikupi proizvedene artifacts/logs, a zatim obriše privremeni branch/workflow run da smanji traces.
|
||||
- **Wormable registry propagation**: stolen npm tokens treba validirati za **publish** permissions i da li zaobilaze 2FA. Ako da, enumerišite writable packages, preuzmite njihove tarballs, inject loader kao `setup.mjs`, postavite `preinstall` da ga izvrši, povećajte patch version i republish. Ovo pretvara jedan CI compromise u downstream auto-execution u drugim environments.
|
||||
|
||||
#### Practical checks during an assessment
|
||||
|
||||
- Pregledajte release automation za package-manager hooks dodate u `package.json`, neočekivane `bin` entries, ili version bumps koji menjaju samo release artifact.
|
||||
- Proverite da li CI čuva long-lived registry credentials u plaintext fajlovima kao `~/.npmrc` umesto da koristi short-lived OIDC ili trusted publishing.
|
||||
- Verifikujte da li GitHub tokens dostupni u CI mogu da pišu workflow fajlove ili kreiraju branches/tags.
|
||||
- Ako se sumnja na compromised package, pregledajte published tarball a ne samo Git repository, jer malicious loader/runtime može postojati samo u published artifact.
|
||||
- Tražite neočekivano package-manager izvršavanje unutar CI kao što je `npm install` umesto `npm ci`, neočekivane Bun downloads/execution, ili nove workflow artifacts generisane iz transient branches.
|
||||
|
||||
## More relevant info
|
||||
|
||||
### Tools & CIS Benchmark
|
||||
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) је open-source алат за аудиторске провере вашег software supply chain стека у смислу сигурности, базиран на новом [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Аудит се фокусира на цео SDLC процес, где може открити ризике од code-а до deploy-а.
|
||||
- [**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
|
||||
|
||||
Погледајте овај занимљив чланак о top 10 CI/CD ризицима према 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
|
||||
|
||||
- На свакој платформи коју можете покренути локално наћи ћете упутство како да је покренете локално да је конфигуришете по вољи за тестирање
|
||||
- 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** је static code analysis алат за 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}}
|
||||
|
||||
Reference in New Issue
Block a user