Sa aming nakaraang post, nakita namin kung paano matukoy at maprotektahan laban sa Direktang Pagkalason Pipeline Pagpapatupad (D-PPE). Nakita rin namin kung paano matukoy ang kahinaang iyon gamit ang Xygeni Scanner, pati na rin ang ilang mekanismo ng proteksyon.
Nakalason Pipeline Pagpapatupad (PPE) ay nalilikha kapag maaaring baguhin ng umaatake ang pipeline lohika sa alinman sa dalawang paraan:
- Sa pamamagitan ng pagbabago sa CI config file (ang pipeline) -> Direktang PPE (D-PPE)
- Sa pamamagitan ng pagbabago ng mga file na tinutukoy ng pipeline (halimbawa: mga script na isinangguni mula sa loob ng pipeline file ng pagsasaayos) -> Hindi direktang PPE (I-PPE)
Sa post na ito, tatalakayin natin nang malalim ang Indirect PPE. Ngunit, bago iyon, at bilang pandagdag sa aking nakaraang post, tingnan muna natin kung paano pinamamahalaan ng GitHub ang pagpapatupad ng pipelineat ano ang mga mekanismo ng proteksyon laban sa D-PPE.
Paano pinoprotektahan ng GitHub ang pagpapatupad ng pipelinegaling ba sa mga PR?
Paano gumagana ang GitHub patungkol sa pagpapatupad ng binagong pipelines?
Binago pipelinemaaaring magmula ang mga Push o Pull Requests (PR). Bilang isang pangunahing pinakamahusay na kasanayan, lubos na inirerekomenda na iwasan ang anumang direktang "pagtulak" sa isang protektadong sangay at gamitin Pull Requests bilang isang mekanismo upang ipatupad ang ilang pagsusuri bago tanggapin ang anumang iniambag na code.
Pull Requests maaaring magmula sa dalawang magkaibang pinagmulan:
- Mga PR na nagmumula sa mga tinidor
- Mga PR na nagmumula sa sanga
Mga PR mula sa mga tinidor maaaring manggaling sa alinman sa publiko or pribado repositoriya.
Habang hinaharap natin ang PPE (Poisoned Pipeline (Pagpatupad), ang pangunahing punto natin ay hindi ang "pagtanggap" ng isang PR kundi ang pagpapatupad ng isang binagong pipeline habang nasa proseso ng pagtanggap/pag-apruba ng PR. Sa kaibuturan ng isang pag-atake sa PPE, mayroong hindi sinasadyang pagpapatupad ng isang "malisyoso" na binago pipeline.
Sa ilang salita, Nalason Pipeline Ang pagpapatupad (PPE) ay ginagawa kapag maaaring baguhin ng umaatake ang pipeline lohika.
Mayroong dalawang variant:
- Direktang PPE (D-PPE): Sa isang senaryo ng D-PPE, Binabago ng attacker ang CI config file sa isang repositoryo, mayroon silang access sa, alinman sa pamamagitan ng direktang pagtulak ng pagbabago sa isang walang proteksyong remote branch sa repo, o sa pamamagitan ng pagsusumite ng PR kasama ang pagbabago mula sa isang branch o isang fork. Simula noong CI pipeline Ang pagpapatupad ay tinutukoy ng mga utos sa binagong CI configuration file, ang mga malisyosong utos ng attacker ay kalaunan ay tatakbo sa build node kapag ang build pipeline ay na-trigger.
- Hindi direktang PPE (I-PPE): Sa ilang mga kaso, ang posibilidad ng D-PPE ay hindi magagamit ng isang kalaban na may access sa isang SCM imbakan (hal. kung ang pipeline ay na-configure upang hilahin ang CI configuration file mula sa isang hiwalay at protektadong sangay sa parehong repository). Sa ganitong sitwasyon, sa halip na lasunin ang pipeline mismo, ang isang attacker ay nag-iinject ng malisyosong code sa mga file na tinutukoy ng pipeline (halimbawa: mga script na isinangguni mula sa loob ng pipeline file ng pagsasaayos)
Sa parehong mga kaso, Ipapatupad ng GitHub ang binagong pipeline nang hindi nangangailangan ng naunang pagsusuri o pag-apruba.
Mga PR mula sa mga fork on publiko Repos
Pinapayagan ng GitHub ang pag-configure ng gawi kapag pinoproseso Mga PR na nagmumula sa mga fork sa mga pampublikong repo.
Kapag ang isang PR ay nagmumula sa isang fork, palaging pinipilit ng GitHub ang ilang antas ng "pag-apruba" bago isagawa ang pipeline kaugnay ng PRAng antas ng pagsang-ayon na ito ay nagpapalit mula sa mahina patungo sa mahigpit na pagsang-ayon.
At Antas ng organisasyon (Org>>Mga Setting>>Mga Pagkilos>>Pangkalahatan), maaari kang pumili mula sa ilang mga opsyon sa "pag-apruba":
Ang pinakamahigpit ay ang huli ("Humingi ng pag-apruba mula sa lahat ng panlabas na kolaborator"") dahil ang GitHub ay palaging mangangailangan ng pag-apruba kapag ang PR ay nagmumula sa mga fork mula sa mga panlabas na collaborator.
Ngunit kahit sa mahigpit na kasong ito, mayroon pa ring mga mga pagkakaiba sa pagitan ng mga collaborator na may mga pahintulot sa pagbasa at pagsulat.
- Kapag ang PR ay nagmumula sa isang basahin gumagamit, ang pagpapatupad ng pipeline ay NATIGIL hanggang sa magkaroon ng pag-apruba ng mga pagbabago. Kung ok ang pag-apruba, kung gayon ang binagong pipeline ay naisakatuparan.
- Kapag ang PR ay nagmumula sa isang magsulat gumagamit, ang hindi kailangan ng pag-apruba at ang binagong pipeline ay palaging pinapatay!!
Bilang konklusyon, ang mga PR na nagmumula sa mga fork sa mga pampublikong repositoryo ay bahagyang protektado laban sa PPE. Mayroong ilang proteksyon laban sa mga panlabas (read) na user, ngunit walang kaugnayan sa mga panloob (write) na user.
Paano kung Mga PR na nagmumula sa mga fork mula sa mga pribadong repo?
Mga PR mula sa mga fork on pribado Repos
Sa sitwasyong ito, nagbibigay ang GitHub ng ilang kapaki-pakinabang na setting ng configuration.
Maaaring i-configure ang mga setting sa itaas sa org o sa repo antas.
Kailan walang opsyon na nasuri, gagawin ng GitHub humingi ng pagsang-ayon at hindi nito isasagawa ang binagong pipelineIto ang pinakaligtas na konpigurasyon!!
Ang pinaka-hindi ligtas na konpigurasyon ay kapag "Patakbuhin ang mga daloy ng trabaho mula sa fork pull request"ay nasuriSa kasong ito, pareho para sa parehong mga gumagamit ng read at write, awtomatikong isasagawa ng Github ang binagong pipeline!! At ang sitwasyong ito ay maaaring maging pantay mas masahol kung "Magpadala ng mga write token sa mga workflow mula sa fork pull requests"At"Magpadala ng mga sikreto at variable sa mga daloy ng trabaho mula sa fork pull requests"ay naka-check. Huwag gawin ito maliban kung malinaw na makatwiran!!
Kung "Kinakailangan ang pag-apruba para sa tinidor pull request Workflows"Kung nasuri, medyo pinahusay ang sitwasyon sa itaas: Hihingi ng pag-apruba ang GitHub at hindi isasagawa ang binagong pipeline para sa read user, ngunit isasagawa pa rin nito ito para sa isang write user.
Nakita ang mga tinidor, paano naman Mga PR na nagmumula sa mga sangay?
Mga PR mula sa sanga
Para maprotektahan ang sitwasyong ito, dapat kang umasa sa Mga Panuntunan sa Proteksyon ng Sangay.
Sa antas ng repo, maaari kang lumikha ng mga patakaran sa proteksyon ng sangay para sa anumang sangay. Ang mga patakarang ito ay nagdaragdag ng ilan mga limitasyon sa pagbabago ng mga protektadong sanga.
Bagama't kino-configure mo ang isang panuntunan sa "Mangangailangan ng a pull request bago pagsamahin"At"Kinakailangan ang mga pag-apruba", ang binago pipeline ay awtomatikong isasagawa sa oras ng paglikha ng PRAng "pag-apruba" ay ilalapat lamang sa aksyon ng pagsasama.
Paano naman ang Indirect Poisoned? Pipeline Pagpapatupad
Gaya ng nakita natin sa itaas, ang D-PPE ay maaaring mabawasan sa pamamagitan ng paggamit ng pull_request_target, ngunit ito hindi naaangkop sa I-PPE.
Kung gagamit ka ng pull_request_target, ang default na checkout ay ang base code. Ngunit kung gusto mong i-validate ang ilang check sa contributed code (PR code), kailangan mong tahasang i-checkout ang PR code. Samakatuwid, kung binago ng PR code ang anumang shell script na ginamit ng pipeline, ang "base" (ligtas) pipeline tatawagin ang "binagong" shell script → Indirect PPE!!
Medyo mas kumplikado ang solusyon dito (walang mahiwagang solusyon tulad ng pull_request_target).
Ang aming pipeline ay ligtas na ngayong i-D-PPE dahil ginagamit natin ang pull_request_target. Ngunit mahina pa rin ito sa I-PPE.
Sa ating halimbawa ng pagsubok, kailangan nating suriin ang PR code para magawa ang build, ngunit ang mga pagsubok ay isinasagawa sa artifact na nabuo ng build.
Kaya .. Bakit hindi mo tingnan ang parehong codebase?
- Tingnan ang PR code dahil ang contributed code ang gusto nating buuin at subukan
- Suriin ang Base code upang patakbuhin ang orihinal na bersyon ng pipeline at ang mga script ng pagbuo/pagsusulit
Maaaring gawin ito ng sinusuri ang mga codebase na iyon sa iba't ibang folder: ang base code ay maaaring i-check out sa root folder, at ang PR sa ibang folder. Sa kasong ito, isasagawa natin ang build at ang test script mula sa root folder laban sa code na inilagay sa bagong folder.
Siyempre, madali lang itong solusyon!! Pero, para sa layunin ng pag-aaral, gusto kong magpakilala ng isang medyo kawili-wiling variant (…)
GitHub daloy ng trabaho pangyayaring nag-trigger
Bukod sa pull_request_target, ang GitHub ay nagbibigay ng isa pang trigger event: daloy ng trabahoAng kaganapang ito ay nagbibigay-daan pagpapatupad ng isang pipeline nakakondisyon sa iba pipelinepagbitay.
daloy ng trabaho at pull_request_target Ang mga trigger ay magkatulad sa isang aspeto: pareho itong isasagawa sa privileged mode at, sa kabila ng mga pagbabago sa PR, ang base pipeline ay papatayin!!
Tingnan natin ang ating kasalukuyan pipeline:
Ligtas sa D-PPE ang build section, ngunit mahina pa rin sa I-PPE ang test section.
Ang pipeline ligtas ang sarili nito sa D-PPE dahil sa pull_request_target gatilyo. Ngunit ang hakbang sa pagsubok ay mahina pa rin sa I-PPE dahil sa paggamit ng isang panlabas na shell script.
Pag-iwas sa I-PPE
Ang layunin ng nabanggit pipeline ay upang buuin at subukan ang iniambag na code, dahil ligtas ito sa PPE.
Kaya .. Bakit hindi hatiin ang pipeline sa dalawa? Isa para sa pagbuo at isa pa para sa pagsubok..
- Ang 1st pipeline (Bumuo ng CI) gagawin tingnan ang PR code (para mabuo ito), gawin ang build at bumuo ng isang artifact.
- Ang 2nd pipeline (Pagsubok CI) gagawin tingnan ang Base code (upang maiwasan ang pagbabago sa shell script) at isagawa ang mga orihinal na script laban sa artifact.
- Para i-synchronize ang Test CI pipeline para tumakbo PAGKATAPOS ng Build CI pipeline, gagamitin natin ang daloy ng trabaho gatilyo
Sa ganitong paraan:
- pipeline Bumuo ng CI is ligtas Sa pareho D-PPE (dahil sa pull_request_target) At I-PPE (dahil hindi na nito isinasagawa ang shell script).
- pipeline Pagsubok CI ding ligtas Sa pareho D-PPE (dahil sa daloy ng trabaho) At I-PPE (dahil sinusuri nito ang base code upang makuha ang orihinal na script ng shell)
Tingnan natin ang code ng pareho pipelineayon sa mga pagbabagong ito …
1st pipeline (Bumuo ng CI):
2nd pipeline (Pagsubok CI):
Naku… magandang solusyon!! Pero ….. Ligtas ba tayo? Natatakot ako na hindi 😭
Tunay nga, may ipinakilala kaming bagong kahinaan!! Alin? Ito ang magiging paksa ng aming susunod na post 🙂 … Abangan!!
PS: Pasensya na, hindi ako pwedeng manahimik 🤐 ..Nabalitaan mo na ba ang tungkol sa Pagkalason sa Artifact ? 😂
