Kas gali nutikti ne taip CI/CD pipelines?

Nuolatinė integracija ir nuolatinis teikimas (CI/CD) pipelineyra bet kurios programinės įrangos organizacijos, kuriančios programinę įrangą „moderniu“ būdu, pagrindas. Automatizavimas suteikia daug galių, tačiau dauguma kūrėjų nepastebi su tuo susijusios atsakomybės.

RyškalasTaip, mes priimame CI/CD saugumas rimtai ir griežtai kontroliuoti kodo prižiūrėtojus, peržiūrėti commitprieš sujungimus; darbo vietos ir pipelineprižiūri vyresnieji darbuotojai, jie rūpinasi, kad paslaptys nebūtų nutekintos pipelines. Ir įrankį sumontavo personalas, kuris išmano šį reikalą. Kas gali nutikti ne taip?

Gerbiamas kūrėjau, CI/CD Sistemos yra sudėtingos. Platus jų atakų paviršius pritraukė piktavalius veikėjus. Geriau būti atsargiems ir niekada nepersistengti.

Numatytoji konfigūracija kartais išsaugoma ir tampa geriausiu įsilaužėlių draugu. Kritinių trūkumų gali būti CI/CD pipeline šaltiniai, sistemos konfigūracija arba procesas ir kontekstas pipeline ir kaip jis suaktyvinamas.

Šiame įraše įsijausime į blogųjų aktorių padėtį. Įsivaizduokite, kad skaitome apmąstymus... M3M3N70 (Memento Mori?) ir Pelkių įniršis kažkur tamsiajame internete, tikriausiai ne vakarietiška kalba, bet niekada nepraleiskite progos, kad blogis plinta visame pasaulyje.

 

Senais gerais laikais viskas buvo taip paprasta…

M3M3N70Grįžtant prie senų gerų laikų, mūsų verslas buvo toks lengvas... Nulinės dienos problemos buvo lengvai pasiekiamos, programėlės buvo plačiai prieinamos su lengvai išnaudojamomis pažeidžiamybėmis, o mes galėjome akimirksniu judėti į priekį.

Pelkių įniršis: Po velnių! Kai kurie dar kvaili, bet viskas pasikeitė. Didieji daug kritikavo tą programėlių saugumo šūdą.

M3M3N70Taip. Bet naujieji kvailiai yra kūrėjai. Mums buvo lengviau rinktis įrankius, kuriuos naudoja šie vaikinai. Ypač CI yra aukso kasykla! Debesijos prieigos žetonai, SCM prisijungimo duomenys, gamybinės duomenų bazės slaptažodžiai, SSH privatūs raktai, kitų CI vartotojų prisijungimo duomenys... Peršokti nuo nuobodžių kūrimo dalykų prie tikrosios esmės buvo gana paprasta.

Programinės įrangos kūrimo, testavimo ir diegimo automatizavimas su CI/CD Įrankiui dažnai reikia perduoti paslaptis komandoms etapais. Ir jos dažnai nuteka, o tai sukelia liūdnai pagarsėjusias pasekmes.

Pipelinereikia paslapčių, kurios kartais nuteka

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.

Galbūt seni geri laikai buvo rasti „Git“ istorijoje .env failas (kūrėjas pamiršo jį pridėti prie .gitignore):

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

kuris buvo naudojamas „GitHub“ darbo eigoje .github/deploy.yaml kuriame buvo kažkas panašaus į tai:

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: vau! Tie AWS klavišai veikė! Pirmiausia išbandėme nedidelį pakeitimą programėlėje, o tada pridėjome „sting“, nes tie vaikinai, regis, nieko nežinojo. Bingo! Kokia kampanija...

Piktavalis veikėjas tiesiog panaudojo AWS raktus, kad įkeltų modifikuotą programą su kenkėjiška programa, ir tada paleido komandą „deploy“ su tokiais prisijungimo duomenimis. Nutekėjusios paslaptys kartu su informacija, esančia... pipeline„Kokia kampanija!“ tikriausiai reiškia, kad „Memento“ sukėlė chaosą vargšei aukai.

