Nuolatinė integracija ir nuolatinis diegimas (CI/CD) pipelineatlieka pagrindinį vaidmenį palengvinant supaprastintą programinės įrangos kūrimą. Vis dėlto, kadangi šie pipelinetampa vis svarbesni, tuo labiau išryškėja būtinybė juos apsaugoti nuo pažeidžiamumų. Šis išsamus tyrimas skirtas spręsti svarbią riziką, nustatytą OWASP 10 svarbiausių rizikos veiksnių sąraše. CI/CD Saugumo rizika: Apsinuodijęs Pipeline Vykdymas (AAP).
Kas yra apsinuodijęs Pipeline Vykdymas (AAP)
Pagal OWASP 10 geriausių CI/CD Saugumo rizikos, “Apsinuodijęs Pipeline Vykdymas (AAP) rizika reiškia užpuoliko, turinčio prieigą prie šaltinio kontrolės sistemų ir neturinčio prieigos prie kūrimo aplinkos, gebėjimą manipuliuoti kūrimo procesu įterpiant kenkėjišką kodą / komandas pipeline konfigūracija, iš esmės „apnuodijimas“ pipeline ir kenkėjiško kodo paleidimas kaip kūrimo proceso dalis“
Keliais žodžiais tariant, apsinuodijęs Pipeline Vykdymas (AAP) atliekamas, kai užpuolikas gali modifikuoti pipeline logika.
Yra du variantai:
- Tiesioginės asmeninės apsaugos priemonės (D-AAP): D-AAP scenarijaus atveju, užpuolikas modifikuoja CI konfigūracijos failą saugykloje, prie kurios jie turi prieigą, arba tiesiogiai perkeldami pakeitimą į neapsaugotą nuotolinę saugyklos šaką, arba pateikdami PR su pakeitimu iš šakos ar išsišakojimo. Nuo CI pipeline Nors vykdymą apibrėžia modifikuoto CI konfigūracijos failo komandos, užpuoliko kenkėjiškos komandos galiausiai paleidžiamos kūrimo mazge, kai kūrimas pipeline suveikia.
- Netiesioginės asmeninės apsaugos priemonės (I-AAP): Tam tikrais atvejais priešininkas, turintis prieigą prie D-AAP, neturi galimybės naudoti SCM saugykla (pvz., jei pipeline yra sukonfigūruota taip, kad CI konfigūracijos failą būtų galima gauti iš atskiros, apsaugotos šakos toje pačioje saugykloje). Tokiu atveju, užuot apsinuodijus pipeline pats užpuolikas į failus, į kuriuos nurodo programa, įterpia kenkėjišką kodą pipeline (pavyzdžiui: scenarijai, į kuriuos daromos nuorodos iš pipeline konfigūracijos failas)
Abiem atvejais „GitHub“ vykdys modifikuotą pipeline be ankstesnės peržiūros ar patvirtinimo.
Ankstyvas AAP aptikimas
Kaip galime aptikti tokio tipo pažeidžiamumą?
Pažiūrėkime šį pavyzdį 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.
Ir bandomojo apvalkalo scenarijaus (runtests.sh) turinys:
#!/usr/bin/bash
echo "Executing Tests script [from user $1 at $2]" >> runtests.out
exit 0
Geriausios pipeline yra gana paprasta: jos tikslas – pateikti recenzentui keletą preliminarių užuominų apie Pull Request (PR) priėmimo procesas:
- Jis bus suaktyvintas užklausos_ištraukimas (t. y. kaskart, kai sukuriamas PR)
- Jis patikrina PR kodą (t. y. įneštą kodą)
- Tai leis sukurti
- Jis atliks pridėto kodo testus (pvz., vykdydamas apvalkalo scenarijų).
3 (sukurti kompiliaciją) ir 4 (vykdyti testą) veiksmai nepavyks, jei kodas nebus kompiliuojamas arba neišlaikys testų. Taigi, šie veiksmai yra būtina, bet nepakankama sąlyga PR priėmimui. Jei jie bus sėkmingi, saugyklos administratorius peržiūrės pateiktą kodą ir, remdamasis tuo, priims / atmes / pakomentuos PR.
Xygeni skaitytuvas
Ksigeni pateikia CLI („Xygeni skaitytuvas“), kurį galima įterpti į pipeline arba paleisti komandinėje eilutėje. „Xygeni Scanner“ apdoros pipelines, kad patikrintų, ar nėra pažeidžiamumų, ir, jei pateikiamas „GitHub“ PAT, prisijungs prie „GitHub“, kad aptiktų pažeidžiamumus organizacijos / saugyklos lygmeniu.
Xygeni inventorius
Kai šioje saugykloje vykdome „Xygeni Scanner“, jis aptinka naudingą išteklių rinkinį ( Xygeni inventorius). Inventoriuje bus daug įvairių tipų CI/CD aktyvai, Kaip antai:
- Geriausios SCM sistema kur saugoma saugykla
- Geriausios SCM Įskiepiai įdiegtas/naudotas
- Geriausios Kodų saugykla pati
- Geriausios SCM Organizacija kur priklauso saugykla
- Geriausios CI/CD Pipelineir darbo vietų
- Geriausios CI/CD sistema paleisti pipelines
- IaC Ištekliai apibrėžta repo
- Išorinis Priklausomybės
- ir tt ..
Mūsų pavyzdyje galime filtruoti atsargas pagal konkretų turto tipą (SCM- ir su CICD susijusį turtą), todėl matome, kad:
- SCM sistema yra „GitHub Cloud“
- Repo saugoma „GitHub Cloud“ ir priklauso konkrečiai „GitHub“ organizacijai.
- Yra du pipelineSukurta naudojant „GitHub“ (CI/CD sistema)
- Kiekvienas pipeline apima vieną konkretų žingsnį
Pasirinkdami aukščiau pateiktą pipeline galime pastebėti keletą pažeidžiamumų:
- At pipeline lygiu, jis yra pažeidžiamas abiejų tiesioginis bei Netiesioginės AAP.
Galime pamatyti tų apsinuodijusiųjų detales Pipeline Vykdymo pažeidžiamumai
„Xygeni“ aptinka, kad tai yra pažeidžiami D-AAP nes jis suveikia dėl Pull Request įvykis ir nėra jokių papildomų saugumo kontrolės priemonių, todėl bet kuris saugyklos naudotojas gali jį modifikuoti pipeline ir šie pakeitimai bus vykdomi be jokio peržiūros ar patvirtinimo.
Tuo pačiu būdu, Xygeni taip pat aptinka, kad yra pažeidžiamas I-PPE dėl iškvietimo į apvalkalo scenarijų iš pipelinebet kuris saugyklos naudotojas gali modifikuoti apvalkalo scenarijų, ir šie pakeitimai bus vykdomi be jokios peržiūros ar patvirtinimo.
Ar norite sužinoti daugiau?
AAP išnaudojimas
Norėdami išnaudoti AAP, panagrinėkime scenarijų, kuriame yra dviejų rūšių repo naudotojai:
- An vidinis vartotojas (vidinis kūrėjas, dirbantis su ta saugykla), turintis rašymo teises saugykloje
- An išorinis vartotojas (išorės kūrėjas, dirbantis su ta saugykla, bet turintis skaitymo teises saugykloje), t. y. neleidžiama kurti saugyklos šakų ir jis priverstas dirbti su atšaka.
Įsivaizduokime, kad abu yra piktavaliai užpuolikai (arba jais apsimetė piktavalis veikėjas). Saugykloje yra kažkokia paslaptis ir abu nori pavogti saugyklos paslaptį ir nusiųskite jį į įsilaužėlių kontroliuojamą serverį. Norėdami tai padaryti, jie pasinaudos Apnuodytu Pipeline Vykdymo pažeidžiamumai pipeline.
Abiem atvejais (išorinio ir vidinio vartotojo) jie atidaro Pull Request su tais pačiais pakeitimais:
- Geriausios pipeline ir apvalkalo scenarijus yra modifikuoti į perskaitykite paslaptį iš aplinkos ir nusiųsti jį į įsilaužėlių kontroliuojamą serverį
Modifikacijos gali būti tokios:
Abu vartotojai sukurs Pull Request su modifikacijomisSukūrus PR, „GitHub“ vykdys abi modifikacijas (nereikia išankstinės peržiūros ar patvirtinimo), dėl to gaunami šie rezultatai:
Tas pats pasakytina ir apie rašymo, ir skaitymo naudotojus. abiem atvejais vykdomos D-PPE ir I-PPE, su tuo skirtumu, kad Skaitymo teisę turintis vartotojas negali pasiekti paslapčių. (!!!!)
Ši priežastis yra ta, kad Jei PR gaunamas iš atšakos, „GitHub“ neleidžia pasiekti saugyklos paslapčių. Nors skaitymo vartotojas negali perskaityti paslapčių, jis/ji vis tiek gali paleisti bet kurią kitą programą. Tipiškas atakos pavyzdys yra PR, kurie atsisiunčia kriptovaliutų kasimo programą, kūrimas, todėl „GitHub“ vykdytojas vykdys kriptovaliutų kasimo programą, kai vykdys užkrėstą programą. pipeline.
Žinoma, tai nėra saugi aplinka!! Ką galėtų padaryti saugyklos administratorius, kad to išvengtų?
Po šiek tiek paieškojimo „Google“ paieškoje, saugyklos administratorius nusprendžia modifikuoti pipeline būti suaktyvintam užklausos_tikslas įvykis. Kodėl? Nes pipelinesuveikti dėl pull_request_target neleidžia vykdyti pipeline pakeitimai, t. y. nepaisant bet kokių naudotojo atliktų pakeitimų, „originalas“ pipeline bus įvykdyta mirties bausmė.
Sekant mūsų pavyzdžiu, ataka bus tokia pati kaip ir anksčiau. Kas nutiks po to? pipeline modifikacija?
Kaip tikėtasi, D-AAP nevykdoma bet kadangi I-PPE vis dar yra, Skaitymo vartotojas dabar gali pasiekti saugyklos paslaptį!!!
Dėl kokios priežasties skaitymo teisę turintis vartotojas dabar turi prieigą prie paslapčių? Nors pipeline negalima modifikuoti, vis tiek galima modifikuoti apvalkalo skriptą. Kai pipeline suveikia pull_request_target, jis bus vykdomas privilegijuotu režimu so Tai taip pat bus apvalkalo scenarijus, todėl apvalkalo scenarijus turi prieigą prie saugyklos paslapčių!!
Prevencinės priemonės
„GitHub“ siūlo keletą priemonių, skirtų apsisaugoti nuo kenkėjiškų PR.
Filialų apsaugos taisyklės
Naudodami „GitHub“ galite apibrėžti šakų apsaugos taisykles pasirinktoms šakoms.
Savo apsaugotoms šakoms galite nurodyti politiką, kuri reikalauja a pull request prieš sujungiant (taip pat papildomos sąlygos, pvz., reikiamas patvirtinimų skaičius, kodo savininkų peržiūros ir kt.)
Pora sąlygų, į kurias reikia atkreipti ypatingą dėmesį, yra šios:
- "Leisti nurodytiems veikėjams apeiti privalomą pull requests".
- "Neleisti apeiti aukščiau nurodytų nustatymų"
Nors dauguma sąlygų sugriežtina politiką, šios sąlygos ją sušvelnina, o tai gali atverti duris kenkėjiškai veiklai, pavyzdžiui, jei prisijungimo duomenis pavagia „privilegijuoti“ subjektai.
Apriboti GITHUB_TOKEN teises (mažiausios privilegijos)
Apribokite „GitHub“ prieigos rakto teises tik iki būtinų; tokiu būdu, net jei užpuolikams pavyktų pažeisti jūsų pipeline, jie daug ką negalės padaryti.
Venkite eilučių interpoliacijos naudodami pipeline aplinkos kintamieji
Kai naudojate kai kuriuos įvesties kintamuosius savo pipeline, atminkite, kad pagal numatytuosius nustatymus jie turėtų būti laikomi „nepatikimais“ duomenimis (jų turinį kontroliuoja galutinis vartotojas). Žr. Nepatikimi veiksmai ir darbo eigos yra saugios bei Sužinokite apie „Github“ veiksmus.
Įvesties kintamiesiems įterpti į scenarijus visada reikėtų naudoti aplinkos kintamuosius, o ne eilučių interpoliaciją.
Darbo eigų vykdymo ir patvirtinimo reikalavimai
Dėl visuomenės saugyklos, „GitHub“ leidžia nurodyti Kaip dirbti su „išoriniais“ PR.
„GitHub“ organizacijos nustatymuose („Organizacija >> Nustatymai >> Veiksmai >> Bendrieji“) nurodoma, kaip valdyti išorinius PR:
Pagal numatytuosius nustatymus „GitHub“ pirmą kartą prisidedantiems asmenims reikės PR patvirtinimo, todėl kenkėjiškų užklausų atakos bus sudėtingesnės. Net ir tokiu atveju užpuolikas gali įgyti projekto prižiūrėtojų pasitikėjimą, pavyzdžiui, prisidėdamas prie nekaltų dalykų. pull request prieš tikrąją ataką.
Šia prasme, Trečias variantas (reikalavimas visų išorinių bendradarbių patvirtinimo) suteikia aukštesnį kontrolės lygį.
Dėl privatus „GitHub“ taip pat teikia naudingą kontrolę tiek organizacijos, tiek saugyklos lygmeniu.
"Vykdyti darbo eigas iš Pull Requests„“ (pagal numatytuosius nustatymus nepažymėta) leidžia vartotojams vykdyti darbo eigas iš atskirų PR (naudojant GITHUB_TOKEN su tik skaitymo teisėmis ir be prieigos prie slaptų raktų). Pasirinkus šią parinktį kartu su paskutine („Reikalauti patvirtinimo šakotųjų PR darbo eigoms“), galite pasiekti panašią politiką kaip ir privačių repo sandorių atveju (kaip parodyta aukščiau).
Kaip matėme PPE išnaudojimo atveju iš perskaityto vartotojo, leidžia vykdyti darbo eigas iš šakutės pull requests yra nesaugu!!
Likusios parinktys („Siųsti rašymo žetonus į darbo eigas iš šakotosios dalies pull requests"Ir"Siųsti paslaptis ir kintamuosius į darbo eigas iš pull requests) sumažinti saugumo lygį taikoma šakinėms PR.
Šią atskyrimo politiką galite apibrėžti organizacijos arba saugyklos lygmeniu. Jei politika išjungta organizacijos lygmeniu, jos negalima įjungti saugyklos lygmeniu. Tačiau jei politika įjungta organizacijos lygmeniu, ją galima išjungti saugyklos lygmeniu.
Priminti
Tikimės, kad matėte, ką reiškia turėti tam tikrų pipeline pažeidžiamas apsinuodijimo Pipeline Vykdymas. Tai per lengva commit pažeidžiamas pipeline, ir sunku parašyti saugų.
Todėl labai vertinga naudoti „Xygeni“ skaitytuvą, kad būtų galima žinoti apie tokius pažeidžiamumus.
Negalite išspręsti pažeidžiamumo, nebent žinote apie jo egzistavimą!!
Bet... vis dar yra neišspręstas klausimas... Kaip išvengti I-PPE?
Tai bus mūsų kito įrašo tema 🙂 … Netiesiogiai apsinuodijęs Pipeline Vykdymas (I-AAP) !!
