Ano ang maaaring magkamali CI/CD pipelines?

Patuloy na integrasyon at patuloy na paghahatid (CI/CD) pipelineAng mga ito ang pundasyon ng anumang organisasyon ng software na bumubuo ng software sa isang "modernong" paraan. Ang automation ay nagbibigay ng malaking kapangyarihan, ngunit karamihan sa mga developer ay nakakaligtaan ang responsibilidad na kaakibat nito.

Developer: Oo, kukuha kami CI/CD katiwasayan seryoso at may matibay na kontrol sa mga tagapangalaga ng code, pagsusuri commits bago ang mga pagsasanib; mga trabaho at pipelineay pinapanatili ng mga nakatataas na kawani, inaalagaan nila ang hindi pagtagas ng mga sikreto sa pipelines. At ang kagamitan ay inilagay ng mga tauhang may alam sa bagay na ito. Ano ang maaaring magkamali?

Mahal na developer, CI/CD Ang mga sistema ay kumplikado. Ang malawak na pag-atake nito ay nakaakit ng mga masasamang aktor. Mas mabuting maging maingat at huwag maging labis na kumpiyansa.

Minsan, ang default na configuration ay pinapanatili at nagiging matalik na kaibigan para sa mga hacker. Maaaring may mga kritikal na depekto sa CI/CD pipeline mga pinagmumulan, sa konpigurasyon ng sistema, o sa paligid ng proseso at konteksto ng pipeline at kung paano ito nati-trigger.

Sa post na ito, ilalagay natin ang ating mga sarili sa sitwasyon ng mga hindi magandang aktor. Isipin na binabasa natin ang mga iniisip ng M3M3N70 (Memento Mori?) at Galit sa Latian sa kung saan sa dark web, marahil sa isang wikang hindi kanluranin, ngunit huwag palampasin na ang kasamaan ay kumakalat sa buong mundo.

 

Noong unang panahon, napakadali lang...

M3M3N70: Balik tayo sa magandang panahon, napakadali lang ng negosyo natin… Madali lang ang mga Zero-days, bukas ang mga app na may mga vuln na madaling gamitin, at nakakagalaw tayo nang pahilis sa isang iglap.

Galit sa Latian: Fu#@Hell! May mga baliw pa rin diyan, pero nagbago na ang lahat. Puro kalokohan ang ginagawa ng mga malalaking tao diyan sa kalokohang AppSec na 'yan.

M3M3N70Oo. Pero ang mga bagong hangal ay ang mga developer. Para sa amin, mas madaling gamitin ang mga tool na ginagamit ng mga taong ito. Ang CI, sa partikular, ay isang minahan ng ginto! Mga cloud access token, SCM mga kredensyal, mga password sa production database, mga pribadong key ng SSH, mga kredensyal ng iba pang mga CI user… Ang paglipat mula sa nakakabagot na mga bagay tungkol sa dev patungo sa totoong nilalaman ay medyo simple lang.

Awtomasyon para sa pagbuo, pagsubok, at pag-deploy ng software na may CI/CD Ang tool ay kadalasang nangangailangan ng pagpasa ng mga sikreto sa mga utos nang paunti-unti. At kadalasan ang mga ito ay natutuklasan, na may mga kakila-kilabot na kahihinatnan.

Pipelinekailangan ng mga sikreto na minsan ay nabubunyag

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.

Marahil ang magagandang lumang panahon ay ang matagpuan sa kasaysayan ng Git ang isang .env file (nakalimutan itong idagdag ng developer sa .gitignore):

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

na ginamit sa isang daloy ng trabaho sa GitHub .github/deploy.yaml na naglalaman ng ganito:

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! Gumagana naman ang mga aws key na 'yan! Sinubukan muna namin ang isang inocuos change sa app, tapos dinagdagan pa ng sting dahil mukhang walang kaalam-alam ang mga 'yon. Bingo! Ang galing naman ng campaign na 'yan...

Ginamit lang ng masamang aktor ang mga AWS key para mag-upload ng binagong application na may malware at pagkatapos ay pinatakbo ang deploy command na may ganitong mga kredensyal. Ang mga nabunyag na sikreto, kasama ang impormasyong nakapaloob sa pipelineAng "Napakagandang kampanya!" ay malamang na nangangahulugang sinira ni Memento ang kawawang biktima.

