Translated ['src/pentesting-ci-cd/cloudflare-security/cloudflare-domains

2025-12-25 20:34:33 -08:00 · 2025-01-11 19:21:25 +00:00
parent a6b21df8e1
commit afd1580602
44 changed files with 2099 additions and 524 deletions
--- 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,29 +1,29 @@
-# Github Actions का दुरुपयोग
+# Abusing Github Actions

 {{#include ../../../banners/hacktricks-training.md}}

-## बुनियादी जानकारी
+## Basic Information

 इस पृष्ठ पर आपको मिलेगा:

 - एक **सारांश सभी प्रभावों** का जब एक हमलावर Github Action तक पहुँचने में सफल होता है
- **एक्शन तक पहुँचने के विभिन्न तरीके**:
+- **एक्शन** तक पहुँचने के विभिन्न तरीके:
 - एक्शन बनाने के लिए **अनुमतियाँ** होना
- **पुल अनुरोध** से संबंधित ट्रिगर्स का दुरुपयोग
- **अन्य बाहरी पहुँच** तकनीकों का दुरुपयोग
- पहले से समझौता किए गए रिपॉजिटरी से **पिवोटिंग**
+- **पुल अनुरोध** से संबंधित ट्रिगर्स का दुरुपयोग करना
+- **अन्य बाहरी पहुँच** तकनीकों का दुरुपयोग करना
+- पहले से समझौता किए गए रिपॉजिटरी से **पिवटिंग** करना
 - अंत में, एक अनुभाग **एक्शन के अंदर से दुरुपयोग करने के लिए पोस्ट-एक्सप्लॉइटेशन तकनीकों** के बारे में (क्योंकि उल्लेखित प्रभाव)

-## प्रभावों का सारांश
+## Impacts Summary

-[**Github Actions के बारे में बुनियादी जानकारी**](../basic-github-information.md#github-actions) के लिए एक परिचय।
+[**Github Actions के बारे में मूल जानकारी के लिए यहाँ देखें**](../basic-github-information.md#github-actions).

 यदि आप **GitHub Actions में मनमाना कोड निष्पादित कर सकते हैं** एक **रिपॉजिटरी** के भीतर, तो आप सक्षम हो सकते हैं:

- **गुप्त जानकारी चुराना** जो पाइपलाइन में माउंट की गई है और **पाइपलाइन के विशेषाधिकारों का दुरुपयोग** करके बाहरी प्लेटफार्मों, जैसे AWS और GCP, तक अनधिकृत पहुँच प्राप्त करना।
- **डिप्लॉयमेंट्स और अन्य** **कलाकृतियों** का समझौता करना।
- यदि पाइपलाइन संपत्तियों को तैनात या संग्रहीत करती है, तो आप अंतिम उत्पाद को बदल सकते हैं, जिससे एक सप्लाई चेन हमला सक्षम हो सकता है।
- **कस्टम वर्कर्स में कोड निष्पादित करना** ताकि कंप्यूटिंग शक्ति का दुरुपयोग किया जा सके और अन्य सिस्टम पर पिवोट किया जा सके।
+- **गुप्त जानकारी चुराना** जो पाइपलाइन में माउंट की गई है और **पाइपलाइन के विशेषाधिकारों का दुरुपयोग करना** ताकि AWS और GCP जैसे बाहरी प्लेटफार्मों तक अनधिकृत पहुँच प्राप्त कर सकें।
+- **डिप्लॉयमेंट्स और अन्य **कलाकृतियों** का समझौता करना।
+- यदि पाइपलाइन संपत्तियों को तैनात या संग्रहीत करती है, तो आप अंतिम उत्पाद को बदल सकते हैं, जिससे आपूर्ति श्रृंखला हमले की अनुमति मिलती है।
+- **कस्टम वर्कर्स में कोड निष्पादित करना** ताकि कंप्यूटिंग शक्ति का दुरुपयोग किया जा सके और अन्य सिस्टम पर पिवट किया जा सके।
 - `GITHUB_TOKEN` से संबंधित अनुमतियों के आधार पर **रिपॉजिटरी कोड को ओवरराइट करना**।

 ## GITHUB_TOKEN
@@ -35,7 +35,7 @@
 यह टोकन वही है जो एक **Github एप्लिकेशन उपयोग करेगा**, इसलिए यह समान एंडपॉइंट्स तक पहुँच सकता है: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)

 > [!WARNING]
-> Github को एक [**फ्लो**](https://github.com/github/roadmap/issues/74) जारी करना चाहिए जो **GitHub के भीतर क्रॉस-रिपॉजिटरी** पहुँच की अनुमति देता है, ताकि एक रिपॉजिटरी अन्य आंतरिक रिपॉजिटरी तक `GITHUB_TOKEN` का उपयोग करके पहुँच सके।
+> Github को एक [**फ्लो**](https://github.com/github/roadmap/issues/74) जारी करना चाहिए जो **GitHub के भीतर क्रॉस-रिपॉजिटरी** पहुँच की अनुमति देता है, ताकि एक रिपॉजिटरी अन्य आंतरिक रिपॉजिटरी तक पहुँच सके `GITHUB_TOKEN` का उपयोग करके।

 आप इस टोकन की संभावित **अनुमतियों** को देख सकते हैं: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)

@@ -67,7 +67,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/reviews \
 -d '{"event":"APPROVE"}'
 ```
 {{#endtab }}
-{{#tab name="PR बनाएं" }}
+{{#tab name="Create PR" }}
 ```bash
 # Create a PR
 curl -X POST \
@@ -81,11 +81,11 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
 {{#endtabs }}

 > [!CAUTION]
-> ध्यान दें कि कई अवसरों पर आप **Github Actions envs या secrets के अंदर github उपयोगकर्ता टोकन पा सकते हैं**। ये टोकन आपको रिपॉजिटरी और संगठन पर अधिक अधिकार दे सकते हैं।
+> ध्यान दें कि कई अवसरों पर आप **Github Actions envs या secrets के अंदर github user tokens पा सकते हैं**। ये tokens आपको repository और organization पर अधिक अधिकार दे सकते हैं।

 <details>

-<summary>Github Action आउटपुट में secrets की सूची</summary>
+<summary>Github Action output में secrets की सूची</summary>
 ```yaml
 name: list_env
 on:
@@ -143,11 +143,11 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 > [!NOTE]
 > यह Github क्रियाओं को समझौता करने का सबसे आसान तरीका होगा, क्योंकि इस मामले में यह मान लिया गया है कि आपके पास **संगठन में एक नया रिपॉजिटरी बनाने का अधिकार** है, या आपके पास **एक रिपॉजिटरी पर लिखने के अधिकार** हैं।
 >
-> यदि आप इस परिदृश्य में हैं, तो आप बस [Post Exploitation techniques](./#post-exploitation-techniques-from-inside-an-action) की जांच कर सकते हैं।
+> यदि आप इस परिदृश्य में हैं, तो आप बस [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) की जांच कर सकते हैं।

 ### रिपॉजिटरी निर्माण से निष्पादन

-यदि संगठन के सदस्य **नए रिपॉजिटरी बना सकते हैं** और आप github क्रियाएँ निष्पादित कर सकते हैं, तो आप **एक नया रिपॉजिटरी बना सकते हैं और संगठन स्तर पर सेट किए गए रहस्यों को चुरा सकते हैं**।
+यदि संगठन के सदस्य **नए रिपॉजिटरी बना सकते हैं** और आप Github क्रियाएँ निष्पादित कर सकते हैं, तो आप **एक नया रिपॉजिटरी बना सकते हैं और संगठन स्तर पर सेट किए गए रहस्यों को चुरा सकते हैं**।

 ### नए शाखा से निष्पादन

@@ -170,7 +170,7 @@ branches:
 ## Forked Execution

 > [!NOTE]
-> विभिन्न ट्रिगर्स हैं जो एक हमलावर को **दूसरे रिपॉजिटरी का Github Action निष्पादित करने** की अनुमति दे सकते हैं। यदि उन ट्रिगर करने योग्य क्रियाओं को खराब तरीके से कॉन्फ़िगर किया गया है, तो एक हमलावर उन्हें समझौता करने में सक्षम हो सकता है।
+> विभिन्न ट्रिगर्स हैं जो एक हमलावर को **दूसरे रिपॉजिटरी का Github Action निष्पादित करने** की अनुमति दे सकते हैं। यदि उन ट्रिगर करने योग्य क्रियाओं को खराब तरीके से कॉन्फ़िगर किया गया है, तो एक हमलावर उन्हें समझौता कर सकता है।

 ### `pull_request`

@@ -179,7 +179,7 @@ branches:
 <figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>

 > [!NOTE]
-> चूंकि **डिफ़ॉल्ट सीमा** **पहली बार** योगदानकर्ताओं के लिए है, आप **एक मान्य बग/टाइपो को ठीक करके योगदान** कर सकते हैं और फिर **अपने नए `pull_request` विशेषाधिकारों का दुरुपयोग करने के लिए अन्य PR भेज सकते हैं**।
+> चूंकि **डिफ़ॉल्ट सीमा** **पहली बार** योगदानकर्ताओं के लिए है, आप **एक मान्य बग/टाइपो को ठीक करके** योगदान कर सकते हैं और फिर **अपने नए `pull_request` विशेषाधिकारों का दुरुपयोग करने के लिए अन्य PR भेज सकते हैं**।
 >
 > **मैंने इसका परीक्षण किया और यह काम नहीं करता**: ~~एक और विकल्प होगा किसी ऐसे व्यक्ति का नाम लेकर एक खाता बनाना जिसने परियोजना में योगदान दिया और उसका खाता हटा दिया।~~

@@ -187,7 +187,7 @@ branches:

 > `GITHUB_TOKEN` को छोड़कर, **गुप्त को रनर को नहीं भेजा जाता** जब कार्यप्रवाह एक **फोर्क किए गए** रिपॉजिटरी से ट्रिगर किया जाता है। **`GITHUB_TOKEN` में पुल अनुरोधों में **पढ़ने की केवल अनुमति** होती है **फोर्क किए गए रिपॉजिटरी** से।

-एक हमलावर Github Action की परिभाषा को संशोधित कर सकता है ताकि मनमाने कार्यों को निष्पादित किया जा सके और मनमाने कार्यों को जोड़ा जा सके। हालाँकि, वह गुप्त चुराने या रिपॉजिटरी को ओवरराइट करने में सक्षम नहीं होगा क्योंकि उल्लेखित सीमाएँ हैं।
+एक हमलावर Github Action की परिभाषा को संशोधित कर सकता है ताकि मनमाने कार्यों को निष्पादित किया जा सके और मनमाने कार्यों को जोड़ा जा सके। हालाँकि, वह गुप्त चुराने या रिपॉजिटरी को ओवरराइट करने में असमर्थ होगा क्योंकि उल्लेखित सीमाएँ हैं।

 > [!CAUTION]
 > **हाँ, यदि हमलावर PR में उस github action को बदलता है जो ट्रिगर किया जाएगा, तो उसका Github Action उपयोग किया जाएगा और मूल रिपॉजिटरी का नहीं!**
@@ -201,7 +201,7 @@ branches:
 ध्यान दें कि कार्यप्रवाह ट्रिगर **`pull_request_target`** **बेस संदर्भ में चलता है** और PR द्वारा दिए गए संदर्भ में नहीं (ताकि **अविश्वसनीय कोड निष्पादित न हो**)। `pull_request_target` के बारे में अधिक जानकारी के लिए [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target) देखें।\
 इसके अलावा, इस विशिष्ट खतरनाक उपयोग के बारे में अधिक जानकारी के लिए इस [**github ब्लॉग पोस्ट**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/) की जांच करें।

-यह लग सकता है कि चूंकि **निष्पादित कार्यप्रवाह** वह है जो **बेस** में परिभाषित है और **PR में नहीं** है, इसलिए **`pull_request_target`** का उपयोग करना **सुरक्षित** है, लेकिन कुछ **केस हैं जहाँ यह नहीं है**।
+यह लग सकता है कि चूंकि **निष्पादित कार्यप्रवाह** वह है जो **बेस** में परिभाषित है और **PR** में नहीं है, इसलिए **`pull_request_target`** का उपयोग करना **सुरक्षित** है, लेकिन कुछ **केस हैं जहाँ यह नहीं है**।

 और यह एक **गुप्तों तक पहुंच** होगी।

@@ -209,7 +209,7 @@ branches:

 [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) ट्रिगर एक कार्यप्रवाह को एक अलग कार्यप्रवाह से चलाने की अनुमति देता है जब यह `पूर्ण`, `अनुरोधित` या `प्रगति में` हो।

-इस उदाहरण में, एक कार्यप्रवाह को "Run Tests" कार्यप्रवाह के पूरा होने के बाद चलाने के लिए कॉन्फ़िगर किया गया है:
+इस उदाहरण में, एक कार्यप्रवाह को अलग "Run Tests" कार्यप्रवाह के पूरा होने के बाद चलाने के लिए कॉन्फ़िगर किया गया है:
 ```yaml
 on:
 workflow_run:
@@ -219,7 +219,7 @@ types:
 ```
 इसके अलावा, दस्तावेज़ों के अनुसार: `workflow_run` इवेंट द्वारा शुरू किया गया वर्कफ़्लो **गुप्त कोड और टोकन लिखने तक पहुँच सकता है, भले ही पिछले वर्कफ़्लो नहीं था**।

-इस प्रकार का वर्कफ़्लो हमला किया जा सकता है यदि यह एक **वर्कफ़्लो** पर **निर्भर** करता है जिसे एक बाहरी उपयोगकर्ता द्वारा **`pull_request`** या **`pull_request_target`** के माध्यम से **प्रेरित** किया जा सकता है। कुछ कमजोर उदाहरण [**इस ब्लॉग में पाया जा सकता है**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**।** पहला उदाहरण **`workflow_run`** द्वारा प्रेरित वर्कफ़्लो है जो हमलावर के कोड को डाउनलोड करता है: `${{ github.event.pull_request.head.sha }}`\
+इस प्रकार का वर्कफ़्लो हमला किया जा सकता है यदि यह एक **वर्कफ़्लो** पर **निर्भर** करता है जिसे एक बाहरी उपयोगकर्ता द्वारा **`pull_request`** या **`pull_request_target`** के माध्यम से **प्रेरित** किया जा सकता है। कुछ कमजोर उदाहरण [**इस ब्लॉग में**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**।** पहला उदाहरण **`workflow_run`** द्वारा प्रेरित वर्कफ़्लो है जो हमलावर के कोड को डाउनलोड करता है: `${{ github.event.pull_request.head.sha }}`\
 दूसरा उदाहरण **`workflow_run`** वर्कफ़्लो में **अविश्वसनीय** कोड से एक **कलाकृति** **पास** करने और इस कलाकृति की सामग्री का उपयोग करने पर आधारित है, जिससे यह **RCE के लिए कमजोर** हो जाता है।

 ### `workflow_call`
@@ -234,12 +234,12 @@ TODO: जांचें कि क्या `pull_request` से निष्

 ### अविश्वसनीय चेकआउट निष्पादन

-**`pull_request`** के मामले में, वर्कफ़्लो **PR के संदर्भ में** निष्पादित होगा (इसलिए यह **दुष्ट PRs कोड** को निष्पादित करेगा), लेकिन किसी को पहले इसे **अधिकृत** करना होगा और यह कुछ [सीमाओं](./#pull_request) के साथ चलेगा।
+**`pull_request`** के मामले में, वर्कफ़्लो **PR के संदर्भ में** निष्पादित होगा (इसलिए यह **दुष्ट PRs कोड** को निष्पादित करेगा), लेकिन किसी को इसे **पहले अधिकृत** करना होगा और यह कुछ [सीमाओं](#pull_request) के साथ चलेगा।

-यदि एक वर्कफ़्लो **`pull_request_target` या `workflow_run`** का उपयोग कर रहा है जो एक वर्कफ़्लो पर निर्भर करता है जिसे **`pull_request_target` या `pull_request`** से प्रेरित किया जा सकता है, तो मूल रेपो का कोड निष्पादित होगा, इसलिए **हमलावर निष्पादित कोड को नियंत्रित नहीं कर सकता**।
+यदि एक वर्कफ़्लो **`pull_request_target` या `workflow_run`** का उपयोग करता है जो एक वर्कफ़्लो पर निर्भर करता है जिसे **`pull_request_target` या `pull_request`** से प्रेरित किया जा सकता है, तो मूल रेपो का कोड निष्पादित होगा, इसलिए **हमलावर निष्पादित कोड को नियंत्रित नहीं कर सकता**।

 > [!CAUTION]
-> हालाँकि, यदि **एक्शन** में एक **स्पष्ट PR चेकआउट** है जो **PR से कोड प्राप्त करेगा** (और आधार से नहीं), तो यह हमलावर द्वारा नियंत्रित कोड का उपयोग करेगा। उदाहरण के लिए (लाइन 12 देखें जहां PR कोड डाउनलोड किया गया है):
+> हालाँकि, यदि **क्रिया** में एक **स्पष्ट PR चेकआउट** है जो **PR से कोड प्राप्त करेगा** (और आधार से नहीं), तो यह हमलावर द्वारा नियंत्रित कोड का उपयोग करेगा। उदाहरण के लिए (लाइन 12 देखें जहां PR कोड डाउनलोड किया गया है):

 <pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
 on:
@@ -272,7 +272,7 @@ Thank you!
 संभावित रूप से **अविश्वसनीय कोड `npm install` या `npm build` के दौरान चलाया जा रहा है** क्योंकि निर्माण स्क्रिप्ट और संदर्भित **पैकेज PR के लेखक द्वारा नियंत्रित हैं**।

 > [!WARNING]
-> कमजोर क्रियाओं की खोज के लिए एक गिटहब डॉर्क है: `event.pull_request pull_request_target extension:yml` हालाँकि, भले ही क्रिया को असुरक्षित रूप से कॉन्फ़िगर किया गया हो, फिर भी कार्यों को सुरक्षित रूप से निष्पादित करने के लिए विभिन्न तरीके हैं (जैसे कि यह निर्धारित करने के लिए कि PR उत्पन्न करने वाला अभिनेता कौन है)।
+> कमजोर क्रियाओं की खोज के लिए एक गिटहब डॉर्क है: `event.pull_request pull_request_target extension:yml` हालाँकि, भले ही क्रिया को असुरक्षित रूप से कॉन्फ़िगर किया गया हो, फिर भी कार्यों को सुरक्षित रूप से निष्पादित करने के लिए विभिन्न तरीके हैं (जैसे कि यह देखने के लिए कि PR उत्पन्न करने वाला अभिनेता कौन है)।

 ### संदर्भ स्क्रिप्ट इंजेक्शन <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>

@@ -288,7 +288,7 @@ gh-actions-context-script-injections.md

 यदि एक हमलावर इस **env** चर के अंदर **कोई भी मान** **इंजेक्ट** कर सकता है, तो वह ऐसे env चर इंजेक्ट कर सकता है जो अगले चरणों में कोड निष्पादित कर सकते हैं जैसे **LD_PRELOAD** या **NODE_OPTIONS**।

-उदाहरण के लिए ([**यह**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) और [**यह**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), कल्पना करें कि एक वर्कफ़्लो एक अपलोड की गई कलाकृति पर भरोसा कर रहा है ताकि इसकी सामग्री को **`GITHUB_ENV`** env चर के अंदर संग्रहीत किया जा सके। एक हमलावर इसे समझौता करने के लिए कुछ इस तरह अपलोड कर सकता है:
+उदाहरण के लिए ([**यह**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) और [**यह**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), कल्पना करें कि एक वर्कफ़्लो एक अपलोड की गई कलाकृति पर भरोसा कर रहा है ताकि इसकी सामग्री **`GITHUB_ENV`** env चर के अंदर संग्रहीत की जा सके। एक हमलावर इसे समझौता करने के लिए कुछ इस तरह अपलोड कर सकता है:

 <figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>

@@ -344,7 +344,7 @@ path: ./script.py

 ### हटाए गए Namespace Repo Hijacking

-यदि एक खाता अपना नाम बदलता है, तो कुछ समय बाद कोई अन्य उपयोगकर्ता उस नाम के साथ एक खाता पंजीकृत कर सकता है। यदि एक रिपॉजिटरी का **नाम बदलने से पहले 100 से कम सितारे थे**, तो Github नए पंजीकृत उपयोगकर्ता को उसी नाम के साथ एक **रिपॉजिटरी बनाने** की अनुमति देगा जो हटाई गई थी।
+यदि एक खाता अपना नाम बदलता है, तो कोई अन्य उपयोगकर्ता कुछ समय बाद उस नाम के साथ एक खाता पंजीकृत कर सकता है। यदि एक रिपॉजिटरी के पास **नाम परिवर्तन से पहले 100 से कम सितारे** थे, तो Github नए पंजीकृत उपयोगकर्ता को उसी नाम के साथ एक **रिपॉजिटरी बनाने** की अनुमति देगा जो हटाई गई थी।

 > [!CAUTION]
 > इसलिए यदि कोई क्रिया एक गैर-मौजूद खाते से एक रिपॉजिटरी का उपयोग कर रही है, तो यह संभव है कि एक हमलावर उस खाते को बना सके और क्रिया को समझौता कर सके।
@@ -360,7 +360,7 @@ path: ./script.py

 ### कैश पॉइज़निंग

-एक कैश **समान शाखा में वर्कफ़्लो रन के बीच** बनाए रखा जाता है। जिसका अर्थ है कि यदि एक हमलावर **एक पैकेज को समझौता करता है** जो फिर कैश में संग्रहीत होता है और **डाउनलोड** और **एक्सीक्यूट** किया जाता है एक **अधिक विशेषाधिकार प्राप्त** वर्कफ़्लो द्वारा, तो वह उस वर्कफ़्लो को भी **समझौता** कर सकेगा।
+एक कैश **समान शाखा में वर्कफ़्लो रन के बीच** बनाए रखा जाता है। जिसका अर्थ है कि यदि एक हमलावर **एक पैकेज को समझौता करता है** जो फिर कैश में संग्रहीत होता है और **डाउनलोड** और **अधिक विशेषाधिकार प्राप्त** वर्कफ़्लो द्वारा निष्पादित होता है, तो वह उस वर्कफ़्लो को भी **समझौता** कर सकेगा।

 {{#ref}}
 gh-actions-cache-poisoning.md
@@ -368,7 +368,7 @@ gh-actions-cache-poisoning.md

 ### आर्टिफैक्ट पॉइज़निंग

-वर्कफ़्लो **अन्य वर्कफ़्लो और यहां तक कि रिपॉजिटरी से आर्टिफैक्ट्स** का उपयोग कर सकते हैं, यदि एक हमलावर **Github Action को समझौता करने में सफल होता है** जो एक आर्टिफैक्ट **अपलोड करता है** जो बाद में किसी अन्य वर्कफ़्लो द्वारा उपयोग किया जाता है, तो वह **अन्य वर्कफ़्लो को समझौता** कर सकता है:
+वर्कफ़्लो **अन्य वर्कफ़्लो और यहां तक कि रिपॉजिटरी से आर्टिफैक्ट्स** का उपयोग कर सकते हैं, यदि एक हमलावर **उस Github Action को समझौता करने में सफल होता है** जो एक आर्टिफैक्ट **अपलोड करता है** जो बाद में किसी अन्य वर्कफ़्लो द्वारा उपयोग किया जाता है, तो वह **अन्य वर्कफ़्लो को समझौता** कर सकता है:

 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -394,7 +394,7 @@ gh-actions-artifact-poisoning.md

 यदि आप एक स्क्रिप्ट में सामग्री इंजेक्ट कर रहे हैं, तो यह जानना दिलचस्प है कि आप रहस्यों तक कैसे पहुँच सकते हैं:

- यदि रहस्य या टोकन को **पर्यावरण चर** पर सेट किया गया है, तो इसे **`printenv`** का उपयोग करके सीधे पर्यावरण के माध्यम से एक्सेस किया जा सकता है।
+- यदि रहस्य या टोकन को **पर्यावरण चर** पर सेट किया गया है, तो इसे **`printenv`** का उपयोग करके सीधे पर्यावरण के माध्यम से पहुँचा जा सकता है।

 <details>

@@ -470,7 +470,7 @@ key: ${{ secrets.PUBLISH_KEY }}

 **स्वयं-होस्टेड** रनर्स को **अतिरिक्त संवेदनशील जानकारी** तक पहुंच हो सकती है, अन्य **नेटवर्क सिस्टम** (नेटवर्क में कमजोर एंडपॉइंट? मेटाडेटा सेवा?) या, भले ही यह अलग-थलग और नष्ट हो जाए, **एक से अधिक क्रियाएं एक ही समय में चलाई जा सकती हैं** और दुर्भावनापूर्ण एक **दूसरे के गुप्त चुराने** में सक्षम हो सकता है।

-स्वयं-होस्टेड रनर्स में यह भी संभव है कि **\_Runner.Listener**\_\*\* प्रक्रिया\*\* से **गुप्त प्राप्त करें** जो किसी भी चरण पर कार्यप्रवाह के सभी गुप्त को अपनी मेमोरी को डंप करके रखेगा:
+स्वयं-होस्टेड रनर्स में यह भी संभव है कि **\_Runner.Listener**\_\*\* प्रक्रिया\*\* से **गुप्त प्राप्त करें** जो किसी भी चरण पर कार्यप्रवाह के सभी गुप्त को अपनी मेमोरी को डंप करके शामिल करेगा:
 ```bash
 sudo apt-get install -y gdb
 sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
@@ -479,12 +479,12 @@ sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ prin

 ### Github Docker Images Registry

-यह संभव है कि Github क्रियाएँ **Github के अंदर एक Docker छवि बनाएँ और संग्रहीत करें**।\
-एक उदाहरण निम्नलिखित विस्तारणीय में पाया जा सकता है:
+यह संभव है कि Github actions बनाई जाएं जो **Github के अंदर एक Docker इमेज बनाएं और स्टोर करें**।\
+एक उदाहरण निम्नलिखित विस्तार योग्य में पाया जा सकता है:

 <details>

-<summary>Github Action Build &#x26; Push Docker Image</summary>
+<summary>Github Action Build & Push Docker Image</summary>
 ```yaml
 [...]

@@ -525,21 +525,21 @@ docker pull ghcr.io/<org-name>/<repo_name>:<tag>
 फिर, उपयोगकर्ता **Docker छवि परतों में लीक हुए रहस्यों** के लिए खोज कर सकता है:

 {{#ref}}
-https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics
+https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
 {{#endref}}

 ### Github Actions लॉग में संवेदनशील जानकारी

-यहां तक कि अगर **Github** **क्रियाओं के लॉग में रहस्यमय मानों** का **पता लगाने** की कोशिश करता है और **उन्हें दिखाने से बचता है**, तो **अन्य संवेदनशील डेटा** जो क्रिया के निष्पादन में उत्पन्न हो सकता है, छिपा नहीं होगा। उदाहरण के लिए, एक JWT जो एक रहस्यमय मान के साथ हस्ताक्षरित है, तब तक छिपा नहीं होगा जब तक कि इसे [विशेष रूप से कॉन्फ़िगर](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret) नहीं किया गया हो।
+यहां तक कि यदि **Github** **गुप्त मानों** का पता लगाने की कोशिश करता है और **उन्हें दिखाने से बचता है**, तो **अन्य संवेदनशील डेटा** जो क्रिया के निष्पादन में उत्पन्न हो सकता है, छिपा नहीं होगा। उदाहरण के लिए, एक JWT जो एक गुप्त मान के साथ हस्ताक्षरित है, तब तक छिपा नहीं होगा जब तक कि इसे [विशेष रूप से कॉन्फ़िगर](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret) नहीं किया गया हो।

-## अपने निशान छिपाना
+## अपने निशान छुपाना

-(तकनीक [**यहां**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit) से) सबसे पहले, कोई भी PR जो उठाया गया है, वह स्पष्ट रूप से Github में सार्वजनिक रूप से और लक्षित GitHub खाते के लिए दिखाई देता है। GitHub में डिफ़ॉल्ट रूप से, हम **इंटरनेट से एक PR को हटा नहीं सकते**, लेकिन इसमें एक मोड़ है। उन GitHub खातों के लिए जो **Github द्वारा निलंबित** हैं, उनके सभी **PR स्वचालित रूप से हटा दिए जाते हैं** और इंटरनेट से हटा दिए जाते हैं। इसलिए अपनी गतिविधियों को छिपाने के लिए आपको या तो अपने **GitHub खाते को निलंबित** कराना होगा या अपने खाते को **फ्लैग** कराना होगा। यह **आपकी सभी गतिविधियों** को GitHub से इंटरनेट से छिपा देगा (बुनियादी रूप से आपके सभी शोषण PR को हटा देगा)
+(तकनीक [**यहां**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit) से) सबसे पहले, कोई भी PR जो उठाया गया है, वह स्पष्ट रूप से Github में सार्वजनिक रूप से और लक्षित GitHub खाते के लिए दिखाई देता है। GitHub में डिफ़ॉल्ट रूप से, हम **इंटरनेट से एक PR को हटा नहीं सकते**, लेकिन इसमें एक मोड़ है। उन GitHub खातों के लिए जो **Github द्वारा निलंबित** हैं, उनके सभी **PRs स्वचालित रूप से हटा दिए जाते हैं** और इंटरनेट से हटा दिए जाते हैं। इसलिए अपनी गतिविधियों को छुपाने के लिए आपको या तो अपने **GitHub खाते को निलंबित कराना होगा या अपने खाते को झंडा लगवाना होगा**। यह **आपकी सभी गतिविधियों** को GitHub से इंटरनेट से छुपा देगा (बुनियादी रूप से आपके सभी शोषण PR को हटा देगा)

-GitHub में एक संगठन खातों की रिपोर्ट करने में बहुत सक्रिय है। आपको बस "कुछ चीजें" Issue में साझा करनी हैं और वे सुनिश्चित करेंगे कि आपका खाता 12 घंटे में निलंबित हो जाए :p और वहां आपके पास, आपका शोषण GitHub पर अदृश्य हो गया।
+GitHub में एक संगठन खातों की रिपोर्ट करने में बहुत सक्रिय है। आपको बस "कुछ चीजें" Issue में साझा करनी हैं और वे सुनिश्चित करेंगे कि आपका खाता 12 घंटे में निलंबित हो जाए :p और आपके पास है, अपने शोषण को github पर अदृश्य बना दिया।

 > [!WARNING]
-> एक संगठन के लिए यह पता लगाने का एकमात्र तरीका है कि वे लक्षित हुए हैं, SIEM से GitHub लॉग की जांच करना है क्योंकि GitHub UI से PR हटा दिया जाएगा।
+> एक संगठन के लिए यह पता लगाने का एकमात्र तरीका कि उन्हें लक्षित किया गया है, SIEM से GitHub लॉग की जांच करना है क्योंकि GitHub UI से PR हटा दिया जाएगा।

 ## उपकरण