Pentesting CI/CD Metodologie

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

VCS

VCS staan vir Version Control System, hierdie stelsels laat ontwikkelaars toe om hulle 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 (they offer their own VCS platforms)

CI/CD Pipelines

CI/CD pipelines stel ontwikkelaars in staat om die uitvoering van code te outomatiseer vir verskeie doeleindes, insluitend die bou, toets en ontplooiing van applications. Hierdie geoutomatiseerde workflows word geaktiveer deur spesifieke aksies, soos code pushes, pull requests, of geskeduleerde take. Hulle is nuttig om die proses van ontwikkeling na production te stroomlyn.

Hierdie systems moet egter iewers uitgevoer word en gewoonlik met geprivilegieerde credentials om code te ontplooi of toegang tot sensitiewe information te verkry.

VCS Pentesting Methodology

Note

Al laat sommige VCS platforms toe om pipelines vir hierdie afdeling te skep, gaan ons net potensiële attacks teen die beheer van die bronkode ontleed.

Platforms wat die bronkode van jou project bevat, bevat sensitiewe information en mense moet baie versigtig wees met die permissions wat binne hierdie platform toegestaan word. Hierdie is sommige algemene problems oor VCS platforms wat attackers kan misbruik:

  • Leaks: As jou code leaks in die commits bevat en die attacker toegang tot die repo kan kry (omdat dit public is of omdat hy toegang het), kan hy die leaks ontdek.
  • Access: As ’n attacker toegang tot ’n account binne die VCS platform kan verkry kan hy meer visibility en permissions kry.
  • Register: Sommige platforms sal net eksterne users toelaat om ’n account te skep.
  • SSO: Sommige platforms sal users nie toelaat om te registreer nie, maar sal enigiemand toelaat om met ’n geldige SSO toegang te verkry (so ’n attacker kan byvoorbeeld sy github account gebruik om in te gaan).
  • Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies… daar is verskeie soort tokens wat ’n user kan steel om op een of ander manier toegang tot ’n repo te verkry.
  • Webhooks: VCS platforms laat toe om webhooks te genereer. As hulle nie beskerm word met nie-sigbare secrets nie, kan ’n attacker hulle misbruik.
  • As geen secret in plek is nie, kan die attacker die webhook van die third party platform misbruik
  • As die secret in die URL is, gebeur dieselfde en die attacker het ook die secret
  • Code compromise: As ’n kwaadwillige actor een of ander soort write access oor die repos het, kan hy probeer om kwaadwillige code in te spuit. Om suksesvol te wees, moet hy dalk branch protections omseil. Hierdie actions kan met verskillende goals in mid uitgevoer word:
  • Die main branch kompromitteer om production te kompromitteer.
  • Die main (of ander branches) kompromitteer om developers machines te kompromitteer (aangesien hulle gewoonlik test, terraform of ander goed binne die repo op hulle machines uitvoer).
  • Die pipeline kompromitteer (check volgende section)

Pipelines Pentesting Methodology

Die mees algemene manier om ’n pipeline te definieer, is deur ’n CI configuration file wat in die repository gehuisves word wat die pipeline bou. Hierdie file beskryf die volgorde van uitgevoerde jobs, conditions wat die flow beïnvloed, en build environment settings.
Hierdie files het tipies ’n konsekwente naam en format, byvoorbeeld — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), en die GitHub Actions YAML files geleë onder .github/workflows. Wanneer dit geaktiveer word, trek die pipeline job die code van die geselekteerde source (bv. commit / branch), en voer die commands wat in die CI configuration file gespesifiseer is uit teen daardie code.

Daarom is die uiteindelike goal van die attacker om op een of ander manier daardie configuration files te kompromitteer of die commands wat hulle uitvoer.

Tip

Sommige hosted builders laat contributors toe om die Docker build context en Dockerfile path te kies. As die context attacker-controlled is, kan jy dit buite die repo stel (bv. “..”) om host files tydens build in te lees en secrets uit te exfiltrate. Sien:

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

PPE - Poisoned Pipeline Execution

Die Poisoned Pipeline Execution (PPE) path misbruik permissions in ’n SCM repository om ’n CI pipeline te manipuleer en skadelike commands uit te voer. Users met die nodige permissions kan CI configuration files of ander files wat deur die pipeline job gebruik word, verander om kwaadwillige commands in te sluit. Dit “vergiftig” die CI pipeline, wat lei tot die uitvoering van hierdie kwaadwillige commands.

Vir ’n kwaadwillige actor om suksesvol ’n PPE attack uit te voer, moet hy in staat wees om:

  • write access tot die VCS platform te hê, aangesien pipelines gewoonlik geaktiveer word wanneer ’n push of ’n pull request uitgevoer word. (Check die VCS pentesting methodology vir ’n opsomming van maniere om toegang te verkry).
  • Let daarop dat ’n external PR soms as “write access” tel.
  • Selfs al het hy write permissions, moet hy seker wees hy kan die CI config file of ander files waarop die config staatmaak, verander.
  • Hiervoor moet hy dalk in staat wees om branch protections te omseil.

Daar is 3 PPE flavours:

  • D-PPE: ’n Direct PPE attack vind plaas wanneer die actor die CI config file wat uitgevoer gaan word, verander.
  • I-DDE: ’n Indirect PPE attack vind plaas wanneer die actor ’n file wat die CI config file wat uitgevoer gaan word gebruik verander (soos ’n make file of ’n terraform config).
  • Public PPE or 3PE: In sommige gevalle kan die pipelines geaktiveer word deur users wat nie write access in die repo het nie (en wat dalk nie eens deel van die org is nie) omdat hulle ’n PR kan stuur.
  • 3PE Command Injection: Gewoonlik sal CI/CD pipelines environment variables stel met information oor die PR. As daardie value deur ’n attacker beheer kan word (soos die title van die PR) en op ’n gevaarlike plek gebruik word (soos om sh commands uit te voer), kan ’n attacker commands daarin injekteer.

