Integrasi Berterusan dan Pelaksanaan Berterusan (CI/CD) pipelinememainkan peranan penting dalam memudahkan pembangunan perisian yang diperkemas. Namun, memandangkan ini pipelinemenjadi semakin penting, kewajipan untuk melindungi mereka daripada kelemahan menjadi lebih ketara. Siasatan mendalam ini memberi tumpuan kepada menangani risiko penting yang dikenal pasti dalam 10 Teratas OWASP CI/CD Risiko Keselamatan: Keracunan Pipeline Pelaksanaan (PPE).
Apa yang Diracuni Pipeline Pelaksanaan (PPE)
Menurut OWASP Top-10 CI/CD Risiko Keselamatan, "Beracun Pipeline Pelaksanaan (PPE) risiko merujuk kepada keupayaan penyerang dengan akses kepada sistem kawalan sumber – dan tanpa akses kepada persekitaran binaan – untuk memanipulasi proses binaan dengan menyuntik kod/arahan berniat jahat ke dalam binaan pipeline konfigurasi, pada asasnya 'meracuni' pipeline dan menjalankan kod berniat jahat sebagai sebahagian daripada proses binaan”
Dalam beberapa perkataan, Keracunan Pipeline Pelaksanaan (PPE) dihasilkan apabila penyerang boleh mengubah suai pipeline logik.
Terdapat dua varian:
- PPE langsung (D-PPE): Dalam senario D-PPE, penyerang mengubah suai fail konfigurasi CI dalam repositori yang mereka boleh akses kepada, sama ada dengan menolak perubahan terus ke cawangan jauh yang tidak dilindungi pada repo, atau dengan menghantar PR dengan perubahan daripada cawangan atau fork. Sejak CI pipeline pelaksanaan ditakrifkan oleh arahan dalam fail konfigurasi CI yang diubah suai, arahan berniat jahat penyerang akhirnya berjalan dalam nod binaan sebaik sahaja binaan pipeline dicetuskan.
- PPE tidak langsung (I-PPE): Dalam kes tertentu, kemungkinan D-PPE tidak tersedia kepada musuh yang mempunyai akses kepada SCM repositori (cth. jika pipeline dikonfigurasikan untuk menarik fail konfigurasi CI daripada cawangan berasingan yang dilindungi dalam repositori yang sama). Dalam senario sedemikian, daripada meracuni pipeline sendiri, penyerang menyuntik kod berniat jahat ke dalam fail yang dirujuk oleh pipeline (contohnya: skrip yang dirujuk dari dalam pipeline fail konfigurasi)
Dalam kedua-dua kes, GitHub akan melaksanakan yang diubah suai pipeline tanpa memerlukan semakan atau kelulusan terdahulu.
Pengesanan awal PPE
Bagaimanakah kita dapat mengesan jenis kelemahan ini?
Mari kita lihat contoh ini 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.
Dan kandungan skrip shell dummy (runtests.sh):
#!/usr/bin/bash
echo "Executing Tests script [from user $1 at $2]" >> runtests.out
exit 0
. pipeline agak mudah: tujuannya adalah untuk memberi pengulas beberapa petunjuk awal untuk Pull Request Proses penerimaan (PR):
- Ia akan dicetuskan pada pull_request (iaitu apabila PR diwujudkan)
- Ia menyemak kod PR (iaitu kod yang disumbangkan)
- Ia akan menjadikan binaan itu
- Ia akan menjalankan ujian pada kod yang disumbangkan (contohnya dengan melaksanakan skrip shell)
Langkah #3 (buat binaan) dan #4 (jalankan ujian) akan gagal jika kod tidak dikompilasi atau gagal lulus ujian. Jadi, langkah-langkah ini bertindak sebagai syarat yang perlu, tetapi tidak mencukupi, untuk menerima PR. Jika berjaya, pentadbir repo akan terus menyemak kod yang disumbangkan dan, berdasarkan itu, dia akan menerima/menolak/mengulas PR.
Pengimbas Xygeni
Xygeni menyediakan CLI ("Pengimbas Xygeni") yang boleh dibenamkan ke dalam pipeline atau jalankan dalam baris arahan. Pengimbas Xygeni akan memproses pipelines untuk menyemak kelemahan dan, jika PAT GitHub disediakan, ia akan bersambung ke GitHub untuk menemui kelemahan pada peringkat org/repo.
Inventori Xygeni
Apabila kita melaksanakan Xygeni Scanner pada repo ini, ia menemui satu set aset yang berguna (yang Inventori XygeniInventori akan diisi dengan pelbagai jenis CI/CD aset, Seperti:
- . SCM sistem tempat repo disimpan
- . SCM Plugin dipasang/digunakan
- . Repositori Kod sendiri
- . SCM pertubuhan di mana repo itu dimiliki
- . CI/CD Pipelinedan Pekerjaan
- . CI/CD sistem menjalankan pipelines
- IaC Sumber ditakrifkan ke dalam repo
- luar Kebergantungan
- dan lain-lain ..
Dalam contoh kita, kita boleh menapis Inventori mengikut beberapa jenis aset tertentu (SCM- dan aset berkaitan CICD), jadi kita dapat melihat bahawa:
- SCM sistem ialah GitHub Cloud
- Repo disimpan dalam GitHub Cloud dan dimiliki oleh Organisasi GitHub tertentu
- Terdapat dua pipelinedikuasakan oleh GitHub (CI/CD sistem)
- Setiap pipeline mengandungi satu langkah tertentu
Dengan memilih perkara di atas pipeline kita dapat melihat beberapa kelemahan:
- At pipeline tahap, ia terdedah kepada kedua-duanya terus dan PPE tidak langsung.
Kita boleh lihat butiran mereka yang Keracunan Pipeline Kerentanan pelaksanaan
Xygeni mengesan bahawa ia terdedah kepada D-PPE kerana ia dicetuskan pada Pull Request acara dan tiada kawalan keselamatan tambahan, jadi mana-mana pengguna repo boleh mengubah suai pipeline dan pengubahsuaian tersebut akan dilaksanakan tanpa sebarang semakan atau kelulusan.
Dalam erti kata yang sama, Xygeni juga mengesan bahawa ia terdedah kepada I-PPE kerana panggilan ke skrip shell daripada pipeline: mana-mana pengguna repo boleh mengubah suai skrip shell dan pengubahsuaian tersebut akan dilaksanakan tanpa sebarang semakan atau kelulusan.
Adakah anda ingin tahu lebih lanjut?
Mengeksploitasi PPE
Untuk mengeksploitasi PPE, mari kita pertimbangkan senario di mana terdapat dua jenis pengguna repo:
- An pengguna dalaman (pembangun dalaman yang mengusahakan repo itu), dengan kebenaran menulis pada repo
- An pengguna luaran (pembangun penyumberan luar yang mengusahakan repo itu tetapi dengan kebenaran baca pada repo), iaitu tidak dibenarkan untuk membuka cawangan repo dan terpaksa mengusahakan fork.
Mari kita bayangkan kedua-duanya adalah penyerang yang berniat jahat (atau disamarkan oleh pelaku yang berniat jahat). Repo tersebut mengandungi beberapa rahsia dan kedua-duanya mahukan untuk mencuri rahsia repo dan hantarkannya ke pelayan yang dikawal oleh penggodam. Untuk melakukannya, mereka akan mengambil kesempatan daripada Poisoned Pipeline Kerentanan pelaksanaan pipeline.
Dalam kedua-dua kes (pengguna luaran dan dalaman), mereka membuka Pull Request dengan pengubahsuaian yang sama:
- . pipeline dan skrip shell diubah suai kepada baca rahsianya daripada persekitaran dan hantarkannya ke pelayan yang dikawal oleh penggodam
Pengubahsuaian mungkin seperti berikut:
Kedua-dua pengguna akan mencipta Pull Request dengan pengubahsuaianSetelah PR diwujudkan, GitHub akan melaksanakan kedua-dua pengubahsuaian (tanpa memerlukan semakan atau kelulusan terdahulu), mengakibatkan perkara berikut:
Sama juga untuk pengguna tulis dan baca, dalam kedua-dua kes D-PPE dan I-PPE dilaksanakan, dengan perbezaannya pengguna baca tidak dapat mengakses rahsia tersebut. (!!!!)
Sebab ini adalah kerana, Dalam kes PR yang datang dari fork, GitHub tidak membenarkan akses kepada rahsia repo. Walaupun pengguna baca tidak dapat membaca rahsia, dia masih boleh menjalankan sebarang program lain. Contoh serangan biasa ialah mencipta PR yang memuat turun pelombong kripto, jadi pelari GitHub akan melaksanakan pelombong kripto apabila melaksanakan racun. pipeline.
Sudah tentu ini bukan persekitaran yang selamat!! Apakah yang mungkin dilakukan oleh pentadbir repo untuk mengelakkannya?
Selepas beberapa carian di Google, pentadbir repo memutuskan untuk mengubah suai pipeline untuk dicetuskan pada sasaran_permintaan_tarik peristiwa. Mengapa? Kerana pipelines yang dicetuskan pada pull_request_target tidak membenarkan pelaksanaan pipeline pengubahsuaian, iaitu walaupun terdapat sebarang pengubahsuaian pengguna, "asal" pipeline akan dilaksanakan.
Mengikuti contoh kita, serangan itu akan sama seperti sebelumnya. Apa yang akan berlaku selepas ini pipeline pengubahsuaian?
Seperti yang diharapkan, D-PPE tidak dilaksanakan tetapi, kerana I-PPE masih ada, pengguna baca kini boleh mengakses rahsia repo!!!
Apakah sebabnya pengguna baca kini mempunyai akses kepada rahsia? Walaupun pipeline tidak boleh diubah suai, skrip shell masih boleh diubah suai. Apabila seorang pipeline dicetuskan pada pull_request_target, ia akan dilaksanakan dalam mod istimewa so ia juga akan menjadi skrip shell, mengakibatkan skrip shell mempunyai akses kepada rahsia repo!!
Langkah-langkah Pencegahan
GitHub menyediakan beberapa langkah untuk melindungi daripada PR yang berniat jahat.
Peraturan perlindungan cawangan
Dengan GitHub anda boleh menentukan Peraturan Perlindungan Cawangan ke atas cawangan yang dipilih.
Untuk cawangan yang dilindungi, anda boleh menentukan dasar yang memerlukan a pull request sebelum penggabungan (serta syarat tambahan seperti bilangan kelulusan yang diperlukan, ulasan daripada pemilik kod, dsb.)
Beberapa syarat yang perlu diberi perhatian khusus ialah:
- "Benarkan pelakon tertentu memintas diperlukan pull requests".
- "Jangan benarkan memintas tetapan di atas"
Walaupun kebanyakan syarat menambahkan ketegasan pada dasar, syarat-syarat ini melonggarkan dasar dan itu mungkin melibatkan pintu terbuka kepada aktiviti berniat jahat, contohnya, sekiranya kelayakan dicuri oleh pelaku "istimewa".
Hadkan kebenaran GITHUB_TOKEN (keistimewaan paling rendah)
Hadkan kebenaran token GitHub hanya kepada yang diperlukan; dengan cara ini, walaupun penyerang berjaya menjejaskan pipeline, mereka tidak akan dapat berbuat banyak.
Elakkan interpolasi rentetan dengan menggunakan pipeline pembolehubah persekitaran
Setiap kali anda menggunakan beberapa pembolehubah input dalam pipeline, perlu diketahui bahawa ia harus dianggap secara lalai sebagai data "tidak dipercayai" (kandungannya dikawal oleh pengguna akhir). Lihat Tindakan dan Aliran Kerja yang Tidak Dipercayai Selamat dan Pelajari Tindakan Github.
Anda harus sentiasa menggunakan pembolehubah persekitaran untuk memasukkan pembolehubah input di dalam skrip dan bukannya menggunakan interpolasi rentetan.
Aliran kerja dan keperluan kelulusan
Untuk awam repos, GitHub membolehkan untuk menentukan cara bekerja dengan PR "luaran".
Tetapan Organisasi GitHub (“Org >> Tetapan >> Tindakan >> Umum”) mari tentukan cara mengurus PR luaran:
Secara lalai, GitHub akan memerlukan kelulusan PR untuk penyumbang kali pertama, menjadikan serangan permintaan berniat jahat lebih rumit. Walaupun begitu, penyerang mungkin mendapat kepercayaan penyelenggara projek contohnya dengan menyumbang beberapa maklumat yang tidak bersalah. pull request sebelum serangan sebenar.
Dalam pengertian ini, Pilihan ke-3 (Memerlukan kelulusan untuk semua kolaborator luar) menambah tahap kawalan yang lebih tinggi.
Untuk swasta repo, GitHub juga menyediakan kawalan yang berguna di peringkat Organisasi dan Repo.
"Jalankan Aliran Kerja daripada Pull Requests"(tidak ditanda secara lalai) membolehkan pengguna menjalankan aliran kerja daripada PR fork (menggunakan GITHUB_TOKEN dengan kebenaran baca sahaja dan tanpa akses kepada rahsia). Dengan memilih pilihan ini bersama-sama dengan yang terakhir ("Memerlukan kelulusan untuk aliran kerja PR fork"") , anda boleh mencapai dasar yang serupa dengan repo persendirian (seperti yang ditunjukkan di atas).
Seperti yang telah kita lihat dalam eksploitasi PPE daripada pengguna yang dibaca, membenarkan aliran kerja berjalan dari fork pull requests tidak selamat!!
Pilihan yang tinggal (“Hantar token tulis ke aliran kerja daripada fork pull requests"Dan"Hantar rahsia dan pembolehubah ke aliran kerja daripada untuk pull requests") mengurangkan tahap keselamatan digunakan pada PR fork.
Anda boleh mentakrifkan dasar fork ini sama ada di Peringkat Organisasi atau di peringkat Repo. Jika dasar dinyahdayakan di peringkat organisasi, ia tidak boleh didayakan di peringkat repo. Tetapi, jika dasar didayakan di peringkat organisasi, ia boleh dinyahdayakan di peringkat repo.
Recap
Kami harap anda telah melihat implikasi daripada mempunyai beberapa pipeline terdedah kepada Keracunan Pipeline Pelaksanaan. Terlalu mudah untuk commit seorang yang terdedah pipeline, dan sukar untuk menulis yang selamat.
Jadi, adalah sangat berharga untuk menggunakan Pengimbas Xygeni bagi mengetahui tentang kelemahan sedemikian.
Anda tidak boleh menyelesaikan kelemahan melainkan anda menyedari kewujudannya!!
Tapi… Masih ada soalan yang tertangguh… Bagaimana untuk mengelakkan I-PPE?
Ini akan menjadi tajuk catatan kami yang seterusnya 🙂 … Keracunan Tidak Langsung Pipeline Pelaksanaan (I-PPE) !!
