Integrasi Berkelanjutan dan Penerapan Berkelanjutan (CI/CD) pipelinememainkan peran penting dalam memfasilitasi pengembangan perangkat lunak yang efisien. Namun, seiring berjalannya waktu, pipelineKarena semakin pentingnya teknologi informasi, kebutuhan untuk melindunginya dari kerentanan menjadi semakin mendesak. Investigasi mendalam ini berfokus pada penanganan risiko penting yang diidentifikasi dalam OWASP Top-10. CI/CD Risiko Keamanan: Keracunan Pipeline Eksekusi (APD).
Apa yang Diracuni? Pipeline Eksekusi (APD)
Menurut OWASP Top-10 CI/CD Risiko Keamanan, “Keracunan Pipeline Execution (PPERisiko mengacu pada kemampuan penyerang yang memiliki akses ke sistem kontrol sumber – dan tanpa akses ke lingkungan pengembangan – untuk memanipulasi proses pembuatan dengan menyuntikkan kode/perintah berbahaya ke dalam proses pembuatan. pipeline konfigurasipada dasarnya 'meracuni' pipeline dan menjalankan kode berbahaya sebagai bagian dari proses pembuatan"
Singkatnya, Diracuni Pipeline Eksekusi (PPE) diproduksi ketika Penyerang dapat memodifikasi pipeline logika.
Ada dua varian:
- APD Langsung (D-PPE): Dalam skenario D-PPE, Penyerang memodifikasi file konfigurasi CI. di repositori yang mereka akses, baik dengan mendorong perubahan langsung ke cabang jarak jauh yang tidak terlindungi di repositori tersebut, atau dengan mengirimkan permintaan pull (PR) dengan perubahan dari cabang atau fork. Sejak CI pipeline Eksekusi ditentukan oleh perintah-perintah dalam file konfigurasi CI yang dimodifikasi, perintah-perintah berbahaya penyerang pada akhirnya akan dijalankan di node build setelah proses build selesai. pipeline dipicu.
- APD Tidak Langsung (I-PPEDalam kasus tertentu, kemungkinan D-PPE tidak tersedia bagi pihak lawan yang memiliki akses ke SCM repositori (misalnya jika pipeline dikonfigurasi untuk mengambil file konfigurasi CI dari cabang terpisah yang dilindungi di repositori yang sama). Dalam skenario seperti itu, daripada meracuni pipeline Dengan sendirinya, penyerang menyuntikkan kode berbahaya ke dalam file yang dirujuk oleh pipeline (misalnya: skrip yang dirujuk dari dalam pipeline berkas konfigurasi)
Dalam kedua kasus tersebut, GitHub akan menjalankan yang telah dimodifikasi. pipeline tanpa perlu peninjauan atau persetujuan sebelumnya.
Deteksi dini APD
Bagaimana cara kita mendeteksi jenis kerentanan ini?
Mari kita lihat contoh ini. pipeline :
Dan isi dari skrip shell dummy (runtests.sh):
The pipeline Cukup sederhana: tujuannya adalah untuk memberikan beberapa petunjuk awal kepada peninjau. Pull Request Proses penerimaan (PR):
- Ini akan dipicu pada permintaan tarik (yaitu setiap kali permintaan pull dibuat)
- Ini memeriksa kode PR (yaitu kode yang disumbangkan)
- Ini akan membuat pembangunan
- Program ini akan menjalankan pengujian pada kode yang disumbangkan (misalnya dengan mengeksekusi skrip shell).
Langkah #3 (membuat build) dan #4 (menjalankan pengujian) akan gagal jika kode tidak dapat dikompilasi atau gagal melewati pengujian. Jadi, langkah-langkah ini bertindak sebagai syarat yang diperlukan, tetapi tidak cukup, untuk menerima PR. Jika berhasil, admin repositori akan melanjutkan untuk meninjau kode yang disumbangkan dan, berdasarkan itu, dia akan menerima/menolak/memberi komentar pada PR.
Pemindai Xygeni
Xygeni menyediakan CLI (“Pemindai Xygeni”) yang dapat disematkan ke dalam sebuah pipeline atau dijalankan melalui baris perintah. Xygeni Scanner akan memprosesnya. pipelineuntuk memeriksa kerentanan dan, jika GitHub PAT disediakan, ia akan terhubung ke GitHub untuk menemukan kerentanan di tingkat organisasi/repositori.
Inventaris Xygeni
Saat kita menjalankan Xygeni Scanner pada repositori ini, ia menemukan serangkaian aset yang berguna (yaitu Inventaris XygeniInventaris akan diisi dengan berbagai macam jenis CI/CD aktiva, Seperti:
- The SCM System tempat repositori disimpan
- The SCM plugin terpasang/digunakan
- The Repositori Kode Diri
- The SCM Organisasi di mana repositori tersebut milik
- The CI/CD PipelinePekerjaan dan
- The CI/CD System menjalankan pipelines
- IaC Publikasi didefinisikan ke dalam repositori
- Luar Dependensi
- dll ..
Dalam contoh kita, kita dapat memfilter Inventaris berdasarkan jenis aset tertentu (SCM- dan aset terkait CICD), sehingga kita dapat melihat bahwa:
- SCM sistemnya adalah GitHub Cloud
- Repositori ini disimpan di GitHub Cloud dan dimiliki oleh Organisasi GitHub tertentu.
- Ada dua pipelinedidukung oleh GitHub (CI/CD sistem)
- Setiap pipeline berisi satu langkah spesifik
Dengan memilih di atas pipeline Kita dapat melihat beberapa kerentanan:
- At pipeline pada level tersebut, ia rentan terhadap keduanya. langsung ke APD tidak langsung.
Kita dapat melihat detail tentang mereka yang diracuni. Pipeline Kerentanan eksekusi
Xygeni mendeteksi bahwa itu rentan terhadap D-PPE karena itu dipicu pada Pull Request Acara tersebut tidak disertai kontrol keamanan tambahan, sehingga setiap pengguna repositori dapat memodifikasinya. pipeline dan modifikasi tersebut akan dieksekusi tanpa tinjauan atau persetujuan apa pun.
Dalam pengertian yang sama, Xygeni juga mendeteksi bahwa ia rentan terhadap I-PPE karena panggilan ke skrip shell dari pipelineSetiap pengguna repositori dapat memodifikasi skrip shell dan modifikasi tersebut akan dieksekusi tanpa tinjauan atau persetujuan apa pun.
Apakah Anda ingin tahu lebih banyak?
Memanfaatkan APD
Untuk memanfaatkan APD, mari kita pertimbangkan skenario di mana terdapat dua jenis pengguna repositori:
- An pengguna internal (seorang pengembang internal yang mengerjakan repositori tersebut), dengan izin tulis pada repositori tersebut.
- An pengguna eksternal (pengembang pihak luar yang mengerjakan repositori tersebut tetapi hanya memiliki izin baca pada repositori), yaitu tidak diizinkan untuk membuat cabang repositori dan dipaksa untuk mengerjakan fork.
Mari kita bayangkan bahwa keduanya adalah penyerang jahat (atau menyamar sebagai pelaku jahat). Repositori tersebut berisi beberapa rahasia dan keduanya menginginkannya. untuk mencuri rahasia repositori dan mengirimkannya ke server yang dikendalikan peretas. Untuk melakukannya, mereka akan memanfaatkan Poisoned. Pipeline Kerentanan eksekusi dari pipeline.
Dalam kedua kasus (pengguna eksternal dan internal), mereka membuka sebuah Pull Request dengan modifikasi yang sama:
- The pipeline dan skrip shell dimodifikasi untuk baca rahasianya dari lingkungan dan mengirimkannya ke server yang dikendalikan peretas.
Modifikasi yang mungkin dilakukan adalah sebagai berikut:
Kedua pengguna akan membuat Pull Request dengan modifikasiSetelah pembuatan PR, GitHub akan menjalankan kedua modifikasi tersebut. (tanpa perlu peninjauan atau persetujuan sebelumnya), yang menghasilkan hal-hal berikut:
Sama halnya untuk pengguna yang menulis dan membaca, Dalam kedua kasus tersebut, D-PPE dan I-PPE dilaksanakan., dengan perbedaan bahwa Pengguna yang memiliki hak baca tidak dapat mengakses rahasia tersebut. (!!!!)
Alasannya adalah karena, Dalam kasus permintaan pull (PR) yang berasal dari fork, GitHub tidak mengizinkan akses ke rahasia repositori. Meskipun pengguna yang membaca tidak dapat membaca rahasia tersebut, ia tetap dapat menjalankan program lain. Contoh serangan yang umum adalah membuat permintaan pull (PR) yang mengunduh penambang kripto, sehingga GitHub runner akan mengeksekusi penambang kripto saat menjalankan skrip yang telah diracuni. pipeline.
Ini bukanlah lingkungan yang aman, tentu saja!! Apa yang bisa dilakukan admin repositori untuk menghindari hal tersebut?
Setelah melakukan pencarian di Google, admin repositori memutuskan untuk memodifikasi pipeline untuk dipicu pada target_permintaan_tarik acara. Mengapa? Karena pipelines yang dipicu pada pull_request_target tidak mengizinkan eksekusi pipeline modifikasi, yaitu terlepas dari modifikasi apa pun yang dilakukan pengguna, "asli" pipeline akan dieksekusi.
Mengikuti contoh kita, serangannya akan sama seperti sebelumnya. Lalu apa yang akan terjadi setelah ini? pipeline modifikasi?
Seperti yang diharapkan, D-PPE tidak dilaksanakan tetapi, karena I-PPE masih ada, Pengguna yang memiliki hak baca sekarang dapat mengakses rahasia repositori!!!
Apa alasan pengguna baca sekarang memiliki akses ke rahasia? Meskipun pipeline Meskipun tidak dapat dimodifikasi, skrip shell masih dapat dimodifikasi. Ketika sebuah pipeline Jika dipicu pada pull_request_target, maka akan dieksekusi dalam mode istimewa. so itu juga akan menjadi skrip shell., sehingga skrip shell tersebut memiliki akses ke rahasia repositori!!
Tindakan pencegahan
GitHub menyediakan beberapa langkah untuk melindungi dari permintaan perubahan (PR) yang berbahaya.
Aturan perlindungan cabang
Dengan GitHub, Anda dapat menentukan Aturan Perlindungan Cabang pada cabang-cabang terpilih.
Untuk cabang yang dilindungi, Anda dapat menentukan kebijakan yang membutuhkan pull request sebelum penggabungan (serta persyaratan tambahan seperti jumlah persetujuan yang dibutuhkan, tinjauan dari pemilik kode, dll.)
Beberapa kondisi yang perlu mendapat pertimbangan khusus adalah:
- "Izinkan aktor tertentu untuk melewati persyaratan yang diperlukan. pull requests".
- "Jangan izinkan pengabaian terhadap pengaturan di atas."
Meskipun sebagian besar ketentuan menambah keketatan kebijakan, ketentuan-ketentuan ini justru melonggarkan kebijakan dan hal itu dapat membuka peluang bagi aktivitas jahat, misalnya, jika kredensial dicuri oleh pihak-pihak yang memiliki "hak istimewa".
Batasi izin GITHUB_TOKEN (hak akses minimal)
Batasi izin token GitHub hanya pada yang diperlukan; dengan cara ini, bahkan jika penyerang berhasil membobol sistem Anda, pipeline, mereka tidak akan bisa berbuat banyak.
Hindari interpolasi string dengan menggunakan pipeline variabel lingkungan
Setiap kali Anda menggunakan beberapa variabel input dalam pipelinePerlu diingat bahwa secara default data tersebut harus dianggap sebagai data yang "tidak tepercaya" (kontennya dikendalikan oleh pengguna akhir). Lihat Tindakan dan Alur Kerja yang Tidak Tepercaya Diamankan ke Pelajari Github Actions.
Anda sebaiknya selalu menggunakan variabel lingkungan untuk memasukkan variabel input ke dalam skrip, alih-alih menggunakan interpolasi string.
Alur kerja dan persyaratan persetujuan
Untuk publik Repositori, GitHub memungkinkan untuk menentukan cara bekerja dengan PR “eksternal”.
Pengaturan Organisasi GitHub (“Org >> Settings >> Actions >> General”) memungkinkan Anda menentukan cara mengelola PR eksternal:
Secara default, GitHub akan memerlukan persetujuan PR untuk kontributor pertama kali, sehingga serangan permintaan berbahaya menjadi lebih rumit. Meskipun demikian, penyerang mungkin dapat memperoleh kepercayaan pengelola proyek, misalnya dengan menyumbangkan sesuatu yang tampaknya tidak berbahaya. pull request sebelum serangan sebenarnya.
Dalam pengertian ini, the Opsi ke-3 (Membutuhkan persetujuan untuk semua kolaborator eksternal) menambahkan tingkat kontrol yang lebih tinggi.
Untuk swasta GitHub juga menyediakan kontrol yang bermanfaat baik di tingkat Organisasi maupun Repositori.
"Jalankan Alur Kerja dari Pull Requests” (tidak dicentang secara default) memungkinkan pengguna untuk menjalankan alur kerja dari PR fork (menggunakan GITHUB_TOKEN dengan izin baca saja dan tanpa akses ke rahasia). Dengan memilih opsi ini bersamaan dengan opsi terakhir (“Membutuhkan persetujuan untuk alur kerja PR fork”), Anda dapat mencapai kebijakan serupa untuk repositori pribadi (seperti yang ditunjukkan di atas).
Seperti yang telah kita lihat pada eksploitasi PPE dari pengguna baca, memungkinkan menjalankan alur kerja dari fork pull requests Ini tidak aman!!
Opsi yang tersisa (“Kirim token tulis ke alur kerja dari fork pull requests"Dan"Kirim rahasia dan variabel ke alur kerja dari untuk pull requests") menurunkan tingkat keamanan Diterapkan pada PR (Pull Request) hasil fork.
Anda dapat menentukan kebijakan fork ini baik di tingkat Organisasi maupun di tingkat Repositori. Jika kebijakan dinonaktifkan di tingkat organisasi, kebijakan tersebut tidak dapat diaktifkan di tingkat repositori. Namun, jika kebijakan diaktifkan di tingkat organisasi, kebijakan tersebut dapat dinonaktifkan di tingkat repositori.
Ikhtisar
Kami harap Anda telah melihat implikasi dari memiliki beberapa hal pipeline rentan terhadap keracunan Pipeline Eksekusi. Terlalu mudah untuk commit rentan pipeline, dan sulit untuk menulis yang aman.
Oleh karena itu, sangat berharga untuk menggunakan Xygeni Scanner agar mengetahui kerentanan tersebut.
Anda tidak dapat mengatasi kerentanan kecuali Anda menyadari keberadaannya!!
Namun… Masih ada pertanyaan yang belum terjawab… Bagaimana cara menghindari I-PPE?
Ini akan menjadi topik postingan kita selanjutnya 🙂… Keracunan Tidak Langsung Pipeline Eksekusi (I-PPE) !!
