Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Katika ukurasa huu utaona:
Muhtasari wa athari zote za mshambuliaji kufanikiwa kupata ufikiaji wa Github Action
Njia tofauti za kupata ufikiaji wa hatua:
Kuwa na idhini za kuunda hatua
Kunyanyasa michocheo inayohusiana na ombi la kuvuta
Kunyanyasa mbinu nyingine za ufikiaji wa nje
Pivoting kutoka kwenye repo iliyoshambuliwa tayari
Hatimaye, sehemu kuhusu mbinu za baada ya unyanyasaji ili kunyanyasa hatua kutoka ndani (kusababisha athari zilizotajwa)
Kwa utangulizi kuhusu Github Actions angalia taarifa za msingi.
Ikiwa unaweza kutekeleza msimbo wowote katika GitHub Actions ndani ya repo, unaweza kuwa na uwezo wa:
Kuhujumu siri zilizowekwa kwenye pipeline na kunyanyasa mamlaka ya pipeline kupata ufikiaji usioidhinishwa kwa majukwaa ya nje, kama AWS na GCP.
Kuhujumu matumizi na vitu vingine.
Ikiwa pipeline inapeleka au kuhifadhi mali, unaweza kubadilisha bidhaa ya mwisho, kuwezesha shambulio la mnyororo wa usambazaji.
Tekeleza msimbo katika wafanyakazi maalum ili kunyanyasa nguvu za kompyuta na pivot kwa mifumo mingine.
Futa msimbo wa repo, kulingana na ruhusa zinazohusiana na GITHUB_TOKEN.
Hii "siri" (inayotoka ${{ secrets.GITHUB_TOKEN }} na ${{ github.token }}) inatolewa wakati msimamizi anapowezesha chaguo hili:
Token hii ni sawa na ile Github Application itakayotumia, hivyo inaweza kufikia mwisho sawa: https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps
Github inapaswa kutoa mchakato ambao unaruhusu ufikiaji wa kuvuka-repo ndani ya GitHub, ili repo iweze kufikia repo nyingine za ndani kwa kutumia GITHUB_TOKEN.
Unaweza kuona idhini zinazowezekana za token hii katika: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token
Kumbuka kwamba token inaisha muda baada ya kazi kukamilika.
Token hizi zinaonekana kama hii: ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7
Mambo kadhaa ya kuvutia unaweza kufanya na token hii:
Kumbuka kwamba katika matukio kadhaa utaweza kupata tokens za mtumiaji wa github ndani ya mazingira ya Github Actions au katika siri. Tokens hizi zinaweza kukupa mamlaka zaidi juu ya hifadhi na shirika.
Inawezekana kuangalia ruhusa zilizotolewa kwa Github Token katika hazina za watumiaji wengine kwa kuangalia kumbukumbu za vitendo:
Hii ingekuwa njia rahisi zaidi ya kuathiri vitendo vya Github, 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 Baada ya Utekelezaji.
Katika kesi ambapo wanachama wa shirika wanaweza kuunda hazina mpya na unaweza kutekeleza vitendo vya github, unaweza kuunda hazina mpya na kuiba siri zilizowekwa katika kiwango cha shirika.
Ikiwa unaweza kuunda tawi jipya katika hazina ambayo tayari ina Github Action iliyowekwa, unaweza kubadilisha hiyo, kupakia maudhui, na kisha kutekeleza kitendo hicho kutoka kwa tawi jipya. Kwa njia hii unaweza kuondoa siri za hazina na kiwango cha shirika (lakini unahitaji kujua zinaitwaje).
Unaweza kufanya kitendo kilichobadilishwa kiwe cha kutekelezeka kwa mikono, wakati PR inaundwa au wakati kodi fulani inasukumwa (kulingana na jinsi unavyotaka kuwa na kelele):
Kuna vichocheo tofauti ambavyo vinaweza kumruhusu mshambuliaji kutekeleza Github Action ya hifadhi nyingine. Ikiwa vitendo hivyo vinavyoweza kuchochewa havijakamilika vizuri, mshambuliaji anaweza kuweza kuyaharibu.
pull_requestVichocheo vya kazi pull_request vitatekeleza kazi kila wakati ombi la kuvuta linapopokelewa na baadhi ya visingizio: kwa kawaida ikiwa ni mara ya kwanza unapo shirikiana, baadhi ya wasimamizi watahitaji kuthibitisha kuendesha kazi hiyo:
Kama kikomo cha kawaida ni kwa watoaji wa mara ya kwanza, unaweza kuchangia kurekebisha hitilafu halali/typo na kisha kutuma PR nyingine ili kutumia haki zako mpya za pull_request.
Nilijaribu hii na haifanyi kazi: Chaguo lingine lingekuwa kuunda akaunti kwa jina la mtu ambaye alichangia kwenye mradi na kufuta akaunti yake.
Zaidi ya hayo, kwa kawaida inazuia ruhusa za kuandika na ufikiaji wa siri kwa hifadhi lengwa kama ilivyoelezwa katika docs:
Kwa kuzingatia
GITHUB_TOKEN, siri hazipitishwi kwa mchezaji wakati kazi inachochewa kutoka hifadhi iliyoforked.GITHUB_TOKENina ruhusa za kusoma tu katika ombi la kuvuta kutoka hifadhi zilizoforked.
Mshambuliaji anaweza kubadilisha ufafanuzi wa Github Action ili kutekeleza mambo yasiyo na mipaka na kuongeza vitendo vya kiholela. Hata hivyo, hataweza kuiba siri au kufuta repo kwa sababu ya vikwazo vilivyotajwa.
Ndio, ikiwa mshambuliaji atabadilisha katika PR github action itakayochochewa, Github Action yake itakuwa ndiyo itakayotumika na si ile kutoka hifadhi ya asili!
Kwa kuwa mshambuliaji pia anadhibiti msimbo unaotekelezwa, hata kama hakuna siri au ruhusa za kuandika kwenye GITHUB_TOKEN, mshambuliaji anaweza kwa mfano kupakia vitu vya uharibifu.
pull_request_targetVichocheo vya kazi pull_request_target vina ruhusa za kuandika kwa hifadhi lengwa na ufikiaji wa siri (na havitaki ruhusa).
Kumbuka kwamba vichocheo vya kazi pull_request_target vinakimbia katika muktadha wa msingi na si katika ule unaotolewa 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 maalum angalia hii blogu ya github.
Inaweza kuonekana kwamba kwa sababu kazi inayotekelezwa ni ile iliyofafanuliwa katika msingi na siyo katika PR ni salama kutumia pull_request_target, lakini kuna mifano michache ambapo si salama.
Na hii itakuwa na ufikiaji wa siri.
workflow_runVichocheo vya workflow_run vinaruhusu kuendesha kazi kutoka nyingine wakati inakamilika, inahitajika au inaendelea.
Katika mfano huu, kazi imewekwa ili kuendesha baada ya kazi tofauti "Run Tests" kukamilika:
Moreover, according to the docs: The workflow started by the workflow_run event is able to access secrets and write tokens, even if the previous workflow was not.
This kind of workflow could be attacked if it's depending on a workflow that can be triggered by an external user via pull_request or pull_request_target. A couple of vulnerable examples can be found this blog. The first one consist on the workflow_run triggered workflow downloading out the attackers code: ${{ github.event.pull_request.head.sha }}
The second one consist on passing an artifact from the untrusted code to the workflow_run workflow and using the content of this artifact in a way that makes it vulnerable to RCE.
workflow_callTODO
TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR
We have mentioned all the ways an external attacker could manage to make a github workflow to execute, now let's take a look about how this executions, if bad configured, could be abused:
In the case of pull_request, the workflow is going to be executed in the context of the PR (so it'll execute the malicious PRs code), but someone needs to authorize it first and it will run with some limitations.
In case of a workflow using pull_request_target or workflow_run that depends on a workflow that can be triggered from pull_request_target or pull_request the code from the original repo will be executed, so the attacker cannot control the executed code.
However, if the action has an explicit PR checkout that will get the code from the PR (and not from base), it will use the attackers controlled code. For example (check line 12 where the PR code is downloaded):
The potentially untrusted code is being run during npm install or npm build as the build scripts and referenced packages are controlled by the author of the PR.
A github dork to search for vulnerable actions is: event.pull_request pull_request_target extension:yml however, there are different ways to configure the jobs to be executed securely even if the action is configured insecurely (like using conditionals about who is the actor generating the PR).
Note that there are certain github contexts whose values are controlled by the user creating the PR. If the github action is using that data to execute anything, it could lead to arbitrary code execution:
Gh Actions - Context Script InjectionsFrom the docs: You can make an environment variable available to any subsequent steps in a workflow job by defining or updating the environment variable and writing this to the GITHUB_ENV environment file.
If an attacker could inject any value inside this env variable, he could inject env variables that could execute code in following steps such as LD_PRELOAD or NODE_OPTIONS.
For example (this and this), imagine a workflow that is trusting an uploaded artifact to store its content inside GITHUB_ENV env variable. An attacker could upload something like this to compromise it:
As mentioned in this blog post, this Github Action allows to access artifacts from different workflows and even repositories.
The thing problem is that if the path parameter isn't set, the artifact is extracted in the current directory and it can override files that could be later used or even executed in the workflow. Therefore, if the Artifact is vulnerable, an attacker could abuse this to compromise other workflows trusting the Artifact.
Example of vulnerable workflow:
Hii inaweza kushambuliwa kwa kutumia mchakato huu:
Ikiwa akaunti inabadilisha jina lake, mtumiaji mwingine anaweza kujiandikisha na akaunti yenye jina hilo baada ya muda fulani. Ikiwa hazina ilikuwa na nyota chini ya 100 kabla ya kubadilisha jina, Github itaruhusu mtumiaji mpya aliyejiandikisha kwa jina hilo kuunda hazina yenye jina sawa na ile iliyofutwa.
Hivyo basi, ikiwa hatua inatumia hazina kutoka kwa akaunti isiyokuwepo, bado inawezekana kwamba mshambuliaji anaweza kuunda akaunti hiyo na kuathiri hatua hiyo.
Ikiwa hazina nyingine zilikuwa zikitumika kutegemea kutoka kwa hazina za mtumiaji huyu, mshambuliaji ataweza kuzikamata. Hapa kuna maelezo kamili zaidi: https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/
Katika sehemu hii tutazungumzia mbinu ambazo zitaruhusu kuhamasisha kutoka hazina moja hadi nyingine tukidhani tuna aina fulani ya ufikiaji kwenye ya kwanza (angalia sehemu iliyopita).
Cache inatunzwa kati ya mizunguko ya workflow katika tawi moja. Hii ina maana kwamba ikiwa mshambuliaji ataathiri kifurushi ambacho kisha kinahifadhiwa kwenye cache na kupakuliwa na kutekelezwa na workflow yenye mamlaka zaidi, ataweza pia kuathiri workflow hiyo.
GH Actions - Cache PoisoningWorkflows zinaweza kutumia kazi kutoka kwa workflows nyingine na hata hazina, ikiwa mshambuliaji anafanikiwa kuathiri Github Action inayopakia kazi ambayo baadaye inatumika na workflow nyingine, anaweza kuathiri workflows nyingine:
Gh Actions - Artifact PoisoningAngalia kurasa zifuatazo:
AWS - Federation AbuseGCP - Federation AbuseIkiwa unachoma maudhui kwenye script, ni muhimu kujua jinsi unavyoweza kufikia siri:
Ikiwa siri au token imewekwa kwenye kigezo cha mazingira, inaweza kufikiwa moja kwa moja kupitia mazingira kwa kutumia printenv.
Ikiwa siri inatumika moja kwa moja katika muktadha, skripti ya shell iliyotengenezwa inahifadhiwa kwenye diski na inapatikana.
cat /home/runner/work/_temp/*
Kwa hatua maalum, hatari inaweza kutofautiana kulingana na jinsi programu inavyotumia siri iliyoipata kutoka kwa hoja:
Njia ya kupata ni zipi Github Actions zinazotekelezwa katika miundombinu isiyo ya github ni kutafuta runs-on: self-hosted katika usanidi wa yaml wa Github Action.
Runners zilizojitegemea zinaweza kuwa na ufikiaji wa habari nyeti zaidi, kwa mifumo mingine ya mtandao (nukta dhaifu katika mtandao? huduma ya metadata?) au, hata kama imewekwa kando na kuharibiwa, hatua zaidi ya moja zinaweza kufanywa kwa wakati mmoja na ile mbaya inaweza kuiba siri za nyingine.
Katika runners zilizojitegemea pia inawezekana kupata siri kutoka kwa _Runner.Listener_** mchakato** ambao utakuwa na siri zote za kazi katika hatua yoyote kwa kutupa kumbukumbu yake:
Check this post for more information.
Inawezekana kuunda Github actions ambazo zitajenga na kuhifadhi picha ya Docker ndani ya Github. Mfano unaweza kupatikana katika ifuatayo inayoweza kupanuliwa:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