„Memento“ čia mums sako, kad įvykus slaptam informacijos nutekėjimui, pavyzdžiui, AWS prieigos raktams pavyzdyje, turite atšaukti slaptą informaciją (pakeisti aukščiau pateiktus raktus). nedelsiantVisada yra ekspozicijos langas tarp nesandaraus commit ir slaptas anuliavimas; Git istorijos perrašymas yra sunkus (net ir griežčiausia autoritarinė valstybė bandė perrašyti istoriją, bet nesėkmingai) ir tikriausiai neefektyviai (mūsų draugai galėjo klonuotis dar prieš saugyklą su slaptu nutekėjimu commit). Nedelsdami keiskite raktus ir melskitės skaitydami tikslinės paskyros veiklos žurnalus per poveikio laikotarpį!

Tikriausiai organizacijos turėtų uždrausti naudoti ilgalaikes paslaptis CI/CD pipelinesir pakeiskite juos laikinaisiais prisijungimo duomenimis. Ankstesniame pavyzdyje su AWS raktais „GitHub“ veiksmuose saugiau naudoti „OpenID Connect“ (OIDC) teikėjas gauti trumpalaikius įgaliojimus, reikalingus veiksmams atlikti.

Pelkių įniršisTau taip pasisekė! Skriptų su užprogramuotais raktais nutekinimas senais laikais buvo įprasta praktika, net viešai prieinamuose S3 segmentuose. Viskas, ką tau reikėjo padaryti, tai peržiūrėti objektus segmente ir atlikti šiek tiek „gripping“, kad rastum įdomių dalykų.

Kartais diegimui naudojama sritis (šiame pavyzdyje – AWS S3 kibiras) buvo atvira pašaliniams asmenims nuskaityti dėl konfigūracijos klaidos (kuri nebuvo aptikta). Ką? Pelkių įniršis buvo naudotas kažkas panašaus į tai:

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

Šis segmentas tikriausiai buvo sukurtas aprūpinimo šablone, kurį galima automatiškai nuskaityti ieškant saugumo spragų.

Numatytoji įrankio konfigūracija mums buvo žaisliukas

Pateiksime konkrečių pavyzdžių, pakalbėkime apie Jenkins, viena populiariausių CI įrankių.

Pelkių įniršisAr prisimenate tą žymimąjį langelį „Įjungti saugumą“ „Jenkins“ programoje ir kiek organizacijų nusprendė jo neaktyvuoti dėl patogumo? Ir tie „Kiekvienas gali padaryti bet ką„leidimų deriniai pagal numatytuosius nustatymus?“ O tie erzinantys „Jenkins“ įskiepiai, tokie kaip „GitHub OAuth“ įskiepisVaikinas, kuris jį sukonfigūravo, pasirinko ir „Suteikti SKAITYMO teises visiems autentifikuotiems vartotojams“, ir „Naudoti „GitHub“ saugyklos teises“, suteikdamas mums prieigą prie visų jų projektų.

