Naon anu tiasa lepat CI/CD pipelines?

Integrasi kontinyu sareng pangiriman kontinyu (CI/CD) pipelinemangrupikeun pondasi tina organisasi perangkat lunak naon waé anu ngawangun perangkat lunak ku cara "modéren". Otomatisasi nyayogikeun kakuatan anu ageung, tapi kaseueuran pamekar sono kana tanggung jawab anu ditanggungna.

pamekar: Muhun, urang nyandak CI/CD kaamanan sacara serius sareng gaduh kontrol anu kuat kana pangurus kode, marios commits sateuacan ngahiji; padamelan sareng pipelinedijaga ku staf senior, aranjeunna ngajaga henteu bocor rahasia di pipelines. Sareng alat éta dipasang ku jalmi anu terang kana hal éta. Naon anu tiasa lepat?

Pamekar anu dipikahormat, CI/CD Sistemna rumit. Seranganana anu lega narik minat aktor jahat. Langkung saé waspada sareng ulah percaya diri teuing.

Konfigurasi standar sakapeung dijaga sareng janten sobat pangsaéna pikeun hacker. Cacat kritis tiasa aya dina CI/CD pipeline sumber, dina konfigurasi sistem, atanapi di sabudeureun prosés sareng kontéksna pipeline sareng kumaha éta dipicu.

Dina tulisan ieu urang bakal nempatkeun diri urang dina posisi aktor jahat. Bayangkeun urang nuju maca renungan M3M3N70 (Memento Mori?) jeung Amarah Rawa di hiji tempat di jero dark web, meureun dina basa non-kulon, tapi ulah poho yen kajahatan geus nyebar ka sakuliah dunya.

 

Jaman baheula mah gampang pisan...

M3M3N70Balik deui ka jaman baheula, bisnis urang téh gampang pisan… Zero-days téh gampang pisan, aplikasi mah gampang diéksploitasi, aya vuln nu gampang diéksploitasi, jeung urang bisa pindah ka gigir dina waktu nu singget.

Amarah Rawa: Fu#@Naraka! Aya nu geus rada bodo di luar sana, tapi kaayaan geus robah. Jelema-jelema gede teh geus loba omong kosongna jeung AppSec eta.

M3M3N70Muhun. Tapi nu bodo anyar téh para pamekar. Pikeun urang, leuwih gampang milih alat anu dianggo ku jalma-jalma ieu. CI, khususna, nyaéta tambang emas! Token aksés awan, SCM kredensial, kecap akses database produksi, konci pribadi SSH, kredensial pangguna CI anu sanés… Luncat tina hal-hal pamekaran anu pikaboseneun ka inti masalahna rada sepele.

Otomatisasi pikeun ngawangun, nguji, sareng nerapkeun parangkat lunak kalayan CI/CD Alat ieu sering peryogi ngirimkeun rusiah kana paréntah dina léngkah-léngkah. Sareng seringna éta bocor, kalayan akibat anu teu pikaresepeun.

Pipelinebutuh rusiah anu sakapeung 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.

Panginten jaman baheula anu saé nyaéta mendakan dina sajarah Git hiji .env file (pamekar poho nambahkeun kana .gitignore):

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

anu dianggo dina alur kerja GitHub .github/deploy.yaml anu ngandung hal sapertos kieu:

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! Konci aws éta jalan! Kami nguji heula parobihan inocuos dina aplikasi, teras nambihan sting sabab éta jalma siga anu teu sadar. Bingo! Kampanye anu saé pisan…

Aktor jahat éta ngan saukur nganggo konci AWS pikeun unggah aplikasi anu dimodifikasi nganggo malware teras ngajalankeun paréntah deploy nganggo kredensial sapertos kitu. Rahasia anu bocor, sareng inpormasi anu aya dina pipeline"Kampanye anu hebat!" sigana hartina Memento geus ngaruksak korban anu malang éta.

