gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-25 20:34:33 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/azure-security/az-post-exploitatio

Browse Source
This commit is contained in:
Translator
2025-09-29 22:42:45 +00:00
parent d9f1c1f7a1
commit f7f3b8798d
6 changed files with 325 additions and 329 deletions
Download Patch File Download Diff File Expand all files Collapse all files

210
src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
View File

@@ -1,58 +1,58 @@
# Abusing Github Actions
# Github Actions का दुरुपयोग
{{#include ../../../banners/hacktricks-training.md}}
## टूल्स
## Tools
The following tools are useful to find Github Action workflows and even find vulnerable ones:
निम्नलिखित उपकरण Github Action workflows खोजने और यहाँ तक कि संभावित 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) - Check also its checklist in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - इसकी checklist भी देखें: [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
## मूल जानकारी
## Basic Information
इस पृष्ठ में आप पाएँगे:
- किसी attacker द्वारा Github Action तक पहुँचने पर होने वाले **सभी प्रभावों का सारांश**
- एक action तक पहुँचने के विभिन्न तरीके:
- action बनाने की **permissions** होना
- **pull request** संबंधित triggers का दुरुपयोग
- अन्य **external access** तकनीकों का दुरुपयोग
- पहले से compromised repo से **Pivoting**
- अंत में, action के अंदर से दुरुपयोग करने के लिए **post-exploitation techniques** के बारे में एक सेक्शन (जो ऊपर बताए गए प्रभावों का कारण बनते हैं)
- एक **सभी प्रभावों का सारांश** जब कोई attacker Github Action तक access प्राप्त कर ले
- किसी action तक **access प्राप्त करने** के विभिन्न तरीके:
- Action बनाने के लिए **permissions** होना
- **pull request** से जुड़े triggers का दुरुपयोग
- अन्य **external access** तकनीकों का दुरुपयोग
- पहले से compromised repo से **Pivoting**
- अंत में, एक सेक्शन **post-exploitation techniques** के बारे में ताकि action के अंदर से उसे abuse किया जा सके (और बताए गए प्रभाव उत्पन्न हों)
## प्रभावों का सारांश
## Impacts Summary
For an introduction about [**Github Actions check the basic information**](../basic-github-information.md#github-actions).
Github Actions के परिचय के लिए [**basic information देखें**](../basic-github-information.md#github-actions).
If you can **execute arbitrary code in GitHub Actions** within a **repository**, you may be able to:
यदि आप किसी **repository** के भीतर GitHub Actions में arbitrary code execute कर सकते हैं, तो आप संभवतः निम्न कर पाएँगे:
- 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 कर सकते हैं।
- **Steal secrets** mounted to the pipeline और external platforms (जैसे AWS और GCP) में unauthorized access पाने के लिए pipeline की **abuse the pipeline's privileges** कर सकते हैं।
- **Compromise deployments** और अन्य **artifacts**।
- यदि pipeline assets को deploy या store करता है, तो आप final product को बदल सकते हैं, जिससे supply chain attack संभव हो सकता है।
- **Execute code in custom workers** करके computing power का दुरुपयोग कर सकते हैं और अन्य systems की ओर pivot कर सकते हैं।
- `GITHUB_TOKEN` से जुड़ी permissions पर निर्भर करते हुए, आप **Overwrite repository code** भी कर सकते हैं।
## GITHUB_TOKEN
This "**secret**" (coming from `${{ secrets.GITHUB_TOKEN }}` and `${{ github.token }}`) is given when the admin enables this option:
यह "**secret**" (जो `${{ secrets.GITHUB_TOKEN }}` और `${{ github.token }}` से आता है) तब दिया जाता है जब admin इस option को enable करता है:
<figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
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)
यह token वही है जिसका उपयोग एक **Github Application** करेगा, इसलिए यह वही endpoints access कर सकता है: [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 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`.
> Github को एक [**flow**](https://github.com/github/roadmap/issues/74) जारी करना चाहिए जो GitHub के भीतर **cross-repository** access की अनुमति दे, ताकि एक repo अन्य internal repos को `GITHUB_TOKEN` का उपयोग करके access कर सके।
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)
आप इस token की संभावित **permissions** यहाँ देख सकते हैं: [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)
Note that the token **expires after the job has completed**.\
These tokens looks like this: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
ध्यान दें कि यह token **job पूरा होने के बाद expire हो जाता है**.\
ये tokens इस तरह दिखते हैं: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
Some interesting things you can do with this token:
कुछ रोचक चीज़ें जो आप इस token से कर सकते हैं:
{{#tabs }}
{{#tab name="Merge PR" }}
@@ -95,7 +95,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
<details>
<summary>Github Action output में secrets सूचीबद्ध करें</summary>
<summary>Github Action output में secrets की सूची</summary>
```yaml
name: list_env
on:
@@ -144,29 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
```
</details>
It's possible to check the permissions given to a Github Token in other users repositories **checking the logs** of the actions:
यह संभव है कि आप अन्य उपयोगकर्ताओं के रिपॉजिटरी में Github Token को दी गई permissions की जाँच कर सकें **checking the logs** of the actions:
<figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
## अनुमत निष्पादन
> [!NOTE]
> 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**.
> यह Github actions को compromise करने का सबसे आसान तरीका होगा, क्योंकि इस केस में माना गया है कि आपके पास **create a new repo in the organization** करने की पहुँच है, या किसी रिपॉजिटरी पर **write privileges over a repository** हैं।
>
> यदि आप इस परिदृश्य में हैं तो आप बस [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) देख सकते हैं।
### Repo Creation से निष्पादन
### Execution from Repo Creation
यदि किसी संगठन के सदस्य **create new repos** कर सकते हैं और आप github actions चला सकते हैं, तो आप **create a new repo and steal the secrets set at organization level** कर सकते हैं।
यदि किसी organization के सदस्य **create new repos** कर सकते हैं और आप github actions execute कर सकते हैं, तो आप **create a new repo and steal the secrets set at organization level** कर सकते हैं।
### New Branch से निष्पादन
### Execution from a New Branch
यदि आप किसी 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** कर सकते हैं (लेकिन आपको पता होना चाहिए कि उन्हें क्या कहा जाता है)।
यदि आप किसी repository में **create a new branch in a repository that already contains a Github Action** configured कर सकते हैं, तो आप इसे **modify** कर सकते हैं, content **upload** कर सकते हैं, और फिर **execute that action from the new branch** कर सकते हैं। इस तरह आप **exfiltrate repository and organization level secrets** कर सकते हैं (लेकिन आपको पता होना चाहिए कि उन्हें क्या नाम दिया गया है)।
> [!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.
> यदि कोई restriction केवल workflow YAML के भीतर लागू की गई है (उदाहरण के लिए, `on: push: branches: [main]`, job conditionals, or manual gates) तो collaborators उसे edit कर सकते हैं। बाहरी प्रवर्तन (branch protections, protected environments, and protected tags) के बिना, एक contributor किसी workflow को उनके branch पर चलाने के लिए retarget कर सकता है और mounted secrets/permissions का दुरुपयोग कर सकता है।
आप संशोधित action को **manually,** जब **PR is created** या जब **some code is pushed** के समय executable बना सकते हैं (निर्भर करता है कि आप कितना noisy होना चाहते हैं):
आप modified action को **manually,** जब एक **PR is created** या जब **some code is pushed** (यह निर्भर करता है कि आप कितना noisy होना चाहते हैं) executable बना सकते हैं:
```yaml
on:
workflow_dispatch: # Launch manually
@@ -180,47 +180,47 @@ branches:
```
---
## Forked निष्पादन
## Forked Execution
> [!NOTE]
> अलग-अलग ट्रिगर्स हैं जो एक attacker को **किसी अन्य रिपॉज़िटरी के Github Action को execute** करने की अनुमति दे सकते हैं। अगर उन triggerable actions को ठीक से configured नहीं किया गया है, तो एक attacker उन्हें compromise कर सकता है।
> विभिन्न triggers हैं जो एक हमलावर को **execute a Github Action of another repository** करने की अनुमति दे सकते हैं। यदि उन triggerable actions का configuration खराब है, तो हमलावर उन्हें compromise कर सकता है।
### `pull_request`
The workflow trigger **`pull_request`** हर बार workflow को execute करेगा जब एक pull request प्राप्त होता है, कुछ exceptions के साथ: डिफ़ॉल्ट रूप से अगर यह आपकी **पहली बार** collaboration है, तो किसी **maintainer** को workflow के **run** को **approve** करना होगा:
The workflow trigger **`pull_request`** वर्कफ़्लो को हर बार execute करेगा जब भी एक pull request प्राप्त होगा, कुछ अपवादों के साथ: डिफ़ॉल्ट रूप से अगर यह आपकी **first time** **collaborating** है, तो किसी **maintainer** को workflow के **run** को **approve** करना होगा:
<figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
> [!NOTE]
> चूंकि यह **default limitation** **first-time** contributors के लिए है, आप एक वैध bug/typo fix करके contribute कर सकते हैं और फिर अपने नए `pull_request` privileges का दुरुपयोग करने के लिए **other PRs** भेज सकते हैं।
> चूँकि यह **default limitation** पहली बार योगदान करने वालों पर लागू होती है, आप एक वैध **fixing a valid bug/typo** का योगदान करके फिर अपने नए `pull_request` privileges का दुरुपयोग करने के लिए अन्य PR भेज सकते हैं।
>
> **मैंने इसे टेस्ट किया और यह काम नहीं करता**: ~~एक और विकल्प यह होगा कि उस व्यक्ति के नाम से एक account बनाया जाए जिसने प्रोजेक्ट में योगदान दिया था और फिर उसने अपना account delete कर दिया था।~~
> **मैंने इसे टेस्ट किया और यह काम नहीं करता**: ~~एक और विकल्प यह होगा कि किसी ऐसे व्यक्ति के नाम से एक account बनाया जाए जिसने परियोजना में योगदान दिया था और फिर उसने अपना account हटा दिया।~~
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):
इसके अलावा, डिफ़ॉल्ट रूप से यह target repository को **prevents write permissions** और **secrets access** नहीं देता जैसा कि [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories) में उल्लेख है:
> 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**.
एक attacker Github Action की definition को modify करके arbitrary चीज़ें execute करने और arbitrary actions जोड़ने की कोशिश कर सकता है। हालांकि, उपरोक्त सीमाओं के कारण वह secrets चोरी नहीं कर पाएगा और repo को overwrite नहीं कर पाएगा।
एक हमलावर Github Action की definition को बदल सकता है ताकि arbitrary चीज़ें execute की जा सकें और arbitrary actions जोड़ी जा सकें। हालांकि, बताए गए सीमाओं के कारण वह secrets चुरा नहीं पाएगा या repo को overwrite नहीं कर पाएगा।
> [!CAUTION]
> **हाँ, अगर attacker ने PR में उस github action को बदल दिया है जो trigger होगा, तो उसका Github Action ही उपयोग किया जाएगा न कि origin repo का!**
> **हाँ, अगर हमलावर PR में उस github action को बदल देता है जो trigger होगा, तो उसका Github Action ही उपयोग होगा न कि origin repo का!**
क्योंकि attacker उस code को भी control करता है जो execute हो रहा है, भले ही `GITHUB_TOKEN` पर secrets या write permissions न हों, attacker उदाहरण के लिए **upload malicious artifacts** कर सकता है।
चूंकि हमलावर उस code को भी नियंत्रित करता है जो execute किया जा रहा है, भले ही `GITHUB_TOKEN` पर secrets या write permissions न हों, हमलावर उदाहरण के लिए **upload malicious artifacts** कर सकता है।
### **`pull_request_target`**
The workflow trigger **`pull_request_target`** को target repository पर **write permission** और **access to secrets** मिलता है (और यह permission नहीं मांगता)।
The workflow trigger **`pull_request_target`** को target repository पर **write permission** और **access to secrets** मिलता है (और यह permission के लिए पूछता नहीं है)।
ध्यान दें कि 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/).
ध्यान दें कि workflow trigger **`pull_request_target`** **base context** में चलता है और PR द्वारा दिए गए context में नहीं (ताकि **not execute untrusted code**)। `pull_request_target` के बारे में अधिक जानकारी के लिए [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target) देखें।\
इसके अलावा, इस विशिष्ट खतरनाक उपयोग के बारे में और जानकारी के लिए यह [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/) देखें।
यह ऐसा लग सकता है कि क्योंकि **executed workflow** वही है जो **base** में defined है और **PR** में नहीं, इसलिए **`pull_request_target`** का उपयोग सुरक्षित है, पर कुछ मामले ऐसे हैं जहाँ यह सुरक्षित नहीं होता।
यह ऐसा लग सकता है कि क्योंकि **executed workflow** वही है जो **base** में परिभाषित है और **not in the PR**, इसलिए **`pull_request_target`** का उपयोग करना **secure** है, पर कुछ मामलों में ऐसा नहीं होता।
और इस एक को **secrets** तक **access** होगा।
और यह **access to secrets** प्राप्त कर सकेगा।
### `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` हो।
The [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger एक workflow को किसी अन्य workflow द्वारा तब चलाने की अनुमति देता है जब वह `completed`, `requested` या `in_progress` हो।
In this example, a workflow is configured to run after the separate "Run Tests" workflow completes:
```yaml
@@ -232,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**.
इस तरह के 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 पर तब हमला किया जा सकता है जब यह किसी ऐसे **workflow** पर निर्भर हो जो किसी external user द्वारा **`pull_request`** या **`pull_request_target`** के ज़रिए **trigger** किया जा सकता है। कुछ vulnerable उदाहरण [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** पहला उदाहरण उस **`workflow_run`** triggered workflow का है जो attacker के code को डाउनलोड कर लेता है: `${{ github.event.pull_request.head.sha }}`\
दूसरा उदाहरण उस स्थिति का है जहाँ untrusted code से एक **artifact** को **`workflow_run`** workflow में पास किया जाता है और उस artifact की content को इस तरह इस्तेमाल किया जाता है कि वह **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
हमने उन सभी तरीकों का ज़िक्र किया है जिनसे एक बाहरी attacker किसी github workflow को execute करने में कामयाब हो सकता है, अब आइए देखें कि ये executions, अगर गलत तरीके से configured हों, तो किस तरह दुरुपयोग किए जा सकते हैं:
हमने उन सभी तरीकों का ज़िक् किया है जिनसे एक external attacker किसी GitHub workflow को execute करवाने में कामयाब हो सकता है, अब देखते हैं कि ये executions, अगर गलत कॉन्फ़िगर किए गए हों, तो कैसे दुरुपयोग किए जा सकते हैं:
### Untrusted checkout execution
@@ -299,7 +299,7 @@ gh-actions-context-script-injections.md
From the docs: You can make an **environment variable available to any subsequent steps** in a workflow job by defining or updating the environment variable and writing this to the **`GITHUB_ENV`** environment file.
If an attacker could **inject any value** inside this **env** variable, he could inject env variables that could execute code in following steps such as **LD_PRELOAD** or **NODE_OPTIONS**.
यदि कोई attacker इस **env** variable के अंदर कोई भी value **inject** कर सके, तो वह ऐसे env variables inject कर सकता है जो आगे के steps में code execute करवा सकते हैं, जैसे **LD_PRELOAD** या **NODE_OPTIONS**।
For example ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) and [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), imagine a workflow that is trusting an uploaded artifact to store its content inside **`GITHUB_ENV`** env variable. An attacker could upload something like this to compromise it:
@@ -317,18 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
steps:
- run: gh pr merge $ -d -m
```
Which is a problem because the `github.actor` field contains the user who caused the latest event that triggered the workflow. -> यह समस्या है क्योंकि `github.actor` फ़ील्ड उस उपयोगकर्ता को दर्शाता है जिसने workflow को ट्रिगर करने वाला नवीनतम इवेंट उत्पन्न किया।
Which is a problem because the `github.actor` field contains the user who caused the latest event that triggered the workflow. And There are several ways to make the `dependabot[bot]` user to modify a PR. For example:
And There are several ways to make the `dependabot[bot]` user to modify a PR. For example: -> और `dependabot[bot]` user को PR modify करने के कई तरीके हैं। उदाहरण के लिए:
- 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)
- पीड़ित repository को fork करें
- अपने कॉपी में malicious payload जोड़ें
- अपने fork पर Dependabot सक्षम करें और एक outdated dependency जोड़ें। Dependabot उस dependency को ठीक करने के लिए एक branch बनाएगा जिसमें malicious code होगा।
- उस branch से पीड़ित रिपॉज़िटरी पर एक Pull Request खोलें (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 हो:
Moving on, what if instead of merging the Github Action would have a command injection like in:
```yaml
on: pull_request_target
jobs:
@@ -338,24 +336,24 @@ if: ${ { github.actor == 'dependabot[bot]' }}
steps:
- run: echo ${ { github.event.pull_request.head.ref }}
```
ठीक है, मूल ब्लॉगपोस्ट इस व्यवहार का दुरुपयोग करने के लिए दो विकल्प प्रस्तावित करती है, जिनमें से दूसरा है:
Well, the original blogpost proposes two options to abuse this behavior being the second one:
- Fork the victim repository और Dependabot को किसी outdated dependency के साथ enable करें।
- Victim repository को fork करें और किसी outdated dependency के साथ Dependabot सक्षम करें।
- एक नया branch बनाएं जिसमें malicious shell injection code हो।
- repo का default branch उस branch में बदल दें
- 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 का उपयोग करेगा।
- PR में जो Dependabot ने उसके fork में खोला है, वहां `@dependabot merge` चलाएं।
- Dependabot उसके forked repository के default branch में उनके changes को merge कर देगा, victim repository में PR को अपडेट करेगा, जिससे अब `dependabot[bot]` उस latest event का actor होगा जिसने workflow को trigger किया और malicious branch name का उपयोग किया जा रहा होगा।
### कमज़ोर तृतीय-पक्ष Github Actions
### Vulnerable Third Party Github Actions
#### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
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.
जैसा कि [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) में बताया गया है, यह Github Action अलग-अलग workflows और यहाँ तक कि अन्य repositories से artifacts तक access करने की अनुमति देता है।
समस्या यह है कि अगर **`path`** parameter सेट नहीं है, तो artifact वर्तमान directory में extract हो जाता है और यह उन फ़ाइलों को overwrite कर सकता है जिन्हें बाद में workflow में इस्तेमाल या execute किया जा सकता है। इसलिए, अगर Artifact vulnerable है, तो attacker इसका दुरुपयोग करके उस Artifact पर भरोसा करने वाले अन्य workflows को compromise कर सकता है।
समस्या यह है कि अगर **`path`** parameter सेट नहीं है, तो artifact वर्तमान directory में extract हो जाता है और यह उन फ़ाइलों को override कर सकता है जिन्हें बाद में workflow में उपयोग या execute किया जा सकता है। इसलिए, अगर Artifact vulnerable है, तो एक attacker इसका दुरुपयोग कर के उन अन्य workflows को compromise कर सकता है जो उस Artifact पर भरोसा करते हैं।
कमज़ोर workflow का उदाहरण:
Example of vulnerable workflow:
```yaml
on:
workflow_run:
@@ -378,7 +376,7 @@ with:
name: artifact
path: ./script.py
```
इसे इस workflow के साथ हमला किया जा सकता है:
इसे इस workflow से हमला किया जा सकता है:
```yaml
name: "some workflow"
on: pull_request
@@ -395,27 +393,27 @@ path: ./script.py
```
---
## Other External Access
## अन्य External Access
### Deleted Namespace Repo Hijacking
अगर कोई account अपना नाम बदलता है तो कुछ समय बाद कोई और user उसी नाम के साथ account register कर सकता है। अगर किसी repository के पास नाम बदलने से पहले **100 से कम stars** थे, तो Github नए registered user को वही नाम देकर हटाए गए repository के समान **repository with the same name** बनाने की अनुमति देगा।
अगर किसी account ने अपना नाम बदल दिया है तो कुछ समय बाद कोई अन्य user उसी नाम के साथ एक account रजिस्टर कर सकता है। अगर किसी repository के पास नाम बदलने से पहले **less than 100 stars previously to the change of nam**e थे, Github नए रजिस्टर किए गए user को उसी नाम से वही **repository with the same name** बनाने की अनुमति दे देगा जो हटाई गई थी।
> [!CAUTION]
> इसलिए यदि कोई action किसी non-existent account के repo का उपयोग कर रहा है, तो यह अभी भी संभव है कि एक attacker वह account बना ले और action को compromise कर दे।
> तो अगर कोई action किसी non-existent account के repo का उपयोग कर रहा है, तो attacker उस account को बना कर action को compromise कर सकता है।
यदि अन्य 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/)
अगर अन्य repositories इस user के repos से **dependencies from this user repos** इस्तेमाल कर रहे थे, तो attacker उन्हें hijack कर पाएगा। यहाँ एक अधिक विस्तृत व्याख्या है: [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** करने की अनुमति देंगी (पिछले सेक्शन को देखें)।
> इस सेक्शन में हम उन techniques के बारे में बात करेंगे जो हमें यह अनुमति देंगी कि हम **pivot from one repo to another** — मान लेते हैं कि हमारे पास पहले repo पर कुछ तरह की access है (पिछले सेक्शन देखें)।
### Cache Poisoning
एक cache उसी branch में चलने वाले **workflow runs** के बीच maintained रहती है। इसका मतलब है कि अगर कोई attacker किसी **package** को compromise कर देता है जो cache में store हो जाता है और बाद में किसी **more privileged** workflow द्वारा **downloaded** और execute किया जाता है, तो वह उस workflow को भी **compromise** कर सकेगा।
एक cache को वही branch में चल रहे **wokflow runs in the same branch** के बीच में रखा जाता है। इसका मतलब है कि अगर कोई attacker किसी **package** को compromise कर देता है, जो बाद में cache में store हो जाता है और किसी **more privileged** workflow द्वारा **downloaded** और execute किया जाता है, तो वह उस workflow को भी **compromise** कर सकेगा।
{{#ref}}
gh-actions-cache-poisoning.md
@@ -423,7 +421,7 @@ gh-actions-cache-poisoning.md
### Artifact Poisoning
Workflows अन्य workflows और यहां तक कि repos से भी **artifacts** उपयोग कर सकते हैं; अगर कोई attacker उस Github Action को **compromise** कर ले जो कोई **artifact upload** करता है और वह बाद में किसी दूसरे workflow द्वारा उपयोग किया जाता है, तो वह अन्य workflows को भी **compromise** कर सकता है:
Workflows अन्य workflows और यहाँ तक कि repos से भी **artifacts from other workflows and even repos** का उपयोग कर सकते हैं; अगर कोई attacker उस Github Action को **compromise** कर ले जो **uploads an artifact** और वह artifact बाद में किसी अन्य workflow द्वारा उपयोग किया जाता है, तो वह अन्य workflows को भी **compromise** कर सकता है:
{{#ref}}
gh-actions-artifact-poisoning.md
@@ -435,7 +433,7 @@ gh-actions-artifact-poisoning.md
### 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.**
जैसा कि [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass) में बताया गया है, भले ही किसी repository या organization के पास कुछ actions के उपयोग को सीमित करने वाली policy हो, एक attacker बस workflow के अंदर किसी action को डाउनलोड (`git clone`) कर सकता है और फिर उसे local action के रूप में reference कर सकता है। चूँकि policies local paths को प्रभावित नहीं करतीं, **action बिना किसी restriction के execute हो जाएगा।**
Example:
```yaml
@@ -460,7 +458,7 @@ path: gha-hazmat
```
### OIDC के माध्यम से AWS और GCP तक पहुँच
Check the following pages:
निम्न पृष्ठ देखें:
{{#ref}}
../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
@@ -472,13 +470,13 @@ Check the following pages:
### secrets तक पहुँच <a href="#accessing-secrets" id="accessing-secrets"></a>
यदि आप किसी script में content inject कर रहे हैं, तो यह जानना उपयोगी है कि आप secrets तक कैसे पहुँच सकते हैं:
यदि आप किसी script में content inject कर रहे हैं तो यह जानना उपयोगी है कि आप secrets तक कैसे पहुँच सकते हैं:
- यदि secret या token **environment variable** में सेट है, तो इसे **`printenv`** का उपयोग करके environment से सीधे एक्सेस किया जा सकता है।
- यदि secret या token को एक **environment variable** में सेट किया गया है, तो इसे सीधे environment के माध्यम से **`printenv`** का उपयोग करके access किया जा सकता है।
<details>
<summary>Github Action output में secrets की सूची</summary>
<summary>Github Action output में secrets सूचीबद्ध करें</summary>
```yaml
name: list_env
on:
@@ -528,15 +526,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
```
</details>
- यदि secret को **directly in an expression** में उपयोग किया जाता है, तो जनरेट किया गया shell script **on-disk** पर स्टोर होता है और पहुँच योग्य होता है.
- यदि secret का उपयोग **directly in an expression** किया जाता है, तो generated shell script **on-disk** पर स्टोर होता है और उपलब्ध रहता है।
- ```bash
cat /home/runner/work/_temp/*
```
- JavaScript actions के लिए secrets को environment variables के माध्यम से भेजा जाता है
- JavaScript actions के लिए secrets environment variables के माध्यम से भेजे जाते हैं
- ```bash
ps axe | grep node
```
- एक **custom action** के लिए, जोखिम इस बात पर निर्भर कर सकता है कि प्रोग्राम उस secret का उपयोग कैसे कर रहा है जो उसे **argument** से मिला है:
- एक **custom action** के लिए, जोखिम इस बात पर निर्भर कर सकता है कि कोई program उस **secret** का उपयोग कैसे कर रहा है जो उसे **argument** से मिला है:
```yaml
uses: fakeaction/publish@v3
@@ -544,7 +542,7 @@ 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 करें:
- secrets context (collaborator level) के माध्यम से सभी secrets को enumerate करें। write access वाला contributor किसी भी branch पर workflow को modify करके सभी repository/org/environment secrets को dump कर सकता है। GitHub के log masking से बचने के लिए double base64 का उपयोग करें और लोकल रूप से decode करें:
```yaml
name: Steal secrets
@@ -560,31 +558,31 @@ run: |
echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0
```
लोकल में decode करें:
लोकल रूप से decode करें:
```bash
echo "ZXdv...Zz09" | base64 -d | base64 -d
```
Tip: परीक्षण के दौरान stealth के लिए, print करने से पहले encrypt करें (openssl GitHub-hosted runners पर पहले से इंस्टॉल होता है)।
टिप: परीक्षण के दौरान stealth के लिए, printing से पहले encrypt करें (openssl पहले से GitHub-hosted runners पर preinstalled है)।
### Self-hosted runners का दुरुपयोग
पता लगाने का तरीका कि कौन से **Github Actions are being executed in non-github infrastructure** वह है Github Action configuration yaml में **`runs-on: self-hosted`** को search करना।
यह पता लगाने का तरीका कि कौन से **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 को **extra sensitive information**, अन्य **network systems** (नेटवर्क में vulnerable endpoints? metadata service?) तक access मिल सकता है, या, भले ही यह isolated हो और destroy कर दिया जाए, **more than one action might be run at the same time** और malicious action दूसरे का **secrets** चुरा सकता है।
Self-hosted runners में यह भी संभव है कि आप **secrets from the \_Runner.Listener**\_\*\* process\*\* को प्राप्त कर सकें, जो किसी भी step पर workflows के सभी secrets को contain करेगा, उसके memory को dump करके:
Self-hosted runners में मेमोरी dump करके **secrets from the \_Runner.Listener**\_\*\* process\*\* प्राप्त करना भी संभव है, यह process किसी भी step पर workflows के सभी secrets को रखेगा:
```bash
sudo apt-get install -y gdb
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
```
Check [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
जानकारी के लिए [**इस पोस्ट को देखें**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
### Github Docker Images Registry
यह संभव है कि आप ऐसे Github actions बना सकें जो **Github के अंदर एक Docker image बनाकर उसे संग्रहित करें**.\
एक उदाहरण निम्न विस्तारयोग्य अनुभाग में दिया गया है:
यह संभव है कि Github actions बनाए जा सकें जो **Github के अंदर एक Docker image बनाकर स्टोर करें**.\\
निम्न विस्तार योग्य सेक्शन में एक उदाहरण दिया गया है:
<details>
@@ -619,14 +617,14 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
```
</details>
जैसा कि आप पिछले कोड में देख सकते हैं, Github registry होस्ट किया गया है **`ghcr.io`**.
जैसा कि आप पिछले कोड में देख सकते हैं, Github registry **`ghcr.io`** पर होस्ट है।
repo पर read permissions वाले उपयोगकर्ता personal access token का उपयोग करके Docker Image डाउनलोड करने में सक्षम होंगे:
repo पर read permissions वाले एक user तब 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>
```
फिर, उपयोगकर्ता **leaked secrets in the Docker image layers:** की खोज कर सकता है:
Then, the user could search for **leaked secrets in the Docker image layers:**
{{#ref}}
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
@@ -634,18 +632,18 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens
### Github Actions logs में संवेदनशील जानकारी
यहाँ तक कि अगर **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) न हो।
भले ही **Github** actions लॉग्स में **detect secret values** और उन्हें **avoid showing** करने की कोशिश करे, action के निष्पादन के दौरान उत्पन्न हुई **other sensitive data** छिपायी नहीं जाएगी। उदाहरण के लिए, एक JWT जो किसी secret value से साइन किया गया है वह तब तक छिपाया नहीं जाएगा जब तक कि वह [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret) न हो।
## अपने निशान छुपाना
(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)
(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) सबसे पहले, कोई भी PR जो उठाया गया है वह GitHub पर और टार्गेट GitHub अकाउंट पर सार्वजनिक रूप से दिखाई देता है। GitHub में डिफ़ॉल्ट रूप से, हम **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 पर आपकी **hide all your activities** इंटरनेट से छिप जाएँगी (बुनियादी रूप से आपके सभी exploit PR हट जाएँगे)।
एक organization GitHub पर अकाउंट रिपोर्ट करने में बहुत proactive रहती है। आपको बस Issue में “some stuff” शेयर करना है और वे सुनिश्चित कर देंगे कि 12 घंटे में आपका account suspended हो जाए :p और इस तरह आपका exploit GitHub पर invisible हो जाएगा।
GitHub में एक organization अकाउंट्स को रिपोर्ट करने में बहुत proactive होती है। आपको बस Issue में "some stuff" शेयर करना होगा और वे सुनिश्चित कर देंगे कि आपका अकाउंट 12 hours में suspended हो जाए :p और बस, आपकी exploit GitHub पर invisible हो जाएगी।
> [!WARNING]
> किसी organization के लिए यह पता लगाने का единमात्र तरीका कि उन्हें target किया गया है, GitHub logs को SIEM से चेक करना है क्योंकि GitHub UI से PR हटा दिया जाएगा।
> किसी organization के लिए यह पता लगाने का единमात्र तरीका यह होगा कि वे SIEM से GitHub logs चेक करें क्योंकि GitHub UI से PR हटा दिया जाएगा।
## References
## संदर्भ
- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)