Metodologija pentesting CI/CD

Tip

Nauči & vežbaj AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Nauči & vežbaj GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Nauči & vežbaj Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks

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:

  • Github
  • Gitlab
  • Bitbucket
  • Gitea
  • Gitblit
  • Cloud providers (they offer their own VCS platforms)

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.

Međutim, ovi sistemi moraju da se izvršavaju negde i obično sa privilegovanih 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.

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:

  • 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:
  • 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).
  • Compromise the pipeline (check next section)

Metodologija pentesting pipelines

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.

Zato je krajnji cilj napadača da nekako kompromituje te configuration file-ove ili commands koje 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:

{{#ref}} docker-build-context-abuse.md {{#endref}}

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.

Da bi napadač bio uspešan pri izvođenju PPE napada, 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.

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.

Prednosti eksploatacije

Poznajući 3 varijante za trovanje pipeline-a, pogledajmo šta napadač može da dobije nakon uspešne eksploatacije:

  • 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.

Zloupotreba dependency i registry supply-chain-a

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:

  • 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.

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.

Više relevantnih informacija

Alati & CIS Benchmark

  • 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. Audit se fokusira na ceo SDLC proces, 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/

Labovi

Automatski alati

  • Checkov: Checkov je alat za static code analysis za infrastructure-as-code.

References

Tip

Nauči & vežbaj AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Nauči & vežbaj GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Nauči & vežbaj Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks