Hva kan gå galt med CI/CD pipelines?

Kontinuerlig integrasjon og kontinuerlig levering (CI/CD) pipelineer grunnlaget for enhver programvareorganisasjon som bygger programvare på en «moderne» måte. Automatisering gir stor kraft, men de fleste utviklere går glipp av ansvaret det medfører.

UtviklerJa, vi tar CI/CD sikkerhet seriøst og ha sterk kontroll over kodevedlikeholdere, gjennomgå commits før fusjoner; jobber og pipelines vedlikeholdes av seniorpersonell, de passer på at hemmeligheter ikke lekker ut i pipelines. Og verktøyet ble installert av personell som kan saken. Hva kan gå galt?

Kjære utvikler, CI/CD Systemer er komplekse. Den brede angrepsflaten tiltrakk seg ondsinnede aktører. Vær forsiktig og aldri overmodig.

Standardkonfigurasjonen beholdes noen ganger og blir hackernes beste venn. Kritiske feil kan forekomme i CI/CD pipeline kilder, i systemets konfigurasjon, eller rundt prosessen og konteksten til pipeline og hvordan den utløses.

I dette innlegget skal vi sette oss inn i de dårlige skuespillernes sko. Tenk deg at vi leser grublene til M3M3N70 (Memento Mori?) og Sumprase et sted på det mørke nettet, sannsynligvis på et ikke-vestlig språk, men gå aldri glipp av at ondskap spres over hele verden.

I gode gamle dager var det så lett…

M3M3N70Tilbake til de gode gamle tider var virksomheten vår sååå enkel ... Nulldager var lavthengende frukter, apper var vidåpne med sårbarheter som var lette å utnytte, og vi kunne bevege oss sidelengs på et blunk.

Sumprase: Fu#@Hell! Noen gale der ute ennå, men ting har forandret seg. De store gutta la mye vekt på det AppSec-drillen.

M3M3N70Jepp. Men de nye tullingene er utviklerne. For oss har det vært enklere å gå for verktøyene disse karene bruker. Spesielt CI er en gullgruve! Skytilgangstokener, SCM påloggingsinformasjon, passord for produksjonsdatabaser, private SSH-nøkler, andre CI-brukeres påloggingsinformasjon … Å hoppe fra de kjedelige utviklertingene til det virkelige kjernen var ganske trivielt.

Automatisering for bygging, testing og distribusjon av programvare med en CI/CD Verktøyet trenger ofte å overføre hemmeligheter til kommandoer i trinn. Og ofte lekkes de, med beryktede konsekvenser.

Pipelinetrenger hemmeligheter som noen ganger lekker ut

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.

Kanskje i de gode gamle dager fant man i Git-historien en .env filen (utvikleren glemte å legge den til .gitignore):

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

som ble brukt i en GitHub-arbeidsflyt .github/deploy.yaml som inneholdt noe sånt som dette:

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! De aws-tastene virket! Vi testet først en ufarlig endring i appen, og la deretter til «sting»-endringen siden de karene tilsynelatende ikke var klar over det. Bingo! For en kampanje…

Den ondsinnede aktøren brukte ganske enkelt AWS-nøklene til å laste opp en modifisert applikasjon med skadelig programvare, og kjørte deretter deploy-kommandoen med slike påloggingsinformasjoner. De lekkede hemmelighetene, sammen med informasjonen i pipeline«For en kampanje!» betyr sannsynligvis at Memento herjet med det stakkars offeret.

Det Memento forteller oss her er at når en hemmelig lekkasje har skjedd, som AWS-tilgangsnøkler i eksemplet, må du tilbakekalle hemmeligheten (rotere nøklene ovenfor). umiddelbartDet er alltid en eksponeringsvindu mellom lekkasjen commit og den hemmelige ugyldiggjørelsen; Det er vanskelig å omskrive Git-historikken (selv den tøffeste autoritære staten prøvde slik historieomskriving, uten hell) og sannsynligvis ineffektivt (vennene våre kan ha klonet før depotet med den hemmelige lekkasjen commit). Roter tastene umiddelbart, og be mens du leser aktivitetslogger for den målrettede kontoen i løpet av eksponeringsvinduet!

Sannsynligvis burde organisasjoner forby bruk av langsiktige hemmeligheter i CI/CD pipelines, og erstatte dem med tidsbestemte legitimasjonsopplysninger. I det forrige eksemplet med AWS-nøkler i GitHub-handlinger er det tryggere å bruke en OpenID Connect (OIDC)-leverandør for å få kortvarig legitimasjon som trengs for handlinger.

SumpraseSå heldig du var! Lekkasje av skript med hardkodede nøkler var vanlig praksis i gamle dager, selv på offentlig tilgjengelige S3-bøtter. Alt du trengte å gjøre var å bla gjennom objektene i bøtten og gjøre litt greping for å finne interessante ting.

Noen ganger var området som ble brukt til utrulling (en AWS S3-bøtte i dette eksemplet) åpent for lesing fra utenforstående, på grunn av en konfigurasjonsfeil (som ikke ble oppdaget). Hva Sumprase brukt var noe sånt som dette:

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

Bøtten ble sannsynligvis opprettet i en klargjøringsmal som kunne skannes automatisk for sikkerhetsfeil.

Verktøyets standardkonfigurasjon var et leketøy for oss

For å gi konkrete eksempler, la oss snakke om Jenkins, et av de mest populære CI-verktøyene.

SumpraseHusker du avmerkingsboksen «Aktiver sikkerhet» i Jenkins, og hvor mange organisasjoner som valgte å ikke aktivere den for enkelhets skyld? Og de «Hvem som helst kan gjøre hva som helst"tillatelseskombinasjoner som standard? Og de irriterende Jenkins-pluginene, som GitHub OAuth-pluginFyren som konfigurerte det valgte både «Gi lesetillatelser til alle autentiserte brukere» og «Bruk GitHub-repositorytillatelser», noe som ga oss tilgang til alle prosjektene deres.

(Beklager, Jenkins, for at jeg brukte deg som eksempel 😉)

Hold deg dyktig (til og med avhengig) av sikkerhetsprinsipper. En av dem er Sikker som standard Prinsipp: Kontrollene bør som standard ha de sikreste innstillingene som mulig. Sikkerhet bør innebygd i CI/CD verktøy og pipelines fra grunnen av, snarere enn å være en ettertanke. Men brukervennlighet og bekvemmelighet kolliderer ofte med sikkerhet.

For Jenkins-tilfellet er innebygd autentisering for skjør: bruk aldri de innebygde autentiseringsmekanismene i JenkinsDet er bedre å velge en tredjepartsmekanisme (SAML, LDAP, Google …), med en rollebasert autorisasjonsstrategi («RBAC»)-plugin. Og vær ekstremt forsiktig med admin konto.

Ta vare på hvordan jobb og pipeline filer i Jenkins håndteres. Det samme gjelder Konfigurasjon-som-kode-plugin og konfigurasjonsfilene, som gjelder for Jenkins-konfigurasjonen.

Flytter fra selvhosting CI/CD systemer til skybaserte SaaS-systemer eliminerer noen potensielle risikoer som tillater lateral bevegelse innenfor organisasjonsnettverket, men legger til andre, som å måtte åpne eksterne forbindelser mellom eksisterende interne systemer og de eksternaliserte CI/CD verktøyet.

Organisasjoner bør utøvecise forsiktighet ved herding av CI/CD systemet, startende med de mest restriktive innstillingene og gradvis åpnet opp med de minimale nødvendige tillatelsene for pipeline trinn.

Konfigurering av sikkerhet i CI/CD Verktøy kan være komplisert. Mange har programtillegg eller utvidelser som har de fleste sårbarhetene og må oppdateres.

Skannere for sikkerhetsfeilkonfigurasjon for slike komplekse verktøy, eller benchmarks, kan hjelpe.

Injiserer kode inn pipeline kommandoer for moro og profitt

M3M3N70Har du noen gang brukt utsjekkinger av upålitelige koder, der sårbare handlinger og skript er sårbare for kommandoinjeksjon?

Denne delen viser at pipeline i seg selv kunne ha kodefeil som gjør det mulig for skadelige aktører å injisere vilkårlig kodekjøring i pipeline uten å endre pipeline kilden selvFor eksempel ved å bruke en PR

Et første eksempel på en uheldig GitHub-arbeidsflyt:

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

Kombinere pull_request_target En arbeidsflytutløser med en eksplisitt utsjekking av en upålitelig PR er en farlig praksis som kan føre til kompromittering av repositoriet. I eksemplet er den uheldige kombinasjonen av:

• pull_request_target hendelse, som som standard har skrivetillatelse til målrepositoriet og målrepositoriets hemmeligheter, selv fra eksterne forks, og kjører i konteksten til målrepositoriet til PR,
• sjekk PR-koden fra kilden, upålitelig depot,
• utløse ethvert skript som kan operere på PR-kontrollert innhold, som i tilfellet med npm installog
• ikke bruker en betingelse for utløsningen pull_request_target hendelsen skal bare kjøres hvis en slags «denne PR-en ble godkjent»-etikett er tilordnet PR-en (eksterne brukere kan ikke tilordne etiketter til PR-en).

Et annet eksempel tar upålitelige innspill (fra et problem, en kommentar eller pull request) som kilde for argumenter sendt til en pipeline kommando via uttrykk. Dette er pipeline versjon av sårbarheten for kommandoinjeksjon i operativsystemet.

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

Kjøreoperasjonen genererer et midlertidig skallskript basert på malen, med $ erstattet, noe som gjør den sårbar for injeksjon av skallkommandoer. En angriper med en falsk GitHub-konto kan skape et problem med en tittel a"; bad_code_goes_here;#, og boom! 

SumpraseÅ, de karene åpnet døren for kommandoinjeksjon ved å rett og slett åpne en sak ...

Det var sårbarheter for kodekjøring i GitHub-handlinger, som for eksempel gajira-kommentar, nå fikset. Vennligst les «Upålitelig inndata i GitHub-arbeidsflyter» for alle detaljer.

Moralen i historien: Aldri sjekk ut og bygg PR-er fra upålitelige kilder uten først å gjennomgå PR-en. «Ikke klarert» her, med mindre det er streng autentisering av opprinnelse, kan bety enhver potensielt kapret utviklerkonto.

Utilsiktet utrulling av skadelig programvare her!

Kontinuerlig utplassering er automatiseringens klimaks, men det klimaks kan bli forpurret av mangelen på passende godkjenningskontroller på pipeline strømme.

Risikoene ved helautomatisert distribusjon fra kildekode commit til produksjonssystemer inkluderer potensialet for at skadelig kode kan distribueres i produksjonsmiljøer uten å bli oppdaget, samt potensialet for at feil i distribusjonsprosessen kan forårsake forstyrrelser eller driftsavbrudd.

For å redusere disse risikoene anbefales det ofte at organisasjoner implementerer en «hard pause» i utrullingsprosessen, som krever menneskelig godkjenning før utgivelser distribueres til sluttmiljøer.

De lukker dørene

SumpraseDe gledelige standardpassordene i CI/CD verktøy blir tørket av. Tilgang til /var/lib/jenkins/secrets/initialAdminPassword er nå et dødt spor. Mange verktøy tilbyr nå 2FA, som Covid gjorde populært, og selv den lateste kodeapen der ute bruker det!

M3M3N70Vi kjemper mot 2FA, men det er ikke så lett. Det er vanskelig å bruke spearphishing på disse karene, ettersom «Scatter Swine» gjorde det med TwilioMed WebAuthn-nøkler er det mye vanskeligere. I det minste kan vi prøve å stjele informasjonskapsler for å omgå MFA, men trenger å bryte seg inn i utviklerens boks.

Flerfaktorautentisering er et godt skritt i riktig retning for å begrense risikoen for lekkasje av autentiseringshemmeligheter. De fleste moderne DevOps-verktøy støtter MFA. Og autentiseringsnøkler under WebAuthn / U2F (se FIDO2-prosjektet) er kanskje det beste alternativet for MFA i DevOps, hvis de administreres riktig.

SumpraseDevOps-folkene våkner. De har den forbannede «minst privilegier»-greia i blodet. Og de er ikke kodeaper lenger. Nå blir vi tatt på fersken av anmeldere.

Faktisk, pipelineer nå litt mer robuste enn for et par år siden, med svake handlinger og skript fjernet, og med ekstra sikkerhetstesttrinn som til og med oppdaget dropperne våre skjult i snikende omgivelser. commitog pakker vi kapret.

Spørsmål til leseren: er prosessen med å bygge programvaren fra kildekode og distribuere den til produksjon en risikabel virksomhet? Kan du se for deg DevOps-fasen din i ... gamle gode tider for de onde?