Anu dicaritakeun ku Memento di dieu nyaéta sakali aya bocor rahasia, sapertos konci aksés AWS dina conto, anjeun kedah ngabatalkeun rahasia éta (puter konci di luhur) geuwatSok aya waé jandela paparan antara bocorna commit sareng pembatalan rahasia; nulis ulang riwayat Git téh hésé (malahan nagara otoriter anu paling tangguh parantos nyobian nyerat ulang sajarah sapertos kitu, tapi teu aya hasilna) sareng sigana teu efektif (babaturan urang panginten parantos ngaklon sateuacan gudang kalayan bocor rahasia commit). Puterkeun konci langsung, teras ngadoa bari maca log aktivitas pikeun akun anu dituju salami jandela paparan!

Sigana mah organisasi kudu larangan ngagunakeun rusiah jangka panjang dina CI/CD pipelines, sareng gentos ku kredensial temporal. Dina conto sateuacanna nganggo konci AWS dina tindakan GitHub, langkung aman nganggo Panyadia OpenID Connect (OIDC) pikeun kéngingkeun kredensial jangka pondok anu diperyogikeun pikeun tindakan.

Amarah RawaAnjeun untung pisan! Ngabocorkeun skrip nganggo konci anu di-hardcode mangrupikeun prakték umum dina jaman baheula, bahkan dina ember S3 anu tiasa diaksés ku masarakat. Anu anjeun kedah laksanakeun nyaéta ngalangkungan objék dina ember sareng ngalakukeun sababaraha grepping pikeun mendakan hal-hal anu pikaresepeun.

Kadang-kadang daérah anu dianggo pikeun palaksanaan (ember AWS S3 dina conto ieu) dibuka pikeun dibaca ti pihak luar, kusabab cacad konfigurasi (anu teu kadeteksi). Naon Amarah Rawa anu dianggo téh siga kieu:

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>'"

Bucket éta sigana dijieun dina témplat provisioning anu tiasa otomatis discan pikeun kakurangan kaamanan.

Konfigurasi standar alat éta téh ngan saukur cocooan pikeun urang

Pikeun masihan conto anu kongkrit hayu urang bahas Jenkins, salah sahiji alat CI anu paling populér.

Amarah RawaNaha anjeun émut kotak centang "Aktipkeun Kaamanan" dina Jenkins, sareng sabaraha organisasi anu milih henteu ngaktipkeunana demi genah? Sareng éta "Saha waé tiasa ngalakukeun naon waé"kombinasi idin salaku standar? Sareng plugin Jenkins anu ngaganggu éta, sapertos Plugin GitHub OAuthJelema anu ngonpigurasikeunana milih "Berikeun idin READ ka sadaya Pangguna anu Diautentikasi" sareng "Anggo idin repositori GitHub", masihan urang aksés ka sadaya proyékna.

