Apa yang boleh menjadi salah dengan CI/CD pipelines?

Integrasi berterusan dan penyampaian berterusan (CI/CD) pipelines merupakan asas bagi mana-mana organisasi perisian yang membina perisian dengan cara yang "moden". Automasi memberikan kuasa yang besar, tetapi kebanyakan pembangun terlepas pandang tanggungjawab yang diperlukan.

PemajuYa, kami ambil CI/CD keselamatan serius dan mempunyai kawalan yang kuat terhadap penyelenggara kod, semak commits sebelum penggabungan; pekerjaan dan pipelinediselenggara oleh kakitangan kanan, mereka menjaga agar rahsia tidak bocor dalam pipelines. Dan alat itu dipasang oleh kakitangan yang mengetahui perkara itu. Apa yang boleh menjadi salah?

Pembangun yang dihormati, CI/CD Sistem ini kompleks. Permukaan serangannya yang luas telah menarik pelaku jahat. Lebih baik berhati-hati dan jangan terlalu yakin.

Konfigurasi lalai kadangkala dikekalkan dan menjadi sahabat baik bagi penggodam. Kecacatan kritikal boleh wujud dalam CI/CD pipeline sumber, dalam konfigurasi sistem, atau di sekitar proses dan konteks pipeline dan bagaimana ia dicetuskan.

Dalam catatan ini, kita akan meletakkan diri kita di tempat pelakon jahat. Bayangkan kita sedang membaca renungan M3M3N70 (Memento Mori?) dan Kemarahan Paya di suatu tempat dalam web gelap, mungkin dalam bahasa bukan barat, tetapi jangan sesekali terlepas bahawa kejahatan sedang tersebar ke seluruh dunia.

Pada zaman dahulu, ia sangat mudah…

M3M3N70Kembali ke zaman dahulu kala, perniagaan kami sangat mudah… Zero-days mudah dicapai, aplikasi terbuka luas dengan vuln yang mudah dieksploitasi, dan kami boleh bergerak ke sisi dalam sekelip mata.

Kemarahan Paya: Fu#@Neraka! Ada orang bodoh di luar sana yang masih berfikiran waras, tetapi keadaan telah berubah. Orang besar-besaran banyak mempermainkan masalah AppSec itu.

M3M3N70Ya. Tetapi orang bodoh baharu itu ialah pembangun. Bagi kami, lebih mudah untuk menggunakan alatan yang digunakan oleh mereka ini. CI, khususnya, adalah lombong emas! Token akses awan, SCM kelayakan, kata laluan pangkalan data pengeluaran, kunci peribadi SSH, kelayakan pengguna CI lain… Beralih daripada perkara pembangun yang membosankan kepada perkara sebenar agak mudah.

Automasi untuk membina, menguji dan menggunakan perisian dengan CI/CD Alat ini sering perlu menyampaikan rahsia kepada arahan secara berperingkat. Dan selalunya ia dibocorkan, dengan akibat yang terkenal.

Pipelinememerlukan rahsia yang kadangkala bocor

M3M3N70: The code monkeys slipped their AWS keys in a pipeline on a GitHub commit, later they removed the thing but not changed git history. For our scripts it was trivial to scan the history, grab the key and wreak havoc.

Mungkin zaman dahulu yang indah adalah untuk menemui dalam sejarah Git .env fail (pembangun terlupa untuk menambahkannya ke .gitignore):

AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=wJalrXUtn...
AWS_REGION=us-east-1
APP_FOLDER=...
S3BUCKET=...

yang telah digunakan dalam aliran kerja GitHub .github/deploy.yaml yang mengandungi sesuatu seperti ini:

jobs:
  build:
    name: Automated build and deployment into AWS
    runs-on: 	ubuntu-22.04
    steps:
      # Load environment from .env file
      - id: dotenv
        uses: falti/dotenv-action@v1.0.2
        
      - name: Configure AWS Credentials
        uses:
        with:
          args: --acl public-read --follow-symlinks --delete 
          aws-access-key-id: $
          aws-secret-access-key: $
          aws-region: $
      
      # ... build steps skipped ...
      
      -  name: Upload compiled code for deployment
         working-directory: $/packaged_app
         run: aws s3 cp my-app.zip s3://$ 
         
      - name: Deploy the app
        run: aws deploy create-deployment ...

