Mikä voi mennä pieleen CI/CD pipelines?

Jatkuva integrointi ja jatkuva toimitus (CI/CD) pipelineovat minkä tahansa ohjelmisto-organisaation perusta, joka rakentaa ohjelmistoja "modernilla" tavalla. Automaatio tarjoaa paljon tehoa, mutta useimmat kehittäjät unohtavat sen tuoman vastuun.

KehittäjäKyllä, otamme CI/CD turvallisuus vakavasti ja joilla on vahva kontrolli koodin ylläpitäjiin, tarkista commitennen fuusioita; työpaikkoja ja pipelinevanhempi henkilökunta ylläpitää niitä, he huolehtivat siitä, etteivät salaisuudet vuoda pipelines. Ja työkalun asensivat asiaan perehtyneet henkilöt. Mikä voi mennä pieleen?

Hyvä kehittäjä, CI/CD Järjestelmät ovat monimutkaisia. Sen laaja hyökkäyspinta houkutteli pahantahtoisia toimijoita. On parempi olla varovainen eikä koskaan olla liian itsevarma.

Oletusasetukset säilytetään joskus ja niistä tulee hakkereiden paras ystävä. Kriittisiä haavoittuvuuksia voi esiintyä CI/CD pipeline lähteistä, järjestelmän kokoonpanosta tai prosessin ja kontekstin ympäriltä pipeline ja miten se laukaistaan.

Tässä postauksessa asetumme pahiksen rooliin. Kuvittele, että lukisimme jonkun ajatuksia... M3M3N70 (Memento Mori?) ja Suon raivo jossain pimeässä verkossa, luultavasti ei-länsimaisella kielellä, mutta älä koskaan missaa sitä, että pahuus leviää maailmanlaajuisesti.

 

Vanhoina hyvinä aikoina se oli niin helppoa…

M3M3N70Takaisin vanhoihin hyviin aikoihin liiketoimintamme oli niin helppoa… Nollapäiväprojektit olivat helposti saavutettavissa, sovellukset olivat avoinna helposti hyödynnettävissä haavoittuvuuksissa, ja pystyimme liikkumaan sivusuunnassa hetkessä.

Suon raivo: V*ttu! Vielä on joitakin idiootteja, mutta asiat ovat muuttuneet. Isot jätkät panostavat paljon tuohon AppSec-paskaan.

M3M3N70Jep. Mutta uudet hölmöt ovat kehittäjät. Meille on ollut helpompaa valita työkalut, joita nämä kaverit käyttävät. Erityisesti CI on kultakaivos! Pilvipalvelun käyttötunnukset, SCM tunnistetiedot, tuotantotietokannan salasanat, SSH-yksityiset avaimet, muiden CI-käyttäjien tunnistetiedot… Hyppääminen tylsistä kehitysasioista varsinaiseen asiaan oli melko triviaalia.

Automaatio ohjelmistojen rakentamiseen, testaamiseen ja käyttöönottoon CI/CD työkalu tarvitsee usein salaisuuksien välittämistä komennoille vaiheittain. Ja usein ne vuotavat, millä on surullisenkuuluisat seuraukset.

Pipelinetarvitsevat salaisuuksia, jotka joskus vuotavat

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.

Ehkä vanhoina hyvinä aikoina oli löytää Gitin historiasta .env tiedosto (kehittäjä unohti lisätä sen .gitignore):

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

jota käytettiin GitHub-työnkulussa .github/deploy.yaml jossa oli jotain tällaista:

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! Nuo AWS-näppäimet toimivat! Testasimme ensin pientä muutosta sovelluksessa ja lisäsimme sitten sting-virheen, koska nuo kaverit tuntuivat olevan tietämättömiä. Bingo! Mikä kampanja…

Haittaohjelmassa olevat tiedot vuodettiin AWS-avaimilla muokatun sovelluksen avulla, ja sitten he suorittivat deploy-komennon näillä tunnistetiedoilla. Vuodetut salaisuudet sekä tiedostossa olevat tiedot... pipeline”Mikä kampanja!” tarkoittaa luultavasti sitä, että Memento aiheutti tuhoa raukalle uhrille.