(Hapunten, Jenkins, parantos masihan conto ka anjeun 😉

Tetep pinter (sanajan kecanduan) kana prinsip-prinsip kaamanan. Salah sahijina nyaéta Aman sacara standar prinsip: kontrol kedah standar kana setélan anu paling aman. Kaamanan kedah diwangun kana CI/CD parabot na pipelineti mimiti, lain ngan saukur dipikiran samemehna. Tapi gampang dipaké jeung merenahna mindeng pasea jeung kaamanan.

Pikeun kasus Jenkins, auténtikasi bawaan téh rapuh teuing: ulah pernah nganggo mékanisme auténtikasi bawaan dina JenkinsLeuwih hade milih mékanisme pihak katilu (SAML, LDAP, Google…), nganggo plugin Strategi Otorisasi Berbasis Peran ("RBAC"). Sareng ati-ati pisan sareng admin Akun.

Ngurus kumaha padamelan sareng pipeline file dina Jenkins diurus. Sarua jeung Plugin Konfigurasi-salaku-Kodeu sareng file konfigurasina, anu lumaku pikeun konfigurasi Jenkins.

Pindah ti anu di-host mandiri CI/CD sistem ka SaaS berbasis awan ngaleungitkeun sababaraha résiko poténsial anu ngamungkinkeun gerakan lateral dina jaringan organisasi, tapi nambihan anu sanés, sapertos kedah muka sambungan éksternal antara sistem internal anu tos aya sareng sistem anu diéksternalisasi CI/CD alat.

Organisasi kedah ngalaksanakeuncisati-ati dina ngagedékeun CI/CD sistem, dimimitian ku setélan anu paling ngawatesan teras laun-laun dibuka ku idin minimal anu diperyogikeun pikeun pipeline léngkah.

Ngonpigurasikeun kaamanan dina CI/CD Alat-alatna tiasa janten hal anu rumit. Seueur anu gaduh plugin atanapi éksténsi anu ngagaduhan kaseueuran kerentanan sareng kedah diénggalan.

Pamindai konfigurasi kaamanan anu salah pikeun alat atanapi tolok ukur anu rumit sapertos kitu tiasa ngabantosan.

Nyuntikkeun kodeu kana pipeline paréntah pikeun senang-senang sareng kauntungan

M3M3N70Dupi anjeun kantos nganggo Untrusted Code Checkouts, tindakan sareng skrip anu rentan ka injeksi paréntah?

Bagian ieu nunjukkeun yén pipeline sorangan bisa jadi boga kasalahan coding anu ngamungkinkeun aktor jahat pikeun nyuntik palaksanaan kodeu sacara sembarangan dina pipeline tanpa ngarobah pipeline sumberna soranganContona nganggo PR

Conto munggaran tina hiji alur kerja GitHub anu hanjakal:

# 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 ...

Kombinasi pull_request_target Pemicu alur kerja kalayan pamariksaan eksplisit tina PR anu teu dipercaya mangrupikeun prakték anu bahaya anu tiasa nyababkeun kompromi repositori. Dina conto éta, kombinasi anu teu dipiharep tina:

• pull_request_target kajadian, anu sacara standar gaduh idin nulis ka repositori target sareng rahasia repositori target, bahkan ti garpu éksternal, sareng dijalankeun dina kontéks repositori target PR,
• pariksa kode PR tina sumberna, repo anu teu dipercaya,
• micu skrip naon waé anu tiasa beroperasi dina eusi anu dikontrol PR, sapertos dina kasus npm install, sarta
• henteu nganggo kaayaan pikeun memicu pull_request_target kajadian ngan ukur dijalankeun upami aya labél 'PR ieu parantos dipariksa' anu ditugaskeun ka PR (pangguna éksternal teu tiasa masihan labél ka PR).

Conto kadua nyandak input anu teu dipercaya (tina masalah, koméntar atanapi pull request) salaku sumber pikeun argumén anu disalurkeun ka a pipeline paréntah ngalangkungan éksprési. Ieu mangrupikeun pipeline vérsi kerentanan injeksi paréntah OS.

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

Operasi anu dijalankeun ngahasilkeun skrip shell samentawis dumasar kana citakan, kalayan $ diganti, janten rentan ka suntikan paréntah shell. Penyerang anu gaduh akun GitHub palsu tiasa nyiptakeun masalah sareng judul a"; bad_code_goes_here;#, jeung boom! (or) , jeung boom! 

Amarah RawaOh, éta jalma-jalma muka panto pikeun suntikan paréntah ku ngan saukur muka masalah…

Aya kerentanan palaksanaan kode dina tindakan GitHub, sapertos gajira-comment, ayeuna tos dibenerkeun. Mangga baca "Input anu teu dipercaya dina alur kerja GitHub" keur leuwih jelasna.

Moral caritana: Ulah pernah mariksa sareng ngadamel PR tina sumber anu teu tiasa dipercaya tanpa marios heula PR-na. 'Teu dipercaya' di dieu, kajaba lamun aya auténtikasi asal anu kejem, bisa hartina akun pamekar anu kamungkinan dibajak.

 

Panyebaran malware anu teu dihaja di dieu!

deployment kontinyu nyaéta klimaks otomatisasi, tapi klimaks éta tiasa diganggu ku kurangna kontrol persetujuan anu pas dina pipeline aliran.

Résiko tina palaksanaan otomatis pinuh ti sumber commit kana sistem produksi kalebet poténsi kode jahat anu bakal disebarkeun ka lingkungan produksi tanpa dideteksi, ogé poténsi kasalahan dina prosés panyebaran anu nyababkeun gangguan atanapi gangguan.

Pikeun ngirangan résiko ieu, sering disarankeun yén organisasi ngalaksanakeun "hard break" dina prosés palaksanaanna, anu meryogikeun persetujuan manusa sateuacan rilis disebarkeun ka lingkungan tungtung.

Aranjeunna nuju nutup panto

Amarah Rawa: Sandi standar anu pikabungaheun éta CI/CD parabot-parabot keur dipupus. Ngaksés /var/lib/jenkins/secrets/initialAdminPassword ayeuna geus teu aya gunana. Seueur alat ayeuna nu nyadiakeun 2FA, nu dipopulerkeun ku Covid, komo deui monyét kode nu pangmalesna ogé ngagunakeunana!

M3M3N70Kami keur ngalawan 2FA, tapi teu gampang. Hésé pikeun ngabobol jalma-jalma éta, sabab "Scatter Swine" dilakukeun sareng Twilio. Ku konci WebAuthn éta langkung sesah. Sahenteuna, urang tiasa nyobian maok cookies pikeun ngungkulan MFA, tapi kedah lebet kana kotak pamekar.

Autentikasi Multi-Faktor mangrupikeun léngkah anu saé dina arah anu leres pikeun ngawatesan résiko bocor rahasia auténtikasi. Kaseueuran alat DevOps modéren ngadukung MFA. Sareng konci auténtikasi dina WebAuthn / U2F (tingali Proyék FIDO2) panginten mangrupikeun pilihan anu pangsaéna pikeun MFA dina DevOps, upami dikokolakeun kalayan leres.

Amarah RawaJelema DevOps keur hudang. Maranéhna boga hal "hak istimewa pangleutikna" dina getihna. Jeung maranéhna lain monyét kode deui. Ayeuna urang katéwak ku para reviewer.

Kanyataanna, pipelines ayeuna rada langkung kuat tibatan sababaraha taun ka pengker, kalayan tindakan sareng skrip anu lemah dihapus, sareng kalayan léngkah uji kaamanan tambahan anu bahkan ngadeteksi dropper urang anu disumputkeun sacara siluman commits sareng pakét anu kami bajak.

Patarosan kanggo nu maca: naha prosés ngawangun parangkat lunak tina sumber sareng nerapkeun kana produksi mangrupikeun bisnis anu résiko? Naha anjeun tiasa ningali DevOps anjeun dina tahap jaman baheula anu saé pikeun jalma jahat?

Rekomendasi Akhir

Ti mana mimitina CI/CD pipelines?

Rekomendasi anu munggaran saderhana di dieu: Ati-ati tingalian pipelines (maranéhna nyaéta genting sumber daya) pikeun masalah kaamanan. Ulasan téh mahal tapi perlu, sareng kedah dilakukeun kalayan leres. Anu ngulas kedah terang naon anu kedah ditingali. Unggal léngkah kedah dipariksa pikeun kakurangan.

Sugan waé kombinasi ti para ahli reviewer anu dilengkepan ku pamindai kode jahat otomatis tiasa ngabantosan.

Rekomendasi anu kadua nyaéta pikeun ngalatih pamekar anu nyerat pipelines sareng ngajaga aranjeunna dina kaamananHal-hal anu kedah diperhatoskeun:

• Kumaha carana ngatur auténtikasi nganggo layanan internal sareng awan kalayan leres, nyingkahan gangguan dina ngatur kredensial jangka panjang.
• Kumaha carana ngawatesan pipelinekana sakumpulan sumber daya anu pas anu diperyogikeun. Prinsip hak istimewa anu paling saeutik katingali deui.
• Kumaha carana nulis léngkah-léngkah nyieun pipelines bisa diulang kawas nyematkan vérsi, sarta nyingkahan karentanan injeksi paréntah.
• Kumaha carana nyatujuan palaksanaan tina sudut pandang kaamanan (aranjeunna anu sanés!): kaamanan mana standards kedah cocog sareng kumaha nambihan cék/gerbang anu saluyu dina pipelines.

Rekomendasi katilu nyaéta pikeun ngonpigurasikeun CI/CD sistem kalawan ati-atiAutentikasi anu kuat, teu aya kecap akses standar atanapi setélan anu teu aman, hak istimewa minimal… Jaga kerentanan dina plugin sareng éksténsi anu dipasang. Ieu tiasa janten fokus tulisan-tulisan salajengna, mangga teraskeun.

Rekomendasi kaopat nyaéta pikeun ngungkit nu CI/CD pipelines pikeun otomatisasi kaamananAnalisis kode sumber (SAST), analisis komposisi sumber (SCA), pamindaian bocor rahasia, alat anti-malware, pamindai kaamanan wadah, atanapi detektor runtime otomatis (DAST sareng malware) tiasa dijalankeun sacara rutin dina pipelineSareng organisasi anjeun tiasa ngalaksanakeun standardngeunaan cakupan dina pamindaian kaamanan di CI/CD.

Émut, alat-alat ieu henteu ngaleungitkeun ulasan ahli tina persamaan, upami henteu anjeun tiasa ngagaduhan rasa aman anu palsu.

Upami anjeun ahli dina OWASP top-tens, proyék anu saé anyar nyaéta OWASP Top 10 CI/CD Résiko Kaamanan.

Catetan Bantahan

(1) Conto-conto dina tulisan ieu nganggo GitHub salaku SCM, AWS salaku panyadia awan, sareng GitHub Actions atanapi Jenkins salaku CI/CD alatna. Éta henteu langkung lemah / langkung aman tibatan alternatifna. Teu aya niat pers anu goréng! Alat-alat ieu kuat sareng kedah dianggo kalayan leres.

(2) M3M3N70 jeung Amarah Rawa nyaéta karakter fiksi. Sagala kamiripan jeung jalma atawa kelompok, nu masih hirup atawa nu geus maot, ngan saukur kabeneran… atawa enya?

Pikeun maca leuwih lengkep

• Haymore, A. et al. "10 carita di dunya nyata ngeunaan kumaha urang geus kompromi" CI/CD pipelines ”. Grup NCC, Januari 2022.
• configure-aws-credentials Peta GitHub jeung Ngonpigurasikeun OpenID Connect dina Amazon Web Services kanggo wincikan ngeunaan kumaha ngajalankeun paréntah AWS pikeun palaksanaan dina alur kerja GitHub.
• Lobacevski J. "Ngajaga kaamanan Aksi sareng alur kerja GitHub anjeun Bagian 1: Nyegah pamundut pwn". Lab Kaamanan GitLab, Désémber 2020.
• Lobacevski J. "Ngajaga kaamanan Aksi sareng alur kerja GitHub anjeun Bagian 2: Input anu teu dipercaya". Lab Kaamanan GitLab, Januari 2021.
• OWASP. "10 Puncak OWASP" CI/CD Résiko Kaamanan". Juli 2022.
• Saltzer J. & Schroeder M. "Panyalindungan Informasi dina Sistem Komputer". Apr 1975. Prinsip kaamanan mekar bareng jeung téknologi, tapi 47 taun ti harita kaseueuran ideu S&S tetep lumaku.
• NCSC Inggris. "Amankeun pangwangunan sareng palaksanaanna pipeline". Pusat Kaamanan Siber Nasional Inggris, Pébruari 2019.