GH Actions - Cache Poisoning

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

• Ako želite da vidite vašu kompaniju reklamiranu na HackTricks-u ili preuzmete HackTricks u PDF formatu proverite SUBSCRIPTION PLANS!

• Nabavite zvanični PEASS & HackTricks swag

• Otkrijte The PEASS Family, našu kolekciju ekskluzivnih NFT-ova

• Pridružite se 💬 Discord grupi ili telegram grupi ili nas pratite na Twitter-u 🐦 @hacktricks_live.

• Podelite svoje hakovanje trikove slanjem PR-ova na HackTricks i HackTricks Cloud github repozitorijume.

Za dalje detalje pogledajte originalni post https://scribesecurity.com/blog/github-cache-poisoning/

Trovanje keša

Git akcija action/cache uvodi mehanizam keširanja u proces kontinuirane integracije (CI), obuhvatajući dve ključne faze:

1. Pokreni akciju: Ova faza uključuje pretragu i dobavljanje keširanih podataka tokom CI izvršavanja. Pretraga koristi jedinstveni ključ keša, dajući dva rezultata:

• Keš pogodak: Traženi podaci se nalaze u kešu i stoga se odmah dobavljaju za upotrebu.

• Keš promašaj: Nema podudaranja podataka u kešu, što dovodi do svežeg preuzimanja potrebnih datoteka i direktorijuma, slično kao kod prvog zahteva.

1. Post Workflow akcija: Ova faza je posvećena keširanju podataka nakon CI workflow-a. Konkretno, ako se dogodi keš promašaj tokom izvršavanja akcije, trenutno stanje određenih direktorijuma se kešira koristeći pruženi ključ. Ovaj proces je automatizovan i ne zahteva eksplicitno pozivanje.

Mere bezbednosti: Izolacija keša i ograničenja pristupa

Da bi se održala bezbednost i osigurala izolacija keša, primenjuju se ograničenja pristupa, stvarajući logičku separaciju između različitih grana. Na primer, keš kreiran za granu Feature-A (sa bazom u glavnoj grani) neće biti dostupan za pull zahtev za granu Feature-B (takođe baziranu na glavnoj grani).

Akcija keša se pridržava određenog redosleda pretrage:

• Prvo traži keš pogotke unutar iste grane kao i izvršavanje workflow-a.

• Ako ne uspe, proširuje pretragu na nadređenu granu i druge uzvodne grane.

Važno je napomenuti da je pristup kešu ograničen na granu, proteže se na sve workflow-e i izvršavanja određene grane. Dodatno, GitHub primenjuje pravilo samo za čitanje za unose keša nakon što su kreirani, zabranjujući bilo kakve izmene.

Implikacija u stvarnom svetu: Od napada sa niskim do napada sa visokim privilegijama u workflow-u

Ilustrativni CI scenario prikazuje kako napadač može iskoristiti trovanje keša da bi eskalirao privilegije od workflow-a sa niskim privilegijama do onog sa visokim privilegijama:

• Workflow Unit-test, odgovoran za pokretanje jediničnih testova i alata za pokrivenost koda, pretpostavlja da koristi kompromitovan ili ranjiv alat. Ovaj workflow koristi Git akciju action/cache, čime keš postaje dostupan svakom workflow-u.

• Workflow Release, zadužen za izgradnju i objavljivanje aplikacionog artefakta, optimizuje svoje operacije keširanjem Golang zavisnosti.

U ovom scenariju, workflow za jedinično testiranje uvodi zlonamerni unos u keš zamenom legitimne Golang biblioteke za logovanje (`go