Memento kertoo meille tässä, että kun salainen vuoto on tapahtunut, kuten esimerkissä AWS-käyttöavainten kanssa, sinun on peruutettava salaisuus (kierrettävä yllä olevia avaimia). hetiAina on olemassa valotusikkuna vuotavan välissä commit ja salainen mitätöinti; Gitin historian uudelleenkirjoittaminen on vaikeaa (jopa kovin autoritaarinen valtio yritti tällaista historian uudelleenkirjoittamista, tuloksetta) ja luultavasti tehotonta (ystävämme olisivat voineet kloonata sen ennen arkistoa, josta salainen vuoto löytyi) commit). Vaihda avaimia välittömästi ja rukoile samalla kun luet kohdetilin toimintalokeja altistumisikkunan aikana!

Todennäköisesti organisaatioiden pitäisi kieltää pitkäaikaisten salaisuuksien käytön CI/CD pipelinesja korvaa ne ajallisilla tunnistetiedoilla. Edellisessä esimerkissä, jossa käytettiin AWS-avaimia GitHub-toiminnoissa, on turvallisempaa käyttää OpenID Connect (OIDC) -palveluntarjoaja saadakseen toimiin tarvittavia lyhytaikaisia ​​​​valtakirjoja.

Suon raivoOlitpa niin onnekas! Kovakoodattujen avainten sisältävien skriptien vuotaminen oli yleistä käytäntöä ennen vanhaan, jopa julkisesti saatavilla olevissa S3-säiliöissä. Sinun tarvitsi vain käydä läpi säiliön objekteja ja tehdä jonkin verran grep-hakua löytääksesi mielenkiintoisia asioita.

Joskus käyttöönottoon käytetty alue (tässä esimerkissä AWS S3 -säiliö) oli ulkopuolisten luettavissa kokoonpanovirheen vuoksi (joka jäi huomaamatta). Mitä Suon raivo käytetty oli jotain tällaista:

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

Ämpäri luotiin luultavasti provisiointimallissa, joka voitiin automaattisesti skannata tietoturva-aukkojen varalta.

Työkalun oletusasetukset olivat meille leikkikalu

Annetaanpa konkreettisia esimerkkejä, keskustellaanpa Jenkins, yksi suosituimmista CI-työkaluista.

Suon raivoMuistatko Jenkinsin ”Ota suojaus käyttöön” -valintaruudun ja kuinka moni organisaatio päätti olla ottamatta sitä käyttöön mukavuussyistä? Ja nuo ”Kuka tahansa voi tehdä mitä tahansa”käyttöoikeusyhdistelmät oletuksena? Ja ne ärsyttävät Jenkins-laajennukset, kuten GitHub OAuth -laajennusSen konfiguroija valitsi sekä ”Myönnä LUKUoikeudet kaikille todennetuille käyttäjille” että ”Käytä GitHub-arkiston oikeuksia”, antaen meille pääsyn kaikkiin heidän projekteihinsa.

