Kontinuerlig integrasjon og kontinuerlig distribusjon (CI/CD) pipelinespiller en sentral rolle i å legge til rette for strømlinjeformet programvareutvikling. Likevel, ettersom disse pipelineEtter hvert som det blir stadig viktigere, blir nødvendigheten av å beskytte dem mot sårbarheter mer uttalt. Denne grundige undersøkelsen fokuserer på å adressere en fremtredende risiko identifisert i OWASP Topp-10 CI/CD Sikkerhetsrisikoer: Forgiftet Pipeline Henrettelse (PPE).
Hva er forgiftet Pipeline Henrettelse (PPE)
I følge OWASP Topp-10 CI/CD Sikkerhetsrisikoer,Forgiftet Pipeline Gjennomføring (PPE) risiko refererer til evnen til en angriper med tilgang til kildekontrollsystemer – og uten tilgang til byggemiljøet – å manipulere byggeprosessen ved å injisere ondsinnet kode/kommandoer i byggeprosessen pipeline konfigurasjon, i hovedsak 'forgiftning' av pipeline og kjører ondsinnet kode som en del av byggeprosessen»
Med noen få ord, forgiftet Pipeline Henrettelse (PPE) produseres når angriperen kan endre pipeline logikk.
Det er to varianter:
- Direkte personlig verneutstyr (D-PPE): I et D-PPE-scenario, angriperen endrer CI-konfigurasjonsfilen i et repository de har tilgang til, enten ved å pushe endringen direkte til en ubeskyttet ekstern gren på repoet, eller ved å sende inn en PR med endringen fra en gren eller en fork. Siden CI pipeline Utførelsen er definert av kommandoene i den modifiserte CI-konfigurasjonsfilen. Angriperens ondsinnede kommandoer kjøres til slutt i byggenoden når byggeprosessen er fullført. pipeline utløses.
- Indirekte personlig verneutstyr (I-PVU): I visse tilfeller er muligheten for D-PPE ikke tilgjengelig for en motpart med tilgang til en SCM depotet (f.eks. hvis pipeline er konfigurert til å hente CI-konfigurasjonsfilen fra en separat, beskyttet gren i samme repository). I et slikt scenario, i stedet for å forgifte pipeline i seg selv injiserer en angriper skadelig kode i filer referert til av pipeline (for eksempel: skript referert fra innsiden av pipeline konfigurasjonsfil)
I begge tilfeller, GitHub vil kjøre den modifiserte pipeline uten behov for forutgående gjennomgang eller godkjenning.
Tidlig deteksjon av personlig verneutstyr
Hvordan kan vi oppdage denne typen sårbarhet?
La oss se på dette eksemplet pipeline :
name: PR CI
on:
pull_request:
branches: [ main ]
env:
MY_SECRET: ${{ secrets.MY_SECRET }}
jobs:
pr_build_test_and_merge:
runs-on: ubuntu-latest
steps:
# checkout PR code
- name: Checkout repository
uses: actions/checkout@v4
# Simulation of a compilation
- name: Building ...
run: |
echo $MY_SECRET
mkdir ./bin
touch ./bin/mybin.exe
# Simulation of running tests
- name: Running tests ...
id : run_tests
run: |
echo Running tests..
chmod +x runtests.sh
./runtests.sh "${{ github.event.pull_request.user.login }}" "${{ github.workflow }}"
echo Tests executed.
Og innholdet i et dummy-shell-skript (runtests.sh):
#!/usr/bin/bash
echo "Executing Tests script [from user $1 at $2]" >> runtests.out
exit 0
Ocuco pipeline er ganske enkel: målet er å gi anmelderen noen innledende hint om Pull Request (PR) akseptprosess:
- Den vil bli utløst på pull_request (dvs. hver gang en PR opprettes)
- Den sjekker PR-koden (dvs. den bidragte koden)
- Det vil gjøre byggingen
- Den vil kjøre tester på bidratt kode (f.eks. ved å kjøre et skallskript)
Trinn nr. 3 (lage byggingen) og nr. 4 (kjøre test) vil mislykkes hvis koden ikke kompileres eller ikke består testene. Så disse trinnene fungerer som en nødvendig, men ikke tilstrekkelig, betingelse for å godta PR-en. Hvis det lykkes, vil repoadministratoren gå videre til å gjennomgå den bidradde koden, og basert på det vil han/hun godta/avvise/kommentere PR-en.
Xygeni-skanner
Xygeni tilbyr et CLI («Xygeni-skanner”) som kan legges inn i en pipeline eller kjøre i en kommandolinje. Xygeni-skanneren vil behandle pipelines for å se etter sårbarheter, og hvis en GitHub PAT leveres, vil den koble til GitHub for å oppdage sårbarheter på organisasjons-/depotnivå.
Xygeni-inventar
Når vi kjører Xygeni Scanner på dette depotet, oppdager det et nyttig sett med ressurser (den Xygeni-inventar). Inventarlisten vil bli fylt med mange forskjellige typer CI/CD eiendeler, Slik som:
- Ocuco SCM System hvor depotet er lagret
- Ocuco SCM plugins installert/brukt
- Ocuco Kodelager selv
- Ocuco SCM Organisasjon hvor depotet tilhører
- Ocuco CI/CD Pipelines og jobber
- Ocuco CI/CD System kjører pipelines
- IaC Ressurser definert i repoet
- Ekstern avhengig
- etc..
I vårt eksempel kan vi filtrere beholdningen etter en spesifikk aktivumstype (SCM- og CICD-relaterte eiendeler), slik at vi kan se at:
- SCM systemet er GitHub Cloud
- Repoet lagres i GitHub Cloud og tilhører en spesifikk GitHub-organisasjon.
- Det er to pipelinedrevet av GitHub (CI/CD system)
- Hver pipeline inneholder ett spesifikt trinn
Ved å velge det ovennevnte pipeline Vi kan se noen sårbarheter:
- At pipeline nivå, er det sårbart for begge deler Direkte og Indirekte personlig verneutstyr.
Vi kan se detaljene til de forgiftede Pipeline Utførelsessårbarheter
Xygeni oppdager at det er sårbar for D-PPE fordi den utløses på en Pull Request hendelsen, og det finnes ingen ekstra sikkerhetskontroller, så enhver repositorybruker kan endre den pipeline og disse endringene vil bli utført uten noen gjennomgang eller godkjenning.
På samme måte oppdager Xygeni også at det er sårbar for personlig verneutstyr på grunn av kallet til skallskriptet fra pipelineEnhver repo-bruker kan endre skallskriptet, og disse endringene vil bli utført uten gjennomgang eller godkjenning.
Vil du vite mer?
Utnyttelse av personlig verneutstyr
For å utnytte personlig verneutstyr, la oss se på et scenario der det finnes to typer repobrukere:
- An intern bruker (en intern utvikler som jobber med det repoet), med skriverettigheter til repoet
- An ekstern bruker (en outsourcet utvikler som jobber med det repoet, men med lesetillatelser på repoet), dvs. ikke tillatelse til å forgrene repoet og tvunget til å jobbe på en fork.
La oss forestille oss at begge er ondsinnede angripere (eller utgis for å være av en ondsinnet aktør). Lageret inneholder en hemmelighet, og begge ønsker å stjele depothemmeligheten og sende den til en hackerkontrollert server. For å gjøre det, vil de utnytte den forgiftede Pipeline Utførelsessårbarheter for pipeline.
I begge tilfeller (ekstern og intern bruker) åpner de en Pull Request med de samme modifikasjonene:
- Ocuco pipeline og skallskriptet er endret til les hemmeligheten fra miljøet og send den til en hackerkontrollert server
Endringene kan være som følger:
Begge brukerne vil opprette en Pull Request med modifikasjoneneVed opprettelsen av PR-en, GitHub vil utføre begge modifikasjonene (uten behov for forhåndsgodkjenning eller vurdering), noe som resulterer i følgende:
Det samme gjelder for brukere med både skrive- og lesefunksjon. i begge tilfeller utføres D-PPE og I-PPE, med den forskjellen at Den lesende brukeren har ikke tilgang til hemmelighetene. (!!!!)
Denne grunnen er fordi, I tilfelle en PR som kommer fra en fork, tillater ikke GitHub tilgang til repo-hemmelighetene. Selv om den lesende brukeren ikke kan lese hemmelighetene, kan han/hun fortsatt kjøre et hvilket som helst annet program. Et typisk angrepseksempel er å lage PR-er som laster ned en kryptominer, slik at GitHub-løperen vil kjøre kryptomineren når den kjører en forgiftet [forgiftet/forgiftet]. pipeline.
Dette er selvsagt ikke et trygt miljø!! Hva kan repoadministratoren gjøre for å unngå det?
Etter litt googling bestemmer repoadministratoren seg for å endre pipeline å bli utløst på en pull_request_target hendelse. Hvorfor? Fordi pipelines utløst på pull_request_target tillater ikke utførelse pipeline modifikasjoner, dvs. til tross for eventuelle brukermodifikasjoner, den «originale» pipeline vil bli henrettet.
Etter vårt eksempel vil angrepet være det samme som før. Hva vil skje etter dette? pipeline modifikasjon?
Som forventet, D-PPE er ikke utført men fordi I-PPE fortsatt er der, Den lesende brukeren har nå tilgang til depothemmeligheten!!!
Hva er grunnen til at den lesende brukeren nå har tilgang til hemmeligheter? Selv om pipeline kan ikke endres, det er fortsatt mulig å endre skallskriptet. Når en pipeline utløses på pull_request_target, vil den bli utført i privilegert modus so det vil også være skallskriptet, noe som resulterer i at skallskriptet har tilgang til repohemmeligheter!!
Forebyggende tiltak
GitHub tilbyr noen tiltak for å beskytte mot ondsinnede PR-er.
Regler for beskyttelse av filialer
Med GitHub kan du definere grenbeskyttelsesregler over utvalgte grener.
For dine beskyttede grener kan du spesifisere en policy som krever a pull request før sammenslåing (samt tilleggsbetingelser som et nødvendig antall godkjenninger, vurderinger fra kodeeiere osv.)
Et par forhold som fortjener spesiell oppmerksomhet er:
- "Tillat spesifiserte aktører å omgå nødvendige pull requests".
- "Ikke tillat omgåelse av innstillingene ovenfor"
Selv om de fleste betingelsene skjerper retningslinjene, myker disse opp på dem, og det kan innebære en åpen dør for ondsinnede aktiviteter, for eksempel dersom påloggingsinformasjon blir stjålet av «privilegerte» aktører.
Begrens GITHUB_TOKEN-tillatelser (minst privilegier)
Begrens GitHub-tokentillatelsene til kun de nødvendige. På denne måten, selv i tilfelle angriperne lykkes med å kompromittere sikkerhetskopien din. pipeline, de vil ikke kunne gjøre mye.
Unngå strenginterpolering ved å bruke pipeline miljøvariabler
Når du bruker noen inputvariabler i din pipeline, vær oppmerksom på at de som standard bør betraktes som «uklarerte» data (innholdet deres kontrolleres av sluttbrukeren). Se Upålitelige handlinger og arbeidsflyter sikre og Lær Github-handlinger.
Du bør alltid bruke miljøvariabler til å sette inn inputvariabler i skript i stedet for å bruke strenginterpolasjon.
Arbeidsflytkjøringer og godkjenningskrav
Til offentlig repos, GitHub tillater å spesifisere hvordan man jobber med «eksterne» PR-er.
GitHub-organisasjonsinnstillingene («Org >> Innstillinger >> Handlinger >> Generelt») lar deg spesifisere hvordan eksterne PR-er skal administreres:
Som standard krever GitHub PR-godkjenning for førstegangsbidragsytere, noe som gjør ondsinnede forespørselsangrep mer kompliserte. Likevel kan angriperen vinne prosjektvedlikeholdernes tillit, for eksempel ved å bidra med uskyldige bidrag. pull request før det virkelige angrepet.
I denne forstand, Det tredje alternativet (krever godkjenning for alle eksterne samarbeidspartnere) gir et høyere kontrollnivå.
Til privat reposer, GitHub gir også nyttig kontroll både på organisasjons- og reponivå.
"Kjør arbeidsflyter fra Pull Requests” (ikke avmerket som standard) lar brukere kjøre arbeidsflyter fra fork-PR-er (ved å bruke en GITHUB_TOKEN med skrivebeskyttet tilgang og uten tilgang til hemmeligheter). Ved å velge dette alternativet sammen med det siste (“Krev godkjenning for fork-PR-arbeidsflyter”), kan du oppnå en lignende policy som for private repositorier (som vist ovenfor).
Som vi har sett i PPE-utnyttelsen fra en lesende bruker, tillater kjøring av arbeidsflyter fra fork pull requests er utrygt!!
De resterende alternativene (“Send skrivetokener til arbeidsflyter fra fork pull requests"Og"Send hemmeligheter og variabler til arbeidsflyter fra for pull requests") senke sikkerhetsnivået brukt på gaffel-PR-er.
Du kan definere denne fork-policyen enten på organisasjonsnivå eller på repositorinivå. Hvis policyen er deaktivert på organisasjonsnivå, kan den ikke aktiveres på repositorinivå. Men hvis policyen er aktivert på organisasjonsnivå, kan den deaktiveres på repositorinivå.
Oppsummering
Vi håper du har sett konsekvensene av å ha noen pipeline sårbar for forgiftning Pipeline Henrettelse. Det er for lett å commit en sårbar pipeline, og det er vanskelig å skrive en trygg en.
Så det er svært verdifullt å bruke Xygeni-skanneren for å være oppmerksom på slike sårbarheter.
Du kan ikke løse et sårbarhet med mindre du er klar over dets eksistens!!
Men ... Det er fortsatt et spørsmål som venter ... Hvordan unngå I-PPE?
Dette blir temaet for vårt neste innlegg 🙂 … Indirekte forgiftning Pipeline Henrettelse (I-PPE) !!