(Atsiprašau, Jenkinsai, kad pateikiu tave kaip pavyzdį 😉

Laikykitės (netgi priklausomo) saugumo principų. Vienas iš jų yra Saugus pagal numatytuosius nustatymus principas: valdikliai turėtų būti numatyti saugiausiuose įmanomuose nustatymuose. Saugumas turėtų būti integruotas CI/CD įrankiai ir pipelinenuo nulio, o ne kaip antraeilis dalykas. Tačiau patogumas ir patogumas dažnai prieštarauja saugumui.

„Jenkins“ atveju integruotas autentifikavimas yra pernelyg trapus: niekada nenaudokite integruotų autentifikavimo mechanizmų „Jenkins“ sistemojeGeriau rinkitės trečiosios šalies mechanizmą (SAML, LDAP, „Google“ ir kt.) su vaidmenimis pagrįstos autorizacijos strategijos („RBAC“) papildiniu. Ir būkite itin atsargūs su... admin sąskaitą.

Pasirūpinkite, kaip darbas ir pipeline tvarkomi failai „Jenkins“ sistemoje. Tas pats ir su Konfigūracijos kaip kodo įskiepis ir jo konfigūracijos failus, kurie taikomi „Jenkins“ konfigūracijai.

Persikėlimas iš savarankiško apgyvendinimo CI/CD sistemų perkėlimas į debesijos pagrindu veikiančias SaaS sistemas pašalina kai kurias galimas rizikas, leidžiančias judėti horizontaliai organizacijos tinkle, tačiau prideda ir kitų, pavyzdžiui, būtinybę atidaryti išorinius ryšius tarp esamų vidinių sistemų ir išorinių sistemų. CI/CD įrankis.

Organizacijos turėtų stengtiscisgrūdinant reikia deramo dėmesio CI/CD sistemą, pradedant nuo griežčiausių nustatymų ir palaipsniui atidarant iki minimalių reikalingų leidimų pipeline žingsniai.

Saugos konfigūravimas CI/CD įrankiai gali būti sudėtingi. Daugelis jų turi papildinius ar plėtinius, kurie turi daugumą pažeidžiamumų ir kuriuos reikia atnaujinti.

Tokiems sudėtingiems įrankiams skirti saugumo klaidingos konfigūracijos skaitytuvai arba etalonai gali padėti.

Įterpiamas kodas pipeline komandos pramogai ir pelnui

M3M3N70Ar kada nors naudojote nepatikimus kodo patikrinimus, kurie pažeidžiami veiksmai ir scenarijai, pažeidžiami komandų injekcijos?

Šiame skyriuje parodyta, kad pipeline pats gali turėti kodavimo klaidų, kurios leidžia kenkėjiškiems veikėjams įterpti savavališką kodo vykdymą pipeline nekeičiant pipeline pats šaltinisPavyzdžiui, naudojant PR

Pirmasis pavyzdys nesėkminga „GitHub“ darbo eiga:

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

Derinant pull_request_target Darbo eigos paleidiklis su aiškiu nepatikimo PR patikrinimu yra pavojinga praktika, galinti pakenkti saugyklai. Pavyzdyje nesėkmingas šių veiksnių derinys:

• pull_request_target įvykis, kuris pagal numatytuosius nustatymus turi rašymo leidimą į tikslinę saugyklą ir tikslinės saugyklos paslaptis, net ir iš išorinių šakų, ir vykdomas PR tikslinės saugyklos kontekste,
• patikrinkite PR kodą iš šaltinio, nepatikimo saugyklos,
• suaktyvinti bet kokį scenarijų, kuris gali veikti su PR kontroliuojamu turiniu, pavyzdžiui, npm installir
• nenaudojant sąlygos suveikimui pull_request_target įvykis vykdomas tik tuo atveju, jei PR priskirta tam tikra žyma „šis PR buvo patikrintas“ (išoriniai vartotojai negali priskirti PR žymų).

Antrame pavyzdyje pateikiama nepatikima informacija (iš problemos, komentaro ar pull request) kaip argumentų, perduodamų a, šaltinis pipeline komanda per išraiškas. Tai yra pipeline OS komandų injekcijos pažeidžiamumo versija.

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

Vykdymo operacija sukuria laikiną apvalkalo scenarijų, pagrįstą šablonu, su $ pakeistas, todėl jis tampa pažeidžiamas apvalkalo komandų injekcijos. Užpuolikas, turintis netikrą „GitHub“ paskyrą, gali sukelti problemą su pavadinimu a"; bad_code_goes_here;#, ir bum! 

Pelkių įniršisO, tie vaikinai atvėrė duris komandų įvedimui tiesiog atidarydami problemą...

„GitHub“ veiksmuose buvo kodo vykdymo pažeidžiamumų, tokių kaip gajira-comment, dabar pataisyta. Prašome perskaityti „Nepatikima įvestis „GitHub“ darbo eigose“ Visą informaciją.

Istorijos moralas: Niekada neperžiūrėkite ir nekurkite PR iš nepatikimų šaltinių, pirmiausia jų neperžiūrėję. „Nepatikima“ čia gali reikšti bet kokią potencialiai užgrobtą kūrėjo paskyrą, nebent būtų taikomas griežtas kilmės patvirtinimas.

 

Netyčinis kenkėjiškų programų diegimas čia!

Nuolatinis diegimas yra automatizavimo kulminacija, tačiau šią kulminaciją gali sužlugdyti tinkamų patvirtinimo kontrolės priemonių trūkumas. pipeline srautas.

Visiškai automatizuoto diegimo iš šaltinio rizika commit gamybinėms sistemoms apima galimybę, kad kenkėjiškas kodas bus dislokuotas gamybinėje aplinkoje jo neaptikdamas, taip pat gali būti, kad diegimo proceso klaidos gali sukelti sutrikimų ar nutrūkimų.

Siekiant sušvelninti šią riziką, organizacijoms dažnai rekomenduojama diegimo procese įdiegti „griežtąjį nutraukimą“, kuris reikalauja žmogaus pritarimas prieš diegiant leidimus galutinėse aplinkose.

Jie uždaro duris

Pelkių įniršisTie džiaugsmingi numatytieji slaptažodžiai CI/CD įrankiai nuvalomi. Prieiga prie /var/lib/jenkins/secrets/initialAdminPassword dabar nebenaudojamas kelias. Daugybė įrankių dabar teikia dviejų faktorių autentifikavimą (2FA), kurį išpopuliarino Covid, ir net tingiausias programuotojas jį naudoja!

M3M3N70Kovojame su 2FA, bet tai nėra taip lengva. Sunku apgauti tuos vaikinus, nes... „Scatter Swine“ su „Twilio“Su „WebAuthn“ raktais tai daug sudėtingiau. Bent jau galime pabandyti. vogti slapukus, kad apeitų MFA, bet reikia įsilaužti į kūrėjo nišą.

Daugiafaktorinis autentifikavimas yra geras žingsnis teisinga linkme siekiant apriboti autentifikavimo paslapčių nutekėjimo riziką. Dauguma šiuolaikinių „DevOps“ įrankių palaiko daugiafaktorinį autentifikavimą (MFA). Ir autentifikavimo raktai, esantys „WebAuthn“ / „U2F“ sistemoje (žr. FIDO2 projektas) yra bene geriausias daugiafaktorinio autentifikavimo (MFA) pasirinkimas DevOps aplinkoje, jei tinkamai valdomi.

Pelkių įniršis„DevOps“ vaikinai pradeda atsibusti. Jiems kraujyje įaugęs tas prakeiktas „mažiausių privilegijų“ dalykas. Ir jie nebėra programuotojai. Dabar mus pagauja apžvalgininkai.

Iš tiesų, pipelinedabar yra šiek tiek tvirtesni nei prieš porą metų, pašalinti silpni veiksmai ir scenarijai, o papildomi saugumo testavimo veiksmai netgi aptiko mūsų slaptus lašintuvus. commitir paketus, kuriuos pagrobėme.

Klausimas skaitytojui: ar programinės įrangos kūrimo iš šaltinių ir diegimo gamyboje procesas yra rizikingas? Ar matote savo „DevOps“ etape? seni geri laikai dėl blogiukų?

Galutinės rekomendacijos

Nuo ko pradėti CI/CD pipelines?

Pirmoji rekomendacija čia paprasta: atsargiai apžvalga pipelines (jie yra kritinis ištekliai) dėl saugumo problemų. Peržiūros yra brangios, bet būtinos ir turėtų būti atliekamos tinkamai. Peržiūros atlikėjai turėtų žinoti, į ką atkreipti dėmesį. Kiekvienas žingsnis turi būti patikrintas dėl trūkumų.

Galbūt padėtų ekspertų, turinčių automatinius kenkėjiško kodo skaitytuvus, derinys.

Antroji rekomendacija yra ta, kad apmokyti kūrėjus, kurie rašo pipelineir saugokite juosĮ ką reikėtų atsižvelgti:

• Kaip tinkamai tvarkyti autentifikavimą naudojant vidines ir debesijos paslaugas, išvengiant ilgalaikių prisijungimo duomenų tvarkymo nepatogumų.
• Kaip apriboti pipelines tiksliam išteklių rinkiniui, prie kurio jai reikia prieigos. Mažiausių privilegijų principas vėl sužiba.
• Kaip parašyti veiksmus, kuriuos reikia atlikti pipelineatkuriama kaip versijų prisegimas ir išvengiama komandų įterpimo pažeidžiamumų.
• Kaip patvirtinti diegimus saugumo požiūriu (jie yra kiti!): kuris saugumas standardturėtų atitikti ir kaip pridėti atitinkamus patikrinimus / vartus pipelines.

Trečia rekomendacija yra ta, kad sukonfigūruoti CI/CD sistema su derama priežiūraGriežtas autentifikavimas, jokių numatytųjų slaptažodžių ar nesaugių nustatymų, minimalios privilegijos… Atkreipkite dėmesį į įdiegtų papildinių ir plėtinių pažeidžiamumus. Tai gali būti aptarta kituose įrašuose, tad sekite naujienas.

Ketvirta rekomendacija yra ta, kad panaudoti CI/CD pipelines saugumo automatizavimuiŠaltinio kodo analizė (SAST), šaltinio sudėties analizė (SCA), paslapčių nutekėjimo nuskaitymas, kenkėjiškų programų prevencijos įrankiai, konteinerių saugumo skaitytuvai arba automatiniai vykdymo laiko detektoriai (DAST ir kenkėjiškos programos) gali būti reguliariai vykdomi pipelineIr jūsų organizacija gali vykdyti standardapie saugumo skenavimo aprėptį CI/CD.

Atminkite, kad šios priemonės vis dėlto neatmeta ekspertų peržiūros, kitaip galite susidaryti klaidingą saugumo jausmą.

Jei mokate naudotis OWASP dešimtukais, puikus neseniai atliktas projektas yra 10 geriausių „OWASP“ CI/CD Saugumo rizika.

Atsisakymo pastaba

(1) Šiame įraše pateikti pavyzdžiai naudoja „GitHub“ kaip SCM, AWS kaip debesijos teikėjas ir „GitHub Actions“ arba „Jenkins“ kaip CI/CD įrankis. Jie nėra silpnesni / saugesni už savo alternatyvas. Be jokių blogų spaudos ketinimų! Šie įrankiai yra galingi ir juos reikia naudoti tinkamai.

(2) M3M3N70 bei Pelkių įniršis yra išgalvoti personažai. Bet koks panašumas į asmenis ar grupes, gyvus ar mirusius, tėra atsitiktinis... ar ne?

Norėdami paskaityti daugiau

• Haymore, A. ir kt. „10 realių istorijų apie tai, kaip mes leidome į kompromisus“ CI/CD pipelines “NCC grupė, 2022 m. sausio mėn.
• configure-aws-credentials „GitHub“ veiksmas bei „OpenID Connect“ konfigūravimas „Amazon Web Services“ Išsamesnės informacijos apie tai, kaip vykdyti AWS komandas diegimui „GitHub“ darbo eigose, rasite čia.
• Lobačevskis J. „GitHub veiksmų ir darbo eigų apsauga. 1 dalis: pwn užklausų prevencija“„GitLab“ saugumo laboratorija, 2020 m. gruodis.
• Lobačevskis J. „GitHub veiksmų ir darbo eigų apsauga. 2 dalis: Nepatikima įvestis“„GitLab“ saugumo laboratorija, 2021 m. sausio mėn.
• OWASP. „OWASP 10 geriausiųjų“ CI/CD Saugumo rizikos2022 m. liepa.
• Saltzer J. ir Schroeder M. „Informacijos apsauga kompiuterinėse sistemose“1975 m. balandis. Saugumo principai vystėsi kartu su technologijomis, tačiau po 47 metų dauguma saugumo ir saugos idėjų tebegalioja.
• JK NCSC. „Užtikrinkite kūrimą ir diegimą“ pipeline"JK nacionalinis kibernetinio saugumo centras, 2019 m. vasaris.