Ang sinasabi sa atin ng Memento dito ay kapag nangyari ang isang sikretong pagtagas, tulad ng mga AWS access key sa halimbawa, kailangan mong bawiin ang sikreto (i-rotate ang mga key sa itaas) agad. Palaging mayroong bintana ng pagkakalantad sa pagitan ng pagtulo commit at ang lihim na pagpapawalang-bisa; Mahirap ang muling pagsusulat ng kasaysayan ng Git (kahit ang pinakamatigas na awtoritaryan na estado ay sinubukan ang ganitong muling pagsusulat ng kasaysayan, ngunit walang naging resulta) at malamang ay hindi epektibo (maaaring na-clone na ng ating mga kaibigan bago pa man ang imbakan na may sikretong tagas) commit). I-rotate agad ang mga key, at magdasal habang nagbabasa ng mga activity log para sa target na account habang nasa exposure window!

Marahil dapat ang mga organisasyon pagbabawal sa paggamit ng mga pangmatagalang sikreto CI/CD pipelines, at palitan ang mga ito ng mga temporal na kredensyal. Sa nakaraang halimbawa gamit ang mga AWS key sa mga aksyon sa GitHub, mas ligtas na gumamit ng Tagapagbigay ng serbisyo ng OpenID Connect (OIDC) upang makakuha ng mga panandaliang kredensyal na kinakailangan para sa mga aksyon.

Galit sa LatianAng swerte mo! Karaniwang gawain noon ang pagtagas ng mga script na may mga hardcoded key, kahit na sa mga pampublikong S3 bucket. Ang kailangan mo lang gawin ay suriin ang mga bagay sa bucket at maghanap ng mga interesanteng bagay.

Minsan, ang lugar na ginagamit para sa deployment (isang AWS S3 bucket sa halimbawang ito) ay bukas para mabasa mula sa mga tagalabas, dahil sa isang depekto sa configuration (na hindi natukoy). Ano Galit sa Latian ginamit ay parang ganito:

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

Ang bucket ay malamang na nilikha sa isang provisioning template na maaaring awtomatikong i-scan para sa mga depekto sa seguridad.

Ang default na configuration ng tool ay isang laruan para sa amin

Para magbigay ng mga konkretong halimbawa, pag-usapan natin ang Jenkins, isa sa mga pinakasikat na kagamitang CI.

Galit sa LatianNatatandaan mo ba yung checkbox na “Enable Security” sa Jenkins, at ilang organisasyon ang pumiling huwag itong i-activate para sa kaginhawahan? At yung mga “Kahit sino ay kayang gawin ang kahit ano"mga kombinasyon ng pahintulot bilang default? At ang mga nakakainis na plugin ng Jenkins, tulad ng GitHub OAuth pluginPinili ng taong nag-configure nito ang parehong “Grant READ permissions to all Authenticated Users” at “Gumamit ng mga pahintulot sa repositoryo ng GitHub”, na nagbibigay sa amin ng access sa lahat ng kanilang mga proyekto.

(Paumanhin, Jenkins, sa pagbibigay sa iyo ng halimbawa 😉)

Manatiling bihasa (kahit adik) sa mga prinsipyo ng seguridad. Ang isa ay ang Ligtas bilang default prinsipyo: ang mga kontrol ay dapat na naka-default sa mga pinaka-secure na setting hangga't maaari. Ang seguridad ay dapat na nakapaloob sa CI/CD mga tool at pipelinemula sa simula, sa halip na maging isang nahuling isip lamang. Ngunit ang pagiging madaling gamitin at kaginhawahan ay kadalasang sumasalungat sa seguridad.

Para sa kaso ni Jenkins, ang built-in na authentication ay masyadong marupok: huwag kailanman gamitin ang built-in na mga mekanismo ng pagpapatotoo sa JenkinsMas mainam na pumili ng mekanismo mula sa ikatlong partido (SAML, LDAP, Google...), na may Role-based Authorization Strategy (“RBAC”) plugin. At maging lubos na maingat sa admin account.

Alagaan kung paano ang trabaho at pipeline ang mga file sa Jenkins ay hinahawakan. Ganun din sa Plugin na Configuration-as-Code at ang mga config file nito, na naaangkop sa Jenkins configuration.

