V našom predchádzajúcom príspevku, Videli sme, ako odhaliť priamu otravu a ako sa pred ňou chrániť. Pipeline Exekúcia (D-PPE). Videli sme tiež, ako túto zraniteľnosť odhaliť pomocou Skener Xygeni, ako aj niektoré ochranné mechanizmy.
otrávená Pipeline Vykonanie (PPE) sa vytvorí, keď útočník môže upraviť pipeline logiku jedným z dvoch spôsobov:
- Úpravou konfiguračného súboru CI ( pipeline) -> Priame OOP (D-OOP)
- Úpravou súborov, na ktoré odkazuje pipeline (napríklad: skripty, na ktoré sa odkazuje v rámci pipeline konfiguračný súbor) -> Nepriame OOP (I-OOP)
V tomto príspevku sa podrobne ponoríme do nepriameho PPE. Ale predtým, a ako doplnok k môjmu predchádzajúcemu príspevku, sa najprv pozrime, ako GitHub riadi vykonávanie... pipelinea aké sú ochranné mechanizmy proti D-OOP.
Ako GitHub chráni vykonávanie pipelinePochádza to od PR?
Ako funguje GitHub, pokiaľ ide o vykonávanie upravených pipelines?
Upravené pipelinemôžu pochádzať z tlačení alebo Pull Requests (PR). Ako hlavný osvedčený postup sa dôrazne odporúča vyhnúť sa akémukoľvek priamemu „push“ do chránenej vetvy a použiť Pull Requests ako mechanizmus na vynútenie určitej kontroly pred prijatím akéhokoľvek prispievaného kódu.
Pull Requests môže pochádzať z dvoch rôznych zdrojov:
- PR pochádzajúce z vidličky
- PR pochádzajúce z vetvy
PR od vidličky môže pochádzať buď z verejnosť or súkromný úložiska.
Keďže máme do činenia s OOPP (ochrana proti otravám Pipeline vykonanie), naším hlavným bodom nie je „prijatie“ žiadosti o prijatie, ale vykonanie upravenej pipeline počas procesu schvaľovania/akceptácie zo strany PR. Jadrom útoku na OOP je neúmyselné spustenie „škodlivého“ modifikovaného pipeline.
V niekoľkých slovách, otrávený Pipeline Exekúcia (OOP) sa vykonáva, keď útočník môže upraviť pipeline logika.
Existujú dva varianty:
- Priame OOP (D-OOP): V scenári D-OOP, útočník upraví konfiguračný súbor CI v repozitári, ku ktorému majú prístup, buď priamym odoslaním zmeny do nechránenej vzdialenej vetvy v repozitári, alebo odoslaním PR so zmenou z vetvy alebo forku. Odkedy CI pipeline Ak je vykonávanie definované príkazmi v upravenom konfiguračnom súbore CI, škodlivé príkazy útočníka sa nakoniec spustia v uzle zostavenia po dokončení zostavenia. pipeline sa spúšťa.
- Nepriame OOP (I-OOP): V určitých prípadoch nie je možnosť D-OOP k dispozícii protivníkovi s prístupom k SCM úložisko (napr. ak pipeline je nakonfigurovaný tak, aby sťahoval konfiguračný súbor CI zo samostatnej, chránenej vetvy v tom istom repozitári). V takomto scenári, namiesto otravy pipeline útočník vloží škodlivý kód do súborov, na ktoré odkazuje pipeline (napríklad: skripty, na ktoré sa odkazuje v rámci pipeline konfiguračný súbor)
V oboch prípadoch, GitHub vykoná upravený súbor pipeline bez nutnosti predchádzajúceho preskúmania alebo schválenia.
PR z vidlíc ďalej verejnosť repo
GitHub umožňuje konfiguráciu správania pri spracovaní PR pochádzajúce z forkov vo verejných repozitároch.
Keď PR prichádza z forku (rozvetvenia), GitHub si vždy vynúti určitú úroveň „schválenia“ pred vykonaním. pipeline spojené s PRTáto úroveň schválenia sa mení od slabého po prísne schválenie.
At Úroveň organizácie (Organizácia >> Nastavenia >> Akcie >> Všeobecné) si môžete vybrať z niekoľkých možností „schválenia“:
Najprísnejší je ten posledný („Vyžadovať súhlas od všetkých externých spolupracovníkov„“), pretože GitHub bude vždy vyžadovať schválenie, keď PR pochádza z forkov od externých spolupracovníkov.
Ale aj v tomto prísnom prípade existujú rozdiely medzi spolupracovníkmi s oprávneniami na čítanie a zápis.
- Keď PR pochádza z čítať používateľ, ten vykonanie pipeline je ZASTAVENÉ kým nedôjde k schváleniu zmien. Ak je schválenie v poriadku, potom sa upravené pipeline je vykonaný.
- Keď PR pochádza z písať používateľ, ten schválenie nie je potrebné a upravené pipeline sa vždy vykonáva!!
Záverom možno povedať, že PR prichádzajúce z forkov na verejných repozitároch sú mierne chránené pred PPE. Existuje určitá ochrana pred externými (čítajúcimi) používateľmi, ale nič, čo by sa týkalo interných (zapisujúcich) používateľov.
A čo PR pochádzajúce z forkov zo súkromných repozitárov?
PR z vidlíc ďalej súkromný repo
V tomto scenári poskytuje GitHub niekoľko užitočných konfiguračných nastavení.
Vyššie uvedené nastavenia je možné nakonfigurovať buď na varhany alebo repo úrovni.
Kedy nie je zaškrtnutá žiadna možnosť, GitHub bude požiadať o schválenie a nevykoná upravenú verziu pipelineToto je najbezpečnejšia konfigurácia!!
najnebezpečnejšia konfigurácia je kedy "Spúšťanie pracovných postupov z forku pull request„je zaškrtnuté“V tomto prípade, rovnako ako pre používateľov s oprávneniami na čítanie aj zápis, Github automaticky vykoná upravený súbor. pipeline!! A táto situácia môže byť dokonca horšie ak „Odoslať tokeny zápisu do pracovných postupov z forku pull requests"A"Odosielanie tajných kódov a premenných do pracovných postupov z forku pull requests„“ sú zaškrtnuté. Nerobte to, pokiaľ to nie je jasne odôvodnené!!
Ak „Vyžadovať schválenie pre vidlicu pull request pracovné postupy„, vyššie uvedená situácia sa trochu vylepší: GitHub požiada o schválenie a nevykoná upravenú úpravu pipeline pre používateľa s oprávnením na čítanie, ale stále sa vykoná pre používateľa s oprávnením na zápis.
Vidličky videné, čo s tým? PR prichádzajúce z pobočiek?
PR od vetvy
Na ochranu v tomto scenári sa musíte spoľahnúť na Pravidlá ochrany pobočiek.
Na úrovni repozitára môžete vytvoriť pravidlá ochrany vetiev pre ľubovoľnú vetvu. Tieto pravidlá pridávajú niektoré obmedzenia úpravy chránených vetiev.
Aj keď nakonfigurujete pravidlo na „Vyžadovať a pull request pred zlúčením"A"Vyžadovať schválenia", upravený pipeline sa automaticky vykoná po vytvorení PR„Schválenie“ sa bude vzťahovať iba na akciu zlúčenia.
A čo nepriama otrava? Pipeline Prevedenie
Ako sme videli vyššie, D-OOP možno zmierniť použitím cieľ_žiadosti_o_pull, ale to nevzťahuje sa na I-OOP.
Ak použijete pull_request_target, predvoleným kódom na kontrolu bude základný kód. Ak však chcete overiť niektoré kontroly v prispievajúcom kóde (PR kóde), musíte explicitne skontrolovať PR kód. Preto, ak PR kód upravil akýkoľvek shell skript volaný programom pipeline, „základňa“ (bezpečná) pipeline spustí „upravený“ shell skript → Nepriamy OOP!!
Riešenie je trochu zložitejšie (neexistuje zázračné riešenie ako pull_request_target).
Naše pipeline je teraz bezpečný pre D-PPE, pretože používame pull_request_target. Stále je však zraniteľný pre I-PPE.
V našom testovacom príklade potrebujeme v podstate skontrolovať PR kód, aby sme mohli zostaviť, ale testy sa vykonávajú na artefakte vygenerovanom zostavením.
Takže .. prečo si nepozrieš obe kódové databázy?
- Pokladňa PR kódu, pretože ide o prispený kód, ktorý chceme zostaviť a otestovať
- Základný kód pre pokladňu na spustenie pôvodnej verzie pipeline a skripty na zostavenie/testovanie
Toto by sa mohlo urobiť kontrola týchto kódových báz do rôznych priečinkovZákladný kód by sa mohol uložiť do koreňového priečinka a žiadosť o zostavenie (PR) do iného priečinka. V tomto prípade by sme spustili zostavenie a testovací skript z koreňového priečinka s kódom umiestneným do nového priečinka.
Toto je samozrejme jednoduché riešenie!! Ale pre účely učenia by som rád predstavil celkom zaujímavý variant (…)
GitHub spustenie_pracovného_postupu spúšťacia udalosť
okrem cieľ_žiadosti_o_pull, GitHub poskytuje ďalšiu spúšťaciu udalosť: spustenie_pracovného_postupuTáto udalosť umožňuje vykonanie pipeline podmienený iným pipelinepoprava.
spustenie_pracovného_postupu a cieľ_žiadosti_o_pull Spúšťače sú si v jednom aspekte podobné: oba sa vykonajú v privilegovanom režime a, napriek úpravám PR, základňa pipeline bude popravený!!
Pozrime sa na našu súčasnosť pipeline:
Výstavná sekcia je bezpečná pre D-OOP, ale testovacia sekcia je stále zraniteľná pre I-OOP.
pipeline sám o sebe je bezpečný pre D-OOP kvôli cieľ_žiadosti_o_pull spúšťač. Testovací krok je však stále zraniteľný voči I-PPE kvôli volaniu externého skriptu shellu.
Vyhýbanie sa I-OOP
Účel vyššie uvedeného pipeline je zostaviť a otestovať prispievaný kód, pričom je bezpečný pre OOP.
Takže .. Prečo nerozdeliť pipeline na dve? Jeden na stavbu a druhý na testovanie..
- Prvý pipeline (Vytvoriť CI) by skontrolovať PR kód (na jeho zostavenie), vytvorte zostavu a vygenerujte artefakt.
- Druhý pipeline (Testovacia CI) by skontrolovať základný kód (aby sa predišlo úprave shellu) a spustite pôvodné skripty proti artefaktu.
- Synchronizácia testovacej CI pipeline spustiť PO zostavení CI pipeline, použijeme spustenie_pracovného_postupu spúšť.
Týmto spôsobom:
- pipeline Vytvoriť CI is bezpečný obom D-OOP (kvôli cieľ_žiadosti_o_pull) a I-OOP (pretože už nespúšťa shellový skript).
- pipeline Testovacia CI je tiež bezpečný obom D-OOP (kvôli spustenie_pracovného_postupu) a I-OOP (pretože kontroluje základný kód, aby získal pôvodný skript shellu)
Pozrime sa na kód oboch pipelinepodľa týchto úprav …
1. pipeline (Vytvoriť CI):
2. pipeline (Testovací interval spoľahlivosti):
Páni... pekné riešenie!! Ale... Sme v bezpečí? Obávam sa, že nie 😭
Vskutku, zaviedli sme novú zraniteľnosť!! Ktorú? To bude témou nášho ďalšieho príspevku 🙂 … Zostaňte naladení!!
PS: Prepáč, nemôžem mlčať 🤐 ..Počuli ste už o Otrava artefaktmi ? 😂
