Co se může pokazit CI/CD pipelines?

Průběžná integrace a průběžné dodávání (CI/CD) pipelineJsou základem každé softwarové organizace, která vytváří software „moderním“ způsobem. Automatizace poskytuje velkou sílu, ale většina vývojářů si neuvědomuje odpovědnost, kterou s sebou nese.

VývojářAno, bereme CI/CD zabezpečení vážně a mít silnou kontrolu nad správci kódu, kontrolovat commitpřed sloučením; úlohy a pipelineJsou udržovány vedoucími pracovníky, kteří dbají na to, aby nedošlo k úniku tajemství. pipelines. A nástroj byl nainstalován personálem, který se v dané věci vyzná. Co se může pokazit?

Vážený vývojáři, CI/CD Systémy jsou složité. Jeho široká útočná plocha přitahovala zlomyslné aktéry. Raději buďte opatrní a nikdy si nevěřte příliš.

Výchozí konfigurace se někdy zachovává a stává se nejlepším přítelem hackerů. Kritické chyby se mohou vyskytovat v CI/CD pipeline zdroje, v konfiguraci systému nebo v souvislosti s procesem a kontextem pipeline a jak se to spouští.

V tomto příspěvku se vžijeme do role padouchů. Představte si, že čteme úvahy M3M3N70 (Memento Mori?) a Bažinatá zuřivost někde na temném webu, pravděpodobně v nezápadním jazyce, ale nikdy nepřehlédněte, že zlo se šíří po celém světě.

 

Za starých dobrých časů to bylo tak snadné…

M3M3N70Zpátky do starých dobrých časů, naše podnikání bylo taaak snadné… Zero-day programy byly snadno ovladatelné, aplikace byly dokořán s snadno zneužitelnými zranitelnostmi a my jsme se mohli během chvilky pohnout stranou.

Bažinatá zuřivost: Do prdele! Je tu pár bláznů, ale věci se změnily. Velcí chlapi do toho AppSec hodně vsadili.

M3M3N70Ano. Ale ti noví blázni jsou vývojáři. Pro nás bylo snazší zvolit nástroje, které používají tito lidé. Zejména CI je zlatý důl! Tokeny pro přístup do cloudu, SCM přihlašovací údaje, hesla k produkční databázi, soukromé klíče SSH, přihlašovací údaje dalších uživatelů CI… Přechod od nudných vývojářských věcí k podstatě byl poměrně triviální.

Automatizace pro tvorbu, testování a nasazení softwaru s CI/CD Nástroj často vyžaduje postupné předávání tajných informací příkazům. A často dochází k úniku tajných informací s nechvalně známými následky.

PipelinePotřebují tajemství, která někdy uniknou

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.

Možná za starých dobrých časů bylo v historii Gitu najít .env soubor (vývojář ho zapomněl přidat do .gitignore):

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

který byl použit v pracovním postupu GitHubu .github/deploy.yaml který obsahoval něco takového:

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! Ty AWS klíče fungovaly! Nejdřív jsme otestovali změnu v aplikaci, která byla neškodná, a pak jsme přidali tu správnou změnu, protože si toho ti kluci zřejmě neuvědomovali. Bingo! To byla ale kampaň…

Zločinec jednoduše použil klíče AWS k nahrání upravené aplikace s malwarem a poté s těmito přihlašovacími údaji spustil příkaz nasazení. Uniklé tajemství spolu s informacemi obsaženými v pipeline„To byla ale kampaň!“ pravděpodobně znamená, že Memento ubohou oběť zničilo.

Memento nám zde říká, že jakmile dojde k úniku tajného data, jako například u přístupových klíčů AWS v příkladu, musíte toto tajné data zrušit (střídat výše uvedené klíče). ihnedVždycky existuje expoziční okno mezi únikem commit a tajné zneplatnění; Přepisování historie Gitu je těžké (i ten nejtvrdší autoritářský stát se o takové přepisování historie pokusil, ale bezvýsledně) a pravděpodobně neúčinný (naši přátelé možná naklonovali před únikem tajných informací z repozitáře) commit). Okamžitě otočte klíče a modlete se při čtení protokolů aktivit cílového účtu během expozičního okna!

Organizace by pravděpodobně měly zákaz používání dlouhodobých tajemství CI/CD pipelinesa nahraďte je dočasnými přihlašovacími údaji. V předchozím příkladu s klíči AWS v akcích GitHubu je bezpečnější použít Poskytovatel OpenID Connect (OIDC) získat krátkodobé přihlašovací údaje potřebné pro akce.