Paglipat mula sa self-hosted CI/CD ang mga sistema patungo sa mga cloud-based na SaaS ay nag-aalis ng ilang potensyal na panganib na nagpapahintulot sa paggalaw sa loob ng network ng organisasyon, ngunit nagdagdag ng iba pa, tulad ng pagkakaroon ng pagbubukas ng mga panlabas na koneksyon sa pagitan ng mga umiiral na panloob na sistema at ng mga externalized na sistema CI/CD tool.

Dapat magsikap ang mga organisasyoncisang nararapat na pag-iingat sa pagpapatigas ng CI/CD sistema, simula sa mga pinaka-mahigpit na setting at unti-unting binubuksan gamit ang mga minimum na kinakailangang pahintulot para sa pipeline hakbang.

Pag-configure ng seguridad sa CI/CD Ang mga tool ay maaaring maging kumplikado. Marami ang may mga plugin o extension na nagtataglay ng karamihan sa mga kahinaan at kailangang i-update.

Maaaring makatulong ang mga scanner o benchmark na may maling configuration sa seguridad para sa mga ganitong kumplikadong tool.

Pag-inject ng code pipeline mga utos para sa kasiyahan at kita

M3M3N70Gumamit ka na ba ng Untrusted Code Checkouts, yung mga vulnerable na aksyon at script na vulnerable sa command-injection?

Ipinapakita ng seksyong ito na ang pipeline mismo ay maaaring magkaroon ng mga pagkakamali sa pag-coding na nagbibigay-daan sa masasamang aktor na magpasok ng arbitraryong pagpapatupad ng code sa pipeline nang hindi binabago ang pipeline pinagmulan mismoHalimbawa, ang paggamit ng PR

Isang unang halimbawa ng isang kapus-palad na daloy ng trabaho sa GitHub:

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

Pagsasama pull_request_target Ang workflow trigger na may tahasang pag-checkout ng isang hindi mapagkakatiwalaang PR ay isang mapanganib na gawain na maaaring humantong sa pagkompromiso sa repository. Sa halimbawa, ang hindi kanais-nais na kumbinasyon ng:

• pull_request_target kaganapan, na bilang default ay may pahintulot na magsulat sa target na repositoryo at mga lihim ng target na repositoryo, kahit na mula sa mga panlabas na fork, at tumatakbo sa konteksto ng target na repositoryo ng PR,
• tingnan ang PR code mula sa pinagmulan, hindi mapagkakatiwalaang repo,
• mag-trigger ng anumang script na maaaring gumana sa mga nilalamang kontrolado ng PR, tulad ng sa kaso ng npm install, at
• hindi paggamit ng isang kondisyon sa pag-trigger pull_request_target tatakbo lamang ang kaganapan kung ang isang uri ng label na 'nasuri na ang PR na ito' ay itinalaga sa PR (hindi maaaring magtalaga ng mga label ang mga panlabas na user sa PR).

Ang pangalawang halimbawa ay kumukuha ng hindi mapagkakatiwalaang input (mula sa isang isyu, komento o pull request) bilang pinagmumulan ng mga argumentong ipinasa sa isang pipeline utos sa pamamagitan ng mga ekspresyon. Ito ang pipeline bersyon ng kahinaan sa pag-iniksyon ng utos ng OS.

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

Ang pagpapatakbo ng operasyon ay bumubuo ng isang pansamantalang script ng shell batay sa template, na may $ pinalitan, na ginagawang mahina ito sa shell command injection. Ang isang attacker na may pekeng GitHub account ay maaaring lumikha ng isyu sa isang pamagat a"; bad_code_goes_here;#, at boom! 

Galit sa LatianNaku, binubuksan lang ng mga 'yan ang pinto para sa command injection sa pamamagitan lang ng pagbubukas ng isyu…

May mga kahinaan sa pagpapatupad ng code sa mga aksyon sa GitHub, tulad ng komento ni gajira, naayos na ngayon. Pakibasa "Hindi mapagkakatiwalaang input sa mga daloy ng trabaho sa GitHub" para sa buong detalye.

Ang aral ng kuwento: Huwag na huwag mag-checkout at gumawa ng mga PR mula sa mga hindi mapagkakatiwalaang mapagkukunan nang hindi muna sinusuri ang PR. Ang 'hindi mapagkakatiwalaan' dito, maliban kung sa ilalim ng mahigpit na pagpapatotoo ng pinagmulan, ay maaaring mangahulugan ng anumang potensyal na na-hijack na developer account.

 

