Wat kin der misgean mei CI/CD pipelines?

Kontinue yntegraasje en trochgeande levering (CI/CD) pipelines binne de basis fan elke softwareorganisaasje dy't software op in "moderne" manier bout. Automatisearring biedt grutte krêft, mar de measte ûntwikkelders misse de ferantwurdlikens dy't it mei him bringt.

Untwikkelder: Ja, wy nimme CI/CD feiligens serieus en hawwe sterke kontrôle oer koade-ûnderhâlders, resinsje commits foar fúzjes; banen en pipelines wurde ûnderhâlden troch senior personiel, se soargje derfoar dat gjin geheimen yn 'e lek komme pipelines. En it ark waard ynstalleare troch personiel dat it ding wit. Wat kin der misgean?

Beste ûntwikkelder, CI/CD systemen binne kompleks. It brede oanfalsflak luts kweade akteurs oan. Wês better foarsichtich en nea te selsbetrouwen.

Standertkonfiguraasje wurdt soms bewarre en wurdt de bêste freon foar hackers. Krityske gebreken kinne oanwêzich wêze yn CI/CD pipeline boarnen, yn 'e konfiguraasje fan it systeem, of om it proses en de kontekst fan 'e pipeline en hoe't it aktivearre wurdt.

Yn dizze post sille wy ússels yn 'e skuon fan 'e minne akteurs pleatse. Stel jo foar dat wy de peinzingen lêze fan M3M3N70 (Memento Mori?) en Moeraswoede earne yn it tsjustere web, wierskynlik yn in net-westerse taal, mar mis noait dat it kwea wrâldwiid ferspraat wurdt.

 

Yn 'e goeie âlde tiden wie it sa maklik…

M3M3N70Werom nei de goeie âlde tiden wie ús bedriuw sa maklik ... Zero-days wiene leechhingjende fruchten, apps wiene wiid iepen mei maklik te eksploitearjen kwetsberheden, en wy koenen yn in momint lateraal bewege.

Moeraswoede: Fu#@Hell! Der binne noch wol wat gekken, mar de dingen binne feroare. De grutte jonges hawwe in soad omtinken jûn oan dy AppSec-stront.

M3M3N70Ja. Mar de nije dwazen binne de ûntwikkelders. Foar ús is it makliker west om te kiezen foar de ark dy't dizze jonges brûke. Benammen de CI is in goudmyn! Cloud tagongstokens, SCM ynloggegevens, wachtwurden foar de produksjedatabase, priveekaaien fan SSH, ynloggegevens fan oare CI-brûkers ... De oergong fan 'e saaie ûntwikkelingsdingen nei it echte wurk wie frij triviaal.

Automatisearring foar it bouwen, testen en ymplementearjen fan software mei in CI/CD ark moat faak geheimen yn stappen trochjaan oan kommando's. En faak wurde se lekt, mei beruchte gefolgen.

Pipelines hawwe geheimen nedich dy't soms útlekt wurde

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.

Miskien wie de goede âlde tiid om yn 'e skiednis fan Git in te finen .env bestân (de ûntwikkelder fergeat it ta te foegjen oan .gitignore):

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

dat brûkt waard yn in GitHub-workflow .github/deploy.yaml dat soksawat befette:

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! Dy aws-toetsen wurken! Wy hawwe earst in ûnskealike feroaring yn 'e app testen, en doe de sting tafoege, om't dy jonges it net wisten. Bingo! Wat in kampanje…

De minne akteur brûkte gewoan de AWS-kaaien om in oanpaste applikaasje mei malware te uploaden en fierde doe it deploy-kommando út mei sokke ynloggegevens. De lekte geheimen, tegearre mei de ynformaasje befette yn 'e pipeline“Wat in kampanje!” betsjut wierskynlik dat Memento it earme slachtoffer flink ferwoaste hat.

Wat Memento ús hjir fertelt is dat as der in geheime lek bard is, lykas AWS-tagongskaaien yn it foarbyld, jo it geheim ynlûke moatte (de boppesteande kaaien rotearje) fuortendaliksDer is altyd in bleatstellingsfinster tusken it lekken commit en de geheime ûnjildichstelling; Git-skiednis opnij skriuwe is dreech (sels de hurdste autoritêre steat besocht sokke skiednisherskriuwing, sûnder resultaat) en wierskynlik net effektyf (ús freonen hawwe miskien kloond foar de repository mei it geheime lek commit). Draaie de kaaien fuortendaliks, en bid wylst jo aktiviteitslogs lêze foar it doelakkount tidens it bleatstellingsfinster!