Bažinatá zuřivostMěl jsi velké štěstí! Únik skriptů s pevně zakódovanými klíči byl v minulosti běžnou praxí, a to i na veřejně přístupných S3 bucketech. Stačilo jen procházet objekty v bucketu a provést grepping, abyste našli zajímavé věci.

Oblast použitá pro nasazení (v tomto příkladu bucket AWS S3) byla někdy otevřená pro čtení zvenčí kvůli konfigurační chybě (která zůstala neodhalena). Co Bažinatá zuřivost použité bylo něco jako toto:

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

Věž byla pravděpodobně vytvořena v šabloně pro zřizování, která mohla být automaticky skenována na bezpečnostní chyby.

Výchozí konfigurace nástroje pro nás byla hračka.

Abychom uvedli konkrétní příklady, pojďme si povědět o Jenkins, jeden z nejpopulárnějších nástrojů CI.

Bažinatá zuřivostPamatujete si to zaškrtávací políčko „Povolit zabezpečení“ v Jenkinsu a kolik organizací se rozhodlo ho neaktivovat kvůli pohodlí? A ty „Kdokoli může dělat cokoli„kombinace oprávnění jako výchozí? A ty otravné pluginy Jenkins, jako například OAuth plugin pro GitHubTen, kdo to konfiguroval, vybral obě možnosti: „Udělit oprávnění ke čtení všem ověřeným uživatelům“ a „Používat oprávnění repozitáře GitHub“, což nám dalo přístup ke všem jejich projektům.