M3M3N70: wow! Kekunci aws itu berfungsi! Kami menguji dahulu perubahan inocuos dalam aplikasi, kemudian menambah sting kerana mereka semua nampaknya tidak menyedarinya. Bingo! Kempen yang hebat…

Pelakon jahat itu hanya menggunakan kekunci AWS untuk memuat naik aplikasi yang diubah suai dengan perisian hasad dan kemudian menjalankan arahan deploy dengan kelayakan sedemikian. Rahsia yang bocor, bersama-sama dengan maklumat yang terkandung dalam pipeline"Kempen yang hebat!" mungkin bermaksud Memento telah merosakkan mangsa yang malang itu.

Apa yang Memento beritahu kita di sini ialah sebaik sahaja kebocoran rahsia berlaku, seperti kunci akses AWS dalam contoh, anda perlu membatalkan rahsia tersebut (putar kunci di atas) segeraSentiasa ada tingkap pendedahan antara kebocoran commit dan pembatalan rahsia; menulis semula sejarah Git adalah sukar (malah negara autoritarian yang paling keras cuba menulis semula sejarah sedemikian, tetapi tidak berjaya) dan mungkin tidak berkesan (rakan-rakan kita mungkin telah mengklon sebelum repositori dengan kebocoran rahsia commit). Putar kekunci dengan segera dan berdoa sambil membaca log aktiviti untuk akaun yang disasarkan semasa tempoh pendedahan!

Mungkin organisasi harus larangan penggunaan rahsia jangka panjang dalam CI/CD pipelines, dan gantikannya dengan kelayakan temporal. Dalam contoh sebelumnya dengan kunci AWS dalam tindakan GitHub, adalah lebih selamat untuk menggunakan Pembekal OpenID Connect (OIDC) untuk mendapatkan kelayakan jangka pendek yang diperlukan untuk tindakan.

Kemarahan PayaAnda sangat bernasib baik! Membocorkan skrip dengan kekunci berkod keras adalah amalan biasa pada zaman dahulu, walaupun pada baldi S3 yang boleh diakses secara umum. Apa yang anda perlu lakukan hanyalah menyelusuri objek dalam baldi dan melakukan sedikit pencarian untuk mencari perkara yang menarik.

Kadangkala kawasan yang digunakan untuk penggunaan (baldi AWS S3 dalam contoh ini) dibuka untuk dibaca daripada pihak luar, kerana kecacatan konfigurasi (yang tidak dikesan). Apa Kemarahan Paya digunakan adalah seperti ini:

aws s3 ls --recursive s3://<bucket_name>/<path>/ | \
awk '{print $4}' | \
xargs -I FNAME sh -c "echo FNAME; \
  aws s3 cp s3://<bucket_name>/FNAME - | \
  grep '<regex_pattern>'"

Baldi itu mungkin dicipta dalam templat peruntukan yang boleh diimbas secara automatik untuk kecacatan keselamatan.

Konfigurasi lalai alat itu hanyalah mainan untuk kami

Untuk memberikan contoh konkrit, mari kita bincangkan tentang Jenkins, salah satu alat CI yang paling popular.

Kemarahan PayaAdakah anda ingat kotak pilihan “Dayakan Keselamatan” dalam Jenkins, dan berapa banyak organisasi yang memilih untuk tidak mengaktifkannya demi kemudahan? Dan “Sesiapa sahaja boleh melakukan apa sahaja"gabungan kebenaran sebagai lalai? Dan pemalam Jenkins yang menjengkelkan itu, seperti Plugin GitHub OAuthLelaki yang mengkonfigurasinya memilih kedua-dua “Berikan kebenaran BACA kepada semua Pengguna yang Disahkan” dan “Gunakan kebenaran repositori GitHub”, yang memberikan kami akses kepada semua projek mereka.

(Maaf, Jenkins, kerana menjadikan awak sebagai contoh 😉)

Kekal mahir (walaupun ketagih) dengan prinsip keselamatan. Salah satunya ialah Selamat melalui lalai prinsip: kawalan harus ditetapkan secara lalai kepada tetapan yang paling selamat. Keselamatan harus dibina ke dalam CI/CD alat dan pipelinedari bawah ke atas, bukannya menjadi perkara sampingan. Tetapi keramahan pengguna dan kemudahan sering bertembung dengan keselamatan.

