Čo sa môže pokaziť CI/CD pipelines?

Nepretržitá integrácia a nepretržité dodávanie (CI/CD) pipelinesú základom každej softvérovej organizácie, ktorá vyvíja softvér „moderným“ spôsobom. Automatizácia poskytuje veľkú silu, ale väčšina vývojárov si neuvedomuje zodpovednosť, ktorú so sebou prináša.

VývojkaÁno, berieme CI/CD zabezpečenia vážne a mať silnú kontrolu nad správcami kódu, kontrolovať commitpred zlúčeniami; úlohy a pipelinesú udržiavané vedúcimi pracovníkmi, ktorí dbajú na to, aby sa predišlo úniku tajomstiev. pipelineA nástroj nainštalovali pracovníci, ktorí sa v danej veci vyznajú. Čo sa môže pokaziť?

Vážený vývojár, CI/CD systémy sú zložité. Jeho široká útočná plocha prilákala zlomyseľných aktérov. Radšej buďte opatrní a nikdy si nebuďte príliš istí.

Predvolená konfigurácia sa niekedy zachová a stane sa najlepším priateľom hackerov. Kritické chyby sa môžu vyskytnúť v CI/CD pipeline zdrojov, v konfigurácii systému alebo okolo procesu a kontextu pipeline a ako sa to spúšťa.

V tomto príspevku sa vžijeme do role zlých hercov. Predstavte si, že čítame úvahy... M3M3N70 (Memento Mori?) a Zúrivosť v močiari niekde na dark webe, pravdepodobne v nejakom nezápadnom jazyku, ale nikdy neprehliadnite, že zlo sa šíri po celom svete.

 

Za starých dobrých čias to bolo také jednoduché…

M3M3N70Späť v starých dobrých časoch, naše podnikanie bolo také jednoduché... Zero-day boli ľahko dosiahnuteľné, aplikácie boli dokorán dostupné s ľahko zneužiteľnými zraniteľnosťami a my sme sa mohli pohnúť laterálne v okamihu.

Zúrivosť v močiariDo riti! Síce sú tu poriadni blázni, ale veci sa zmenili. Veľkí chlapi do toho AppSec veľa investovali.

M3M3N70Áno. Ale tí noví blázni sú vývojári. Pre nás bolo jednoduchšie zvoliť si nástroje, ktoré používajú títo ľudia. Najmä CI je zlatá baňa! Tokeny na prístup do cloudu, SCM prihlasovacie údaje, heslá k produkčnej databáze, súkromné ​​kľúče SSH, prihlasovacie údaje ostatných používateľov CI… Prechod od nudných vývojárskych vecí k skutočnému jadru bol dosť triviálny.

Automatizácia pre tvorbu, testovanie a nasadzovanie softvéru s CI/CD Nástroj často vyžaduje postupné odovzdávanie tajomstiev príkazom. A často sa stanú únikmi, čo má neslávne známe následky.

PipelinePotrebujú tajomstvá, ktoré niekedy uniknú

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žno za starých dobrých čias bolo nájsť v histórii Gitu .env súbor (vývojár ho zabudol pridať do .gitignore):

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

ktorý bol použitý v pracovnom postupe GitHub .github/deploy.yaml ktorý obsahoval niečo takéto:

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! Tie klávesy AWS fungovali! Najprv sme otestovali zmenu v aplikácii, ktorú sme použili na Inocuos, a potom sme pridali tú správnu funkciu, keďže si to tí chlapci zrejme neuvedomovali. Bingo! Aká kampaň…

Zločinec jednoducho použil kľúče AWS na nahranie upravenej aplikácie so škodlivým softvérom a potom spustil príkaz nasadiť s týmito prihlasovacími údajmi. Uniknuté tajomstvá spolu s informáciami obsiahnutými v pipeline„Aká kampaň!“ pravdepodobne znamená, že Memento spôsobilo úbohej obeti chaos.

Memento nám tu hovorí, že akonáhle dôjde k úniku tajných údajov, ako napríklad prístupové kľúče AWS v príklade, musíte tajné údaje zrušiť (vymeniť vyššie uvedené kľúče). okamžiteVždy existuje expozičné okno medzi únikom commit a tajné zneplatnenie; Prepisovanie histórie Gitu je ťažké (aj ten najtvrdší autoritársky štát sa pokúsil o takéto prepisovanie histórie, ale bezvýsledne) a pravdepodobne neúčinné (naši priatelia možno naklonovali pred únikom tajných informácií z úložiska) commit). Okamžite otočte kľúče a modlite sa pri čítaní záznamov o aktivite cieľového účtu počas expozičného okna!