(Omlouvám se, Jenkinsi, že tě dávám jako příklad 😉

Buďte zběhlí (i závislí) na bezpečnostních principech. Jedním z nich je Zabezpečeno ve výchozím nastavení princip: ovládací prvky by měly být standardně nastaveny na co nejbezpečnější nastavení. Zabezpečení by mělo být zabudováno do CI/CD nástroje a pipelineod základů, spíše než aby to byla dodatečná myšlenka. Uživatelská přívětivost a pohodlí se však často střetávají s bezpečností.

V případě Jenkinse je vestavěná autentizace příliš křehká: nikdy nepoužívejte vestavěné mechanismy ověřování v JenkinsuRaději zvolte mechanismus třetí strany (SAML, LDAP, Google…) s pluginem Role-based Authorization Strategy („RBAC“). A buďte s ním extrémně opatrní. admin účtu.

Dbejte na to, jak pracujete a pipeline Soubory v Jenkinsu jsou zpracovávány. Totéž platí pro Plugin Konfigurace jako kód a jeho konfigurační soubory, které se vztahují ke konfiguraci Jenkinse.

Přesun z vlastního hostování CI/CD Přechod od cloudových SaaS systémů k cloudovým eliminuje některá potenciální rizika, která umožňují laterální pohyb v rámci organizace, ale přidávají se další, jako je nutnost otevírat externí spojení mezi stávajícími interními systémy a externalizovanými systémy. CI/CD nástroj.

Organizace by měly vynaložit úsilícisnáležitá péče při kalení CI/CD systém, počínaje nejpřísnějším nastavením a postupně se otevírající s minimálními požadovanými oprávněními pro pipeline kroky.

Konfigurace zabezpečení v CI/CD Nástroje mohou být složité. Mnohé z nich mají pluginy nebo rozšíření, která mají většinu zranitelností a je třeba je aktualizovat.

Pomoci mohou skenery chybné konfigurace zabezpečení pro takové složité nástroje nebo benchmarky.

Vkládání kódu do pipeline příkazy pro zábavu a zisk

M3M3N70Použili jste někdy kontrolu nedůvěryhodného kódu, tedy zranitelné akce a skripty, které jsou zranitelné vůči vkládání příkazů?

Tato část ukazuje, že pipeline sám o sobě by mohl obsahovat chyby v kódu, které by umožnily zlomyslným aktérům vložit do něj libovolné spuštění kódu. pipeline beze změny pipeline samotný zdrojNapříklad použití PR

První příklad nešťastný pracovní postup na GitHubu:

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

Kombinace pull_request_target Spouštěč pracovního postupu s explicitním checkoutem nedůvěryhodného PR je nebezpečná praxe, která může vést k ohrožení repozitáře. V tomto příkladu je nešťastná kombinace:

• pull_request_target událost, která má ve výchozím nastavení oprávnění k zápisu do cílového repozitáře a tajných kódů cílového repozitáře, a to i z externích forků, a běží v kontextu cílového repozitáře PR,
• podívejte se na PR kód ze zdrojového kódu, nedůvěryhodný repozitář,
• spustit jakýkoli skript, který může pracovat s obsahem řízeným PR, jako v případě npm install, a
• nepoužívání podmínky ke spuštění pull_request_target událost se spustí pouze v případě, že je k žádosti o zadání přiřazen nějaký štítek „tato žádost o zadání byla ověřena“ (externí uživatelé nemohou žádosti o zadání přiřazovat štítky).

Druhý příklad využívá nedůvěryhodný vstup (z problému, komentáře nebo pull request) jako zdroj argumentů předávaných do pipeline příkaz pomocí výrazů. Toto je pipeline verze zranitelnosti umožňující vkládání příkazů do operačního systému.

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

Operace spuštění generuje dočasný shellový skript založený na šabloně s $ nahrazen, čímž se stane zranitelným vůči vkládání příkazů do shellu. Útočník s falešným účtem GitHub by mohl způsobit problém s názvem a"; bad_code_goes_here;#, a bum! 

Bažinatá zuřivostTi chlapi otevírali dveře pro vkládání příkazů pouhým otevřením problému…

V akcích GitHubu se vyskytly zranitelnosti umožňující spuštění kódu, například gajira-comment, nyní opraveno. Přečtěte si prosím „Nedůvěryhodný vstup v pracovních postupech GitHubu“ Veškeré podrobnosti.

Ponaučení z příběhu: Nikdy nekontrolujte a nevytvářejte PR z nedůvěryhodných zdrojů bez jejich předchozího prostudování. „Nedůvěryhodný“ zde, pokud se nejedná o drakonické ověřování původu, by mohl znamenat jakýkoli potenciálně unesený vývojářský účet.

 

Neúmyslné nasazení malwaru zde!

Průběžné nasazení je vyvrcholením automatizace, ale toto vyvrcholení by mohlo být zmařeno nedostatkem vhodných kontrol schvalování na pipeline tok.

Rizika plně automatizovaného nasazení ze zdroje commit Mezi rizikové faktory pro produkční systémy patří možnost nasazení škodlivého kódu do produkčního prostředí bez jeho detekce a také možnost, že chyby v procesu nasazení způsobí narušení nebo výpadky.

Aby se tato rizika zmírnila, často se doporučuje, aby organizace ve svém procesu nasazení zavedly „tvrdý přerušení“, které vyžaduje lidský souhlas před nasazením verzí do koncových prostředí.

Zavírají dveře

Bažinatá zuřivostTa radostná výchozí hesla v CI/CD nástroje se stírají. Přístup k /var/lib/jenkins/secrets/initialAdminPassword je teď slepá cesta. Mnoho nástrojů nyní poskytuje 2FA, které zpopularizoval Covid, a používá ho i ten nejlínější programátor!

M3M3N70Bojujeme s 2FA, ale není to tak snadné. Je těžké tyhle lidi spear phishovat, protože „Scatter Swine“ udělal s TwiliemS klíči WebAuthn je to mnohem složitější. Alespoň se o to můžeme pokusit. ukrást soubory cookie pro obcházení MFA, ale je potřeba se do toho pustit.

Vícefaktorové ověřování (Multi-Factor Authentication) je dobrým krokem správným směrem k omezení rizika úniku autentizačních tajných dat. Většina moderních DevOps nástrojů podporuje MFA. A autentizační klíče v rámci WebAuthn / U2F (viz Projekt FIDO2) jsou pravděpodobně nejlepší volbou pro MFA v DevOps, pokud jsou správně spravovány.

Bažinatá zuřivostDevOpsoví chlápci se probouzejí. Mají v krvi tu zatracenou věc s „nejmenšími privilegii“. A už to nejsou programátorské opice. Teď nás recenzenti chytají při činu.

Ve skutečnosti, pipelineJsou nyní o něco robustnější než před pár lety, byly odstraněny slabé akce a skripty a byly provedeny další kroky bezpečnostního testování, které dokonce detekovaly naše droppery skryté v nenápadném režimu. commita balíky, které jsme unesli.

Otázka pro čtenáře: je proces sestavování softwaru ze zdrojového kódu a jeho nasazení do produkčního prostředí riskantní záležitost? Dokážete si představit svůj DevOps ve fázi... staré dobré časy pro ty padouchy?

Konečné doporučení

Kde začít CI/CD pipelines?

První doporučení je zde jednoduché: Opatrně recenze pipelines (jsou kritický zdroje) pro bezpečnostní problémy. Kontroly jsou nákladné, ale nezbytné a měly by být provedeny řádně. Kontroloři by si měli být vědomi toho, na co se zaměřit. Každý krok musí být zkontrolován, zda neobsahuje nedostatky.

Možná by mohla pomoci kombinace odborných recenzentů vybavených automatizovanými skenery škodlivého kódu.

Druhé doporučení je školit vývojáře, kteří píší pipelinea udržovat je v bezpečíVěci, které je třeba zvážit:

• Jak správně zvládat ověřování pomocí interních a cloudových služeb a vyhnout se tak nepříjemné manipulaci s dlouhodobými přihlašovacími údaji.
• Jak omezit pipelines přesnou sadou zdrojů, ke kterým potřebuje přístup. Princip nejnižších privilegií opět září.
• Jak napsat kroky k vytvoření pipelinereprodukovatelné, jako je připínání verzí, a vyhýbání se zranitelnostem typu vkládání příkazů.
• Jak schvalovat nasazení z bezpečnostního hlediska (jsou to jiní!): které zabezpečení standards by měly být spárovány a jak přidat odpovídající kontroly/brány v pipelines.

Třetím doporučením je nakonfigurovat CI/CD systém s náležitou péčíSilné ověřování, žádná výchozí hesla ani nezabezpečená nastavení, minimální oprávnění… Postarejte se o zranitelnosti v nainstalovaných pluginech a rozšířeních. Toto by mohlo být tématem následujících příspěvků, sledujte prosím další informace.

Čtvrté doporučení zní využít CI/CD pipelinepro automatizaci zabezpečeníAnalýza zdrojového kódu (SAST), analýza složení zdroje (SCA), skenování úniků tajných informací, antimalwarové nástroje, skenery zabezpečení kontejnerů nebo automatizované běhové detektory (DAST a malware) lze rutinně spouštět na pipelineA vaše organizace může vymáhat standardo pokrytí bezpečnostního skenování v CI/CD.

Připomeňme, že tyto nástroje stále nevylučují odborné posouzení, jinak byste mohli mít falešný pocit bezpečí.

Pokud jste zběhlí v top desítkách OWASP, pěkným nedávným projektem je OWASP Top 10 CI/CD Bezpečnostní riziko.

Poznámka o vyloučení odpovědnosti

(1) Příklady v tomto příspěvku používají GitHub jako SCM, AWS jako poskytovatel cloudových služeb a GitHub Actions nebo Jenkins jako CI/CD nástroj. Nejsou slabší/bezpečnější než jejich alternativy. Žádný záměr negativní publicity! Tyto nástroje jsou účinné a je třeba je používat vhodně.

(2) M3M3N70 a Bažinatá zuřivost jsou fiktivní postavy. Jakákoli podobnost s osobami nebo skupinami, žijícími nebo mrtvými, je pouze náhodná… nebo ne?

Chcete-li si přečíst více

• Haymore, A. a kol. „10 skutečných příběhů o tom, jak jsme se dopustili kompromisů.“ CI/CD pipelines ”Skupina NCC, leden 2022.
• configure-aws-credentials Akce na GitHubu a Konfigurace OpenID Connect v Amazon Web Services pro podrobnosti o tom, jak spouštět příkazy AWS pro nasazení v pracovních postupech GitHubu.
• Lobačevski J. „Zabezpečení akcí a pracovních postupů na GitHubu – 1. část: Prevence požadavků pwn“Bezpečnostní laboratoř GitLab, prosinec 2020.
• Lobačevski J. „Zabezpečení akcí a pracovních postupů na GitHubu – 2. část: Nedůvěryhodný vstup“Bezpečnostní laboratoř GitLabu, leden 2021.
• OWASP. „OWASP Top 10“ CI/CD Bezpečnostní rizika“Červenec 2022.
• Saltzer J. a Schroeder M. „Ochrana informací v počítačových systémech“Duben 1975. Bezpečnostní principy se vyvíjely s technologií, ale i o 47 let později většina myšlenek S&S zůstává v platnosti.
• NCSC Spojeného království. „Zabezpečení sestavení a nasazení“ pipeline"Britské národní centrum pro kybernetickou bezpečnost, únor 2019.