Zerk huts egin dezake CI/CD pipelines?

Integrazio jarraitua eta entrega jarraitua (CI/CD) pipelines dira softwarea modu "modernoan" eraikitzen duen edozein software erakunderen oinarria. Automatizazioak botere handia ematen du, baina garatzaile gehienek ez dute ulertzen dakarren erantzukizuna.

GaratzailearenBai, hartzen dugu CI/CD segurtasun seriotasunez eta kodearen mantentzaileen gaineko kontrol sendoa izan, berrikusi commitbatu baino lehen; lanak eta pipelinegoi-mailako langileek mantentzen dituzte, sekretuak ez filtratzeaz arduratzen dira pipelines. Eta tresna gauza horretan dakiten langileek instalatu zuten. Zer gerta daiteke gaizki?

Garatzaile maitea, CI/CD sistemak konplexuak dira. Erasotzeko azalera zabalak aktore gaiztoak erakarri zituen. Hobe da zuhurra izatea eta ez gehiegi fidatzea.

Batzuetan konfigurazio lehenetsia mantentzen da eta hackerrentzako lagunik onena bihurtzen da. Akats kritikoak egon daitezke CI/CD pipeline iturriak, sistemaren konfigurazioan edo prozesuaren eta testuinguruaren inguruan pipeline eta nola pizten den.

Mezu honetan aktore gaiztoen lekuan jarriko gara. Imajinatu hauen gogoetak irakurtzen ari garela... M3M3N70 (Memento Mori?) eta Zingira-amorrua nonbait sare ilunaren barruan, ziurrenik mendebaldekoa ez den hizkuntza batean, baina ez ahaztu inoiz gaiztakeria mundu osoan hedatuta dagoela.

Garai onetan hain erraza zen…

M3M3N70Garai zaharretara itzuliz, gure negozioa oso erraza zen... Zero-day-ak oso errazak ziren, aplikazioak zabalik zeuden, erraz ustiatzeko ahultasunekin, eta alboetara azkar mugi gintezkeen.

Zingira-amorrua: Kaka! Buru ergela bada ere, gauzak aldatu egin dira. Handiek ausardia handia jarri dute AppSec-eko txorakeria horretan.

M3M3N70Bai. Baina ergel berriak garatzaileak dira. Guretzat, errazagoa izan da hauek erabiltzen dituzten tresnak aukeratzea. CI, bereziki, urre meategi bat da! Hodeiko sarbide tokenak, SCM kredentzialak, ekoizpen-datu-basearen pasahitzak, SSH gako pribatuak, beste CI erabiltzaileen kredentzialak… Garapen-gauza aspergarrietatik benetako mamira jauzi egitea nahiko erraza izan zen.

Softwarea eraikitzeko, probatzeko eta zabaltzeko automatizazioa CI/CD tresnak askotan sekretuak komandoei urratsez urrats eman behar dizkie. Eta askotan filtratu egiten dira, ondorio tristeekin.

Pipelinebatzuetan filtratzen diren sekretuak behar dituzte

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.

Agian garai zahar onak Git historian aurkitzea zen .env fitxategia (garatzaileak ahaztu egin du gehitzea .gitignore):

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

GitHub-eko lan-fluxu batean erabili zena .github/deploy.yaml honelako zerbait zeukan:

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: harrigarria! AWS gako horiek funtzionatzen ari ziren! Lehenik aplikazioan aldaketa kaltegabe bat probatu genuen, eta gero, tipo horiek konturatu gabe ziruditenez, mina gehitu genuen. Bingo! Zer kanpaina...

Gaizkileak AWS gakoak erabili zituen malwarea zuen aplikazio aldatu bat kargatzeko eta gero deploy komandoa exekutatu zuen kredentzial horiekin. Filtratutako sekretuak, baita bertan zegoen informazioarekin ere... pipeline«Zer kanpaina!» esan nahi du ziurrenik Mementok biktima pobreari kalte handia egin ziola.

Mementok hemen esaten diguna da sekretu-ihes bat gertatu ondoren, adibidean AWS sarbide-giltzak bezala, sekretua ezeztatu egin behar duzula (goiko giltzak biratu). berehalaBeti dago bat esposizio leihoa ihesaren artean. commit eta baliogabetze sekretua; Git historia berridaztea zaila da (estatu autoritario gogorrenak ere historia berridaztea saiatu zen, alferrik) eta ziurrenik eraginkorra ez dena (gure lagunek biltegiaren aurretik klonatu ahal izan zuten ihes sekretuarekin) commit). Biratu giltzak berehala, eta otoitz egin esposizio-leihoan zehar xede-kontuaren jarduera-erregistroak irakurtzen dituzun bitartean!

Seguruenik, erakundeek beharko lukete epe luzeko sekretuak erabiltzea debekatu CI/CD pipelines, eta ordezkatu itzazu denborazko kredentzialekin. Aurreko adibidean, GitHub-eko ekintzetan AWS gakoekin, seguruagoa da erabiltzea OpenID Connect (OIDC) hornitzailea ekintzetarako beharrezkoak diren iraupen laburreko kredentzialak lortzeko.

Zingira-amorruaZorte handia izan duzu! Garai batean, ohikoa zen giltza gogor kodetuak zituzten script-ak filtratzea, baita publikoki eskuragarri zeuden S3 ontzietan ere. Egin behar zenuen guztia ontziko objektuak arakatzea eta grepping batzuk egitea zen gauza interesgarriak aurkitzeko.

Batzuetan, hedapenerako erabilitako eremua (adibide honetan AWS S3 ontzi bat) kanpokoek irakurtzeko irekita egoten zen, konfigurazio akats batengatik (detektatu gabe geratu zena). Zer Zingira-amorrua erabilitakoa honelako zerbait izan zen:

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

Ontzia ziurrenik segurtasun-akatsak automatikoki eskaneatu ahal izango zen hornidura-txantiloi batean sortu zen.

Tresnaren konfigurazio lehenetsia jostailu bat zen guretzat

Adibide zehatzak emateko, hitz egin dezagun Jenkins, CI tresna ezagunenetako bat.

Zingira-amorruaGogoratzen al duzu Jenkins-eko "Segurtasuna gaitu" kontrol-laukia, eta zenbat erakundek aukeratu zuten ez aktibatzea erosotasunagatik? Eta horiek "Edonork egin dezake edozer"baimen konbinazioak lehenespenez? Eta Jenkins plugin gogaikarri horiek, adibidez GitHub OAuth pluginaKonfiguratu zuen tipoak “Eman irakurtzeko baimenak autentifikatutako erabiltzaile guztiei” eta “Erabili GitHub biltegiko baimenak” hautatu zituen, eta horrek haien proiektu guztietarako sarbidea eman zigun.

(Barkatu, Jenkins, adibide gisa jartzeagatik 😉)

Segurtasun printzipioei eutsi (baita mendekotasuna ere izan). Bat da Segurua lehenespenez printzipioa: kontrolak ahalik eta ezarpen seguruenetara lehenetsi behar dira. Segurtasuna txertatu behar da CI/CD tresnak eta pipelinehutsetik sortzen da, bigarren mailako kontua izan beharrean. Baina erabilerraztasunak eta erosotasunak askotan talka egiten dute segurtasunarekin.

Jenkins kasurako, barneratutako autentifikazioa hauskorregia da: Ez erabili inoiz Jenkins-en barneratutako autentifikazio mekanismoakHobe da hirugarrenen mekanismo bat aukeratzea (SAML, LDAP, Google...), Roletan Oinarritutako Baimen Estrategia (“RBAC”) pluginarekin. Eta kontuz ibili oso ondo honekin... admin kontua.

Kontuz ibili lana nola egiten den eta pipeline Jenkins-eko fitxategiak kudeatzen dira. Gauza bera gertatzen da honekin Konfigurazio-kode gisa plugina eta bere konfigurazio fitxategiak, Jenkins konfigurazioari aplikatzen zaizkionak.

Auto-ostatutakotik aldatzea CI/CD SaaS sistemak hodeian oinarritutakoetara aldatzeak erakundearen sarean mugimendu laterala ahalbidetzen duten arrisku potentzial batzuk ezabatzen ditu, baina beste batzuk gehitu ditu, hala nola, barneko sistemen eta kanpoko sistemen artean kanpoko konexioak ireki behar izatea. CI/CD tresna.

Erakundeek ahalegindu beharko luketecisgogortzean behar bezalako arreta CI/CD sistema, ezarpen murriztaileenekin hasita eta pixkanaka beharrezko baimen minimoekin irekiz pipeline urratsak.

Segurtasuna konfiguratzen hemen: CI/CD Tresnak konplexuak izan daitezke. Askok ahultasun gehienak dituzten pluginak edo luzapenak dituzte eta eguneratu behar dira.

Tresna konplexu horietarako segurtasun-konfigurazio okerreko eskanerrek edo benchmarkek lagun dezakete.

Kodea txertatzen pipeline aginduak dibertsio eta irabazietarako

M3M3N70Erabili al dituzu inoiz Untrusted Code Checkouts, ekintza eta script ahulak komando-injekzioaren aurrean zaurgarriak direnak?

Atal honek erakusten du pipeline berak kodeketa akatsak izan ditzake, eta horrek gaizkileek kode arbitrarioa exekutatzea ahalbidetzen die pipeline aldatu gabe. pipeline iturria beraAdibidez, PR bat erabiliz

Lehenengo adibide bat GitHub-en lan-fluxu tamalgarria:

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

batzea pull_request_target PR fidagarri ez baten egiaztapen esplizituarekin lan-fluxuaren abiarazlea praktika arriskutsua da, biltegia arriskuan jar dezakeena. Adibidean, honako konbinazio tamalgarria:

• pull_request_target gertaera, zeinak lehenespenez helburuko biltegian eta helburuko biltegiko sekretuetan idazteko baimena duen, kanpoko adarretatik ere, eta PR-aren helburuko biltegiaren testuinguruan exekutatzen den,
• egiaztatu PR kodea iturburutik, fidagarria ez den biltegitik,
• PR kontrolatutako edukietan funtziona dezakeen edozein script abiarazi, adibidez npm install, eta
• baldintza bat ez erabiltzea abiarazle gisa pull_request_target Gertaera exekutatzeko PRri 'PR hau egiaztatuta dago' etiketa motaren bat esleituta badago bakarrik (kanpoko erabiltzaileek ezin diote etiketarik esleitu PRri).

Bigarren adibide batek fidagaitzak ez diren sarrerak hartzen ditu (arazo, iruzkin edo pull request) bati pasatako argumentuen iturri gisa pipeline adierazpenen bidezko komandoa. Hau da pipeline OS komandoen injekzioaren ahultasunaren bertsioa.

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

Exekuzio eragiketak txantiloian oinarritutako shell script bat sortzen du aldi baterako, honekin: $ ordezkatuta, shell komandoen injekzioaren aurrean zaurgarri bihurtuz. GitHub kontu faltsu bat duen erasotzaile batek arazo bat sor dezake izenburu batekin a"; bad_code_goes_here;#, eta bum! 

Zingira-amorruaAi, tipo horiek komando-injekziorako atea irekitzen ari ziren arazo bat irekiz besterik gabe...

GitHub-eko ekintzetan kodearen exekuzio ahultasunak zeuden, adibidez gajira-iruzkina, orain konponduta. Irakurri mesedez "Sarrera ez-fidagarria GitHub-eko lan-fluxuetan" xehetasunak osoa.