May hindi sinasadyang pag-deploy ng malware dito!

Patuloy na deployment ay ang kasukdulan ng automation, ngunit ang kasukdulan na iyon ay maaaring mabigo dahil sa kakulangan ng naaangkop na mga kontrol sa pag-apruba sa pipeline flow.

Ang mga panganib ng ganap na awtomatikong pag-deploy mula sa pinagmulan commit Kabilang sa mga problema sa mga sistema ng produksyon ang posibilidad na mai-deploy ang malisyosong code sa mga kapaligiran ng produksyon nang hindi natutukoy, pati na rin ang potensyal para sa mga error sa proseso ng pag-deploy na magdulot ng mga pagkaantala o pagkawala ng kuryente.

Upang mabawasan ang mga panganib na ito, kadalasang inirerekomenda na magpatupad ang mga organisasyon ng isang "hard break" sa kanilang proseso ng pag-deploy, na nangangailangan ng pagsang-ayon ng tao bago i-deploy ang mga release sa mga end environment.

Isinasara nila ang mga pinto

Galit sa Latian: Ang mga masasayang default na password na iyon CI/CD binubura ang mga kagamitan. Ina-access ang /var/lib/jenkins/secrets/initialAdminPassword ay isa na ngayong patay na landas. Maraming mga tool na ngayon ang nagbibigay ng 2FA, na pinasikat ng Covid, at kahit ang pinakatamad na code monkey ay gumagamit nito!

M3M3N70: Nakikipaglaban kami sa 2FA, pero hindi ganoon kadali. Mahirap i-spear-phish ang mga 'yan, dahil Ginawa ng "Scatter Swine" kasama si Twilio. Mas mahirap ito gamit ang mga WebAuthn key. Kahit papaano, maaari nating subukan na magnakaw ng cookies para malampasan ang MFA, pero kailangang pasukin ang developer's box.

Ang Multi-Factor Authentication ay isang magandang hakbang sa tamang direksyon para limitahan ang panganib ng mga tagas ng mga sikreto ng pagpapatotoo. Karamihan sa mga modernong tool ng DevOps ay sumusuporta sa MFA. At ang mga authentication key sa ilalim ng WebAuthn / U2F (tingnan ang Proyekto ng FIDO2) ay marahil ang pinakamahusay na opsyon para sa MFA sa DevOps, kung maayos na pinamamahalaan.

Galit sa LatianGising na ang mga taga-DevOps. Nasa dugo nila ang "pinakamaliit na pribilehiyo". At hindi na sila mga code monkey. Nahuhuli na tayo ngayon ng mga reviewer.

Sa katunayan, pipelineAng mga s ngayon ay medyo mas matatag kaysa ilang taon na ang nakalilipas, na may mga natanggal na mahihinang aksyon at script, at may mga karagdagang hakbang sa pagsubok sa seguridad na nakatukoy pa nga sa aming mga dropper na nakatago nang palihim. commitmga at paketeng aming na-hijack.

Tanong para sa mambabasa: mapanganib ba ang proseso ng pagbuo ng software mula sa mga pinagmulan at pag-deploy sa produksyon? Nakikita mo ba ang iyong DevOps sa yugto ng mga magagandang panahon para sa mga masasamang tao?

Pangwakas na Mga Rekomendasyon

Saan magsisimula CI/CD pipelines?

Ang unang rekomendasyon ay simple lamang dito: Maingat suriin pipelines (sila ay mapanganib mga mapagkukunan) para sa mga isyu sa seguridad. Magastos ang mga pagsusuri ngunit kinakailangan, at dapat gawin nang maayos. Dapat malaman ng mga tagasuri kung ano ang dapat tingnan. Dapat suriin ang bawat hakbang para sa mga depekto.

Marahil ay makakatulong ang isang kombinasyon ng mga ekspertong tagasuri na armado ng mga awtomatikong malisyosong scanner ng code.

Ang pangalawang rekomendasyon ay ang sanayin ang mga developer na nagsusulat pipelineat panatilihin ang mga ito sa seguridadMga bagay na dapat isaalang-alang:

