Ankstesniame mūsų įraše matėme, kaip aptikti ir apsisaugoti nuo tiesioginio apsinuodijimo Pipeline Vykdymas (D-PPE). Taip pat matėme, kaip aptikti tą pažeidžiamumą naudojant Xygeni skaitytuvas, taip pat kai kuriuos apsaugos mechanizmus.
Apsinuodijęs Pipeline Vykdymas (AAP) sukuriamas, kai užpuolikas gali modifikuoti pipeline logika vienu iš dviejų būdų:
- Modifikuojant CI konfigūracijos failą (t. y. pipeline) -> Tiesioginės asmeninės apsaugos priemonės (D-AAP)
- Modifikuojant failus, į kuriuos nurodo pipeline (pavyzdžiui: scenarijai, į kuriuos daromos nuorodos iš pipeline konfigūracijos failas) -> Netiesioginės asmeninės apsaugos priemonės (I-AAP)
Šiame įraše mes išsamiai aptarsime netiesioginius AAP. Tačiau prieš tai, papildydami mano ankstesnį įrašą, pirmiausia pažiūrėkime, kaip „GitHub“ valdo vykdymą. pipelineir kokie yra apsaugos mechanizmai nuo D-AAP.
Kaip „GitHub“ apsaugo vykdymą? pipelinear tai iš PR?
Kaip „GitHub“ veikia modifikuotų programų vykdymo atžvilgiu? pipelines?
Modifikuota pipelinegali kilti iš „Pushes“ arba Pull Requests (PR). Kaip pagrindinė geriausia praktika, primygtinai rekomenduojama vengti tiesioginio „siuntimo“ į apsaugotą šaką ir naudoti Pull Requests kaip mechanizmas, užtikrinantis tam tikrą peržiūrą prieš priimant bet kokį pateiktą kodą.
Pull Requests gali kilti iš dviejų skirtingų šaltinių:
- PR, gaunami iš šakės
- PR, gaunami iš šakos
PR iš šakės gali kilti iš bet kurio visuomenės or privatus saugyklos.
Kadangi susiduriame su AAP (apnuodytomis Pipeline Vykdymas), mūsų pagrindinis tikslas yra ne PR „priėmimas“, o modifikuoto vykdymas pipeline PR priėmimo / patvirtinimo proceso metu. AAP atakos esmė – netyčinis „kenkėjiškos“ modifikuotos funkcijos vykdymas. pipeline.
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.
PR iš šakių visuomenės poilsis
„GitHub“ leidžia konfigūruoti elgesį apdorojimo metu PR, gaunami iš viešųjų saugyklų atšakų.
Kai PR gaunamas iš atšakos, „GitHub“ visada priverčia gauti tam tikrą „patvirtinimo“ lygį prieš vykdydamas pipeline susijęs su PRŠis pritarimo lygis svyruoja nuo silpno iki griežto pritarimo.
At Organizacijos lygis (Organizacija >> Nustatymai >> Veiksmai >> Bendrieji), galite rinktis iš kelių „patvirtinimo“ parinkčių:
Griežčiausias yra paskutinis („Reikalauti visų išorinių bendradarbių patvirtinimo“), nes „GitHub“ visada reikalaus patvirtinimo, kai PR gaunamas iš išorinių bendradarbių atšakų.
Bet net ir šiuo griežtu atveju yra skirtumai tarp bendradarbių, turinčių skaitymo ir rašymo teises.
- Kai PR ateina iš skaityti vartotojas vykdymas pipeline yra SUSTABDYTA kol nebus patvirtinti pakeitimai. Jei patvirtinimas geras, tada modifikuotas pipeline yra įvykdytas.
- Kai PR ateina iš rašyti vartotojas patvirtinimo nereikia, o pakeistas pipeline visada vykdomas!!
Apibendrinant galima teigti, kad PR, gaunami iš viešųjų saugyklų atšakų (fork), yra silpnai apsaugoti nuo PPE. Yra tam tikra apsauga nuo išorinių (skaitymo) vartotojų, bet nieko, kas susiję su vidiniais (rašymo) vartotojais.
Kaip apie PR, gaunami iš privačių saugyklų atšakų?
PR iš šakių privatus poilsis
Tokiu atveju „GitHub“ pateikia keletą naudingų konfigūracijos nustatymų.
Aukščiau pateiktus nustatymus galima konfigūruoti adresu organas arba atpirkimo lygį.
Kada nepažymėta jokia parinktis„GitHub“ tai padarys prašyti patvirtinimo bei jis nevykdys modifikuoto pipelineTai saugiausia konfigūracija!!
Geriausios nesaugiausia konfigūracija yra kada "Vykdyti darbo eigas iš šakutės pull request„yra pažymėta“Šiuo atveju, tiek skaitymo, tiek rašymo vartotojams, „Github“ automatiškai vykdys modifikuotą pipeline!! Ir ši situacija gali būti netgi blogiau jei "Siųsti rašymo žetonus į darbo eigas iš šakotosios dalies pull requests"Ir"Siųskite paslaptis ir kintamuosius į darbo eigas iš šakės pull requests„yra pažymėti“. Nedarykite to, nebent tam būtų aiškiai pagrįsta!!
Jei „Reikalingas patvirtinimas dėl išsišakojimo pull request Darbo eigos„“, aukščiau pateikta situacija šiek tiek pagerėja: „GitHub“ prašys patvirtinimo ir nevykdys modifikuoto pipeline skaitymo vartotojui, bet vis tiek vykdys jį rašymo vartotojui.
Matytos šakės, o kaip? Iš filialų gaunami PR?
PR iš šakos
Norėdami apsisaugoti nuo šio scenarijaus, turite pasikliauti Filialų apsaugos taisyklės.
Saugyklos lygmenyje galite sukurti šakos apsaugos taisykles bet kuriai šakai. Šios taisyklės prideda tam tikrų Apsaugotų šakų modifikavimo apribojimai.
Nors taisyklę konfigūruojate kaip „Reikalauti pull request prieš sujungiant"Ir"Reikalauti patvirtinimų" modifikuotas pipeline bus automatiškai įvykdytas sukūrus PR„Patvirtinimas“ bus taikomas tik sujungimo veiksmui.
O kaip dėl netiesioginio apsinuodijimo? Pipeline Vykdymas
Kaip matėme aukščiau, D-APE galima sumažinti naudojant užklausos_tikslas, Bet tai netaikoma I-AAP.
Jei naudojate „pull_request_target“, numatytasis patikrinimas bus bazinis kodas. Tačiau jei norite patvirtinti kai kuriuos patikrinimus pateiktame kode (PR kode), turite aiškiai patikrinti PR kodą. Todėl, jei PR kodas pakeitė bet kurį iškviesto apvalkalo scenarijų pipeline, „bazė“ (saugi) pipeline iškvies „modifikuotą“ apvalkalo scenarijų → Netiesioginis PPE!!
Šios problemos sprendimas yra šiek tiek sudėtingesnis (nėra tokios stebuklingos priemonės kaip „pull_request_target“).
Mūsų pipeline dabar saugu naudoti D-PPE, nes naudojame „pull_request_target“. Tačiau jis vis dar pažeidžiamas I-PPE.
Mūsų bandymo pavyzdyje, norėdami sukurti kompiliavimą, turime patikrinti PR kodą, tačiau testai vykdomi su kompiliavimo sugeneruotu artefaktu.
Taip .. Kodėl neperžiūrėjus abiejų kodų bazių?
- Patikrinkite PR kodą, nes būtent pateiktą kodą norime sukurti ir išbandyti
- Bazinis kodas, skirtas paleisti originalią versiją, naudojant „Checkout“ pipeline ir kūrimo/testavimo scenarijai
Tai gali būti padaryta patikrinti tas kodo bazes skirtinguose aplankuoseBazinis kodas gali būti perkeltas į šakninį aplanką, o PR – į kitą. Tokiu atveju vykdytume kūrimo ir testavimo scenarijus iš šakninio aplanko su kodu, patalpintu naujame aplanke.
Žinoma, tai paprastas sprendimas!! Bet mokymosi tikslais norėčiau pristatyti gana įdomų variantą (…)
GitHub darbo eigos_vykdymas suaktyvinimo įvykis
Be užklausos_tikslas„GitHub“ pateikia dar vieną paleidimo įvykį: darbo eigos_vykdymasŠis renginys leidžia vykdymas pipeline sąlygotas kitam pipelinevykdymas.
darbo eigos_vykdymas bei užklausos_tikslas Paleidikliai yra panašūs vienu aspektu: abu bus vykdomi privilegijuotu režimu ir nepaisant PR modifikacijų, bazė pipeline bus įvykdyta mirties bausmė!!
Pažiūrėkime mūsų dabartinį pipeline:
Konstravimo sekcija yra saugi D-PPE, tačiau bandymų sekcija vis dar pažeidžiama I-PPE.
Geriausios pipeline pats yra saugus D-AAP dėl užklausos_tikslas paleidiklis. Tačiau bandymo žingsnis vis dar pažeidžiamas I-PPE dėl išorinio apvalkalo scenarijaus iškvietimo.
Venkite naudoti individualias asmenines apsaugos priemones (I-AAP)
Aukščiau pateikto tikslas pipeline yra sukurti ir išbandyti pateiktą kodą, užtikrinant, kad jis būtų saugus AAP.
Taip .. Kodėl nepadalinti? pipeline į dvi? Vienas statyboms, kitas bandymams..
- 1-asis pipeline (Sukurti CI) būtų patikrinkite PR kodą (norėdami jį sukurti), sukurkite konstrukciją ir sugeneruokite artefaktą.
- "2" pipeline (Testo CI) būtų patikrinkite bazinį kodą (kad išvengtumėte apvalkalo scenarijaus modifikavimo) ir vykdyti originalius scenarijus prieš artefaktą.
- Norėdami sinchronizuoti bandymo CI pipeline paleisti PO „Build CI“ pipeline, mes naudosime darbo eigos_vykdymas sukelti.
Tokiu būdu:
- pipeline Sukurti CI is saugus abiems D-AAP (dėl užklausos_tikslas) ir I-AAP (nes jis nebevykdo apvalkalo scenarijaus).
- pipeline Testo CI Taip pat saugus abiems D-AAP (dėl darbo eigos_vykdymas) ir I-AAP (nes jis patikrina bazinį kodą, kad gautų originalų apvalkalo scenarijų)
Pažiūrėkime abiejų kodą pipelinepagal šias modifikacijas…
1. pipeline (Sukurti CI):
2. pipeline (Bandymo pasikliautinumas):
Oho... puikus sprendimas!! Bet... Ar mes saugūs? Bijau, kad ne 😭
Iš tiesų, pristatėme naują pažeidžiamumą!! Kokį? Apie tai papasakosime kitame mūsų įraše 🙂 … Sekite naujienas!!
PS: Atsiprašau, negaliu tylėti 🤐 ..Ar girdėjai apie Artefaktų apsinuodijimas ? 😂
