Hvað getur farið úrskeiðis með CI/CD pipelines?

Stöðug samþætting og stöðug afhending (CI/CD) pipelineeru grunnurinn að öllum hugbúnaðarfyrirtækjum sem smíða hugbúnað á „nútímalegan“ hátt. Sjálfvirkni veitir mikinn kraft, en flestir forritarar missa af þeirri ábyrgð sem henni fylgir.

HönnuðurJá, við tökum CI/CD öryggi alvarlega og hafa sterka stjórn á kóðaviðhaldurum, endurskoðun commitfyrir sameiningar; störf og pipelineeru viðhaldið af eldri starfsmönnum, þeir gæta þess að leyndarmál leki ekki út í pipelineOg tólið var sett upp af starfsfólki sem þekkir málið. Hvað getur farið úrskeiðis?

Kæri verktaki, CI/CD Kerfin eru flókin. Breiða árásarflöturinn laðaði að sér illgjarna aðila. Betra er að vera varkár og aldrei of öruggur með sig.

Sjálfgefin stilling er stundum geymd og verður besti vinur tölvuþrjóta. Alvarlegir gallar geta verið til staðar í CI/CD pipeline heimildum, í uppsetningu kerfisins, eða í kringum ferlið og samhengið við pipeline og hvernig það er virkjað.

Í þessari færslu ætlum við að setja okkur í spor slæmu leikaranna. Ímyndaðu þér að við værum að lesa hugleiðingar M3M3N70 (Memento Mori?) og Mýrarreiði einhvers staðar á myrka vefnum, líklega á tungumáli sem ekki er vestrænt, en missið aldrei af því að illskan dreifist um allan heim.

 

Í gamla daga var þetta svo auðvelt…

M3M3N70Aftur til góðu gömlu tímanna var viðskipti okkar svo auðveld ... Núlldagar voru lághangandi ávextir, öpp voru opin með auðvelt að nýta sér veikleika og við gátum fært okkur til hliðar á augabragði.

Mýrarreiði: Fu#@Hell! Nokkrir kjánar þarna úti ennþá, en hlutirnir hafa breyst. Stóru strákarnir lögðu mikla áherslu á þetta AppSec drasl.

M3M3N70Já. En nýju fíflarnir eru forritararnir. Fyrir okkur hefur verið auðveldara að velja þau verkfæri sem þessir gaurar nota. Sérstaklega CI er gullnáma! Aðgangsmerki fyrir skýið, SCM Innskráningarupplýsingar, lykilorð fyrir framleiðslugagnagrunna, einkalyklar fyrir SSH, innskráningarupplýsingar annarra notenda CI… Það var frekar auðvelt að hoppa frá leiðinlegu þróunarhlutunum yfir í raunverulega kjarnann.

Sjálfvirkni við smíði, prófanir og dreifingu hugbúnaðar með CI/CD Tól þarf oft að senda leyndarmál til skipana í skrefum. Og oft leka þau út, með alræmdum afleiðingum.

Pipelineþarfnast leyndarmála sem stundum leka út

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.

Kannski var það í gamla daga að finna í sögu Git .env skrá (forritarinn gleymdi að bæta henni við .gitignore):

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

sem var notað í GitHub vinnuflæði .github/deploy.yaml sem innihélt eitthvað á þessa leið:

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: Vá! Þessir aws-lyklar virkuðu! Við prófuðum fyrst skaðlausa breytingu í appinu og bættum svo við „sting“ þar sem þessir gaurar virtust ekki vita af því. Bingó! Þvílík herferð…

Ógjörðamaðurinn notaði einfaldlega AWS lyklana til að hlaða inn breyttu forriti með spilliforriti og keyrði síðan deploy skipunina með slíkum innskráningarupplýsingum. Lekuðu leyndarmálin, ásamt upplýsingunum sem eru í pipeline„Hvílík herferð!“ þýðir líklega að Memento olli miklu tjóni hjá hinu vesalings fórnarlambinu.

Það sem Memento segir okkur hér er að þegar leynilegt leki hefur átt sér stað, eins og AWS aðgangslyklar í dæminu, verður þú að afturkalla leynilegt leynilegt efni (snúa lyklunum hér að ofan). straxÞað er alltaf til staðar útsetningargluggi á milli leka commit og leynilega ógildingin; Það er erfitt að endurskrifa sögu Git (jafnvel harðasta einræðisríkið reyndi slíka söguendurritun, án árangurs) og líklega árangurslaust (vinir okkar gætu hafa klónað áður en geymslunni með leynilegu lekanum lauk commit). Snúðu tökkunum strax og biddu á meðan þú lest virkniskrár fyrir markreikninginn á meðan birtingarglugginn er!

