Integrasi Terus-terusan lan Penerapan Terus-terusan (CI/CD) pipelinenduweni peran penting kanggo nggampangake pangembangan piranti lunak sing efisien. Nanging, amarga iki pipelinedadi saya penting, prentah kanggo nglindhungi saka kerentanan dadi luwih jelas. Investigasi jero iki fokus kanggo ngatasi risiko sing penting sing diidentifikasi ing OWASP Top-10 CI/CD Risiko Keamanan: Keracunan Pipeline Eksekusi (APD).
Apa sing keracunan Pipeline Eksekusi (APD)
Miturut OWASP Top-10 CI/CD Risiko Keamanan, "Racun Pipeline execution (PPE) risiko nuduhake kemampuan penyerang kanthi akses menyang sistem kontrol sumber - lan tanpa akses menyang lingkungan bangunan - kanggo manipulasi proses pambangunan kanthi nyuntikake kode/perintah jahat menyang pambangunan pipeline konfigurasi, ateges 'keracunan' pipeline lan mbukak kode angkoro minangka bagéan saka proses pambangunan"
Ing sawetara tembung, Keracunan Pipeline Eksekusi (APD) digawe nalika penyerang bisa ngowahi pipeline logika.
Ana loro variasi:
- APD langsung (D-PPE): Ing skenario D-PPE, Penyerang ngowahi file konfigurasi CI ing repositori sing bisa diakses, kanthi meksa pangowahan langsung menyang cabang remot sing ora dilindhungi ing repo, utawa kanthi ngirim PR kanthi pangowahan saka cabang utawa fork. Wiwit CI pipeline Eksekusi ditemtokake dening printah ing file konfigurasi CI sing dimodifikasi, printah jahat penyerang pungkasane mlaku ing simpul build sawise build pipeline dipicu.
- APD ora langsung (I-PPE): Ing kasus tartamtu, kemungkinan D-PPE ora kasedhiya kanggo mungsuh sing duwe akses menyang SCM gudang (contone, yen pipeline dikonfigurasi kanggo narik file konfigurasi CI saka cabang sing dilindhungi lan kapisah ing repositori sing padha). Ing kahanan kaya ngono, tinimbang ngracuni pipeline dhewe, penyerang nyuntikake kode jahat menyang file sing dirujuk dening pipeline (contone: skrip sing dirujuk saka njero pipeline berkas konfigurasi)
Ing loro kasus kasebut, GitHub bakal nglakokake sing diowahi pipeline tanpa perlu review utawa persetujuan sadurunge.
Deteksi awal APD
Kepiye carane kita bisa ndeteksi jinis kerentanan iki?
Ayo delengen conto iki pipeline :
name: PR CI
on:
pull_request:
branches: [ main ]
env:
MY_SECRET: ${{ secrets.MY_SECRET }}
jobs:
pr_build_test_and_merge:
runs-on: ubuntu-latest
steps:
# checkout PR code
- name: Checkout repository
uses: actions/checkout@v4
# Simulation of a compilation
- name: Building ...
run: |
echo $MY_SECRET
mkdir ./bin
touch ./bin/mybin.exe
# Simulation of running tests
- name: Running tests ...
id : run_tests
run: |
echo Running tests..
chmod +x runtests.sh
./runtests.sh "${{ github.event.pull_request.user.login }}" "${{ github.workflow }}"
echo Tests executed.
Lan isi skrip shell dummy (runtests.sh):
#!/usr/bin/bash
echo "Executing Tests script [from user $1 at $2]" >> runtests.out
exit 0
The pipeline cukup prasaja: tujuane yaiku menehi sawetara pitunjuk awal marang reviewer kanggo Pull Request Proses panampa (PR):
- Iku bakal dipicu ing panjaluk_tarik (yaiku kapan wae PR digawe)
- Iku mriksa kode PR (yaiku kode sing disumbangake)
- Iku bakal nggawe bangunan
- Iki bakal nglakokake tes ing kode sing disumbangake (contone kanthi nglakokake skrip shell)
Langkah #3 (nggawe build) lan #4 (run test) bakal gagal yen kode ora bisa dikompilasi utawa gagal lulus tes. Dadi, langkah-langkah iki tumindak minangka syarat sing perlu, nanging ora cukup, kanggo nampa PR. Yen sukses, admin repo bakal nerusake kanggo mriksa kode sing disumbangake lan, adhedhasar iku, dheweke bakal nampa/nolak/komentar PR kasebut.
Pemindai Xygeni
Xygeni nyedhiyakake CLI ("Pemindai Xygeni") sing bisa dilebokake ing pipeline utawa mbukak ing baris printah. Xygeni Scanner bakal ngolah pipelines kanggo mriksa kerentanan lan, yen GitHub PAT diwenehake, bakal nyambung menyang GitHub kanggo nemokake kerentanan ing tingkat org/repo.
Inventaris Xygeni
Nalika kita nglakokake Xygeni Scanner ing repo iki, dheweke nemokake sakumpulan aset sing migunani (sing Inventaris Xygeni). Inventaris kasebut bakal diisi karo macem-macem jinis CI/CD aset, kayata:
- The SCM sistem ing ngendi repo disimpen
- The SCM Plugins dipasang/digunakake
- The Kode Repository dhewe
- The SCM Organisasi ing ngendi repo kasebut kagungane
- The CI/CD Pipelinelan Pakaryan
- The CI/CD sistem mlaku ing pipelines
- IaC Resources ditetepake ing repo
- njaba Dependencies
- lsp.
Ing conto kita, kita bisa nyaring Inventaris miturut sawetara jinis aset tartamtu (SCM- lan aset sing ana gandhengane karo CICD), saengga kita bisa ndeleng manawa:
- SCM sistem kasebut yaiku GitHub Cloud
- Repo disimpen ing GitHub Cloud lan kalebu Organisasi GitHub tartamtu
- Ana loro pipelinedidhukung dening GitHub (CI/CD sistem)
- Saben pipeline ngandhut siji langkah tartamtu
Kanthi milih sing kasebut ing ndhuwur pipeline kita bisa ndeleng sawetara kerentanan:
- At pipeline tingkat kasebut, iku rentan marang loro-lorone Direct lan APD ora langsung.
Kita bisa ndeleng rincian saka wong-wong sing keracunan Pipeline Kerentanan eksekusi
Xygeni ndeteksi yen iku rentan marang D-PPE amarga iku dipicu ing Pull Request acara lan ora ana kontrol keamanan tambahan, mula pangguna repo apa wae bisa ngowahi pipeline lan modifikasi kasebut bakal ditindakake tanpa ana review utawa persetujuan.
Ing pangertèn sing padha, Xygeni uga ndeteksi manawa iku rentan marang I-PPE amarga ana panggilan menyang skrip shell saka pipeline: panganggo repo apa waé bisa ngowahi skrip shell lan modifikasi kasebut bakal dieksekusi tanpa review utawa persetujuan.
Apa sampeyan pengin ngerti luwih akeh?
Nggunakaké APD
Kanggo nggunakake APD, ayo dipikirake skenario ing ngendi ana rong jinis panganggo repo:
- An panganggo internal (pangembang internal sing nggarap repo kasebut), kanthi ijin nulis ing repo kasebut
- An panganggo njaba (pangembang outsourcing sing nggarap repo kasebut nanging nganggo ijin maca ing repo), yaiku ora diidini nyabang repo lan dipeksa nggarap fork.
Ayo bayangna yen loro-lorone penyerang jahat (utawa ditiru dening aktor jahat). Repo kasebut ngemot sawetara rahasia lan loro-lorone pengin nyolong rahasia repo lan ngirim menyang server sing dikontrol hacker. Kanggo nindakake, dheweke bakal njupuk kauntungan saka Poisoned Pipeline Kerentanan eksekusi saka pipeline.
Ing loro kasus kasebut (pangguna eksternal lan internal), dheweke mbukak Pull Request kanthi modifikasi sing padha:
- The pipeline lan skrip shell wis diowahi kanggo maca rahasiane saka lingkungan lan kirim menyang server sing dikontrol hacker
Modifikasi bisa uga kaya ing ngisor iki:
Kaloro pangguna bakal nggawe Pull Request karo modifikasiSawise PR digawe, GitHub bakal nglakokake loro modifikasi kasebut (tanpa perlu review utawa persetujuan sadurunge), sing nyebabake ing ngisor iki:
Padha kanggo pangguna nulis lan maca, ing loro kasus kasebut D-PPE lan I-PPE ditindakake, kanthi bedane sing panganggo sing wis maca ora bisa ngakses rahasia kasebut. (!!!!)
Alesan iki amarga, ing kasus PR sing asale saka fork, GitHub ora ngidini akses menyang rahasia repo. Senajan panganggo sing maca ora bisa maca rahasia, dheweke isih bisa mbukak program liyane. Tuladha serangan sing umum yaiku nggawe PR sing ndownload crypto miner, mula GitHub runner bakal nglakokake crypto miner nalika nglakokake poisoned. pipeline.
Iki dudu lingkungan sing aman, mesthi wae!! Apa sing bisa ditindakake admin repo kanggo nyegah iki?
Sawise nggoleki ing Google, admin repo mutusake kanggo ngowahi pipeline kanggo dipicu ing target_panjaluk_tarik acara. Kenapa? Amarga pipelines sing dipicu ing pull_request_target ora ngidini eksekusi pipeline modifikasi, yaiku sanajan ana modifikasi pangguna, "asli" pipeline bakal dieksekusi.
Niru conto kita, serangan kasebut bakal padha karo sadurunge. Apa sing bakal kedadeyan sawise iki pipeline modifikasi?
Minangka samesthine, D-PPE ora dileksanakake nanging, amarga I-PPE isih ana, panganggo sing wis diwaca saiki bisa ngakses rahasia repo!!!
Apa alesane pangguna sing wis maca saiki duwe akses menyang rahasia? Sanajan pipeline ora bisa diowahi, isih bisa ngowahi skrip shell. Nalika pipeline dipicu ing pull_request_target, bakal dieksekusi ing mode istimewa so iku uga bakal dadi skrip shell, sing nyebabake skrip shell nduweni akses menyang rahasia repo!!
Ukuran Nyegah
GitHub nyedhiyakake sawetara langkah kanggo nglindhungi saka PR sing mbebayani.
Aturan perlindungan cabang
Kanthi GitHub sampeyan bisa nemtokake Aturan Perlindungan Cabang liwat cabang sing dipilih.
Kanggo cabang sing dilindhungi, sampeyan bisa nemtokake kabijakan sing mbutuhake a pull request sadurunge gabung (uga syarat tambahan kayata jumlah persetujuan sing dibutuhake, ulasan saka pemilik kode, lan liya-liyane)
Ana sawetara kahanan sing kudu digatekake kanthi khusus yaiku:
- "Ngidini aktor tartamtu kanggo ngliwati sing dibutuhake pull requests".
- "Aja ngidini nglewati setelan ing ndhuwur"
Sanajan umume syarat nambahake kakuwatan marang kabijakan kasebut, syarat-syarat kasebut ngendhokke kabijakan lan bisa uga mbukak lawang kanggo kegiatan jahat, contone, ing kasus kredensial dicolong dening aktor "sing duwe hak istimewa".
Watesi ijin GITHUB_TOKEN (privilege paling cilik)
Watesi ijin token GitHub mung kanggo sing dibutuhake; kanthi cara iki, sanajan para penyerang kasil ngrusak ijin sampeyan pipeline, dheweke ora bakal bisa nindakake akeh.
Hindari interpolasi string kanthi nggunakake pipeline variabel lingkungan
Saben sampeyan nggunakake sawetara variabel input ing pipeline, elinga yen data kasebut kudu dianggep minangka data "ora dipercaya" (isine dikontrol dening pangguna pungkasan). Deleng Tindakan lan Alur Kerja sing Ora Dipercaya Aman lan Sinau Tindakan Github.
Sampeyan kudu tansah nggunakake variabel lingkungan kanggo nglebokake variabel input ing njero skrip tinimbang nggunakake interpolasi string.
Alur kerja lan syarat persetujuan
kanggo umum repos, GitHub ngidini kanggo nemtokake carane nggarap PR "njaba".
Setelan Organisasi GitHub (“Org >> Setelan >> Tindakan >> Umum”) ayo nemtokake cara ngatur PR eksternal:
Sacara standar, GitHub mbutuhake persetujuan PR kanggo kontributor pisanan, sing ndadekake serangan panjalukan jahat luwih rumit. Sanajan mangkono, penyerang bisa uga entuk kepercayaan saka pengelola proyek, contone kanthi nyumbang sawetara sing ora salah. pull request sadurunge serangan sing nyata.
Ing pangertèn iki, ing Pilihan kaping 3 (Mbutuhake persetujuan kanggo kabeh kolaborator njaba) nambahake tingkat kontrol sing luwih dhuwur.
kanggo pribadi repo, GitHub uga nyedhiyakake kontrol sing migunani ing tingkat Organisasi lan Repo.
"Jalanake Alur Kerja saka Pull Requests"(ora dicenthang kanthi gawan) ngidini pangguna mbukak alur kerja saka PR fork (nggunakake GITHUB_TOKEN kanthi ijin mung-maca lan tanpa akses menyang rahasia). Kanthi milih opsi iki bebarengan karo sing terakhir ("Mbutuhake persetujuan kanggo alur kerja PR fork"") , sampeyan bisa nggayuh kabijakan sing padha karo repo pribadi (kaya sing dituduhake ing ndhuwur).
Kaya sing wis dideleng ing eksploitasi PPE saka pangguna sing wis diwaca, ngidini alur kerja mlaku saka fork pull requests ora aman!!
Pilihan sing isih ana (“Kirim token tulis menyang alur kerja saka fork pull requests"Lan"Kirim rahasia lan variabel menyang alur kerja saka kanggo pull requests" ngurangi tingkat keamanan diterapake ing PR fork.
Sampeyan bisa nemtokake kabijakan fork iki ing Tingkat Organisasi utawa ing tingkat Repo. Yen kabijakan kasebut dipateni ing tingkat org, kabijakan kasebut ora bisa diaktifake ing tingkat repo. Nanging, yen kabijakan kasebut diaktifake ing tingkat org, kabijakan kasebut bisa dipateni ing tingkat repo.
rekap
Muga-muga panjenengan sampun mangertos implikasinipun saking gadhah sawatawis pipeline rentan kena racun Pipeline Eksekusi. Gampang banget kanggo commit sing rentan pipeline, lan angel nulis sing aman.
Dadi, nggunakake Xygeni Scanner iku penting banget kanggo ngerti kerentanan kasebut.
Kowé ora isa ngrampungi vuln kajaba kowé ngerti anané!!
Nanging… Isih ana pitakonan sing durung rampung… Kepriye carane supaya ora kena I-PPE?
Iki bakal dadi topik postingan sabanjure 🙂 … Keracunan Ora Langsung Pipeline Eksekusi (I-PPE) !!