Bagi kes Jenkins, pengesahan terbina dalam terlalu rapuh: jangan sekali-kali menggunakan mekanisme pengesahan terbina dalam JenkinsLebih baik memilih mekanisme pihak ketiga (SAML, LDAP, Google…), dengan pemalam Strategi Kebenaran Berasaskan Peranan (“RBAC”). Dan berhati-hatilah dengan admin akaun.

Jaga bagaimana pekerjaan dan pipeline fail dalam Jenkins dikendalikan. Begitu juga dengan Plugin Konfigurasi-sebagai-Kod dan fail konfigurasinya, yang terpakai pada konfigurasi Jenkins.

Beralih daripada hos kendiri CI/CD sistem kepada sistem SaaS berasaskan awan menghapuskan beberapa potensi risiko yang membolehkan pergerakan lateral dalam rangkaian organisasi, tetapi menambah risiko lain, seperti perlu membuka sambungan luaran antara sistem dalaman sedia ada dan sistem luaran CI/CD alat.

Organisasi harus berusahacisberhati-hati dalam mengeraskan CI/CD sistem, bermula dengan tetapan yang paling ketat dan secara beransur-ansur dibuka dengan kebenaran minimum yang diperlukan untuk pipeline langkah-langkah.

Mengkonfigurasi keselamatan dalam CI/CD Alatan mungkin merupakan satu tugasan yang rumit. Kebanyakannya mempunyai plugin atau sambungan yang mempunyai kebanyakan kelemahan dan perlu dikemas kini.

Pengimbas konfigurasi salah keselamatan untuk alat atau penanda aras yang kompleks sedemikian mungkin dapat membantu.

Menyuntik kod dalam pipeline arahan untuk keseronokan dan keuntungan

M3M3N70Pernahkah anda menggunakan Untrusted Code Checkouts, tindakan dan skrip yang terdedah kepada suntikan arahan?

Bahagian ini menunjukkan bahawa pipeline itu sendiri mungkin mempunyai kesilapan pengekodan yang membolehkan pelaku jahat menyuntik pelaksanaan kod sewenang-wenangnya dalam pipeline tanpa mengubah pipeline sumber itu sendiriContohnya menggunakan PR

Contoh pertama bagi aliran kerja GitHub yang malang:

# INSECURE. Provided as an example only.
on:
  pull_request_target #1

jobs:
  build:
    name: Build and test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: $ #2

      - uses: actions/setup-node@v1
      - run: |
          npm install #3
          npm build
      # ... more steps ...

Menggabungkan pull_request_target Pencetus aliran kerja dengan pembayaran eksplisit PR yang tidak dipercayai adalah amalan berbahaya yang boleh menyebabkan kompromi repositori. Dalam contoh ini, gabungan malang:

• pull_request_target peristiwa, yang secara lalai mempunyai kebenaran menulis kepada repositori sasaran dan rahsia repositori sasaran, walaupun daripada fork luaran, dan berjalan dalam konteks repositori sasaran PR,
• semak kod PR dari sumber, repo yang tidak dipercayai,
• mencetuskan sebarang skrip yang mungkin beroperasi pada kandungan terkawal PR, seperti dalam kes npm install, dan
• tidak menggunakan syarat untuk mencetuskan pull_request_target acara akan dijalankan hanya jika sejenis label 'PR ini telah ditapis' diberikan kepada PR (pengguna luaran tidak boleh memberikan label kepada PR).

Contoh kedua mengambil input yang tidak dipercayai (daripada isu, komen atau pull request) sebagai sumber untuk hujah yang dihantar kepada a pipeline arahan melalui ungkapan. Ini ialah pipeline versi kerentanan suntikan arahan OS.

- name: Check title
  run: |
    title="$"
    if [[ ! $title =~ ^.*:\ .*$ ]]; then
      echo "Bad issue title"
      exit 1
    fi

Operasi jalankan menghasilkan skrip shell sementara berdasarkan templat, dengan $ digantikan, menjadikannya terdedah kepada suntikan arahan shell. Penyerang dengan akaun GitHub palsu boleh menimbulkan masalah dengan tajuk a"; bad_code_goes_here;#, dan ledakan! 