Líklega ættu stofnanir að banna notkun langtímaleyndarmála í CI/CD pipelinesog skipta þeim út fyrir tímabundnar innskráningarupplýsingar. Í fyrra dæminu með AWS lyklum í GitHub aðgerðum er öruggara að nota OpenID Connect (OIDC) veitandi til að fá skammtíma skilríki sem þarf til aðgerðir.

MýrarreiðiÞú varst svo heppinn! Það var algengt að leka forskriftum með harðkóðuðum lyklum í gamla daga, jafnvel á almenningi aðgengilegum S3 fötum. Allt sem þú þurftir að gera var að fletta í gegnum hlutina í fötunni og gera smá grip til að finna áhugaverða hluti.

Stundum var svæðið sem notað var fyrir dreifingu (AWS S3 fötu í þessu dæmi) opið fyrir lestur frá utanaðkomandi aðilum vegna stillingargalla (sem fór ekki fram). Hvað Mýrarreiði notað var eitthvað á þessa leið:

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

Fötunni var líklega búin til í úthlutunarsniðmáti sem hægt var að skanna sjálfkrafa í leit að öryggisgöllum.

Sjálfgefin stilling tólsins var leikfang fyrir okkur

Til að gefa konkret dæmi skulum við ræða um Jenkins, eitt vinsælasta CI tólið.

MýrarreiðiManstu eftir gátreitnum „Virkja öryggi“ í Jenkins og hversu margar stofnanir kusu að virkja hann ekki til þæginda? Og þessir „Hver sem er getur gert hvað sem er„heimildasamsetningar sem sjálfgefnar? Og þessar pirrandi Jenkins viðbætur, eins og GitHub OAuth viðbótSá sem stillti þetta upp valdi bæði „Veita lesheimildir til allra auðkenndra notenda“ og „Nota heimildir fyrir GitHub geymslur“ og gaf okkur aðgang að öllum verkefnum þeirra.