Organisaasjes moatte wierskynlik ferbiede it brûken fan langduorjende geheimen yn CI/CD pipelines, en ferfange se mei tydlike ynloggegevens. Yn it foarige foarbyld mei AWS-kaaien yn GitHub-aksjes is it feiliger om in te brûken OpenID Connect (OIDC) oanbieder om koarte-termyn ynloggegevens te krijen dy't nedich binne foar aksjes.

MoeraswoedeJo hiene safolle gelok! It lekken fan skripts mei hurdkodearre kaaien wie gewoan yn 'e âlde dagen, sels op iepenbier tagonklike S3-buckets. Alles wat jo hoege te dwaan wie de objekten yn 'e bucket trochbrekke en wat greping dwaan om ynteressante dingen te finen.

Soms wie it gebiet dat brûkt waard foar ynset (in AWS S3-bucket yn dit foarbyld) iepen foar lêzen fan bûtensteanders, fanwegen in konfiguraasjefout (dy't net ûntdutsen waard). Wat Moeraswoede brûkt wie soksawat as dit:

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

De bucket is wierskynlik oanmakke yn in foarsjenningssjabloan dat automatysk scannen wurde koe op befeiligingsfouten.

De standertkonfiguraasje fan it ark wie in boartersguod foar ús

Om konkrete foarbylden te jaan, lit ús prate oer Jenkins, ien fan 'e populêrste CI-ark.

MoeraswoedeTinksto noch oan dat seleksjefakje "Feiligens ynskeakelje" yn Jenkins, en hoefolle organisaasjes der foar keazen hawwe om it net te aktivearjen foar it gemak? En dy "Elkenien kin alles dwaan"tastimmingskombinaasjes as standert? En dy ferfelende Jenkins-plugins, lykas de GitHub OAuth-pluginDe keardel dy't it konfigurearre hat sawol "LÊSrjochten jaan oan alle autentisearre brûkers" as "GitHub-repository-rjochten brûke" selektearre, wêrtroch't wy tagong krigen hawwe ta al harren projekten.

(Ekskuzes, Jenkins, dat ik dy as foarbyld nommen haw 😉

Bliuw betûft (sels ferslaafd) oan feiligensprinsipes. Ien is de Standert feilich prinsipe: kontrôles moatte standert de feilichste mooglike ynstellings brûke. Feiligens moat ynboud wurde yn CI/CD ark en pipelines fan 'e grûn ôf, ynstee fan in neitocht te wêzen. Mar brûkersfreonlikens en gemak botsje faak mei feiligens.

Foar it gefal Jenkins is de ynboude autentikaasje te kwetsber: brûk noait de ynboude autentikaasjemeganismen yn JenkinsKies better foar in meganisme fan tredden (SAML, LDAP, Google ...), mei de Role-based Authorization Strategy ("RBAC") plugin. En wês ekstreme foarsichtich mei de admin rekken.

Soargje foar hoe't wurk en pipeline bestannen yn Jenkins wurde behannele. Itselde mei Konfiguraasje-as-koade-plugin en syn konfiguraasjebestannen, dy't jilde foar de Jenkins-konfiguraasje.

Ferhúzje fan selshosting CI/CD systemen nei cloud-basearre SaaS-systemen elimineert guon potinsjele risiko's dy't laterale beweging binnen it organisaasjenetwurk mooglik meitsje, mar foege oaren ta, lykas it iepenjen fan eksterne ferbiningen tusken besteande ynterne systemen en de eksternalisearre CI/CD helpmiddel.

Organisaasjes moatte útoefenjecise soarchfâldige soarch by it ferhurdzjen fan 'e CI/CD systeem, begjinnend mei de meast beheinde ynstellings en stadichoan iepenjend mei de minimaal fereaske tagongsrjochten foar de pipeline stappen.

Feiligens konfigurearje yn CI/CD ark kinne yngewikkeld wêze. In protte hawwe plugins of útwreidings dy't de measte kwetsberheden hawwe en moatte wurde bywurke.

Scanners foar ferkearde konfiguraasje fan befeiliging foar sokke komplekse ark, of benchmarks kinne helpe.

Koade ynjeksje pipeline kommando's foar wille en winst

M3M3N70Hawwe jo ea Untrusted Code Checkouts brûkt, dy kwetsbere aksjes en skripts dy't kwetsber binne foar kommando-ynjeksje?

Dizze seksje lit sjen dat de pipeline sels koe kodearflaters hawwe dy't minne akteurs yn steat stelle om willekeurige koade-útfiering yn te spuitsjen yn 'e pipeline sûnder de pipeline boarne selsBygelyks mei in PR

In earste foarbyld fan in ûngelokkige GitHub-workflow:

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

Kombineare pull_request_target In workflow-trigger mei in eksplisite útsjekking fan in net-fertroude PR is in gefaarlike praktyk dy't kin liede ta kompromittaasje fan 'e repository. Yn it foarbyld is de ûngelokkige kombinaasje fan:

• pull_request_target evenemint, dat standert skriuwtastimming hat foar de doelrepository en geheimen fan 'e doelrepository, sels fan eksterne forks, en rint yn 'e kontekst fan 'e doelrepository fan 'e PR,
• kontrolearje de PR-koade fan 'e boarne, net-fertroude repo,
• trigger elk skript dat kin wurkje op PR-kontroleare ynhâld, lykas yn it gefal fan npm install, en
• gjin betingst brûke foar de trigger pull_request_target barren allinich útfiere as in soarte fan 'dizze PR is kontrolearre' label oan de PR tawiisd is (eksterne brûkers kinne gjin labels oan de PR tawize).

In twadde foarbyld nimt net-fertroude ynput (fan in probleem, kommentaar of pull request) as boarne foar arguminten dy't trochjûn wurde oan in pipeline kommando fia útdrukkings. Dit is de pipeline ferzje fan 'e kwetsberens fan it OS-kommando-ynjeksjesysteem.

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

De útfieroperaasje genereart in tydlik shellskript basearre op it sjabloan, mei $ ferfongen, wêrtroch it kwetsber is foar ynjeksje fan shell-kommando's. In oanfaller mei in falsk GitHub-akkount koe in probleem mei in titel oanmeitsje a"; bad_code_goes_here;#, en boem! 

MoeraswoedeOch, dy jonges iepenen de doar foar kommando-ynjeksje troch gewoan in probleem te iepenjen ...

Der wiene kwetsberheden foar koade-útfiering yn GitHub-aksjes, lykas gajira-kommentaar, no reparearre. Lês asjebleaft "Net-fertroude ynfier yn GitHub-workflows" foar folsleine details.

De moraal fan it ferhaal: Kontrolearje en bou nea PR's fan net-fertroude boarnen sûnder earst de PR te kontrolearjen. 'Net fertroud' hjir, útsein as ûnder drakonyske autentikaasje fan komôf, kin betsjutte dat der potinsjeel kapte ûntwikkeldersakkounts binne.

 

Unbedoelde malware-ynset hjir!

Trochrinnende ynset is de klimaks fan automatisearring, mar dy klimaks koe frustrearre wurde troch it ûntbrekken fan passende goedkarringskontrôles op 'e pipeline streame.

De risiko's fan folslein automatisearre ynset fan 'e boarne commit oan produksjesystemen omfetsje de mooglikheid dat kweade koade ynset wurdt yn produksjeomjouwings sûnder dat it ûntdutsen wurdt, lykas de mooglikheid dat flaters yn it ynsetproses ûnderbrekkings of ûnderbrekkings feroarsaakje.

Om dizze risiko's te ferminderjen, wurdt it faak oanrikkemandearre dat organisaasjes in "hurde ûnderbrekking" yn har ynsetproses ymplementearje, wat fereasket minsklike goedkarring foardat releases ynset wurde nei einomjouwings.

Se slute de doarren

MoeraswoedeDy bliide standertwachtwurden yn CI/CD ark wurde fuortwiske. Tagong ta de /var/lib/jenkins/secrets/initialAdminPassword is no in dea spoar. In protte ark leverje no 2FA, dat Covid populêr makke hat, en sels de luiste kode-aap brûkt it!

M3M3N70Wy fjochtsje tsjin 2FA, mar it is net sa maklik. It is dreech om dy jonges te spearphishen, om't "Scatter Swine" die mei TwilioMei WebAuthn-kaaien is it folle dreger. Teminsten kinne wy ​​besykje stelle koekjes om MFA te omgean, mar moatte yn 'e doaze fan ûntwikkelders ynbrekke.

Multi-Factor Authentication is in goede stap yn 'e goede rjochting foar it beheinen fan it risiko op lekken fan autentikaasjegeheimen. De measte moderne DevOps-ark stypje MFA. En autentikaasjesleutels ûnder WebAuthn / U2F (sjoch FIDO2-projekt) binne miskien de bêste opsje foar MFA yn DevOps, as se goed beheard wurde.

MoeraswoedeDe DevOps-jonges wurde wekker. Se hawwe it ferrekte "minste privileezje" ding yn har bloed. En se binne gjin koade-apen mear. Wy wurde no op iterdaad betrape troch resinsinten.

Yn feite, pipelines binne no wat robúster as in pear jier lyn, mei swakke aksjes en skripts fuorthelle, en mei ekstra feiligensteststappen dy't sels ús droppers ferburgen yn stealth ûntdutsen hawwe. commits en pakketten dy't wy kapet hawwe.

Fraach foar de lêzer: is it proses fan it bouwen fan 'e software út boarnen en it ynset yn produksje in risikofolle saak? Kinne jo jo DevOps yn 'e faze fan sjen âlde goede tiden foar de minne jonges?

Finale oanrikkemedaasjes

Wêr te begjinnen mei CI/CD pipelines?

De earste oanbefelling is hjir ienfâldich: Foarsichtich resinsje pipelines (se binne kritysk boarnen) foar feiligensproblemen. Resinsjes binne djoer mar needsaaklik, en moatte goed dien wurde. Resinsinten moatte witte wêr't se nei moatte sjen. Elke stap moat kontrolearre wurde op gebreken.

Miskien koe in kombinaasje fan saakkundige resinsinten bewapene mei automatisearre scanners foar kweade koade helpe.

De twadde oanbefelling is om ûntwikkelders opliede dy't skriuwe pipelines en ûnderhâld se op feiligensDingen om te beskôgjen:

• Hoe kinne jo autentikaasje goed ôfhannelje mei ynterne en wolktsjinsten, wêrtroch't jo de oerlêst fan it omgean mei langduorjende ynloggegevens foarkomme.
• Hoe te beheinen pipelines nei de krekte set boarnen dêr't it tagong ta nedich hat. It prinsipe fan minste privileezje skynt wer.
• Hoe skriuw ik de stappen om te meitsjen pipelines reprodusearber lykas ferzje-pinnen, en it foarkommen fan kwetsberens foar kommando-ynjeksje.
• Hoe kinne jo ynset goedkarre út it feiligensperspektyf (dat binne oaren!): hokker feiligens standards moatte oerienkomme en hoe't jo oerienkommende kontrôles/poarten tafoegje kinne yn 'e pipelines.

In tredde oanbefelling is om konfigurearje de CI/CD systeem mei soarchSterke autentikaasje, gjin standertwachtwurden of ûnfeilige ynstellings, minimale privileezjes ... Soargje foar kwetsberheden yn ynstalleare plugins en útwreidings. Dit kin de fokus wêze fan folgjende berjochten, bliuw op 'e hichte.

De fjirde oanbefelling is om leverage de CI/CD pipelines foar feiligensautomatisearringAnalyse fan boarnekoade (SAST), analyse fan boarnekomposysje (SCA), kinne it scannen fan geheime lekken, anti-malware-ark, kontenerfeiligensscanners of automatisearre runtime-detektors (DAST en malware) routinematich útfierd wurde op 'e pipelineEn jo organisaasje kin hanthavenje standardoer dekking oer befeiligingsscannen yn CI/CD.

Tink derom, dizze ark ferwiderje noch gjin saakkundige resinsje út 'e fergeliking, oars kinne jo in falsk gefoel fan feiligens hawwe.

As jo ​​betûft binne yn OWASP top-tsienen, is in moai resint projekt de OWASP Top 10 CI/CD Feiligens Risiko.

Disclaimer Notysje

(1) De foarbylden yn dizze post brûke GitHub as SCM, AWS as wolkprovider, en GitHub Actions of Jenkins as CI/CD ark. Se binne net swakker/feiliger as harren alternativen. Gjin minne parsebedoeling! Dizze ark binne krêftich en moatte op passende wize brûkt wurde.

(2) M3M3N70 en Moeraswoede binne fiktive personaazjes. Elke oerienkomst mei persoanen of groepen, libben of dea, is gewoan tafallich ... of is it dat?

Om mear te lêzen

• Haymore, A. et al. "10 echte ferhalen oer hoe't wy kompromissen sluten hawwe" CI/CD pipelines ”NCC Groep, jannewaris 2022.
• configure-aws-credentials GitHub-aksje en OpenID Connect konfigurearje yn Amazon Web Services foar details oer hoe't jo AWS-kommando's útfiere kinne foar ynset yn GitHub-workflows.
• Lobacevski J. "Jo GitHub-aksjes en workflows feilich hâlde Diel 1: Pwn-oanfragen foarkomme"GitLab Feiligenslab, desimber 2020.
• Lobacevski J. "Jo GitHub-aksjes en workflows feilich hâlde Diel 2: Net-fertroude ynfier"GitLab Feiligenslab, jannewaris 2021.
• OWASP. "OWASP Top 10" CI/CD Feiligensrisiko's. Jul 2022.
• Saltzer J. & Schroeder M. "De beskerming fan ynformaasje yn kompjûtersystemen"Apr 1975. Feiligensprinsipes evoluearren mei technology, mar 47 jier letter bliuwe de measte S&S-ideeën fan krêft.
• UK NCSC. "Feilich meitsje fan de bou en ynset pipeline"Nasjonaal CyberSecurity Sintrum fan it Feriene Keninkryk, febrewaris 2019.