Exploitation Benefits

As jy die 3 flavours ken om ’n pipeline te vergiftig, kyk ons wat ’n attacker na suksesvolle exploitation kan verkry:

  • Secrets: Soos voorheen genoem, vereis pipelines privileges vir hulle jobs (die code ophaal, bou, ontplooi…) en hierdie privileges word gewoonlik in secrets toegestaan. Hierdie secrets is gewoonlik toeganklik via env variables of files binne die system. Daarom sal ’n attacker altyd probeer om soveel secrets as moontlik te exfiltrate.
  • Afhangend van die pipeline platform moet die attacker miskien die secrets in die config spesifiseer. Dit beteken dat as die attacker nie die CI configuration pipeline kan verander nie (I-PPE byvoorbeeld), hy net die secrets kan exfiltrate wat daardie pipeline het.
  • Computation: Die code word iewers uitgevoer, afhangend van waar dit uitgevoer word, kan ’n attacker dalk verder pivot.
  • On-Premises: As die pipelines on premises uitgevoer word, kan ’n attacker dalk in ’n interne network met toegang tot meer resources beland.
  • Cloud: Die attacker kan toegang verkry tot ander machines in die cloud maar kan ook IAM roles/service accounts tokens daaruit exfiltrate om verdere access binne die cloud te verkry.
  • Platforms machine: Soms sal die jobs binne die pipelines platform machines uitgevoer word, wat gewoonlik binne ’n cloud is met geen verdere access nie.
  • Select it: Soms sal die pipelines platform verskeie machines gekonfigureer hê en as jy die CI configuration file kan verander kan jy aandui waar jy die kwaadwillige code wil laat loop. In hierdie situasie sal ’n attacker waarskynlik ’n reverse shell op elke moontlike machine laat loop om dit verder te probeer misbruik.
  • Compromise production: As jy binne die pipeline is en die finale version word daaruit gebou en ontplooi, kan jy die code kompromitteer wat uiteindelik in production gaan loop.

Dependency & Registry Supply-Chain Abuse

Om ’n CI/CD pipeline te kompromitteer of credentials daaruit te steel, kan ’n attacker van pipeline execution na ecosystem-wide code execution laat beweeg deur dependencies of release tooling te backdoor:

  • Install-time code execution via package hooks: publiseer ’n package version wat preinstall, postinstall, prepare, of soortgelyke hooks byvoeg sodat die payload outomaties op developer workstations en CI runners tydens dependency installation loop.
  • Secondary execution paths: selfs al installeer targets met --ignore-scripts, kan ’n kwaadwillige package steeds ’n common CLI name in die bin field registreer sodat die attacker-controlled wrapper in PATH gesymlink word en later uitvoer wanneer die command gebruik word.
  • Runtime bootstrapping: ’n klein installer kan tydens installation ’n tweede runtime of toolchain aflaai (byvoorbeeld Bun of ’n gepakte interpreter) en dan die main payload daarmee begin, wat local dependency requirements vermy.
  • Credential harvesting from build environments: sodra code binne CI loop, kontroleer environment variables, ~/.npmrc, ~/.git-credentials, SSH keys, cloud CLI configs, en local tooling soos gh auth token. Op GitHub Actions, kyk ook vir runner-specific secrets en artifacts.
  • Workflow injection with stolen GitHub tokens: ’n token met repo + workflow permissions is genoeg om ’n branch te skep, ’n kwaadwillige file binne .github/workflows/ te commit, dit te aktiveer, die geproduseerde artifacts/logs te versamel, en dan die tydelike branch/workflow run te verwyder om spore te verminder.
  • Wormable registry propagation: gesteelde npm tokens moet vir publish permissions en of hulle 2FA omseil, geverifieer word. As hulle dit doen, lys writable packages, laai hulle tarballs af, injecteer ’n loader soos setup.mjs, stel preinstall om dit uit te voer, verhoog die patch version, en republish. Dit verander een CI compromise in downstream auto-execution in ander environments.

Practical checks during an assessment

  • Hersien release automation vir package-manager hooks wat by package.json gevoeg is, onverwante bin entries, of version bumps wat net die release artifact verander.
  • Kontroleer of CI langlewende registry credentials in plaintext files soos ~/.npmrc stoor in plaas van kortlewende OIDC of trusted publishing te gebruik.
  • Verifieer of GitHub tokens wat in CI beskikbaar is workflow files kan skryf of branches/tags kan skep.
  • As ’n gekompromitteerde package vermoed word, inspekteer die gepubliseerde tarball en nie net die Git repository nie, omdat die kwaadwillige loader/runtime slegs in die gepubliseerde artifact kan bestaan.
  • Soek vir onverwante package-manager uitvoering binne CI soos npm install in plaas van npm ci, onverwante Bun downloads/execution, of nuwe workflow artifacts wat vanaf transient branches gegenereer word.

More relevant info

Tools & CIS Benchmark

  • Chain-bench is ’n open-source tool om jou software supply chain stack vir security compliance te oudit gebaseer op ’n nuwe CIS Software Supply Chain benchmark. Die auditing fokus op die hele SDLC process, waar dit risks van code time tot deploy time kan openbaar.

Top 10 CI/CD Security Risk

Kyk na hierdie interessante article oor die top 10 CI/CD risks volgens Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/

Labs

Automatic Tools

  • Checkov: Checkov is ’n static code analysis tool vir infrastructure-as-code.

References

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks