Translated ['src/pentesting-ci-cd/pentesting-ci-cd-methodology.md', 'src

This commit is contained in:
Translator
2026-07-06 15:54:39 +00:00
parent 5ba2f9072e
commit b6847ac3f6
2 changed files with 283 additions and 63 deletions
+219
View File
@@ -0,0 +1,219 @@
# Argo CD Security
{{#include ../banners/hacktricks-training.md}}
## Osnovne informacije
[Argo CD](https://argo-cd.readthedocs.io/) je GitOps platforma za kontinuiranu isporuku za Kubernetes. Ona prati Git repozitorijume, renderuje Kubernetes manifeste pomoću alata kao što su Helm, Kustomize, Jsonnet ili config management plugins, i usklađuje trenutno stanje clustera sa željenim stanjem sačuvanim u Git-u.
Iz perspektive napadača, tretirajte Argo CD kao **deployment engine sa Kubernetes credentials**. Korisna kompromitacija Argo CD-a može dovesti do:
- Pristupa privatnim Git repozitorijumima i credentials za repozitorijume.
- Pristupa Kubernetes cluster secrets koje koristi Argo CD.
- Izvršavanja koda za generisanje manifesta u `argocd-repo-server`.
- Neovlašćenog deployment-a Kubernetes objekata kroz pouzdane Git repozitorijume, Argo CD aplikacije ili manipulaciju cache-om.
## Arhitektura i interesantne komponente
Uobičajeni Kubernetes objekti i servisi:
```bash
kubectl get pods,svc,endpoints,ingress -A | grep -iE 'argocd|argo-cd'
kubectl get applications,appprojects,applicationsets -A 2>/dev/null
kubectl get secrets,configmaps -n argocd 2>/dev/null
kubectl get networkpolicy -n argocd 2>/dev/null
```
Zanimljive usluge:
- **`argocd-server`**: javni API, web UI, CLI API, autentikacija i autorizacija.
- **`argocd-application-controller`**: poredi željeno i aktivno stanje, zatim primenjuje resurse na Kubernetes.
- **`argocd-repo-server`**: klonira repozitorijume, kešira Git podatke i pokreće Helm/Kustomize/Jsonnet/plugins za generisanje manifesta. Podrazumevani gRPC port je **8081**.
- **`argocd-redis`**: keš za application, manifest i Git reference podatke. Podrazumevani Redis port je **6379**.
- **`argocd-applicationset-controller`**: generiše Argo CD `Application` objekte iz generatora kao što su Git, SCM, clusters i pull requests.
Iz kompromitovanog pod-a ili internog network segmenta, proverite internu dostupnost:
```bash
nc -vz <argocd-server> 443
nc -vz <argocd-repo-server> 8081
nc -vz <argocd-redis> 6379
```
## Public API / UI Attacks
Ako imate Argo CD credentials ili exposed instancu, počnite sa normalnom API površinom:
```bash
argocd login <argocd-server>
argocd account get-user-info
argocd account list
argocd proj list
argocd app list
argocd repo list
argocd cluster list
argocd admin settings rbac can <subject> <action> <resource> <object>
```
Korisne attack paths:
- **Application write access**: izmeni `source.repoURL`, `source.path`, Helm values, Kustomize options, plugin settings ili sync options tako da Argo CD deploy-uje manifests pod kontrolom napadača.
- **Project misconfiguration**: `AppProject` objekti mogu dozvoliti široke `sourceRepos`, široke `destinations`, nesigurne `clusterResourceWhitelist` ili slabe namespace restrikcije.
- **Repository credential abuse**: repository secrets, GitHub App credentials, SSH keys i tokens mogu omogućiti push u trusted repos ili dodavanje malicious dependencies.
- **Cluster credential abuse**: cluster secrets mogu sadržati bearer tokens ili exec-provider configuration koje Argo CD koristi za deploy u target clusters.
- **Local admin / project tokens**: dugotrajni Argo CD tokens mogu se ponovo koristiti kroz API osim ako nisu revoked ili expired.
Enumeriši configuration iz Kubernetes kada imaš cluster read access:
```bash
kubectl get applications.argoproj.io -A -o yaml
kubectl get appprojects.argoproj.io -A -o yaml
kubectl get applicationsets.argoproj.io -A -o yaml
kubectl get secrets -n argocd -o yaml | grep -nE 'repoURL|sshPrivateKey|password|bearerToken|githubApp|tlsClientCertData|tlsClientCertKey'
kubectl get cm -n argocd argocd-cm argocd-rbac-cm argocd-cmd-params-cm -o yaml
```
## Trusted Git Repository Abuse
Ako možete da push-ujete u repository kome Argo CD veruje, obično možete uticati na to šta se deploy-uje. Uticaj zavisi od granica `AppProject` i permissions service account-a koje koristi application controller.
Uobičajene lokacije za payload:
- Raw Kubernetes YAML unutar application path-a.
- Helm chart templates i `values.yaml`.
- Kustomize overlays, remote bases i generators.
- Jsonnet ili input za config management plugin.
- ApplicationSet generator files koji kreiraju ili ažuriraju `Application` objects.
Proverite da li app koristi automated sync, pruning, self-heal, sync windows ili manual approvals:
```bash
kubectl get applications.argoproj.io -A \
-o custom-columns='NS:.metadata.namespace,APP:.metadata.name,PROJECT:.spec.project,AUTOSYNC:.spec.syncPolicy.automated,REPO:.spec.source.repoURL,PATH:.spec.source.path,DEST:.spec.destination.server'
```
## Direktna zloupotreba `argocd-repo-server`
Ne pretpostavljajte da je javni Argo CD API jedina attack surface. Interni Argo CD komponente komuniciraju sa `argocd-repo-server` preko gRPC. Ako arbitrary pods mogu da dosegnu repo-server, attacker-controlled interni requests mogu da zaobiđu provere koje normalno sprovodi `argocd-server`.
Praktične provere:
```bash
kubectl get svc -n argocd argocd-repo-server -o yaml
kubectl get endpoints -n argocd argocd-repo-server -o wide
nc -vz <argocd-repo-server> 8081
```
Zanimljivi znaci:
- `repo-server` gRPC endpoint je dostupan sa non-Argo CD podova.
- `NetworkPolicies` nedostaju ili dozvoljavaju samo allow-list egress bez deny-ing ingress.
- `repo-server` ima pristup custom config management plugins, decryption tools, ili repository content od više tenant-a.
- Redis je dostupan sa non-Argo CD podova, što omogućava inspection ili tampering cache-a ako su credentials dostupni ili nisu potrebni.
## Unauthenticated Repo-Server RCE via Kustomize Options
U julu 2026, Synacktiv je objavio unauthenticated code execution chain u Argo CD `repo-server` kada attacker može da dosegne interni gRPC servis. Napad zloupotrebljava direct access na `/repository.RepoServerService/GenerateManifest` i attacker-controlled `KustomizeOptions`.
Opasna primitive je forsiranje `repo-server` da clone-uje attacker-controlled repository content i pokrene Kustomize sa Helm support:
```bash
kustomize build <attacker_repo_path> --enable-helm --helm-command ./payload.sh
```
Minimalni malicious Kustomize ulaz treba da pokrene Helm obradu:
```yaml
helmCharts:
- name: pwn
version: 0.0.1
```
Zašto ovo radi:
- `argocd-repo-server` klonira repository pre renderovanja.
- `--helm-command ./payload.sh` se rešava relativno u odnosu na klonirani repository.
- Code execution ne zahteva shell metacharacter injection ako napadač može da kontroliše rendered repository i Kustomize build options.
U vreme Synacktiv-ovog otkrivanja 1. jula 2026, prijavili su da issue nema official fix niti CVE. Ovo prvo tretirajte kao network-exposure issue: exploitation zahteva dostupnost internog repo-server gRPC porta.
## Redis Cache Poisoning za Deploy Manifests
Nakon code execution u `argocd-repo-server`, ili nakon direktnog pristupa Redis-u sa validnim credentials, pregledajte Redis-backed cache entries. Argo CD obično čuva gzip-compressed JSON values.
Zanimljivi key prefixes:
```text
mfst|... # cached rendered manifests
git-refs|... # Git branch/ref to commit mappings
app|... # application resource/cache data
cluster|... # cluster cache information
```
Napad trovanja cache-a opisan od strane Synacktiv zloupotrebljava dve stavke stanja:
1. Izmeni odgovarajući `mfst|...` cache entry manifesta tako da uključi Kubernetes manifest pod kontrolom napadača.
2. Izmeni povezani `git-refs|...` mapping tako da Argo CD poveruje da se branch pomerio, a zatim se reconciles nazad na cached revision.
Uticaj:
- Sa uključenim Auto Sync, Argo CD može automatski da primeni poisoned cached manifest.
- Bez Auto Sync, payload se i dalje može primeniti kada korisnik ručno sync-uje aplikaciju.
- Konačni uticaj je ograničen destination-om ciljne aplikacije i Kubernetes permissions dostupnim Argo CD-u.
## ApplicationSet Attacks
ApplicationSet je posebno osetljiv jer kreira ili ažurira `Application` objekte na osnovu generator output-a.
Review:
```bash
kubectl get applicationsets.argoproj.io -A -o yaml
kubectl get appprojects.argoproj.io -A -o yaml
```
Zanimljivi obrasci:
- Git generators koji čitaju fajlove koje napadač može da menja i koji kontrolišu nazive aplikacija, paths, projekte ili destinacije.
- Pull request generators za javne repozitorijume gde nepouzdani saradnici mogu da utiču na generisane aplikacije.
- Template fields koji dozvoljavaju široke destination cluster/namespace.
- AppProjects koji dozvoljavaju `sourceRepos: ["*"]` ili široke `destinations`.
- Generisane aplikacije koje nasleđuju automated sync i pruning.
## Post-Exploitation
Iz Argo CD pod shell-a, prioriteti su:
```bash
env
cat /proc/1/environ 2>/dev/null | tr '\0' '\n'
find /var/run/secrets /app/config -type f -maxdepth 4 2>/dev/null
mount | grep -E 'secret|token|config'
```
Korisni ciljevi:
- Ukrasti `REDIS_PASSWORD` ili Redis TLS/client materijal.
- Izvući kredencijale repozitorijuma iz mounted secrets ili Argo CD Kubernetes secrets.
- Identifikovati cluster kredencijale koje koristi Argo CD.
- Čitati generisane manifests i output pluginova koji mogu sadržati injected secrets.
- Proveriti da li custom plugins, SOPS, Helm secrets, Vault plugins ili cloud CLIs otkrivaju decryption keys i cloud kredencijale.
## Detection & Hardening
Važne provere:
- Ograničiti `argocd-repo-server` port **8081** i Redis port **6379** sa NetworkPolicies tako da im mogu pristupiti samo očekivane Argo CD komponente.
- U Helm deploymentima proveriti da li su network policies zaista kreirane. Argo CD Helm chart values su istorijski podrazumevano imali isključeno kreiranje component network policy-ja.
- Držati `argocd-server` kao autentifikovani ulazni punkt. Interni servisi ne bi smeli biti dostupni proizvoljnim workload-ovima.
- Isključiti neiskorišćene config management alate i pluginove.
- Ograničiti `AppProject` `sourceRepos`, `destinations`, namespace permissions i cluster-scoped resources.
- Izbegavati čuvanje širokih repository kredencijala tamo gde low-privileged Argo CD user može da izazove njihovu ponovnu upotrebu.
- Nadzirati repo-server zahteve, Kustomize build options, plugin izvršavanja, Redis writes i neočekivan pristup `mfst|` / `git-refs|` ključevima.
- Rotirati Argo CD local users, project tokens, repository kredencijale i cluster kredencijale nakon compromise.
Korisne komande:
```bash
kubectl get networkpolicy -n argocd
kubectl get networkpolicy -A | grep -i argocd
kubectl describe networkpolicy -n argocd argocd-repo-server-network-policy 2>/dev/null
kubectl describe networkpolicy -n argocd argocd-redis-network-policy 2>/dev/null
```
## Static Analysis Note: Typed API Requests in CodeQL
Za Go services koji koriste gRPC/REST handlers, podrazumevani CodeQL remote sources mogu propustiti flows kada se raw input jednom unmarshaluje u typed request objects. Koristan model za Argo CD-style services je:
- Receiver type kao `Server` ili `Service`.
- Prvi parameter je `context.Context`.
- Drugi parameter je typed request object.
Modeluj taj drugi parameter kao remote source i dodaj custom sinks za `exec.Command` / `exec.CommandContext` arguments. Ovo pomaže da se pronađu flows od internih API request fields do command execution helpers.
## References
- [Synacktiv - Caught in the Octopus Trap: Unauthenticated RCE in Argo CD with CodeQL](https://www.synacktiv.com/en/publications/caught-in-the-octopus-trap-unauthenticated-rce-in-argo-cd-with-codeql)
- [Argo CD docs - Security considerations](https://argo-cd.readthedocs.io/en/stable/operator-manual/security/)
- [Argo CD docs - High Availability](https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/)
- [Argo CD docs - repo-server command reference](https://argo-cd.readthedocs.io/en/stable/operator-manual/server-commands/argocd-repo-server/)
- [Argo CD - repo-server NetworkPolicy manifest](https://github.com/argoproj/argo-cd/blob/master/manifests/base/repo-server/argocd-repo-server-network-policy.yaml)
- [Argo CD docs - metrics](https://argo-cd.readthedocs.io/en/latest/operator-manual/metrics/)
- [Argo Helm - chart values reference](https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/README.md)
- [Kustomize - Helm chart generator example](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md)
@@ -1,4 +1,4 @@
# Metodologija pentesting CI/CD
# Pentesting CI/CD Metodologija
{{#include ../banners/hacktricks-training.md}}
@@ -6,51 +6,51 @@
## VCS
VCS znači **Version Control System**, ovi sistemi omogućavaju developerima da **upravljaju svojim source code-om**. Najčešći je **git** i kompanije ga obično koriste na jednoj od sledećih **platformi**:
VCS je skraćenica za **Version Control System**, ovaj sistem omogućava developerima da **upravljaju svojim source code-om**. Najčešći je **git** i kompanije ga obično koriste na jednoj od sledećih **platformi**:
- Github
- Gitlab
- Bitbucket
- Gitea
- Gitblit
- Cloud providers (they offer their own VCS platforms)
- Cloud providers (oni nude sopstvene VCS platforme)
## CI/CD Pipelines
CI/CD pipelines omogućavaju developerima da **automatizuju izvršavanje code-a** za različite svrhe, uključujući buildovanje, testiranje i deploy aplikacija. Ovi automatizovani workflow-ovi se **pokreću određenim radnjama**, kao što su code push, pull request-ovi ili zakazani zadaci. Korisni su za pojednostavljivanje procesa od developmenta do production.
CI/CD pipelines omogućavaju developerima da **automatizuju izvršavanje code-a** za različite svrhe, uključujući build, testiranje i deploy aplikacija. Ovi automatizovani workflow-ovi se **aktiviraju određenim akcijama**, kao što su code push-ovi, pull requests ili zakazani zadaci. Korisni su za pojednostavljivanje procesa od developmenta do production.
Međutim, ovi sistemi moraju da se **izvršavaju negde** i obično sa **privilegovanih credentials** za deploy code-a ili pristup osetljivim informacijama.
Međutim, ovi sistemi moraju negde da se **izvršavaju** i obično sa **privileged credentials** za deploy code-a ili pristup osetljivim informacijama.
## VCS Pentesting Metodologija
> [!NOTE]
> Čak i ako neke VCS platforme omogućavaju kreiranje pipelines za ovaj odeljak analiziraćemo samo potencijalne napade na kontrolu source code-a.
> Čak i ako neke VCS platforme omogućavaju kreiranje pipeline-ova, za ovaj deo ćemo analizirati samo potencijalne napade na kontrolu source code-a.
Platforme koje sadrže source code vašeg projekta sadrže osetljive informacije i ljudi moraju biti veoma pažljivi sa permissions dodeljenim unutar ove platforme. Ovo su neki česti problemi na VCS platformama koje napadač može zloupotrebiti:
Platforme koje sadrže source code vašeg projekta sadrže osetljive informacije i ljudi moraju biti veoma oprezni sa dozvolama koje se dodeljuju unutar ove platforme. Ovo su neki česti problemi na VCS platformama koje attacker može da zloupotrebi:
- **Leaks**: Ako vaš code sadrži leaks u commits i napadač može da pristupi repo-u (zato što je javni ili zato što ima pristup), on može otkriti leaks.
- **Access**: Ako napadač može da **pristupi account-u unutar VCS platforme** može dobiti **više vidljivosti i permissions**.
- **Register**: Neke platforme će jednostavno omogućiti eksternim korisnicima da naprave account.
- **SSO**: Neke platforme neće dozvoliti korisnicima da se registruju, ali će dozvoliti bilo kome pristup sa validnim SSO (tako da napadač može, na primer, da koristi svoj github account da uđe).
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... postoji više vrsta tokena koje korisnik može ukrasti da bi na neki način pristupio repo-u.
- **Webhooks**: VCS platforme omogućavaju generisanje webhooks. Ako nisu **zaštićeni** nevidljivim secrets, **napadač ih može zloupotrebiti**.
- Ako nema postavljenog secret-a, napadač može zloupotrebiti webhook treće strane platforme
- Ako je secret u URL-u, dešava se isto i napadač takođe ima secret
- **Code compromise:** Ako zlonamerni akter ima neki oblik **write** access-a nad repo-ima, može pokušati da **ubaci zlonamerni code**. Da bi bio uspešan možda će morati da **zaobiđe branch protections**. Ove akcije mogu se izvesti sa različitim ciljevima:
- **Leaks**: Ako vaš code sadrži leaks u commit-ovima i attacker može da pristupi repo-u (zato što je javni ili zato što ima pristup), može da otkrije leaks.
- **Access**: Ako attacker može da **pristupi nalogu unutar VCS platforme**, može da dobije **više vidljivosti i permisija**.
- **Register**: Neke platforme će jednostavno dozvoliti eksternim korisnicima da kreiraju nalog.
- **SSO**: Neke platforme neće dozvoliti korisnicima da se registruju, ali će dozvoliti bilo kome da pristupi uz validan SSO (pa attacker može, na primer, da iskoristi svoj github nalog da uđe).
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... postoji nekoliko vrsta tokena koje korisnik može ukrasti da bi na neki način pristupio repo-u.
- **Webhooks**: VCS platforme omogućavaju generisanje webhooks. Ako nisu **zaštićeni** nevidljivim secret-ovima, **attacker može da ih zloupotrebi**.
- Ako secret nije postavljen, attacker može da zloupotrebi webhook treće strane platforme
- Ako je secret u URL-u, dešava se isto i attacker takođe ima secret
- **Code compromise:** Ako malicious actor ima neku vrstu **write** pristupa repo-ima, može da pokuša da **inject malicious code**. Da bi bio uspešan, možda će morati da **bypass branch protections**. Ove akcije se mogu izvršiti sa različitim ciljevima:
- Kompromitovati main branch da bi se **kompromitovao production**.
- Kompromitovati main (ili druge branches) da bi se **kompromitovale developer mašine** (pošto one obično izvršavaju test, terraform ili druge stvari unutar repo-a na svojim mašinama).
- Kompromitovati main (ili druge branch-eve) da bi se **kompromitovale developers machines** (jer obično pokreću test, terraform ili druge stvari unutar repo-a na svojim mašinama).
- **Compromise the pipeline** (check next section)
## Metodologija pentesting pipelines
## Pipelines Pentesting Metodologija
Najčešći način da se definiše pipeline je korišćenjem **CI configuration file-a hostovanog u repo-u** koji pipeline builduje. Ovaj fajl opisuje redosled izvršenih jobs, uslove koji utiču na flow i settings build okruženja.\
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 koji se nalaze pod .github/workflows. Kada se pokrene, pipeline job **preuzima code** iz odabranog source-a (npr. commit / branch) i **izvršava commands navedene u CI configuration file-u** nad tim code-om.
Najčešći način da se definiše pipeline jeste korišćenjem **CI configuration file-a hostovanog u repository-u** koji pipeline build-uje. Ovaj file opisuje redosled izvršenih job-ova, uslove koji utiču na flow i podešavanja build environment-a.\
Ovi file-ovi obično imaju dosledan naziv i format, na primer — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) i GitHub Actions YAML file-ovi smešteni pod .github/workflows. Kada se aktivira, pipeline job **povuče code** iz odabranog source-a (npr. commit / branch) i **pokrene komande navedene u CI configuration file-u** nad tim code-om.
Zato je krajnji cilj napadača da nekako **kompromituje te configuration file-ove** ili **commands koje izvršavaju**.
Zato je krajnji cilj attackera da na neki način **kompromituje te configuration file-ove** ili **komande koje oni izvršavaju**.
> [!TIP]
> Neki hosted builders dozvoljavaju contributor-ima da izaberu Docker build context i putanju do Dockerfile-a. Ako je context pod kontrolom napadača, možete ga postaviti van repo-a (npr. "..") da biste tokom build-a učitali host fajlove i izneli secrets. Pogledajte:
> Neki hosted builder-i dopuštaju contributor-ima da izaberu Docker build context i putanju do Dockerfile-a. Ako je context pod kontrolom attackera, možete ga postaviti van repo-a (npr. "..") da biste tokom build-a učitali host fajlove i exfiltrirali secrets. Vidite:
>
>{{#ref}}
>docker-build-context-abuse.md
@@ -58,72 +58,73 @@ Zato je krajnji cilj napadača da nekako **kompromituje te configuration file-ov
### PPE - Poisoned Pipeline Execution
Put Poisoned Pipeline Execution (PPE) koristi permissions u SCM repo-u da manipuliše CI pipeline-om i izvrši štetne commands. Korisnici sa potrebnim permissions mogu da menjaju CI configuration file-ove ili druge fajlove koje pipeline job koristi kako bi ubacili zlonamerne commands. Ovo "truје" CI pipeline, što dovodi do izvršavanja tih zlonamernih commands.
Putanja Poisoned Pipeline Execution (PPE) zloupotrebljava permisije u SCM repository-ju da bi manipulisala CI pipeline-om i izvršila štetne komande. Korisnici sa potrebnim permisijama mogu da menjaju CI configuration file-ove ili druge file-ove koje pipeline job koristi kako bi ubacili malicious commands. Ovo "truје" CI pipeline, što dovodi do izvršavanja tih malicious commands.
Da bi napadač bio uspešan pri izvođenju PPE napada, mora da može da:
Da bi malicious actor bio uspešan u PPE napadu, mora da može da:
- Ima **write access** na VCS platformi, jer se pipelines obično pokreću kada se izvrši push ili pull request. (Pogledajte VCS pentesting metodologiju za sažetak načina da se dobije pristup).
- Napomena: ponekad se **eksterni PR računa kao "write access"**.
- Čak i ako ima write permissions, mora biti siguran da može da **modifikuje CI config file ili druge fajlove na koje config zavisi**.
- Za to će možda morati da može da **zaobiđe branch protections**.
- Ima **write access** na VCS platformu, jer se pipeline-ovi obično aktiviraju kada se izvrši push ili pull request. (Pogledajte VCS pentesting metodologiju za pregled načina za dobijanje pristupa).
- Imajte na umu da ponekad **external PR važi kao "write access"**.
- Čak i ako ima write permisije, mora biti siguran da može da **izmeni CI config file ili druge file-ove na koje se config oslanja**.
- Za to, možda će morati da može da **bypass branch protections**.
Postoje 3 PPE varijante:
- **D-PPE**: **Direct PPE** napad se dešava kada akter **izmeni CI config** fajl koji će biti izvršen.
- **I-DDE**: **Indirect PPE** napad se dešava kada akter **izmeni** **fajl** na koji CI config fajl koji će biti izvršen **se oslanja** (kao što je make fajl ili terraform config).
- **Public PPE or 3PE**: U nekim slučajevima pipelines mogu biti **pokrenuti od strane korisnika koji nema write access na repo-u** (a možda čak nije ni deo org) zato što može da pošalje PR.
- **3PE Command Injection**: Obično će CI/CD pipelines **postavljati environment variables** sa **informacijama o PR-u**. Ako napadač može da kontroliše tu vrednost (kao što je naslov PR-a) i ona se **koristi** na **opasnom mestu** (kao što je izvršavanje **sh commands**), napadač može da **ubrizga commands** tu.
- **D-PPE**: **Direct PPE** napad se dešava kada actor **izmeni CI config** file koji će biti izvršen.
- **I-DDE**: **Indirect PPE** napad se dešava kada actor **izmeni** **file** na koji se CI config file koji će biti izvršen **oslanja** (kao make file ili terraform config).
- **Public PPE or 3PE**: U nekim slučajevima pipeline-ovi mogu biti **pokrenuti od strane korisnika koji nemaju write access na repo** (a možda čak nisu ni deo org-a) zato što mogu da pošalju PR.
- **3PE Command Injection**: Obično će CI/CD pipeline-ovi **postavljati environment variables** sa **informacijama o PR-u**. Ako attacker može da kontroliše tu vrednost (kao što je naslov PR-a) i ona se **koristi** na **opasnom mestu** (kao izvršavanje **sh commands**), attacker može tu da **inject commands**.
### Prednosti eksploatacije
### Exploitation Benefits
Poznajući 3 varijante za trovanje pipeline-a, pogledajmo šta napadač može da dobije nakon uspešne eksploatacije:
Znajući 3 varijante za trovanje pipeline-a, hajde da vidimo šta attacker može da dobije nakon uspešne exploitation:
- **Secrets**: Kao što je ranije pomenuto, pipelines zahtevaju **privilegije** za svoje jobs (preuzimanje code-a, build, deploy...). Ove privilegije su obično **date u secrets**. Ovi secrets su obično dostupni preko **env variables ili fajlova unutar sistema**. Zbog toga će napadač uvek pokušati da iznese što više secrets.
- U zavisnosti od pipeline platforme napadač **možda mora da navede secrets u config-u**. To znači da, ako napadač ne može da izmeni CI configuration pipeline (**I-PPE** na primer), može **samo da iznese secrets koje taj pipeline ima**.
- **Computation**: Code se izvršava negde, u zavisnosti od toga gde se izvršava napadač možda može dalje da pivot-uje.
- **On-Premises**: Ako se pipelines izvršavaju on premises, napadač može završiti u **internoj mreži sa pristupom većem broju resursa**.
- **Cloud**: Napadač može pristupiti **drugim mašinama u cloud-u** ali takođe može da **iznese** IAM roles/service accounts **tokene** odatle kako bi dobio **dalji pristup unutar cloud-a**.
- **Platforms machine**: Ponekad će se jobs izvršavati unutar **platformskih mašina pipelines-a**, koje se obično nalaze u cloud-u sa **nema više pristupa**.
- **Select it:** Ponekad će **platforma pipelines-a imati konfigurisanih više mašina** i ako možete da **izmenite CI configuration file** možete da **odredite gde želite da se izvrši zlonamerni code**. U ovoj situaciji, napadač će verovatno pokrenuti reverse shell na svakoj mogućoj mašini da bi pokušao dalje da je eksploatiše.
- **Compromise production**: Ako ste unutar pipeline-a i finalna verzija se iz njega build-uje i deploy-uje, mogli biste da **kompromitujete code koji će na kraju biti pokrenut u production**.
- **Secrets**: Kao što je prethodno pomenuto, pipeline-ovi zahtevaju **privileges** za svoje job-ove (preuzimanje code-a, build, deploy...) i ti privileges su obično **dodeljeni u secrets**. Ovi secrets su obično dostupni kroz **env variables ili file-ove unutar sistema**. Zato će attacker uvek pokušati da exfiltrira što više secrets.
- U zavisnosti od pipeline platforme attacker **možda mora da navede secrets u config-u**. To znači da, ako attacker ne može da izmeni CI configuration pipeline (**I-PPE** na primer), može da **exfiltrira samo secrets koje taj pipeline već ima**.
- **Computation**: Code se izvršava negde, i u zavisnosti od toga gde se izvršava attacker možda može dalje da pivot-uje.
- **On-Premises**: Ako se pipeline-ovi izvršavaju on premises, attacker može završiti u **internal network-u sa pristupom većem broju resursa**.
- **Cloud**: Attacker bi mogao da pristupi **drugim mašinama u cloud-u**, ali i da **exfiltrira** IAM roles/service accounts **tokens** iz njih kako bi dobio **dalji pristup unutar cloud-a**.
- **Platforms machine**: Ponekad će se job-ovi izvršavati unutar **mašina pipeline platforme**, koje su obično u cloud-u sa **nema više pristupa**.
- **Select it:** Ponekad će **pipeline platforma imati konfigurisanih više mašina** i ako možete da **izmenite CI configuration file** možete da **odredite gde želite da se maliciozni code izvrši**. U toj situaciji attacker će verovatno pokrenuti reverse shell na svakoj mogućoj mašini kako bi pokušao dalje da je exploituje.
- **Compromise production**: Ako ste unutar pipeline-a i finalna verzija se build-uje i deploy-uje iz njega, možete **kompromitovati code koji će na kraju biti izvršavan u production**.
### Zloupotreba dependency i registry supply-chain-a
### Dependency & Registry Supply-Chain Abuse
Kompromitovanje CI/CD pipeline-a ili krađa credentials iz njega može napadaču omogućiti da pređe sa **pipeline execution** na **ekosistem-wide code execution** tako što će backdoor-ovati dependencies ili release tooling:
Kompromitovanje CI/CD pipeline-a ili krađa credentials iz njega može omogućiti attacker-u da pređe sa **pipeline execution** na **ecosystem-wide code execution** backdooring-om dependencies ili release tooling-a:
- **Install-time code execution via package hooks**: objavite verziju package-a koja dodaje `preinstall`, `postinstall`, `prepare` ili slične hooks tako da payload automatski radi na developer workstation-ima i CI runner-ima tokom instalacije dependencies.
- **Secondary execution paths**: čak i ako mete instaliraju sa `--ignore-scripts`, zlonamerni package i dalje može da registruje **uobičajeno CLI ime** u `bin` polju tako da se wrapper pod kontrolom napadača symlink-uje u `PATH` i izvršava kasnije kada se command koristi.
- **Runtime bootstrapping**: mali installer može da preuzme drugi runtime ili toolchain tokom instalacije (na primer Bun ili upakovan interpreter) i zatim pokrene glavni payload pomoću njega, izbegavajući lokalne dependency zahteve.
- **Credential harvesting from build environments**: kada code jednom radi unutar CI, proverite environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs i lokalne alate kao što je `gh auth token`. Na GitHub Actions, takođe tražite runner-specifične secrets i artifacts.
- **Workflow injection with stolen GitHub tokens**: token sa **`repo` + `workflow`** permissions je dovoljan da se napravi branch, commit-uje zlonamerna datoteka unutar `.github/workflows/`, pokrene, prikupe generisani artifacts/logs, a zatim obriše privremeni branch/workflow run da bi se smanjili tragovi.
- **Wormable registry propagation**: ukradeni npm tokeni treba da se provere na **publish** permissions i da li zaobilaze 2FA. Ako da, enumerišite writable packages, preuzmite njihove tarballs, ubacite loader kao što je `setup.mjs`, podesite `preinstall` da ga izvrši, povećajte patch verziju i republish. Ovo pretvara jednu CI kompromitaciju u downstream auto-execution u drugim okruženjima.
- **Install-time code execution via package hooks**: objavite package verziju koja dodaje `preinstall`, `postinstall`, `prepare` ili slične hooks tako da payload automatski bude pokrenut na developer workstation-ima i CI runner-ima tokom instalacije dependencies.
- **Secondary execution paths**: čak i ako targets instaliraju sa `--ignore-scripts`, malicious package i dalje može da registruje **common CLI name** u `bin` polju tako da attacker-controlled wrapper bude symlink-ovan u `PATH` i kasnije se izvrši kada se komanda iskoristi.
- **Runtime bootstrapping**: mali installer može da preuzme drugi runtime ili toolchain tokom instalacije (na primer Bun ili packed interpreter) i zatim pokrene glavni payload sa njim, izbegavajući lokalne dependency zahteve.
- **Credential harvesting from build environments**: kada code jednom radi unutar CI, proverite environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs i lokalne tool-ove kao što je `gh auth token`. Na GitHub Actions, takođe tražite runner-specific secrets i artifacts.
- **Workflow injection with stolen GitHub tokens**: token sa dozvolama **`repo` + `workflow`** dovoljan je da kreira branch, commit-uje malicious file unutar `.github/workflows/`, pokrene ga, prikupi dobijene artifacts/logs i zatim obriše privremeni branch/workflow run kako bi smanjio tragove.
- **Wormable registry propagation**: ukradeni npm token-i treba da se provere za **publish** permisije i da li zaobilaze 2FA. Ako zaobilaze, enumerišite writeable package-e, preuzmite njihove tarball-ove, ubacite loader kao što je `setup.mjs`, postavite `preinstall` da ga izvrši, povećajte patch verziju i republish. Ovo pretvara jednu CI kompromitaciju u downstream auto-execution u drugim okruženjima.
#### Praktične provere tokom assessment-a
- Pregledajte release automation zbog package-manager hooks dodatih u `package.json`, neočekivanih `bin` unosa ili bump-ova verzije koji menjaju samo release artifact.
- Proverite da li CI čuva dugoročne registry credentials u plaintext fajlovima kao što je `~/.npmrc` umesto da koristi kratkoročni OIDC ili trusted publishing.
- Potvrdite da li GitHub tokeni dostupni u CI mogu da pišu workflow fajlove ili kreiraju branches/tags.
- Ako se sumnja na kompromitovan package, pregledajte objavljeni tarball a ne samo Git repository, jer zlonamerni loader/runtime može postojati samo u objavljenom artifact-u.
- Tražite neočekivano package-manager izvršavanje unutar CI, kao što je `npm install` umesto `npm ci`, neočekivana Bun preuzimanja/izvršavanja ili novi workflow artifacts generisani iz transient branches.
- Pregledajte release automation za package-manager hooks dodate u `package.json`, neočekivane `bin` unose ili bump-ove verzija koji menjaju samo release artifact.
- Proverite da li CI čuva dugotrajne registry credentials u plain text file-ovima kao što je `~/.npmrc` umesto da koristi kratkotrajni OIDC ili trusted publishing.
- Proverite da li GitHub token-i dostupni u CI mogu da pišu workflow file-ove ili kreiraju branch-eve/tag-ove.
- Ako se sumnja na kompromitovani package, pregledajte objavljeni tarball, a ne samo Git repository, jer malicious loader/runtime može postojati samo u published artifact-u.
- Tražite neočekivano package-manager izvršavanje unutar CI, kao što je `npm install` umesto `npm ci`, neočekivana Bun preuzimanja/izvršavanja ili novi workflow artifacts generisani iz transient branch-eva.
- Pregledajte GitOps deployment engine-e i kao CI/CD targets. Argo CD-specific enumeration, repo-server abuse i Redis cache poisoning napadi su pokriveni u [Argo CD Security](argocd-security.md).
## Više relevantnih informacija
## More relevant info
### Alati & CIS Benchmark
### Tools & CIS Benchmark
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) je open-source alat za audit vaše software supply chain stack za security compliance zasnovan na novom [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Audit se fokusira na ceo SDLC proces, gde može otkriti rizike od code time do deploy time.
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) je open-source alat za audit vašeg software supply chain stack-a radi bezbednosne usklađenosti na osnovu novog [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Audit se fokusira na ceo SDLC process, gde može otkriti rizike od code time do deploy time.
### Top 10 CI/CD Security Risk
Pogledajte ovaj zanimljiv članak o top 10 CI/CD rizika prema Cider-u: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
Proverite ovaj zanimljiv članak o top 10 CI/CD rizika prema Cider-u: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
### Labovi
### Labs
- Na svakoj platformi koju možete lokalno pokrenuti naći ćete kako da je pokrenete lokalno tako da je možete konfigurisati kako želite da biste je testirali
- Na svakoj platformi koju možete lokalno da pokrenete pronaći ćete kako da je pokrenete lokalno kako biste je mogli konfigurisati po želji i testirati
- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
### Automatski alati
### Automatic Tools
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** je alat za static code analysis za infrastructure-as-code.
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** je alat za statičku analizu code-a za infrastructure-as-code.
## References