9.6 KiB
Pentesting CI/CD Metodologie
{{#include ../banners/hacktricks-training.md}}
VCS
VCS staan vir Version Control System; hierdie stelsels laat ontwikkelaars toe om hul bronkode te bestuur. Die mees algemene is git en jy sal gewoonlik maatskappye vind wat dit op een van die volgende platforms gebruik:
- Github
- Gitlab
- Bitbucket
- Gitea
- Gitblit
- Cloud providers (hulle bied hul eie VCS-platforms aan)
CI/CD Pipelines
CI/CD pipelines maak dit vir ontwikkelaars moontlik om die uitvoering van kode te outomatiseer vir verskeie doeleindes, insluitend bou, toetsing en ontplooiing van toepassings. Hierdie geoutomatiseerde workflows word getrigger deur spesifieke aksies, soos code pushes, pull requests of geskeduleerde take. Hulle help om die proses van ontwikkeling na produksie te stroomlyn.
Meg diestelsels moet egter nerens uitgevoer word en gewoonlik met bevoorregte credentials om kode te ontplooi of sensitiewe inligting te bereik.
VCS Pentesting Methodology
Note
Selfs al laat sommige VCS-platforms toe om pipelines te skep, gaan ons in hierdie afdeling slegs potensiële aanvalle op die beheer van die bronkode ontleed.
Platforms wat die bronkode van jou projek bevat, hou sensitiewe inligting en mense moet baie versigtig wees met die permissies wat binne daardie platform gegee word. Dit is sommige algemene probleme oor VCS-platforms wat 'n aanvaller kan misbruik:
- Leaks: As jou kode leaks in die commits bevat en die aanvaller toegang tot die repo het (omdat dit publiek is of omdat hy toegang het), kan hy die leaks ontdek.
- Access: As 'n aanvaller toegang tot 'n rekening binne die VCS-platform kry, kan hy meer sigbaarheid en permissies bekom.
- Register: Sommige platforms sal net buitegebruikers toelaat om 'n rekening te skep.
- SSO: Sommige platforms sal nie gebruikers toelaat om te registreer nie, maar sal enigiemand toelaat om met 'n geldige SSO in te gaan (so 'n aanvaller kan byvoorbeeld sy github-rekening gebruik om in te gaan).
- Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... daar is verskeie soorte tokens wat 'n gebruiker kan steel om op een of ander manier toegang tot 'n repo te kry.
- Webhooks: VCS-platforms laat toe om webhooks te genereer. As hulle nie beskerm is met nie-sigbare secrets nie, kan 'n aanvaller hulle misbruik.
- As geen geheim ingestel is nie, kan die aanvaller die webhook van die derdeparty-platform misbruik.
- As die geheim in die URL is, gebeur dieselfde en die aanvaller het ook die geheim.
- Code compromise: As 'n kwaadwillige akteur 'n soort skryf toegang oor die repos het, kan hy probeer om kwaadaardige kode in te voeg. Om suksesvol te wees mag hy die branch protections moet omseil. Hierdie aksies kan vir verskeie doelwitte uitgevoer word:
- Kompromitteer die main branch om produksie te kompromitteer.
- Kompromitteer die main (of ander branches) om ontwikkelaars se masjiene te kompromitteer (aangesien hulle gewoonlik teste, terraform of ander dinge binne die repo op hul masjiene uitvoer).
- Compromise the pipeline (kyk volgende afdeling)
Pipelines Pentesting Methodology
Die mees algemene manier om 'n pipeline te definieer, is deur gebruik te maak van 'n CI configuration file gehost in die repository wat die pipeline bou. Hierdie lêer beskryf die volgorde van uitgevoerde jobs, voorwaardes wat die vloei beïnvloed, en build-omgewinginstellings.
Hierdie lêers het tipies 'n konsekwente naam en formaat, byvoorbeeld — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), en die GitHub Actions YAML-lêers onder .github/workflows. Wanneer dit getrigger word, pulls die pipeline job die kode van die gekose bron (bv. commit / branch), en voer die opdragte wat in die CI-konfigurasielêer gespesifiseer is teen daardie kode uit.
Dus is die uiteindelike doel van die aanvaller om op een of ander manier daardie konfigurasielêers of die opdragte wat hulle uitvoer, te kompromitteer.
Tip
Sommige gehoste builders laat contributors toe om die Docker build context en Dockerfile path te kies. As die context deur die aanvaller beheer word, kan jy dit buite die repo stel (bv. "..") om host-lêers tydens build in te neem en secrets te eksfiltreer. Sien:
{{#ref}} docker-build-context-abuse.md {{#endref}}
PPE - Poisoned Pipeline Execution
Die Poisoned Pipeline Execution (PPE) path misbruik permissies in 'n SCM repository om 'n CI pipeline te manipuleer en kwaadaardige opdragte uit te voer. Gebruikers met die nodige permissies kan CI-konfigurasielêers of ander lêers wat deur die pipeline job gebruik word, wysig om kwaadwillige opdragte in te sluit. Dit "vergiftig" die CI-pipeline, wat lei tot die uitvoering van hierdie kwaadwillige opdragte.
Vir 'n kwaadwillige akteur om suksesvol 'n PPE-aanval uit te voer, moet hy:
- Heb write access to the VCS platform, aangesien pipelines gewoonlik getrigger word wanneer 'n push of 'n pull request uitgevoer word. (Kyk die VCS pentesting methodology vir 'n samevatting van maniere om toegang te kry).
- Let daarop dat soms 'n external PR as "write access" tel.
- Selfs as hy write-permissies het, moet hy seker wees dat hy die CI config file of ander lêers waarop die config staatmaak kan wysig.
- Hiervoor mag hy die branch protections moet kan omseil.
Daar is 3 PPE-smake:
- D-PPE: 'n Direct PPE aanval vind plaas wanneer die akteur die CI config lêer wysig wat uitgevoer gaan word.
- I-DDE: 'n Indirect PPE aanval gebeur wanneer die akteur 'n lêer wysig waarop die CI config lêer wat uitgevoer gaan word berus (soos 'n make-lêer of 'n terraform-konfig).
- Public PPE or 3PE: In sommige gevalle kan pipelines getrigger word deur gebruikers wat nie write access in die repo het nie (en wat dalk nie eers deel van die org is nie) omdat hulle 'n PR kan stuur.
- 3PE Command Injection: Gewoonlik stel CI/CD pipelines environment variables met inligting oor die PR. As daardie waarde deur 'n aanvaller beheer kan word (soos die titel van die PR) en dit in 'n gevaarlike plek gebruik word (soos die uitvoering van sh commands), kan 'n aanvaller opdragte daarin injekteer.
Exploitation Benefits
Deur die 3 smake om 'n pipeline te vergiftig te ken, kom ons kyk wat 'n aanvaller na 'n suksesvolle uitbuiting kan bekom:
- Secrets: Soos vroeër genoem, vereis pipelines bevoegdhede vir hul jobs (haal die kode, bou dit, ontplooi dit ...) en hierdie bevoegdhede word gewoonlik in secrets gehou. Hierdie secrets is gewoonlik toeganklik via env variables of lêers binne die stelsel. Daarom sal 'n aanvaller altyd probeer om soveel secrets as moontlik te eksfiltreer.
- Afhangend van die pipeline platform mag die aanvaller die secrets in die config moet spesifiseer. Dit beteken as die aanvaller nie die CI-konfigurasielêer kan wysig nie (I-PPE byvoorbeeld), kan hy slegs die secrets eksfiltreer wat daardie pipeline het.
- Computation: Die kode word êrens uitgevoer; afhangend van waar dit uitgevoer word, mag 'n aanvaller verder kan pivot.
- On-Premises: As die pipelines on-premises uitgevoer word, kan 'n aanvaller in 'n interne netwerk met toegang tot meer hulpbronne beland.
- Cloud: Die aanvaller kan toegang tot ander masjiene in die cloud kry, maar ook IAM roles/service accounts tokens daaruit eksfiltreer om verdere toegang in die cloud te verkry.
- Platforms machine: Soms word die jobs binne die pipelines platform machines uitgevoer, wat gewoonlik in 'n cloud is met geen verdere toegang.
- Select it: Soms het die pipelines platform verskeie masjiene geconfigureer en as jy die CI config file kan wysig, kan jy aandui waar jy die kwaadwillige kode wil laat loop. In daardie situasie sal 'n aanvaller waarskynlik 'n reverse shell op elke moontlike masjien laat loop om dit verder te probeer uitbuit.
- Compromise production: As jy binne die pipeline is en die finale weergawe daargebou en ontplooi word, kan jy die kode wat in produksie gaan loop compromise.
Meer relevante inligting
Tools & CIS Benchmark
- Chain-bench is 'n open-source tool vir die ouditering van jou software supply chain stack vir sekuriteitskompliance gebaseer op 'n nuwe CIS Software Supply Chain benchmark. Die oudit fokus op die hele SDLC-proses, waar dit risiko's van code-time tot deploy-time kan onthul.
Top 10 CI/CD Security Risk
Kyk hierdie interessante artikel oor die top 10 CI/CD risiko's volgens Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/
Labs
- Op elke platform wat jy lokaal kan laat loop, sal jy instruksies vind oor hoe om dit plaaslik te begin sodat jy dit kan konfigureer soos jy wil om dit te toets.
- Gitea + Jenkins lab: https://github.com/cider-security-research/cicd-goat
Automatic Tools
- Checkov: Checkov is 'n static code analysis tool vir infrastructure-as-code.
References
{{#include ../banners/hacktricks-training.md}}