Organizácie by pravdepodobne mali zákaz používania dlhodobých tajomstiev CI/CD pipelinesa nahraďte ich dočasnými povereniami. V predchádzajúcom príklade s kľúčmi AWS v akciách GitHubu je bezpečnejšie použiť Poskytovateľ OpenID Connect (OIDC) získať krátkodobé poverenia potrebné na akcie.

Zúrivosť v močiariMal si také šťastie! Únik skriptov s pevne zakódovanými kľúčmi bol v minulosti bežnou praxou, dokonca aj na verejne prístupných S3 bucketoch. Stačilo len prejsť objekty v buckete a vykonať grepping, aby si našiel zaujímavé veci.

Oblasť použitá na nasadenie (v tomto príklade bucket AWS S3) bola niekedy otvorená na čítanie zvonku kvôli konfiguračnej chybe (ktorá zostala nezistená). Čo Zúrivosť v močiari použité bolo niečo takéto:

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

Vedro bolo pravdepodobne vytvorené v šablóne na poskytovanie služieb, ktorá mohla byť automaticky skenovaná na bezpečnostné chyby.

Predvolená konfigurácia nástroja bola pre nás hračkou

Aby sme uviedli konkrétne príklady, povedzme si o tom Jenkins, jeden z najpopulárnejších nástrojov CI.

Zúrivosť v močiariPamätáte si to zaškrtávacie políčko „Povoliť zabezpečenie“ v Jenkins a koľko organizácií sa rozhodlo ho neaktivovať kvôli pohodliu? A tie „Ktokoľvek môže urobiť čokoľvek„kombinácie povolení ako predvolené? A tie otravné pluginy Jenkins, ako napríklad Doplnok GitHub OAuthChlapík, ktorý to nakonfiguroval, vybral obe možnosti: „Udeliť oprávnenia na čítanie všetkým overeným používateľom“ a „Použiť oprávnenia repozitára GitHub“, čím nám dal prístup ku všetkým ich projektom.

