Abusing Github Actions
Taarifa za Msingi
Katika ukurasa huu utapata:
Muhtasari wa athari zote za mshambuliaji kufanikiwa kupata ufikiaji wa Github Action
Njia tofauti za kupata ufikiaji wa action:
Kuwa na ruhusa za kuunda action
Kudukua pull request zinazohusiana na triggers
Kudukua njia nyingine za ufikiaji wa nje
Kupivot kutoka kwenye repo iliyokwisha dukuliwa
Hatimaye, sehemu kuhusu mbinu za baada ya shambulio za kudukua action kutoka ndani (kusababisha athari zilizotajwa)
Muhtasari wa Athari
Kwa utangulizi kuhusu Github Actions angalia taarifa za msingi.
Iwapo unaweza kutekeleza Github actions kiholela/kudunga code katika repository, unaweza kuwa na uwezo wa:
Kuiba secrets kutoka kwenye repo/organization hiyo.
Ikiwa unaweza tu kudunga, unaweza kuiba chochote kilichopo tayari kwenye workflow.
Kudukua ruhusa za repo kufikia majukwaa mengine kama AWS na GCP.
Kutekeleza code katika custom workers (ikiwa custom workers zinatumika) na kujaribu kupivot kutoka hapo.
Kufuta code ya repository.
Hii inategemea ruhusa za
GITHUB_TOKEN
(ikiwa ipo).Kudukua deployments na artifacts nyingine.
Ikiwa code inafanya deployment au kuhifadhi kitu unaweza kubadilisha hicho na kupata ufikiaji zaidi.
GITHUB_TOKEN
Hii "secret" (inayotoka ${{ secrets.GITHUB_TOKEN }}
na ${{ github.token }}
) inatolewa wakati admin anapowasha chaguo hili:
Token hii ni sawa na ile ambayo Github Application itatumia, hivyo inaweza kufikia endpoints sawa: https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps
Github inapaswa kutoa flow ambayo inaruhusu ufikiaji wa cross-repository ndani ya GitHub, hivyo repo inaweza kufikia repos nyingine za ndani kwa kutumia GITHUB_TOKEN
.
Unaweza kuona ruhusa zinazowezekana za token hii katika: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token
Kumbuka kuwa token inaisha muda baada ya kazi kukamilika.
Token hizi zinaonekana kama hii: ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7
Baadhi ya mambo ya kuvutia unayoweza kufanya na token hii:
Kumbuka kwamba katika matukio kadhaa utaweza kupata github user tokens ndani ya Github Actions envs au kwenye secrets. Tokens hizi zinaweza kukupa haki zaidi juu ya hazina na shirika.
Inawezekana kuangalia ruhusa zilizotolewa kwa Github Token katika hazina za watumiaji wengine kwa kuangalia magogo ya vitendo:
Utekelezaji Ulioruhusiwa
Hii itakuwa njia rahisi zaidi ya kuathiri Github actions, kwani kesi hii inadhani kuwa una ufikiaji wa kuunda hazina mpya katika shirika, au una haki za kuandika juu ya hazina.
Ikiwa uko katika hali hii unaweza tu kuangalia Mbinu za Post Exploitation.
Utekelezaji kutoka kwa Uundaji wa Hazina
Iwapo wanachama wa shirika wanaweza kuunda hazina mpya na unaweza kutekeleza github actions, unaweza kuunda hazina mpya na kuiba siri zilizowekwa katika kiwango cha shirika.
Utekelezaji kutoka kwa Tawi Jipya
Ikiwa unaweza kuunda tawi jipya katika hazina ambayo tayari ina Github Action iliyosanidiwa, unaweza kubadilisha hiyo, kupakia yaliyomo, na kisha kutekeleza hiyo action kutoka kwa tawi jipya. Kwa njia hii unaweza kutoa siri za hazina na shirika (lakini unahitaji kujua jinsi zinavyoitwa).
Unaweza kufanya action iliyobadilishwa iweze kutekelezeka kwa mikono, wakati PR inaundwa au wakati msimbo fulani unasukumwa (kulingana na jinsi unavyotaka kuwa na kelele):
Utekelezaji wa Forked
Kuna vichochezi tofauti ambavyo vinaweza kumruhusu mshambulizi kutekeleza Github Action ya hazina nyingine. Ikiwa vitendo hivyo vinavyoweza kuchochewa vimewekwa vibaya, mshambulizi anaweza kuweza kuvihujumu.
pull_request
pull_request
Kichochezi cha kazi pull_request
kitatekeleza kazi kila wakati ombi la kuvuta linapopokelewa na baadhi ya ubaguzi: kwa chaguo-msingi ikiwa ni mara ya kwanza unashirikiana, baadhi ya mwenye hazina atahitaji kuidhinisha utekelezaji wa kazi:
Kama kizuizi cha chaguo-msingi ni kwa wachangiaji wa mara ya kwanza, unaweza kuchangia kurekebisha hitilafu/typo halali na kisha kutuma PR nyingine ili kutumia vibaya haki zako mpya za pull_request
.
Nilijaribu hii na haifanyi kazi: Chaguo jingine litakuwa kuunda akaunti kwa jina la mtu aliyetoa mchango kwa mradi na kufuta akaunti yake.
Zaidi ya hayo, kwa chaguo-msingi huzuia ruhusa za kuandika na ufikiaji wa siri kwa hazina lengwa kama ilivyoelezwa katika docs:
Isipokuwa
GITHUB_TOKEN
, siri hazipitishwi kwa runner wakati kazi inachochewa kutoka kwa hazina ya forked.GITHUB_TOKEN
ina ruhusa za kusoma tu katika maombi ya kuvuta kutoka kwa hazina za forked.
Mshambulizi anaweza kubadilisha ufafanuzi wa Github Action ili kutekeleza mambo ya kiholela na kuongeza vitendo vya kiholela. Hata hivyo, hatakuwa na uwezo wa kuiba siri au kuandika upya hazina kwa sababu ya vikwazo vilivyotajwa.
Ndiyo, ikiwa mshambulizi atabadilisha katika PR github action ambayo itachochewa, Github Action yake ndiyo itakayotumika na siyo ile ya hazina asili!
Kwa kuwa mshambulizi pia anadhibiti msimbo unaotekelezwa, hata kama hakuna siri au ruhusa za kuandika kwenye GITHUB_TOKEN
mshambulizi anaweza kwa mfano kupakia artifacts zenye nia mbaya.
pull_request_target
pull_request_target
Kichochezi cha kazi pull_request_target
kina ruhusa za kuandika kwa hazina lengwa na ufikiaji wa siri (na haiombi ruhusa).
Kumbuka kwamba kichochezi cha kazi pull_request_target
kinaendeshwa katika muktadha wa msingi na siyo katika ule uliotolewa na PR (ili kutoendesha msimbo usioaminika). Kwa maelezo zaidi kuhusu pull_request_target
angalia docs.
Zaidi ya hayo, kwa maelezo zaidi kuhusu matumizi haya hatari angalia blogu ya github.
Inaweza kuonekana kama kwa sababu kazi inayotekelezwa ni ile iliyofafanuliwa katika msingi na siyo katika PR ni salama kutumia pull_request_target
, lakini kuna matukio machache ambapo siyo salama.
Na hii itakuwa na ufikiaji wa siri.
workflow_run
workflow_run
Kichochezi cha workflow_run huruhusu kuendesha kazi kutoka kwa nyingine wakati imekamilika, imeombwa au inaendelea.
Katika mfano huu, kazi imewekwa ili kuendeshwa baada ya kazi tofauti ya "Run Tests" kukamilika:
Zaidi ya hayo, kulingana na nyaraka: Mchakato ulioanzishwa na tukio la workflow_run
unaweza kupata siri na kuandika tokeni, hata kama mchakato wa awali haukuwa.
Aina hii ya mchakato inaweza kushambuliwa ikiwa inategemea mchakato ambao unaweza kuanzishwa na mtumiaji wa nje kupitia pull_request
au pull_request_target
. Mifano michache ya hatari inaweza kupatikana katika blogu hii. Ya kwanza inahusisha mchakato wa workflow_run
unaoanzishwa kupakua nje msimbo wa mshambuliaji: ${{ github.event.pull_request.head.sha }}
Ya pili inahusisha kupitisha artifact kutoka kwa msimbo usioaminika kwenda kwa mchakato wa workflow_run
na kutumia maudhui ya artifact hii kwa njia inayofanya iwe hatari kwa RCE.
workflow_call
workflow_call
TODO
TODO: Angalia kama inatekelezwa kutoka kwa pull_request msimbo unaotumika/kupakuliwa ni ule kutoka asili au kutoka kwa PR iliyoforkiwa
Kudhalilisha Utekelezaji wa Forked
Tumetaja njia zote ambazo mshambuliaji wa nje anaweza kudhibiti kufanya mchakato wa github utekelezwe, sasa tuangalie jinsi utekelezaji huu, ikiwa umewekwa vibaya, unaweza kudhalilishwa:
Utekelezaji wa checkout usioaminika
Katika kesi ya pull_request
, mchakato utaendeshwa katika muktadha wa PR (kwa hivyo utaendesha msimbo wa PR mbaya), lakini mtu anahitaji kuidhinisha kwanza na utaendeshwa na baadhi ya vikwazo.
Katika kesi ya mchakato unaotumia pull_request_target
au workflow_run
ambao unategemea mchakato ambao unaweza kuanzishwa kutoka pull_request_target
au pull_request
msimbo kutoka repo asili utaendeshwa, kwa hivyo mshambuliaji hawezi kudhibiti msimbo unaotekelezwa.
Hata hivyo, ikiwa action ina checkout ya PR wazi ambayo itapata msimbo kutoka PR (na si kutoka msingi), itatumia msimbo unaodhibitiwa na mshambuliaji. Kwa mfano (angalia mstari wa 12 ambapo msimbo wa PR unapakuliwa):
Msimbo ambao unaweza kuwa hauna uaminifu unatekelezwa wakati wa npm install
au npm build
kwani maandiko ya ujenzi na vifurushi vilivyorejelewa vinadhibitiwa na mwandishi wa PR.
Dork ya github ya kutafuta actions hatarishi ni: event.pull_request pull_request_target extension:yml
hata hivyo, kuna njia tofauti za kusanidi kazi ili zitekelezwe kwa usalama hata kama action imewekwa kwa usalama duni (kama kutumia masharti kuhusu nani ni mwigizaji anayezalisha PR).
Sindano za Maandishi ya Muktadha
Kumbuka kuwa kuna baadhi ya muktadha wa github ambao thamani zake zinadhibitiwa na mtumiaji anayezalisha PR. Ikiwa action ya github inatumia data hiyo kutekeleza chochote, inaweza kusababisha utekelezaji wa msimbo holela:
Gh Actions - Context Script InjectionsSindano ya Maandishi ya GITHUB_ENV
Kutoka kwa nyaraka: Unaweza kufanya kigezo cha mazingira kipatikane kwa hatua zozote zinazofuata katika kazi ya mchakato kwa kufafanua au kusasisha kigezo cha mazingira na kuandika hii kwenye faili ya mazingira ya GITHUB_ENV
.
Ikiwa mshambuliaji anaweza kuingiza thamani yoyote ndani ya kigezo hiki cha env, anaweza kuingiza vigezo vya env ambavyo vinaweza kutekeleza msimbo katika hatua zinazofuata kama LD_PRELOAD au NODE_OPTIONS.
Kwa mfano (hii na hii), fikiria mchakato unaoamini artifact iliyopakiwa kuhifadhi maudhui yake ndani ya kigezo cha env cha GITHUB_ENV
. Mshambuliaji anaweza kupakia kitu kama hiki ili kuathiri:
Hatari za Tatu za Github Actions
Kama ilivyotajwa katika blogu hii, Github Action hii inaruhusu kupata artifacts kutoka kwa michakato tofauti na hata repos tofauti.
Tatizo ni kwamba ikiwa kigezo cha path
hakijasetwa, artifact inatolewa katika saraka ya sasa na inaweza kuandika upya faili ambazo zinaweza kutumika baadaye au hata kutekelezwa katika mchakato. Kwa hivyo, ikiwa Artifact ni hatarishi, mshambuliaji anaweza kutumia hii kudhalilisha michakato mingine inayotegemea Artifact.
Mfano wa mchakato hatarishi:
Hii inaweza kushambuliwa na mtiririko huu wa kazi:
Ufikiaji wa Nje Mwingine
Utekaji wa Repo ya Namespace Iliyofutwa
Ikiwa akaunti inabadilisha jina lake, mtumiaji mwingine anaweza kusajili akaunti na jina hilo baada ya muda fulani. Ikiwa hazina ilikuwa na nyota chini ya 100 kabla ya kubadilisha jina, Github itaruhusu mtumiaji mpya aliyesajiliwa na jina hilo hilo kuunda hazina na jina hilo hilo kama ile iliyofutwa.
Kwa hivyo ikiwa kitendo kinatumia hazina kutoka kwa akaunti isiyokuwepo, bado inawezekana kwamba mshambulizi anaweza kuunda akaunti hiyo na kuhatarisha kitendo hicho.
Ikiwa hazina zingine zilikuwa zinatumia vifaa tegemezi kutoka kwa hazina za mtumiaji huyu, mshambulizi ataweza kuziteka. Hapa kuna maelezo kamili zaidi: https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/
Uhamishaji wa Repo
Katika sehemu hii tutazungumzia mbinu ambazo zitaruhusu kuhamisha kutoka hazina moja kwenda nyingine tukidhani tuna aina fulani ya ufikiaji kwenye ya kwanza (angalia sehemu iliyopita).
Uchafuzi wa Cache
Cache inahifadhiwa kati ya mizunguko ya kazi katika tawi moja. Hii inamaanisha kwamba ikiwa mshambulizi atahatarisha kifurushi ambacho kisha kinahifadhiwa kwenye cache na kupakuliwa na kutekelezwa na mzunguko wa kazi wenye ruhusa zaidi, ataweza pia kuhatarisha mzunguko huo wa kazi.
GH Actions - Cache PoisoningUchafuzi wa Vifaa
Mizunguko ya kazi inaweza kutumia vifaa kutoka kwa mizunguko mingine na hata hazina nyingine, ikiwa mshambulizi ataweza kuhatarisha Github Action inayopakia kifaa ambacho baadaye kinatumika na mzunguko mwingine wa kazi, ataweza kuhatarisha mizunguko mingine ya kazi:
Gh Actions - Artifact PoisoningUtekelezaji Baada ya Shambulio kutoka kwa Kitendo
Kufikia AWS na GCP kupitia OIDC
Angalia kurasa zifuatazo:
AWS - Federation AbuseGCP - Federation AbuseKufikia siri
Ikiwa unaingiza maudhui kwenye script, ni muhimu kujua jinsi unavyoweza kufikia siri:
Ikiwa siri au token imewekwa kwenye variable ya mazingira, inaweza kufikiwa moja kwa moja kupitia mazingira kwa kutumia
printenv
.
Ikiwa siri inatumika moja kwa moja katika usemi, script ya shell inayozalishwa huhifadhiwa kwenye diski na inapatikana.
cat /home/runner/work/_temp/*
Kwa custom action, hatari inaweza kutofautiana kulingana na jinsi programu inavyotumia siri iliyopatikana kutoka kwa argument:
Kudhoofisha Self-hosted runners
Njia ya kupata ni Github Actions zinazotekelezwa katika miundombinu isiyo ya github ni kutafuta runs-on: self-hosted
katika Github Action configuration yaml.
Self-hosted runners wanaweza kuwa na ufikiaji wa taarifa nyeti za ziada, kwa mfumo mingine ya mtandao (vituo vya mwisho vilivyo hatarini kwenye mtandao? huduma ya metadata?) au, hata kama imejitenga na kuharibiwa, zaidi ya action moja inaweza kuendeshwa kwa wakati mmoja na ile yenye nia mbaya inaweza kuiba siri za nyingine.
Katika self-hosted runners pia inawezekana kupata siri kutoka kwa _Runner.Listener_** mchakato** ambao utakuwa na siri zote za workflows katika hatua yoyote kwa kudondosha kumbukumbu yake:
Angalia chapisho hili kwa maelezo zaidi.
Github Docker Images Registry
Inawezekana kutengeneza Github actions ambazo zita jenga na kuhifadhi picha ya Docker ndani ya Github. Mfano unaweza kupatikana katika sehemu inayopanuka ifuatayo:
Last updated