Kemarahan PayaOh, mereka semua membuka pintu untuk suntikan arahan hanya dengan membuka isu…

Terdapat kelemahan pelaksanaan kod dalam tindakan GitHub, seperti komen-gajira, kini telah dibaiki. Sila baca "Input yang tidak dipercayai dalam aliran kerja GitHub" untuk maklumat penuh.

Moral cerita ini: Jangan sekali-kali membuat pembayaran dan membina PR daripada sumber yang tidak dipercayai tanpa menyemak PR terlebih dahulu. 'Tidak dipercayai' di sini, melainkan di bawah pengesahan asal usul yang ketat, boleh bermaksud mana-mana akaun pembangun yang berpotensi dirampas.

Penyebaran perisian hasad yang tidak disengajakan di sini!

Pengerahan berterusan adalah klimaks automasi, tetapi klimaks itu boleh digagalkan oleh kekurangan kawalan kelulusan yang sesuai pada pipeline aliran.

Risiko penggunaan automatik sepenuhnya daripada sumber commit kepada sistem pengeluaran termasuk potensi kod berniat jahat untuk digunakan dalam persekitaran pengeluaran tanpa dikesan, serta potensi ralat dalam proses penggunaan yang menyebabkan gangguan atau gangguan.

Untuk mengurangkan risiko ini, organisasi sering disyorkan untuk melaksanakan "langkah sukar" dalam proses pelaksanaan mereka, yang memerlukan kelulusan manusia sebelum keluaran digunakan ke persekitaran akhir.

Mereka sedang menutup pintu

Kemarahan PayaKata laluan lalai yang menggembirakan itu CI/CD alat-alat sedang dipadamkan. Mengakses /var/lib/jenkins/secrets/initialAdminPassword kini menjadi landasan mati. Banyak alat kini menyediakan 2FA, yang dipopularkan oleh Covid, dan malah monyet kod paling malas di luar sana pun menggunakannya!

M3M3N70Kami sedang melawan 2FA, tetapi ia tidak semudah itu. Sukar untuk menipu mereka, kerana "Scatter Swine" dilakukan dengan TwilioDengan kekunci WebAuthn, ia jauh lebih sukar. Sekurang-kurangnya, kita boleh cuba mencuri kuki untuk memintas MFA, tetapi perlu memasuki kotak pembangun.

Pengesahan Berbilang Faktor merupakan langkah yang baik ke arah yang betul untuk mengehadkan risiko kebocoran rahsia pengesahan. Kebanyakan alatan DevOps moden menyokong MFA. Dan kunci pengesahan di bawah WebAuthn / U2F (lihat Projek FIDO2) mungkin merupakan pilihan terbaik untuk MFA dalam DevOps, jika diuruskan dengan betul.

Kemarahan PayaAhli DevOps sedang sedar. Mereka mempunyai sifat "paling tidak berhak". Dan mereka bukan lagi monyet kod. Kini kita ditangkap basah oleh pengulas.

sebenarnya, pipelinekini lebih mantap berbanding beberapa tahun yang lalu, dengan tindakan dan skrip yang lemah dialih keluar, dan dengan langkah ujian keselamatan tambahan yang juga mengesan dropper kami yang tersembunyi secara sembunyi-sembunyi commits dan pakej yang telah kami rampas.

Soalan untuk pembaca: adakah proses membina perisian daripada sumber dan melaksanakannya ke dalam pengeluaran merupakan satu perniagaan yang berisiko? Bolehkah anda melihat DevOps anda dalam peringkat masa-masa indah dahulu untuk orang jahat?

Cadangan Akhir

Di mana hendak bermula CI/CD pipelines?

Cadangan pertama mudah di sini: Berhati-hati mengkaji pipelines (mereka adalah kritikal sumber) untuk isu keselamatan. Semakan adalah mahal tetapi perlu, dan harus dilakukan dengan betul. Pengulas harus sedar tentang apa yang perlu dilihat. Setiap langkah mesti diperiksa untuk kecacatan.

Mungkin gabungan pengulas pakar yang dilengkapi dengan pengimbas kod berniat jahat automatik boleh membantu.