(Prepáč, Jenkins, že ťa dávam ako príklad 😉

Buďte zdatní (dokonca závislí) na bezpečnostných zásadách. Jednou z nich je Zabezpečené v predvolenom nastavení zásada: ovládacie prvky by mali mať predvolené nastavenia zabezpečenia. Zabezpečenie by malo byť zabudované do CI/CD nástroje a pipelineod základov, a nie ako dodatočná myšlienka. Používateľská prívetivosť a pohodlie sa však často stretávajú s bezpečnosťou.

V prípade Jenkinsa je vstavaná autentifikácia príliš krehká: nikdy nepoužívajte vstavané mechanizmy autentifikácie v JenkinsRadšej zvoľte mechanizmus tretej strany (SAML, LDAP, Google...) s pluginom Role-based Authorization Strategy („RBAC“). A buďte mimoriadne opatrní s... admin účet.

Starajte sa o to, ako pracujete a pipeline Súbory v Jenkins sa spracovávajú. To isté platí pre Doplnok Configuration-as-Code a jeho konfiguračné súbory, ktoré sa vzťahujú na konfiguráciu Jenkinsa.

Prechod z vlastného hostingu CI/CD Prechod systémov na cloudové SaaS riešenia eliminuje niektoré potenciálne riziká, ktoré umožňujú laterálny pohyb v rámci organizácie, ale pridávajú sa ďalšie, ako napríklad nutnosť otvárať externé pripojenia medzi existujúcimi internými systémami a externalizovanými systémami. CI/CD nástroj.

Organizácie by mali vynaložiť úsiliecisnáležitá starostlivosť pri kalení CI/CD systém, počnúc najreštriktívnejšími nastaveniami a postupne otvárajúc s minimálnymi požadovanými povoleniami pre pipeline krokov.

Konfigurácia zabezpečenia v CI/CD Nástroje môžu byť zložité. Mnohé majú pluginy alebo rozšírenia, ktoré majú väčšinu zraniteľností a je potrebné ich aktualizovať.

Pomôcť môžu skenery nesprávnej konfigurácie zabezpečenia pre takéto zložité nástroje alebo benchmarky.

Vkladanie kódu do pipeline príkazy pre zábavu a zisk

M3M3N70Použili ste niekedy nedôveryhodné kontroly kódu, ktoré sú zraniteľné voči vkladaniu príkazov?

Táto časť ukazuje, že pipeline sám o sebe môže obsahovať chyby v kódovaní, ktoré umožňujú zloupotníkom vložiť do pipeline bez zmeny pipeline samotný zdrojNapríklad pomocou PR

Prvý príklad nešťastný pracovný postup 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 ...

kombináciou pull_request_target Spúšťanie pracovného postupu s explicitným checkoutom nedôveryhodného PR je nebezpečná prax, ktorá môže viesť ku kompromitácii repozitára. V tomto príklade je nešťastná kombinácia:

• pull_request_target udalosť, ktorá má štandardne povolenie na zápis do cieľového repozitára a tajných údajov cieľového repozitára, a to aj z externých forkov, a spúšťa sa v kontexte cieľového repozitára PR,
• skontrolovať PR kód zo zdroja, nedôveryhodný repozitár,
• spustiť akýkoľvek skript, ktorý môže fungovať na obsahu kontrolovanom PR, ako v prípade npm installa
• nepoužívanie podmienky na spustenie pull_request_target udalosť sa spustí iba v prípade, že je k žiadosti o zadanie priradený nejaký druh označenia „táto žiadosť o zadanie bola overená“ (externí používatelia nemôžu k žiadosti o zadanie priradiť označenia).

Druhý príklad využíva nedôveryhodný vstup (z problému, komentára alebo pull request) ako zdroj argumentov odovzdaných do pipeline príkaz pomocou výrazov. Toto je pipeline verzia zraniteľnosti umožňujúcej vkladanie príkazov operačného systému.

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

Operácia spustenia vygeneruje dočasný shell skript založený na šablóne s $ nahradený, čím sa stane zraniteľným voči injekcii príkazov shellu. Útočník s falošným účtom GitHub by mohol spôsobiť problém s názvom a"; bad_code_goes_here;#, a bum! 

Zúrivosť v močiariTí chlapci otvárali dvere pre vkladanie príkazov jednoduchým otvorením problému...

V akciách GitHubu sa vyskytli zraniteľnosti pri vykonávaní kódu, ako napríklad gajira-komentár, teraz opravené. Prečítajte si to. „Nedôveryhodný vstup v pracovných postupoch GitHubu“ Všetky podrobnosti.

Ponaučenie z príbehu: Nikdy si nekontrolujte a nevytvárajte PR z nedôveryhodných zdrojov bez toho, aby ste si ich najprv preštudovali. „Nedôveryhodné“ v tomto prípade, pokiaľ nie je podrobené prísnemu overovaniu pôvodu, môže znamenať akýkoľvek potenciálne unesený účet vývojára.

 

Neúmyselné nasadenie škodlivého softvéru tu!

Nepretržité nasadzovanie je vyvrcholením automatizácie, ale toto vyvrcholenie by mohlo byť zmarené nedostatkom vhodných kontrol schvaľovania na pipeline prietok.

Riziká plne automatizovaného nasadenia zo zdroja commit do produkčných systémov patrí možnosť nasadenia škodlivého kódu do produkčných prostredí bez jeho odhalenia, ako aj možnosť, že chyby v procese nasadzovania spôsobia narušenia alebo výpadky.

Na zmiernenie týchto rizík sa organizáciám často odporúča zaviesť do procesu nasadzovania „tvrdé prerušenie“, ktoré vyžaduje ľudský súhlas pred nasadením vydaní do koncových prostredí.

Zatvárajú dvere

Zúrivosť v močiariTie radostné predvolené heslá v CI/CD nástroje sa utierajú. Prístup k /var/lib/jenkins/secrets/initialAdminPassword je teraz slepá koľaj. Mnoho nástrojov teraz poskytuje 2FA, ktoré spopularizoval Covid, a používa ho aj ten najlenivejší kódovací monštrum!

M3M3N70Bojujeme s 2FA, ale nie je to také jednoduché. Je ťažké ich „spear phishingom“ napodobniť, pretože „Scatter Swine“ urobil s TwiliomS kľúčmi WebAuthn je to oveľa zložitejšie. Aspoň sa môžeme pokúsiť kradnúť súbory cookie na obídenie MFA, ale treba sa vlámať do krabice vývojára.

Viacfaktorové overovanie je dobrým krokom správnym smerom k obmedzeniu rizika úniku autentifikačných tajomstiev. Väčšina moderných DevOps nástrojov podporuje MFA. A autentifikačné kľúče v rámci WebAuthn / U2F (pozri Projekt FIDO2) sú pravdepodobne najlepšou možnosťou pre MFA v DevOps, ak sú správne spravované.

Zúrivosť v močiariChlapci z DevOps sa prebúdzajú. Majú v krvi tú prekliatu vec s „najmenšími privilégiami“. A už nie sú kódovacími opicami. Teraz nás recenzenti prichytia pri čine.

V skutočnosti, pipelinesú teraz o niečo robustnejšie ako pred pár rokmi, boli odstránené slabé akcie a skripty a boli zavedené ďalšie kroky bezpečnostného testovania, ktoré dokonca odhalili naše droppery skryté v stealth režime. commita balíky, ktoré sme uniesli.

Otázka pre čitateľa: je proces zostavovania softvéru zo zdrojového kódu a nasadzovania do produkčného prostredia riskantný? Viete si predstaviť svoj DevOps vo fáze... staré dobré časy pre tých zlých?

Záverečné odporúčania

Kde začať CI/CD pipelines?

Prvé odporúčanie je tu jednoduché: Opatrne preskúma pipelines (sú kritický zdroje) pre bezpečnostné problémy. Kontroly sú nákladné, ale potrebné a mali by sa vykonávať správne. Kontrolóri by si mali byť vedomí toho, na čo sa majú zamerať. Každý krok musí byť skontrolovaný, či neobsahuje nedostatky.

Možno by mohla pomôcť kombinácia odborných recenzentov vybavených automatizovanými skenermi škodlivého kódu.

Druhé odporúčanie je školiť vývojárov, ktorí píšu pipelinea udržiavať ich v bezpečí. Čo treba zvážiť:

• Ako správne spracovať autentifikáciu s internými a cloudovými službami a vyhnúť sa nepríjemnej manipulácii s dlhodobými prihlasovacími údajmi.
• Ako obmedziť pipelines presným súborom zdrojov, ku ktorým potrebuje prístup. Princíp najmenších privilégií opäť zažiari.
• Ako napísať kroky na vytvorenie pipelineje reprodukovateľný, ako napríklad pripnutie verzie, a vyhýba sa zraniteľnostiam pri vkladaní príkazov.
• Ako schvaľovať nasadenia z bezpečnostného hľadiska (sú to iné!): ktoré zabezpečenie standardby sa mali zhodovať a ako pridať zodpovedajúce kontroly/brány v pipelines.

Tretím odporúčaním je nakonfigurovať CI/CD systém s náležitou starostlivosťouSilné overovanie, žiadne predvolené heslá ani nezabezpečené nastavenia, minimálne oprávnenia… Starostlivosť o zraniteľnosti v nainštalovaných pluginoch a rozšíreniach. Toto by mohlo byť zamerané na nasledujúce príspevky, prosím, zostaňte naladení.

Štvrté odporúčanie je využiť CI/CD pipelinepre automatizáciu zabezpečeniaAnalýza zdrojového kódu (SAST), analýza zloženia zdroja (SCA), skenovanie únikov tajomstiev, antivírusové nástroje, skenery zabezpečenia kontajnerov alebo automatizované detektory za behu (DAST a malware) je možné bežne spúšťať na pipelineA vaša organizácia môže presadzovať standardo pokrytí bezpečnostného skenovania v CI/CD.

Pripomíname, že tieto nástroje však nevylučujú odborné posúdenie, inak by ste mohli mať falošný pocit bezpečia.

Ak ste zbehlí v rebríčkoch top 10 OWASP, pekným nedávnym projektom je OWASP Top 10 CI/CD Bezpečnostné riziko.

Poznámka k vylúčeniu zodpovednosti

(1) Príklady v tomto príspevku používajú GitHub ako SCM, AWS ako poskytovateľ cloudových služieb a GitHub Actions alebo Jenkins ako CI/CD nástroj. Nie sú slabšie/bezpečnejšie ako ich alternatívy. Žiadny zlý úmysel v publicite! Tieto nástroje sú silné a treba ich používať vhodne.

(2) M3M3N70 a Zúrivosť v močiari sú fiktívne postavy. Akákoľvek podobnosť s osobami alebo skupinami, živými alebo mŕtvymi, je iba náhodná... alebo nie?

Ak chcete čítať viac

• Haymore, A. a kol. „10 príbehov zo skutočného sveta o tom, ako sme robili kompromisy“ CI/CD pipelines ”Skupina NCC, január 2022.
• configure-aws-credentials Akcia GitHubu a Konfigurácia OpenID Connect v Amazon Web Services pre podrobnosti o tom, ako spúšťať príkazy AWS na nasadenie v pracovných postupoch GitHub.
• Lobačevski J. „Zabezpečenie akcií a pracovných postupov na GitHube – 1. časť: Predchádzanie požiadavkám pwn“Bezpečnostné laboratórium GitLab, december 2020.
• Lobačevski J. „Zabezpečenie akcií a pracovných postupov na GitHube – 2. časť: Nedôveryhodný vstup“Bezpečnostné laboratórium GitLab, január 2021.
• OWASP. „OWASP Top 10“ CI/CD Bezpečnostné riziká“Júl 2022.
• Saltzer J. a Schroeder M. „Ochrana informácií v počítačových systémoch“Apríl 1975. Bezpečnostné princípy sa vyvíjali s technológiou, ale aj o 47 rokov neskôr väčšina myšlienok S&S zostáva v platnosti.
• NCSC Spojeného kráľovstva. „Zabezpečte zostavenie a nasadenie pipeline"Národné centrum kybernetickej bezpečnosti Spojeného kráľovstva, február 2019.