Dalam unggahan kami sebelumnya, Kita telah melihat cara mendeteksi dan melindungi diri dari keracunan langsung. Pipeline Eksekusi (D-PPE). Kita juga melihat bagaimana mendeteksi kerentanan tersebut menggunakan Pemindai Xygeni, serta beberapa mekanisme perlindungan.
Keracunan Pipeline Eksekusi (PPE) dihasilkan ketika penyerang dapat memodifikasi pipeline logika dalam salah satu dari dua cara:
- Dengan memodifikasi file konfigurasi CI ( pipeline) -> APD Langsung (D-PPE)
- Dengan memodifikasi file yang dirujuk oleh pipeline (misalnya: skrip yang dirujuk dari dalam pipeline berkas konfigurasi) -> Alat Pelindung Diri Tidak Langsung (I-PPE)
Dalam postingan ini, kita akan membahas secara mendalam tentang APD Tidak Langsung. Namun, sebelum itu, dan sebagai pelengkap postingan saya sebelumnya, mari kita lihat terlebih dahulu bagaimana GitHub mengelola pelaksanaannya. pipelinedan apa saja mekanisme perlindungan terhadap D-PPE.
Bagaimana GitHub melindungi eksekusi dari pipelineApakah ini berasal dari PR?
Bagaimana cara kerja GitHub terkait eksekusi perubahan yang telah dimodifikasi? pipelines?
Diubah pipelinebisa berasal dari Dorongan atau Pull Requests (PR). Sebagai praktik terbaik utama, sangat disarankan untuk menghindari "push" langsung ke branch yang dilindungi dan menggunakan Pull Requests sebagai mekanisme untuk memberlakukan beberapa tinjauan sebelum menerima kode yang disumbangkan.
Pull Requests dapat berasal dari dua sumber berbeda:
- Siaran pers yang berasal dari garpu
- Siaran pers yang berasal dari cabang
Siaran pers dari garpu bisa berasal dari publik or swasta repositori.
Karena kita berurusan dengan APD (Penyakit Beracun) Pipeline (Eksekusi), poin utama kami bukanlah "penerimaan" sebuah PR, tetapi eksekusi dari PR yang telah dimodifikasi. pipeline selama proses penerimaan/persetujuan PR. Inti dari serangan PPE adalah eksekusi yang tidak disengaja dari program yang dimodifikasi dan bersifat "berbahaya". pipeline.
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.
Permintaan perubahan (PR) dari fork pada publik sisa
GitHub memungkinkan konfigurasi perilaku saat memproses data. Permintaan perubahan (PR) yang berasal dari fork di repositori publik..
Ketika sebuah permintaan pull (PR) berasal dari sebuah fork, GitHub selalu memaksakan beberapa tingkat "persetujuan" sebelum mengeksekusinya. pipeline terkait dengan PRTingkat persetujuan ini berkisar dari persetujuan yang lemah hingga persetujuan yang ketat.
At Tingkat organisasi (Org>>Settings>>Actions>>General), Anda dapat memilih di antara beberapa opsi “persetujuan”:
Yang paling ketat adalah yang terakhir (“Membutuhkan persetujuan dari semua kolaborator eksternal.”) karena GitHub akan selalu memerlukan persetujuan ketika PR berasal dari fork dari kolaborator eksternal.
Namun, bahkan dalam kasus yang ketat ini, tetap ada perbedaan antara kolaborator dengan izin baca dan tulis.
- Ketika PR berasal dari sebuah Baca baca pengguna, eksekusi pipeline dihentikan sampai perubahan disetujui. Jika persetujuan sudah diterima, maka modifikasi akan dilakukan. pipeline dieksekusi.
- Ketika PR berasal dari sebuah menulis pengguna, Persetujuan tidak diperlukan dan telah dimodifikasi. pipeline selalu dieksekusi!!
Sebagai kesimpulan, PR yang berasal dari fork pada repositori publik memiliki perlindungan yang lemah terhadap PPE. Terdapat beberapa perlindungan terhadap pengguna eksternal (baca), tetapi tidak ada perlindungan terkait pengguna internal (tulis).
Bagaimana dengan Permintaan pull (PR) yang berasal dari fork dari repositori pribadi.?
Permintaan perubahan (PR) dari fork pada swasta sisa
Dalam skenario ini, GitHub menyediakan beberapa pengaturan konfigurasi yang berguna.
Pengaturan di atas dapat dikonfigurasi baik di organ atau repo tingkat.
Ketika tidak ada opsi yang dicentang, GitHub akan meminta persetujuan ke tidak akan menjalankan yang telah dimodifikasi pipelineIni adalah konfigurasi yang paling aman!!
The konfigurasi paling tidak aman adalah ketika "Jalankan alur kerja dari fork pull request” diperiksaDalam hal ini, sama untuk pengguna baca dan tulis, Github akan secara otomatis mengeksekusi perubahan yang telah dimodifikasi. pipeline!! Dan situasi ini bahkan bisa menjadi lebih buruk jika "Kirim token tulis ke alur kerja dari fork pull requests"Dan"Kirim rahasia dan variabel ke alur kerja dari fork pull requests” diperiksa. Jangan lakukan ini kecuali ada alasan yang jelas!!
Jika "Membutuhkan persetujuan untuk fork pull request Alur kerjaJika opsi ” dicentang, situasi di atas akan sedikit membaik: GitHub akan meminta persetujuan dan tidak akan mengeksekusi perubahan yang telah dimodifikasi. pipeline untuk pengguna baca, tetapi tetap akan dieksekusi untuk pengguna tulis.
Garpu terlihat, bagaimana dengan Permintaan perubahan (PR) yang berasal dari cabang-cabang?
Siaran pers dari cabang
Untuk melindungi skenario ini, Anda harus mengandalkan Peraturan Perlindungan Cabang.
Di tingkat repositori, Anda dapat membuat aturan perlindungan cabang untuk cabang mana pun. Aturan ini menambahkan beberapa hal. batasan terhadap modifikasi cabang yang dilindungi.
Meskipun Anda mengkonfigurasi aturan untuk “Membutuhkan a pull request sebelum penggabungan"Dan"Membutuhkan persetujuan", yang dimodifikasi pipeline akan dieksekusi secara otomatis setelah pembuatan PR.“Persetujuan” hanya akan berlaku untuk tindakan penggabungan.
Bagaimana dengan keracunan tidak langsung? Pipeline Execution
Seperti yang telah kita lihat di atas, D-PPE dapat dikurangi dengan menggunakan target_permintaan_tarik, Tapi tidak berlaku untuk I-PPE.
Jika Anda menggunakan `pull_request_target`, checkout default akan berupa kode dasar. Tetapi jika Anda ingin memvalidasi beberapa pemeriksaan pada kode kontribusi (kode PR), Anda perlu secara eksplisit melakukan checkout kode PR. Oleh karena itu, jika kode PR telah memodifikasi skrip shell apa pun yang dipanggil oleh pipeline, “basis” (aman) pipeline akan menjalankan skrip shell yang “dimodifikasi” → APD Tidak Langsung!!
Solusi untuk masalah ini sedikit lebih rumit (tidak ada jalan pintas seperti pull_request_target).
Mitra pipeline Sekarang sudah aman terhadap D-PPE karena kita menggunakan pull_request_target. Namun masih rentan terhadap I-PPE.
Dalam contoh pengujian kami, pada dasarnya kita perlu melakukan checkout kode PR untuk membuat build, tetapi pengujian dijalankan pada artefak yang dihasilkan oleh build tersebut.
Jadi .. Mengapa tidak memeriksa kedua basis kode tersebut?
- Periksa kode PR karena kode kontribusi itulah yang ingin kita bangun dan uji.
- Keluarkan kode dasar untuk menjalankan versi asli dari pipeline dan skrip pembuatan/pengujian
Hal ini mungkin dilakukan dengan cara memeriksa kode program tersebut ke folder yang berbedaKode dasar mungkin di-checkout ke folder root, dan PR ke folder yang berbeda. Dalam hal ini, kita akan menjalankan build dan skrip pengujian dari folder root terhadap kode yang ditempatkan di folder baru tersebut.
Ini solusi yang mudah, tentu saja!! Tetapi, untuk tujuan pembelajaran, saya ingin memperkenalkan varian yang cukup menarik (...)
GitHub alur kerja_jalankan peristiwa pemicu
Selain target_permintaan_tarikGitHub menyediakan pemicu peristiwa lainnya: alur kerja_jalankanAcara ini memungkinkan pelaksanaan suatu pipeline dikondisikan pada yang lain pipelineeksekusi.
alur kerja_jalankan ke target_permintaan_tarik Trigger memiliki kesamaan dalam satu aspek: keduanya akan dieksekusi dalam mode istimewa dan, terlepas dari modifikasi PR, dasarnya pipeline akan dieksekusi!!
Mari kita lihat kondisi kita saat ini. pipeline:
Bagian perakitan aman terhadap D-PPE, tetapi bagian pengujian masih rentan terhadap I-PPE.
The pipeline itu sendiri aman untuk D-PPE karena target_permintaan_tarik pemicu. Namun langkah pengujian masih rentan terhadap I-PPE karena memanggil skrip shell eksternal.
Menghindari I-PPE
Tujuan dari hal di atas pipeline Tujuannya adalah untuk membangun dan menguji kode yang disumbangkan, dengan tetap memperhatikan keselamatan sesuai dengan APD (Alat Pelindung Diri).
Jadi .. Mengapa tidak dipisah saja pipeline menjadi dua? Satu untuk membangun dan yang lainnya untuk menguji...
- Tanggal 1 pipeline (Membangun CI) akan Periksa kode PR (untuk membangunnya), lakukan build dan hasilkan artefak.
- 2nd pipeline (Uji CI) akan Periksa kode dasar (untuk menghindari modifikasi skrip shell) dan menjalankan skrip asli terhadap artefak tersebut.
- Untuk menyinkronkan CI Pengujian pipeline untuk dijalankan SETELAH Build CI pipeline, kita akan menggunakan alur kerja_jalankan pelatuk.
Dengan cara ini:
- pipeline Membangun CI is Safety untuk keduanya D-PPE (disebabkan oleh target_permintaan_tarik) Dan I-PPE (karena skrip shell tersebut tidak lagi dieksekusi).
- pipeline Uji CI juga Safety untuk keduanya D-PPE (disebabkan oleh alur kerja_jalankan) Dan I-PPE (karena ia memeriksa kode dasar untuk mendapatkan skrip shell asli)
Mari kita lihat kode keduanya. pipelinesesuai dengan modifikasi ini…
1st pipeline (Membangun CI):
2nd pipeline (CI Uji):
Wow… solusi yang bagus!! Tapi… Apakah kita aman? Aku khawatir tidak 😭
Memang benar, kita telah memperkenalkan kerentanan baru!! Yang mana? Ini akan menjadi topik postingan kita selanjutnya 🙂 … Tetap ikuti terus!!
PS: Maaf, aku tidak bisa diam saja 🤐 ..Apakah kamu sudah mendengar tentang Keracunan Artefak ? 😂