• Paano wastong pangasiwaan ang authentication gamit ang mga internal at cloud service, upang maiwasan ang abala ng paghawak ng mga pangmatagalang kredensyal.
• Paano limitahan pipelinesa eksaktong hanay ng mga mapagkukunang kailangan nitong ma-access. Muling sumisikat ang prinsipyo ng pinakamababang pribilehiyo.
• Paano isulat ang mga hakbang sa paggawa pipelinemaaaring kopyahin tulad ng pag-pin ng bersyon, at pag-iwas sa mga kahinaan sa command injection.
• Paano aprubahan ang mga deployment mula sa pananaw ng seguridad (iba pa sila!): aling seguridad standarddapat itugma ang s at kung paano magdagdag ng kaukulang mga tseke/gate sa pipelines.

Ang ikatlong rekomendasyon ay ang i-configure ang CI/CD sistema nang may pag-iingatMalakas na pagpapatotoo, walang mga default na password o mga setting na hindi secure, kaunting pribilehiyo… Asikasuhin ang mga kahinaan sa mga naka-install na plugin at extension. Maaaring ito ang maging pokus ng mga sumusunod na post, mangyaring manatiling nakaantabay.

Ang pang-apat na rekomendasyon ay ang pakinabangan ang CI/CD pipelines para sa automation ng seguridadPagsusuri ng source code (SAST), pagsusuri ng komposisyon ng pinagmulan (SCA), ang pag-scan ng mga sikreto para sa pagtagas, mga tool na anti-malware, mga scanner ng seguridad ng container, o mga awtomatikong runtime detector (DAST at malware) ay maaaring patakbuhin nang regular sa pipelineAt maaaring ipatupad ng iyong organisasyon standardtungkol sa saklaw sa pag-scan ng seguridad sa CI/CD.

Paalala lang, hindi pa rin inaalis ng mga tool na ito ang pagsusuri ng eksperto sa equation, kung hindi ay maaari kang magkaroon ng maling pakiramdam ng seguridad.

Kung mahusay ka sa mga nangungunang sampu ng OWASP, isang magandang kamakailang proyekto ang OWASP Nangungunang 10 CI/CD Panganib sa seguridad.

Tala ng Disclaimer

(1) Ang mga halimbawa sa post na ito ay gumagamit ng GitHub bilang SCM, AWS bilang cloud provider, at GitHub Actions o Jenkins bilang CI/CD kasangkapan. Hindi sila mas mahina/mas ligtas kaysa sa kanilang mga alternatibo. Walang masamang intensyon sa pamamahayag! Ang mga kasangkapang ito ay makapangyarihan at kailangang gamitin nang naaangkop.

(2) M3M3N70 at Galit sa Latian ay mga kathang-isip na karakter. Anumang pagkakahawig sa mga tao o grupo, buhay man o patay, ay nagkataon lamang... o hindi ba?

Upang mabasa ang higit pa

• Haymore, A. at iba pa. "10 totoong kwento sa mundo kung paano tayo nakipagkompromiso" CI/CD pipelines ”. NCC Group, Enero 2022.
• configure-aws-credentials Aksyon sa GitHub at Pag-configure ng OpenID Connect sa Amazon Web Services para sa mga detalye kung paano patakbuhin ang mga utos ng AWS para sa pag-deploy sa mga daloy ng trabaho sa GitHub.
• Lobacevski J. "Pagpapanatiling ligtas ng iyong mga Aksyon at daloy ng trabaho sa GitHub Bahagi 1: Pag-iwas sa mga kahilingan sa pwn". GitLab Security Lab, Disyembre 2020.
• Lobacevski J. “Pagpapanatiling ligtas ng iyong mga Aksyon at daloy ng trabaho sa GitHub Bahagi 2: Hindi mapagkakatiwalaang input”. GitLab Security Lab, Enero 2021.
• OWASP. "Nangungunang 10 ng OWASP" CI/CD Mga Panganib sa Seguridad"Hulyo 2022.
• Saltzer J. at Schroeder M. "Ang Proteksyon ng Impormasyon sa mga Sistema ng Kompyuter"Abr 1975. Ang mga prinsipyo ng seguridad ay umunlad kasabay ng teknolohiya, ngunit pagkalipas ng 47 taon, karamihan sa mga ideya ng S&S ay nananatili pa ring may bisa.
• NCSC ng UK. "I-secure ang pagbuo at pag-deploy" pipeline"Pambansang Sentro ng CyberSecurity ng UK, Pebrero 2019.