Pentesting CI/CD Methodology
Last updated
Last updated
Leer & oefen AWS Hacking:HackTricks Opleiding AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Opleiding GCP Red Team Expert (GRTE)
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
Wolkverskaffers (hulle bied hul eie VCS-platforms aan)
CI/CD pypelines stel ontwikkelaars in staat om die uitvoering van kode te outomatiseer vir verskeie doeleindes, insluitend bou, toets en ontplooi van toepassings. Hierdie geoutomatiseerde werksvloei word geaktiveer deur spesifieke aksies, soos kode stoot, trek versoeke, of geskeduleerde take. Hulle is nuttig om die proses van ontwikkeling na produksie te stroomlyn.
Egter, hierdie stelsels moet ergens uitgevoer word en gewoonlik met bevoorregte akrediteer om kode te ontplooi of toegang tot sensitiewe inligting te verkry.
Alhoewel sommige VCS-platforms toelaat om pypelines 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, bevat sensitiewe inligting en mense moet baie versigtig wees met die toestemmings wat binne hierdie platform toegestaan word. Dit is 'n paar algemene probleme oor VCS-platforms wat 'n aanvaller kan misbruik:
Lekke: As jou kode lekke in die verbintenisse bevat en die aanvaller toegang tot die repo kan verkry (omdat dit publiek is of omdat hy toegang het), kan hy die lekke ontdek.
Toegang: As 'n aanvaller toegang tot 'n rekening binne die VCS-platform kan verkry, kan hy meer sigbaarheid en toestemmings verkry.
Registrasie: Sommige platforms sal net eksterne gebruikers toelaat om 'n rekening te skep.
SSO: Sommige platforms sal nie gebruikers toelaat om te registreer nie, maar sal enigeen toelaat om toegang te verkry met 'n geldige SSO (so 'n aanvaller kan sy github-rekening gebruik om in te gaan byvoorbeeld).
Akrediteer: Gebruikersnaam+Pwd, persoonlike tokens, ssh sleutels, Oauth tokens, koekies... daar is verskeie tipes tokens wat 'n gebruiker 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 is met nie-sigtbare geheime nie, kan 'n aanvaller dit misbruik.
As daar geen geheim 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.
Kode kompromie: As 'n kwaadwillige akteur 'n soort skryf toegang oor die repos het, kan hy probeer om kwaadwillige kode in te spuit. Om suksesvol te wees, mag hy nodig hê om tak beskermings te omseil. Hierdie aksies kan met verskillende doelwitte in gedagte uitgevoer word:
Kompromitteer die hooftak om produksie te kompromitteer.
Kompromitteer die hoof (of ander takke) om ontwikkelaars se masjiene te kompromitteer (aangesien hulle gewoonlik toets, terraform of ander dinge binne die repo op hul masjiene uitvoer).
Kompromitteer die pypeline (kyk na die volgende afdeling).
Die mees algemene manier om 'n pypeline te definieer, is deur 'n CI-konfigurasie lêer wat in die repo gehos is te gebruik. Hierdie lêer beskryf die volgorde van uitgevoerde take, toestande wat die vloei beïnvloed, en bou omgewing instellings. 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 wat onder .github/workflows geleë is. Wanneer geaktiveer, trek die pypeline taak die kode van die geselekteerde bron (bv. verbintenis / tak), en voer die opdragte wat in die CI-konfigurasie lêer gespesifiseer is teen daardie kode uit.
Daarom is die uiteindelike doel van die aanvaller om op een of ander manier daardie konfigurasie lêers of die opdragte wat hulle uitvoer te kompromitteer.
Die Gevaarlike Pypeline Uitvoering (PPE) pad misbruik toestemmings in 'n SCM-repo om 'n CI-pypeline te manipuleer en skadelike opdragte uit te voer. Gebruikers met die nodige toestemmings kan CI-konfigurasie lêers of ander lêers wat deur die pypeline taak gebruik word, wysig om kwaadwillige opdragte in te sluit. Dit "vergiftig" die CI-pypeline, wat lei tot die uitvoering van hierdie kwaadwillige opdragte.
Vir 'n kwaadwillige akteur om suksesvol 'n PPE-aanval uit te voer, moet hy in staat wees om:
Skryf toegang tot die VCS-platform te hê, aangesien pypelines gewoonlik geaktiveer word wanneer 'n stoot of 'n trek versoek uitgevoer word. (Kyk na die VCS pentesting metodologie vir 'n opsomming van maniere om toegang te verkry).
Let daarop dat soms 'n eksterne PR as "skryf toegang" tel.
Alhoewel hy skryf toestemmings het, moet hy seker wees dat hy die CI konfigurasie lêer of ander lêers waarop die konfigurasie staatmaak kan wysig.
Hiervoor mag hy nodig hê om in staat te wees om tak beskermings te omseil.
Daar is 3 PPE variasies:
D-PPE: 'n Direkte PPE aanval vind plaas wanneer die akteur die CI konfigurasie lêer wysig wat gaan uitgevoer word.
I-DDE: 'n Indirekte PPE aanval vind plaas wanneer die akteur 'n lêer wat die CI konfigurasie lêer waarop dit gaan uitgevoer word afhang (soos 'n make-lêer of 'n terraform konfigurasie).
Publieke PPE of 3PE: In sommige gevalle kan die pypelines geaktiveer word deur gebruikers wat nie skryf toegang in die repo het nie (en wat dalk nie eens deel van die org is nie) omdat hulle 'n PR kan stuur.
3PE Opdrag Inspuiting: Gewoonlik sal CI/CD pypelines omgewing veranderlikes met inligting oor die PR stel. As daardie waarde deur 'n aanvaller beheer kan word (soos die titel van die PR) en is gebruik in 'n gevaarlike plek (soos die uitvoering van sh opdragte), kan 'n aanvaller opdragte daar in spuit.
Om die 3 variasies te ken om 'n pypeline te vergiftig, laat ons kyk wat 'n aanvaller kan verkry na 'n suksesvolle eksploitatie:
Geheime: Soos voorheen genoem, vereis pypelines bevoegdhede vir hul take (om die kode te verkry, dit te bou, dit te ontplooi...) en hierdie bevoegdhede word gewoonlik in geheime toegestaan. Hierdie geheime is gewoonlik toeganklik via omgewing veranderlikes of lêers binne die stelsel. Daarom sal 'n aanvaller altyd probeer om soveel geheime as moontlik te eksfiltreer.
Afhangende van die pypeline platform mag die aanvaller die geheime in die konfigurasie moet spesifiseer. Dit beteken dat as die aanvaller nie die CI konfigurasie pypeline kan wysig nie (I-PPE byvoorbeeld), kan hy slegs die geheime wat daardie pypeline het eksfiltreer.
Berekening: Die kode word êrens uitgevoer, afhangende van waar dit uitgevoer word, mag 'n aanvaller in staat wees om verder te pivot.
On-premises: As die pypelines op die perseel uitgevoer word, mag 'n aanvaller eindig in 'n interne netwerk met toegang tot meer hulpbronne.
Wolk: Die aanvaller kan toegang verkry tot ander masjiene in die wolk maar kan ook eksfiltreer IAM rolle/dienste rekeninge tokens daarvan om verdere toegang binne die wolk te verkry.
Platforms masjien: Soms sal die take binne die pypelines platform masjiene uitgevoer word, wat gewoonlik binne 'n wolk met geen verdere toegang is.
Kies dit: Soms sal die pypelines platform verskeie masjiene geconfigureer hê en as jy die CI konfigurasie lêer kan wysig, kan jy aangee waar jy die kwaadwillige kode wil uitvoer. In hierdie situasie sal 'n aanvaller waarskynlik 'n omgekeerde skulp op elke moontlike masjien uitvoer om te probeer om dit verder te exploiteer.
Kompromitteer produksie: As jy binne die pypeline is en die finale weergawe daaruit gebou en ontplooi word, kan jy die kode wat in produksie gaan eindig kompromitteer.
Chain-bench is 'n oopbron gereedskap vir die oudit van jou sagteware voorsieningsketting stap vir sekuriteits nakoming gebaseer op 'n nuwe CIS Sagteware Voorsieningsketting benchmark. Die oudit fokus op die hele SDLC-proses, waar dit risiko's van kode tyd in ontplooi tyd kan onthul.
Kyk na hierdie interessante artikel oor die top 10 CI/CD risiko's volgens Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/
Op elke platform wat jy plaaslik kan uitvoer, sal jy vind hoe om dit plaaslik te begin sodat jy dit kan konfigureer soos jy wil om dit te toets.
Gitea + Jenkins laboratorium: https://github.com/cider-security-research/cicd-goat
Checkov: Checkov is 'n statiese kode analise gereedskap vir infrastruktuur-as-kode.
Leer & oefen AWS Hacking:HackTricks Opleiding AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Opleiding GCP Red Team Expert (GRTE)