(Anteeksipyyntö, Jenkins, että käytin sinua esimerkkinä 😉

Pysy tietoisena (tai jopa riippuvaisena) turvallisuusperiaatteista. Yksi niistä on Oletusarvoisesti suojattu periaate: ohjausobjektien tulisi oletusarvoisesti käyttää mahdollisimman turvallisia asetuksia. Tietoturvan tulisi olla sisäänrakennettuna CI/CD työkaluja ja pipelines alusta alkaen, eikä jälkikäteen ajateltuna. Mutta käyttäjäystävällisyys ja kätevyys ovat usein ristiriidassa turvallisuuden kanssa.

Jenkinsin tapauksessa sisäänrakennettu todennus on liian hauras: älä koskaan käytä Jenkinsin sisäänrakennettuja todennusmekanismejaOn parempi valita kolmannen osapuolen mekanismi (SAML, LDAP, Google …) ja käyttää Role-based Authorization Strategy ("RBAC") -laajennusta. Ja ole äärimmäisen varovainen admin tili.

Huolehdi siitä, miten työsi ja pipeline Jenkins-tiedostoja käsitellään. Sama pätee Configuration-as-Code-laajennus ja sen määritystiedostot, jotka koskevat Jenkins-kokoonpanoa.

Siirtyminen itse isännöidystä palvelusta CI/CD järjestelmien siirtäminen pilvipohjaisiin SaaS-järjestelmiin poistaa joitakin mahdollisia riskejä, jotka mahdollistavat lateraalisen liikkumisen organisaatioverkon sisällä, mutta lisää muita, kuten tarpeen avata ulkoisia yhteyksiä olemassa olevien sisäisten järjestelmien ja ulkoistettujen järjestelmien välille. CI/CD työkalu.

Organisaatioiden tulisi harjoittaacisasianmukaista huolellisuutta karkaisemisessa CI/CD järjestelmää, alkaen rajoittavimmista asetuksista ja vähitellen avaamalla järjestelmän vähimmäisvaatimuksia vastaavilla oikeuksilla. pipeline askeleet.

Suojauksen määrittäminen CI/CD työkalut voivat olla monimutkaisia. Monissa on lisäosia tai laajennuksia, joissa on useimmat haavoittuvuudet ja jotka on päivitettävä.

Tällaisten monimutkaisten työkalujen tietoturvavirheiden skannerit tai vertailuarvot voivat auttaa.

Koodin injektointi pipeline komentoja huvin ja voiton vuoksi

M3M3N70Oletko koskaan käyttänyt epäluotettavia koodin tarkistuksia, jotka ovat alttiita komentojen injektoimiselle?

Tämä osio osoittaa, että pipeline itsessään voi olla koodausvirheitä, jotka mahdollistavat pahantahtoisten toimijoiden suorittaman mielivaltaisen koodin pipeline muuttamatta pipeline lähde itseEsimerkiksi käyttämällä PR:ää

Ensimmäinen esimerkki valitettava GitHub-työnkulku:

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

Yhdistämällä pull_request_target Työnkulun liipaisin, johon liittyy epäluotettavan PR:n eksplisiittinen uloskirjaus, on vaarallinen käytäntö, joka voi johtaa tietovaraston vaarantumiseen. Esimerkissä valitettava yhdistelmä:

• pull_request_target tapahtuma, jolla on oletusarvoisesti kirjoitusoikeus kohdetietovarastoon ja kohdetietovaraston salaisuuksiin, myös ulkoisista haarautumistapahtumista, ja joka suoritetaan PR:n kohdetietovaraston kontekstissa,
• tarkista PR-koodi lähteestä, epäluotettavasta reposta,
• käynnistää minkä tahansa komentosarjan, joka saattaa toimia PR-säädellyn sisällön kanssa, kuten esimerkiksi npm installja
• ei käytetä ehtoa laukaisun yhteydessä pull_request_target tapahtuma suoritetaan vain, jos PR:lle on liitetty jonkinlainen "tämä PR on tarkastettu" -tunniste (ulkoiset käyttäjät eivät voi liittää PR:ään tunnisteita).

Toinen esimerkki ottaa epäluotettavan syötteen (ongelmasta, kommentista tai pull request) lähteenä argumenteille, jotka välitetään pipeline komento lausekkeiden kautta. Tämä on pipeline käyttöjärjestelmän komentojen injektiohaavoittuvuuden versio.

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

Suoritustoiminto luo mallipohjaan perustuvan väliaikaisen komentosarjan, jossa on $ korvattu, mikä tekee siitä alttiin komentotulkkikomentojen injektoimiselle. Hyökkääjä, jolla on väärennetty GitHub-tili, voi aiheuttaa ongelman otsikon kanssa a"; bad_code_goes_here;#, ja pam! 

Suon raivoAi niin, nuo kaverit avasivat oven komentojen syötölle yksinkertaisesti avaamalla ongelman…

GitHubin toiminnoissa oli koodin suoritushaavoittuvuuksia, kuten gajira-kommentti, nyt korjattu. Luethan "Epäluotettava syöte GitHub-työnkuluissa" täydelliset tiedot.

Tarinan moraali: Älä koskaan hanki ja rakenna PR:iä epäluotettavista lähteistä tarkistamatta ensin PR:ää. ”Epäluotettava” voi tässä tarkoittaa mitä tahansa mahdollisesti kaapattua kehittäjätiliä, ellei kyseessä ole ankara alkuperän todennus.

 

Tahaton haittaohjelmien levitys täällä!

Jatkuva käyttöönotto on automaation huipentuma, mutta tuo huipentuma voi turhautua asianmukaisten hyväksyntäkontrollien puutteen vuoksi pipeline virtaus.

Täysin automatisoidun käyttöönoton riskit lähteestä commit Tuotantojärjestelmiin kohdistuviin ongelmiin kuuluu mahdollisuus, että haitallista koodia voidaan levittää tuotantoympäristöihin havaitsematta sitä, sekä mahdollisuus, että käyttöönottoprosessin virheet voivat aiheuttaa häiriöitä tai käyttökatkoksia.

Näiden riskien lieventämiseksi organisaatioille suositellaan usein käyttöönottoprosessissa "kovaa katkaisua", joka edellyttää ihmisen hyväksyntä ennen kuin julkaisut otetaan käyttöön loppuympäristöissä.

He sulkevat ovet

Suon raivoNuo iloiset oletussalasanat CI/CD työkalut pyyhitään pois. Pääsy /var/lib/jenkins/secrets/initialAdminPassword on nyt kuollut raiteelta. Monet työkalut tarjoavat nyt kaksivaiheista tunnistautumista, jonka Covid teki suosituksi, ja jopa laiskin koodiapina käyttää sitä!

M3M3N70Taistelemme 2FA:ta vastaan, mutta se ei ole niin helppoa. On vaikeaa huijata heitä, kuten... ”Scatter Swine” teki TwiliollaWebAuthn-avaimilla se on paljon vaikeampaa. Ainakin voimme yrittää varastaa evästeitä ohittaakseen MFA:n, mutta täytyy murtautua kehittäjän lokeroon.

Monivaiheinen todennus on hyvä askel oikeaan suuntaan todennussalaisuuksien vuotojen riskin rajoittamiseksi. Useimmat nykyaikaiset DevOps-työkalut tukevat monivaiheista todennusta. Ja todennusavaimet WebAuthnin / U2F:n alla (katso FIDO2-projekti) ovat kenties paras vaihtoehto MFA:lle DevOpsissa, jos niitä hallitaan oikein.

Suon raivoDevOps-jätkät heräävät. Heillä on veressään se pirun "vähiten oikeuksien" juttu. Eivätkä he ole enää koodiapinoita. Nyt meidät jäädään kiinni itse teoistaan ​​arvioijien toimesta.

Itse asiassa, pipelineovat nyt hieman vankempia kuin pari vuotta sitten, heikot toiminnot ja skriptit on poistettu ja lisätty tietoturvatestausvaiheita, jotka jopa havaitsivat piilotetut dropperimme. commitja kaapatut paketit.

Kysymys lukijalle: onko ohjelmiston rakentaminen lähdekoodista ja sen käyttöönotto tuotantoympäristössä riskialtista? Näetkö DevOps-prosessisi vaiheessa, jossa... vanhat hyvät ajat pahiksia varten?

Lopulliset suositukset

Mistä aloittaa CI/CD pipelines?

Ensimmäinen suositus on tässä yksinkertainen: Varovasti arvio pipelines (ne ovat kriittinen resursseja) tietoturvaongelmien varalta. Tarkastelmat ovat kalliita, mutta välttämättömiä, ja ne tulisi tehdä asianmukaisesti. Tarkastajien tulisi tietää, mitä tarkastella. Jokainen vaihe on tarkistettava virheiden varalta.

Ehkäpä asiantuntija-arvioijien ja automaattisten haittakoodiskannerien yhdistelmä voisi auttaa.

Toinen suositus on, että kouluttaa kehittäjiä, jotka kirjoittavat pipelineja pidä ne turvassaHuomioitavia asioita:

• Kuinka käsitellä todennusta oikein sisäisissä ja pilvipalveluissa, välttäen pitkäaikaisten tunnistetietojen käsittelyn aiheuttaman haitan.
• Kuinka rajoittaa pipelines tarkalleen siihen resurssijoukkoon, johon se tarvitsee pääsyn. Vähiten oikeuksien periaate loistaa jälleen.
• Kuinka kirjoittaa vaiheet, jotka tarvitaan pipelines toistettavissa kuten version kiinnittäminen ja komentojen injektiohaavoittuvuuksien välttäminen.
• Kuinka hyväksyä käyttöönotot tietoturvan näkökulmasta (ne ovat muita!): mikä tietoturva standards:n tulisi täsmätä ja miten lisätään vastaavat tarkistukset/portit pipelines.

Kolmas suositus on, että määritä CI/CD järjestelmä huolellisestiVahva todennus, ei oletussalasanoja tai suojaamattomia asetuksia, minimaaliset käyttöoikeudet… Huolehdi asennettujen lisäosien ja laajennusten haavoittuvuuksista. Tätä käsitellään mahdollisesti seuraavissa julkaisuissa, pysy kuulolla.

Neljäs suositus on, että hyödyntää CI/CD pipelines tietoturvan automatisointiin. Lähdekoodin analyysi (SAST), lähteen koostumusanalyysi (SCA), salaisuuksien vuotojen skannausta, haittaohjelmien torjuntatyökaluja, säilön tietoturvaskannereita tai automaattisia ajonaikaisia ​​ilmaisimia (DAST ja haittaohjelmat) voidaan suorittaa rutiininomaisesti pipelineJa organisaatiosi voi valvoa standards turvaskannauksen kattavuudesta CI/CD.

Muista, että nämä työkalut eivät kuitenkaan poista asiantuntija-arviointia yhtälöstä, muuten sinulla voi olla väärä turvallisuudentunne.

Jos olet taitava OWASP:n kymmenen parhaan joukossa, mukava tuore projekti on OWASP Top 10 CI/CD Turvallisuusriski.

Vastuuvapauslauseke

(1) Tämän viestin esimerkeissä käytetään GitHubia SCM, AWS pilvipalveluntarjoajana ja GitHub Actions tai Jenkins CI/CD työkalu. Ne eivät ole heikompia/turvallisempia kuin vaihtoehtonsa. Ei pahaa lehdistötarkoitusta! Nämä työkalut ovat tehokkaita ja niitä on käytettävä asianmukaisesti.

(2) M3M3N70 ja Suon raivo ovat kuvitteellisia hahmoja. Kaikki yhtäläisyydet henkilöihin tai ryhmiin, eläviin tai kuolleisiin, ovat vain sattumaa... vai onko?

Lue lisää

• Haymore, A. ym. 10 tositarinaa siitä, miten olemme tehneet kompromisseja CI/CD pipelines ”NCC-ryhmä, tammikuu 2022.
• configure-aws-credentials GitHub-toiminto ja OpenID Connectin määrittäminen Amazon Web Servicesissä lisätietoja AWS-komentojen suorittamisesta GitHub-työnkuluissa käyttöönottoa varten.
• Lobačevski J. "GitHub-toimintojen ja -työnkulkujen suojaaminen, osa 1: pwn-pyyntöjen estäminen"GitLabin tietoturvalaboratorio, joulukuu 2020.
• Lobačevski J. "GitHub-toimintojen ja -työnkulkujen suojaaminen, osa 2: Epäluotettava syöte"GitLabin tietoturvalaboratorio, tammikuu 2021.
• OWASP. OWASP:n kymmenen parasta CI/CD TurvallisuusriskitHeinäkuu 2022.
• Saltzer J. & Schroeder M. "Tietojen suojaaminen tietokonejärjestelmissä"Huhtikuu 1975. Turvallisuusperiaatteet kehittyivät teknologian mukana, mutta 47 vuotta myöhemmin useimmat tieteen ja teknologian ideat ovat edelleen voimassa.
• Yhdistyneen kuningaskunnan NCSC. "Suojaa koonti ja käyttöönotto" pipeline"Yhdistyneen kuningaskunnan kansallinen kyberturvallisuuskeskus, helmikuu 2019.