(Afsakið, Jenkins, að ég set þig sem dæmi 😉

Vertu fær(ur) í (jafnvel háður) öryggisreglum. Ein er sú Öruggt sjálfgefið Meginregla: Stýringar ættu að vera sjálfgefnar með öruggustu mögulegu stillingum. Öryggi ætti að vera innbyggt í CI/CD verkfæri og pipelinefrá grunni, frekar en að vera aukaatriði. En notendavænni og þægindi stangast oft á við öryggi.

Í tilfelli Jenkins er innbyggð auðkenning of brothætt: aldrei nota innbyggðu auðkenningarkerfin í JenkinsBetra er að velja þriðja aðila (SAML, LDAP, Google ...) með viðbótinni „Role-based Authorization Strategy“ („RBAC“). Og gætið ítrustu varúðar með admin reikningur.

Gætið þess hvernig starfið og pipeline Skrár í Jenkins eru meðhöndlaðar. Það sama með Stillingar-sem-kóði viðbót og stillingarskrár þess, sem eiga við um stillingar Jenkins.

Að flytja frá sjálfshýsingu CI/CD Að skipta út kerfum yfir í skýjatengd SaaS-kerfi útilokar sumar hugsanlegar áhættur sem leyfa hliðarhreyfingar innan stofnunarnetsins, en bætir við öðrum, eins og að þurfa að opna ytri tengingar milli núverandi innri kerfa og þeirra ytri sem eru sett á. CI/CD tól.

Stofnanir ættu að beita sércisGætið varúðar við að herða CI/CD kerfið, byrjað með strangustu stillingunum og smám saman opnað með lágmarksheimildum sem krafist er fyrir pipeline skref.

Að stilla öryggi í CI/CD Tól geta verið flókin. Mörg þeirra eru með viðbætur eða viðbætur sem hafa flesta veikleikana og þarf að uppfæra.

Skannarar fyrir rangar öryggisstillingar fyrir svona flókin verkfæri eða viðmið geta hjálpað.

Að sprauta inn kóða pipeline skipanir til gamans og gróða

M3M3N70Hefur þú einhvern tíma notað ótraustar kóðaúttektir, þær viðkvæmu aðgerðir og forskriftir sem eru viðkvæmar fyrir skipanainndælingu?

Þessi kafli sýnir að pipeline sjálft gæti haft kóðunarvillur sem gera slæmum aðilum kleift að sprauta handahófskenndri kóðakeyrslu í pipeline án þess að breyta pipeline uppspretta sjálfrarTil dæmis með því að nota almannatengsl

Fyrsta dæmi um óheppilegt GitHub vinnuflæði:

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

Sameina pull_request_target Að kveikja á verkflæði með skýrri útskráningu á ótraustri persónuverndarupplýsingum er hættuleg aðferð sem getur leitt til þess að gagnasafn komist í hættu. Í dæminu er óheppileg samsetning af:

• pull_request_target atburður, sem sjálfgefið hefur skrifaðgang að markgeymslunni og leyndarmálum markgeymslunnar, jafnvel frá ytri forkum, og keyrir í samhengi markgeymslunnar í PR,
• skoðaðu PR kóðann frá upprunanum, ótrausta geymsluna,
• virkja hvaða forskrift sem er sem kann að virka á PR-stýrðu efni, eins og í tilviki npm installog
• ekki nota skilyrði til að kveikja pull_request_target atburður keyrir aðeins ef einhvers konar „þessi persónuverndaraðili var yfirfarinn“ merki er úthlutað persónuverndaraðilanum (utanaðkomandi notendur geta ekki úthlutað merkimiðum til persónuverndaraðilans).

Annað dæmi tekur óáreiðanlegt inntak (frá vandamáli, athugasemd eða pull request) sem uppspretta fyrir rök sem send eru til a pipeline skipun með segðum. Þetta er pipeline útgáfa af öryggisgallanum við skipanainnspýtingu stýrikerfisins.

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

Keyrsluaðgerðin býr til tímabundið skeljaskriftu byggt á sniðmátinu, með $ skipt út, sem gerir það viðkvæmt fyrir innspýtingu skelskipana. Árásarmaður með falsa GitHub aðgang gæti skapað vandamál með titli a"; bad_code_goes_here;#, og búmm! 

MýrarreiðiÓ, þessir gaurar voru að opna dyrnar fyrir skipanainnspýtingu með því einfaldlega að opna vandamál ...

Það voru veikleikar í keyrslu kóða í GitHub aðgerðum, eins og gajira-athugasemd, nú lagað. Vinsamlegast lesið „Ótreyst inntak í GitHub vinnuflæði“ fyrir frekari upplýsingar.

Siðferði sögunnar: Aldrei skal kaupa og búa til PR frá ótraustum aðilum án þess að fara fyrst yfir PR-ið. „Ótreyst“ hér, nema með strangri staðfestingu uppruna, gæti þýtt hvaða hugsanlega stolna forritarareikninga sem er.

 

Óviljandi dreifing spilliforrita hér!

Stöðug dreifing er hámark sjálfvirknivæðingarinnar, en það hámark gæti verið hindrað vegna skorts á viðeigandi samþykkisstýringum á pipeline flæði.

Áhættan við fullkomlega sjálfvirka dreifingu frá uppruna commit í framleiðslukerfum fela í sér möguleikann á að skaðlegur kóði berist inn í framleiðsluumhverfi án þess að vera greindur, sem og möguleikann á að villur í dreifingarferlinu valdi truflunum eða rekstrarleysi.

Til að draga úr þessari áhættu er oft mælt með því að stofnanir innleiði „hörð hlé“ í dreifingarferli sínu, sem krefst þess að mannlegt samþykki áður en útgáfur eru settar upp í lokaumhverfum.

Þeir eru að loka dyrunum

MýrarreiðiÞessi gleðilegu sjálfgefna lykilorð í CI/CD verkfæri eru þurrkuð af. Aðgangur að /var/lib/jenkins/secrets/initialAdminPassword er nú dauð slóð. Mörg verkfæri bjóða nú upp á 2FA, sem Covid gerði vinsælt, og jafnvel latasta kóðaapinn sem til er notar það!

M3M3N70Við erum að berjast gegn 2FA, en það er ekki svo auðvelt. Það er erfitt að nota spjótveiðar á þá gaura, þar sem „Scatter Swine“ gerði með TwilioMeð WebAuthn lyklum er þetta miklu erfiðara. Að minnsta kosti getum við reynt að stela smákökum til að komast framhjá MFA, en þarf að brjótast inn í kassann hjá forritaranum.

Fjölþátta auðkenning er gott skref í rétta átt til að takmarka hættuna á leka auðkenningarleyndarmála. Flest nútíma DevOps verkfæri styðja MFA. Og auðkenningarlyklar undir WebAuthn / U2F (sjá FIDO2 verkefnið) eru kannski besti kosturinn fyrir MFA í DevOps, ef þeim er stjórnað rétt.

MýrarreiðiDevOps-mennirnir eru að vakna. Þeir eru með þetta bölvaða „minnstu forréttindi“ í blóðinu. Og þeir eru ekki lengur forritunarapar. Núna erum við gripin glóðvolg af gagnrýnendum.

Í raun, pipelineeru nú aðeins öflugri en fyrir nokkrum árum, þar sem veikar aðgerðir og forskriftir hafa verið fjarlægðar og með viðbótar öryggisprófunum sem jafnvel greindu dropatækin okkar falin í laumi. commitog pakka sem við rændum.

Spurning til lesandans: Er ferlið við að smíða hugbúnaðinn frá frumkóða og setja hann í framleiðslu áhættusamt? Sérðu fyrir þér DevOps-ferlið þitt á því stigi... góðar stundir fyrir vondu mennina?

Loka tilmæli

Hvar á að byrja með CI/CD pipelines?

Fyrsta ráðleggingin er einföld hér: Gættu þín vandlega endurskoða pipelines (þau eru mikilvægt úrræði) vegna öryggismála. Endurskoðanir eru kostnaðarsamar en nauðsynlegar og ættu að vera gerðar á réttan hátt. Endurskoðendur ættu að vera meðvitaðir um hvað þeir eiga að skoða. Athuga þarf hvert skref fyrir galla.

Kannski gæti samvinna sérfræðinga sem eru vopnaðir sjálfvirkum skaðlegum kóðaskönnum hjálpað.

Önnur ráðleggingin er að þjálfa forritara sem skrifa pipelineog viðhalda þeim í öryggisgæsluAtriði sem þarf að hafa í huga:

• Hvernig á að meðhöndla auðkenningu á réttan hátt með innri og skýjaþjónustu og forðast fyrirhöfnina við að meðhöndla langtímaupplýsingar.
• Hvernig á að takmarka pipelines að nákvæmlega þeim auðlindum sem það þarf aðgang að. Meginreglan um minnstu forréttindi skín aftur.
• Hvernig á að skrifa skrefin til að búa til pipelineendurtakanlegt eins og útgáfufesting og forðast veikleika við skipanainnspýtingu.
• Hvernig á að samþykkja dreifingar frá öryggissjónarmiði (þær eru aðrar!): hvaða öryggismál standards ættu að vera paraðar saman og hvernig á að bæta við samsvarandi eftirliti/hliðum í pipelines.

Þriðja ráðleggingin er að stilla CI/CD kerfi með viðeigandi aðgátSterk auðkenning, engin sjálfgefin lykilorð eða óöruggar stillingar, lágmarksréttindi ... Gættu að öryggisgöllum í viðbótum og viðbótum sem eru uppsettar. Þetta gæti verið áherslan í næstu færslum, vinsamlegast fylgstu með.

Fjórða ráðleggingin er að nýta sér CI/CD pipelines fyrir sjálfvirkni öryggisGreining frumkóða (SAST), greining á upprunasamsetningu (SCA), lekaskannun fyrir leyndarmál, spilliforritatól, öryggisskann fyrir gáma eða sjálfvirkar keyrslutímaskynjarar (DAST og spilliforrit) er hægt að keyra reglulega á pipelineOg fyrirtækið þitt gæti framfylgt standardum umfjöllun um öryggisskönnun í CI/CD.

Hafðu í huga að þessi verkfæri fjarlægja ekki mat sérfræðinga úr jöfnunni, annars gætirðu fengið falska öryggistilfinningu.

Ef þú ert vel að þér í OWASP topp tíu, þá er gott nýlegt verkefni OWASP topp 10 CI/CD Öryggisáhætta.

Fyrirvari

(1) Dæmin í þessari færslu nota GitHub sem SCM, AWS sem skýjaveita og GitHub Actions eða Jenkins sem CI/CD tól. Þau eru ekki veikari/öruggari en aðrir valkostir. Engin slæm áform um fjölmiðla! Þessi tól eru öflug og þarf að nota þau á viðeigandi hátt.

(2) M3M3N70 og  Mýrarreiði eru skáldaðar persónur. Öll líkindi við einstaklinga eða hópa, lifandi eða dauða, eru einungis tilviljun ... eða hvað?

Til að lesa meira

• Haymore, A. o.fl. „10 raunverulegar sögur af því hvernig við höfum gert málamiðlanir“ CI/CD pipelines ”NCC Group, janúar 2022.
• configure-aws-credentials GitHub aðgerð og  Stilla OpenID Connect í Amazon Web Services fyrir nánari upplýsingar um hvernig á að keyra AWS skipanir fyrir dreifingu í GitHub verkflæði.
• Lobacevski J. „Örugg GitHub aðgerða og vinnuflæðis 1. hluti: Að koma í veg fyrir beiðnir um persónulegar færslur“Öryggisrannsóknarstofa GitLab, desember 2020.
• Lobacevski J. „Örugg GitHub aðgerða og vinnuflæðis, 2. hluti: Ótraustir inntaksmöguleikar“Öryggisrannsóknarstofa GitLab, janúar 2021.
• OWASP. „OWASP topp 10“ CI/CD ÖryggisáhættaJúlí 2022.
• Saltzer J. og Schroeder M. „Vernd upplýsinga í tölvukerfum“Apríl 1975. Öryggisreglur þróuðust með tækni, en 47 árum síðar eru flestar hugmyndir um öryggi og öryggismál enn í gildi.
• Breska NCSC. „Tryggja byggingu og dreifingu“ pipeline"Netöryggismiðstöð Bretlands, febrúar 2019.