Istorioaren morala: Inoiz ez egiaztatu eta ez sortu PRak iturri fidagarri ez direnetatik, lehenik PRa berrikusi gabe. «Fidagarria ez dena» hemen, jatorriaren autentifikazio drakonianoaren pean ez badago behintzat, bahitutako edozein garatzaile-kontu izan liteke.

Malwarearen hedapen ustekabekoa hemen!

Hedapen jarraitua automatizazioaren gailurra da, baina gailur hori zapuztu egin daiteke onarpen-kontrol egokirik ez egoteagatik pipeline fluxua.

Jatorritik guztiz automatizatutako hedapenaren arriskuak commit ekoizpen-sistemetan izandako eraginen artean, kode gaiztoa detektatu gabe ekoizpen-inguruneetan zabaltzeko aukera dago, baita hedapen-prozesuan izandako erroreek etenaldiak edo etenaldiak eragiteko aukera ere.

Arrisku horiek arintzeko, askotan gomendatzen da erakundeek "etenaldi gogorra" ezartzea beren hedapen-prozesuan, eta horrek eskatzen du giza onespena bertsioak azken inguruneetan zabaldu aurretik.

Ateak ixten ari dira.

Zingira-amorruaPasahitz lehenetsi alai horiek CI/CD tresnak ezabatzen ari dira. Sarbidea /var/lib/jenkins/secrets/initialAdminPassword bide hila da orain. Tresna askok 2FA eskaintzen dute orain, Covid-ek ezagun egin zuena, eta kode-tximino alferrenak ere erabiltzen ari da!

M3M3N702FAren aurka borrokan ari gara, baina ez da hain erraza. Zaila da tipo horiei spear-phishing egitea, "Scatter Swine"-ek Twiliorekin egin zuenWebAuthn gakoekin askoz zailagoa da. Gutxienez, saiatu gaitezke cookieak lapurtu MFA saihesteko, baina garatzaileen kutxan sartu behar da.

Faktore Anitzeko Autentifikazioa urrats ona da autentifikazio sekretuen filtrazioen arriskua mugatzeko norabide egokian. DevOps tresna moderno gehienek MFA onartzen dute. Eta WebAuthn / U2F pean dauden autentifikazio gakoak (ikus FIDO2 proiektua) dira, beharbada, DevOps-en MFArako aukerarik onena, behar bezala kudeatzen badira.

Zingira-amorruaDevOps-eko mutilak esnatzen ari dira. "Pribilegio gutxieneko" kontu madarikatua odolean dute. Eta ez dira kode-tximinoak gehiago. Orain berrikusleek eskuak harrapatzen gaituzte delituan.

Hain zuzen ere, pipelines duela urte batzuk baino sendoagoak dira orain, ekintza eta script ahulak kenduta, eta gure dropper-ak ere ezkutuan detektatu dituzten segurtasun probak egiteko urrats gehigarriekin. commitbahitu genituen paketeak eta akabera.

Irakurlearentzako galdera: softwarea iturburuetatik eraiki eta ekoizpenean zabaltzeko prozesua negozio arriskutsua al da? Ikus al dezakezu zure DevOps fasean? garai onak. gaiztoentzat?

Azken gomendioak

Nondik hasi CI/CD pipelines?

Lehenengo gomendioa sinplea da hemen: Kontuz berrikusi pipelines (dira kritikoa baliabideak) segurtasun arazoetarako. Berrikuspenak garestiak dira baina beharrezkoak, eta behar bezala egin behar dira. Berrikusleek jakin behar dute zer begiratu behar duten. Urrats bakoitza akatsak dauden egiaztatu behar da.

Agian, kode gaiztoen eskaner automatizatuekin armatutako berrikusle adituen konbinazio batek lagun dezake.

Bigarren gomendioa da idazten duten garatzaileak trebatu pipelineeta segurtasunean mantendu itzazuKontuan hartu beharreko gauzak:

• Nola kudeatu behar bezala autentifikazioa barneko eta hodeiko zerbitzuekin, epe luzeko kredentzialak maneiatzearen eragozpenak saihestuz.
• Nola mugatu pipelinesarbidea behar duen baliabide multzo zehatzera. Pribilegio gutxienaren printzipioa berriro agertzen da.
• Nola idatzi urratsak egiteko pipelinebertsio pinning-a bezala erreproduzigarria da, eta komando injekzioen ahultasunak saihestu egiten ditu.
• Nola onartu inplementazioak segurtasunaren ikuspegitik (beste batzuk dira!): zein segurtasun standards-ak bat etorri behar dira eta nola gehitu dagokion egiaztapena/atea pipelines.

Hirugarren gomendio bat da konfiguratu CI/CD sistema behar bezala zaindutaAutentifikazio sendoa, pasahitzik lehenetsirik edo ezarpen ez-segururik gabe, pribilegio gutxienekoekin... Kontuz instalatutako plugin eta luzapenen ahultasunekin. Hurrengo argitalpenen ardatza izan liteke hau, adi egon mesedez.

Laugarren gomendioa da aprobetxatu CI/CD pipelinesegurtasun automatizaziorako s. Iturburu-kodearen analisia (SAST), iturriaren konposizioaren analisia (SCA), sekretuen ihesen eskaneatzea, malwarearen aurkako tresnak, edukiontzien segurtasun eskanerrak edo exekuzio-denbora automatikoko detektagailuak (DAST eta malwarea) errutinaz exekutatu daitezke pipelineEta zure erakundeak betearazi dezake standardsegurtasun eskaneatzearen estaldurari buruz CI/CD.

Gogoratu, tresna hauek ez dutela adituen berrikuspena ekuaziotik kentzen, bestela segurtasun sentsazio faltsua izan dezakezu.

OWASP hamarrekoen artean trebea bazara, azken proiektu polit bat da OWASP Top 10 CI/CD Segurtasun Arriskua.

Ezespen-oharra

(1) Mezu honetako adibideek GitHub erabiltzen dute SCM, AWS hodeiko hornitzaile gisa, eta GitHub Actions edo Jenkins gisa CI/CD tresna. Ez dira haien alternatibak baino ahulagoak/seguruagoak. Ez dago prentsa-asmo txarrik! Tresna hauek indartsuak dira eta behar bezala erabili behar dira.

(2) M3M3N70   Zingira-amorrua pertsonaia fikziozkoak dira. Pertsona edo taldeekiko, bizirik edo hilda, edozein antzekotasun kasualitatea da... ala ez?

Gehiago irakurtzeko

• Haymore, A. eta beste batzuk. "10 benetako istorio nola konprometitu garen erakusten dutenak" CI/CD pipelines ”NCC Taldea, 2022ko urtarrila.
• configure-aws-credentials GitHub-eko ekintza   OpenID Connect konfiguratzea Amazon Web Services-en GitHub-eko lan-fluxuetan AWS komandoak nola exekutatu jakiteko xehetasunak lortzeko.
• Lobacevski J. "Zure GitHub ekintzak eta lan-fluxuak seguru mantentzea 1. zatia: pwn eskaerak saihestea"GitLab Segurtasun Laborategia, 2020ko abendua.
• Lobacevski J. "Zure GitHub ekintzak eta lan-fluxuak seguru mantentzea 2. zatia: Sarrera ez fidagarria"GitLab Segurtasun Laborategia, 2021eko urtarrila.
• OWASP. OWASP-eko 10 onenak CI/CD Segurtasun Arriskuak”2022ko uztaila.
• Saltzer J. eta Schroeder M. "Informazioaren Babesa Sistem Informatikoetan"1975eko apirila. Segurtasun printzipioak teknologiarekin batera eboluzionatu ziren, baina 47 urte geroago, Segurtasun eta Segurtasun ideia gehienak indarrean jarraitzen dute.
• Erresuma Batuko NCSC. "Ziurtatu eraikuntza eta hedapena" pipeline"Erresuma Batuko Zibersegurtasun Zentro Nazionala, 2019ko otsaila.