Cadangan kedua adalah untuk melatih pembangun yang menulis pipelinedan pastikan mereka berada dalam keadaan selamatPerkara yang perlu dipertimbangkan:

• Cara mengendalikan pengesahan dengan betul dengan perkhidmatan dalaman dan awan, mengelakkan gangguan pengendalian kelayakan jangka panjang.
• Cara mengehadkan pipelinekepada set sumber yang tepat yang perlu diaksesnya. Prinsip keistimewaan paling minimum sekali lagi menyerlah.
• Cara menulis langkah-langkah untuk membuat pipelineboleh dihasilkan semula seperti penyematan versi dan mengelakkan kerentanan suntikan arahan.
• Cara meluluskan penggunaan dari perspektif keselamatan (mereka adalah orang lain!): keselamatan yang mana standards harus dipadankan dan cara menambah cek/get yang sepadan dalam pipelines.

Cadangan ketiga adalah untuk mengkonfigurasi CI/CD sistem dengan berhati-hatiPengesahan yang kukuh, tiada kata laluan lalai atau tetapan tidak selamat, keistimewaan minimum… Jaga kelemahan dalam pemalam dan sambungan yang dipasang. Ini mungkin menjadi tumpuan siaran berikut, sila teruskan mengikuti.

Cadangan keempat adalah untuk memanfaatkan CI/CD pipelines untuk automasi keselamatanAnalisis kod sumber (SAST), analisis komposisi sumber (SCA), pengimbasan kebocoran rahsia, alat anti-perisian hasad, pengimbas keselamatan kontena atau pengesan masa jalan automatik (DAST dan perisian hasad) boleh dijalankan secara rutin pada pipelineDan organisasi anda mungkin menguatkuasakan standardtentang liputan mengenai pengimbasan keselamatan dalam CI/CD.

Ingatkan, alat-alat ini masih belum mengalih keluar ulasan pakar daripada persamaan, jika tidak, anda mungkin mempunyai rasa selamat yang palsu.

Jika anda mahir dalam kelompok sepuluh teratas OWASP, projek terbaru yang bagus ialah 10 OWASP Teratas CI/CD Risiko Keselamatan.

Nota Penafian

(1) Contoh-contoh dalam catatan ini menggunakan GitHub sebagai SCM, AWS sebagai penyedia awan dan GitHub Actions atau Jenkins sebagai CI/CD alat ini. Ia tidak lebih lemah/selamat daripada alternatifnya. Tiada niat buruk untuk akhbar! Alat ini berkuasa dan perlu digunakan dengan sewajarnya.

(2) M3M3N70 dan Kemarahan Paya adalah watak-watak fiksyen. Sebarang persamaan dengan orang atau kumpulan, sama ada yang masih hidup atau yang telah meninggal dunia, hanyalah kebetulan… atau adakah ia kebetulan?

Untuk membaca lebih lanjut

• Haymore, A. dkk. "10 kisah dunia sebenar tentang bagaimana kita telah berkompromi CI/CD pipelines ”. Kumpulan NCC, Jan 2022.
• configure-aws-credentials Tindakan GitHub dan Mengkonfigurasi OpenID Connect dalam Perkhidmatan Web Amazon untuk butiran tentang cara menjalankan arahan AWS untuk penggunaan dalam aliran kerja GitHub.
• Lobacevski J. “Memastikan Tindakan dan aliran kerja GitHub anda selamat Bahagian 1: Mencegah permintaan pwn”Makmal Keselamatan GitLab, Dis 2020.
• Lobacevski J. “Memastikan Tindakan dan aliran kerja GitHub anda selamat Bahagian 2: Input yang tidak dipercayai”. Makmal Keselamatan GitLab, Jan 2021.
• OWASP. "10 Teratas OWASP CI/CD Risiko Keselamatan"Julai 2022.
• Saltzer J. & Schroeder M. "Perlindungan Maklumat dalam Sistem Komputer". Apr 1975. Prinsip keselamatan berkembang seiring dengan teknologi, tetapi 47 tahun kemudian kebanyakan idea S&S kekal berkuat kuasa.
• NCSC UK. "Lindungi binaan dan penggunaan pipeline". Pusat Keselamatan Siber Kebangsaan UK, Feb 2019.