Endelige anbefalinger

Hvor skal man begynne med CI/CD pipelines?

Den første anbefalingen er enkel her: Vær forsiktig anmeldelse pipelines (de er kritisk ressurser) for sikkerhetsproblemer. Gjennomganger er kostbare, men nødvendige, og bør gjøres riktig. Anmeldere bør være klar over hva de skal se på. Hvert trinn må kontrolleres for feil.

Kanskje en kombinasjon av ekspertanmeldere bevæpnet med automatiserte skannere for skadelig kode kan hjelpe.

Den andre anbefalingen er å trene utviklere som skriver pipelineog vedlikeholde dem på sikkerhetTing å vurdere:

• Hvordan håndtere autentisering på riktig måte med interne og skytjenester, og unngå bryderiet med å håndtere langvarig legitimasjon.
• Hvordan begrense pipelines til det nøyaktige settet med ressurser den trenger tilgang til. Prinsippet om minste privilegium skinner igjen.
• Hvordan skrive trinnene for å lage pipelines reproduserbar som versjonslåsing, og unngår sårbarheter ved kommandoinjeksjon.
• Hvordan godkjenne distribusjoner fra et sikkerhetsperspektiv (de er andre!): hvilken sikkerhet standards skal matches og hvordan legge til tilsvarende sjekker/porter i pipelines.

En tredje anbefaling er å konfigurere CI/CD systemet med tilbørlig forsiktighetSterk autentisering, ingen standardpassord eller usikre innstillinger, minimale rettigheter ... Ta vare på sårbarheter i installerte programtillegg og utvidelser. Dette kan være fokuset i følgende innlegg, følg med.

Den fjerde anbefalingen er å utnytt CI/CD pipelines for sikkerhetsautomatiseringKildekodeanalyse (SAST), analyse av kildesammensetning (SCA), kan skanning av hemmelige lekkasjer, verktøy for anti-malware, containersikkerhetsskannere eller automatiserte runtime-detektorer (DAST og malware) kjøres rutinemessig på pipelineOg organisasjonen din kan håndheve standards om dekning av sikkerhetsskanning i CI/CD.

Husk at disse verktøyene ikke fjerner ekspertvurderingen fra ligningen, ellers kan du få en falsk trygghetsfølelse.

Hvis du er flink til OWASPs topp-ti-lister, er et fint, nylig prosjekt OWASP Topp 10 CI/CD Sikkerhetsrisiko.

Ansvarsfraskrivelse merknad

(1) Eksemplene i dette innlegget bruker GitHub som SCM, AWS som skyleverandør, og GitHub Actions eller Jenkins som CI/CD verktøy. De er ikke svakere/tryggere enn alternativene. Ingen dårlig presseintensjon! Disse verktøyene er kraftige og må brukes riktig.

(2) M3M3N70 og Sumprase er fiktive karakterer. Enhver likhet med personer eller grupper, levende eller døde, er bare tilfeldig ... eller er den det?

For å lese mer

• Haymore, A. m.fl. «10 historier fra den virkelige verden om hvordan vi har inngått kompromisser» CI/CD pipelines ”NCC-gruppen, januar 2022.
• configure-aws-credentials GitHub-handling og Konfigurering av OpenID Connect i Amazon Web Services for detaljer om hvordan du kjører AWS-kommandoer for distribusjon i GitHub-arbeidsflyter.
• Lobacevski J. «Sikkerhet for GitHub-handlinger og arbeidsflyter Del 1: Forebygging av e-postforespørsler»GitLab sikkerhetslaboratorium, desember 2020.
• Lobacevski J. «Sikkerhet for GitHub-handlinger og arbeidsflyter Del 2: Upålitelig inndata»GitLab sikkerhetslaboratorium, januar 2021.
• OWASP. «OWASP Topp 10 CI/CD SikkerhetsrisikoerJuli 2022.
• Saltzer J. og Schroeder M. "Beskyttelse av informasjon i datasystemer"April 1975. Sikkerhetsprinsipper utviklet seg med teknologien, men 47 år senere er de fleste S&S-ideene fortsatt gjeldende.
• Storbritannias NCSC. "Sikre byggingen og utrullingen" pipeline"Storbritannias nasjonale senter for cybersikkerhet, februar 2019.