mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-25 20:34:33 -08:00
Translated ['src/pentesting-ci-cd/github-security/abusing-github-actions
This commit is contained in:
Translator
@@ -1,41 +1,51 @@
|
||||
# Abusing Github Actions
|
||||
# Github Actions का दुरुपयोग
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## उपकरण
|
||||
|
||||
इस पृष्ठ पर आपको मिलेगा:
|
||||
निम्नलिखित उपकरण Github Action वर्कफ़्लो खोजने और यहां तक कि कमजोर वर्कफ़्लो खोजने के लिए उपयोगी हैं:
|
||||
|
||||
- [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) - इसके चेकलिस्ट को भी देखें [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
|
||||
|
||||
## बुनियादी जानकारी
|
||||
|
||||
इस पृष्ठ पर आप पाएंगे:
|
||||
|
||||
- एक **सारांश सभी प्रभावों** का जब एक हमलावर Github Action तक पहुँचने में सफल होता है
|
||||
- **एक्शन** तक पहुँचने के विभिन्न तरीके:
|
||||
- **एक्शन तक पहुँचने के विभिन्न तरीके**:
|
||||
- एक्शन बनाने के लिए **अनुमतियाँ** होना
|
||||
- **पुल अनुरोध** से संबंधित ट्रिगर्स का दुरुपयोग करना
|
||||
- **अन्य बाहरी पहुँच** तकनीकों का दुरुपयोग करना
|
||||
- पहले से समझौता किए गए रिपॉजिटरी से **पिवटिंग** करना
|
||||
- अंत में, एक अनुभाग **एक्शन के अंदर से दुरुपयोग करने के लिए पोस्ट-एक्सप्लॉइटेशन तकनीकों** के बारे में (क्योंकि उल्लेखित प्रभाव)
|
||||
- पहले से समझौता किए गए रेपो से **पिवोटिंग** करना
|
||||
- अंत में, **एक्शन के अंदर से दुरुपयोग करने के लिए पोस्ट-एक्सप्लॉइटेशन तकनीकों** के बारे में एक अनुभाग (उपरोक्त प्रभावों का कारण)
|
||||
|
||||
## Impacts Summary
|
||||
## प्रभावों का सारांश
|
||||
|
||||
[**Github Actions के बारे में मूल जानकारी के लिए यहाँ देखें**](../basic-github-information.md#github-actions).
|
||||
[**Github Actions के बारे में बुनियादी जानकारी**](../basic-github-information.md#github-actions) के लिए एक परिचय।
|
||||
|
||||
यदि आप **GitHub Actions में मनमाना कोड निष्पादित कर सकते हैं** एक **रिपॉजिटरी** के भीतर, तो आप सक्षम हो सकते हैं:
|
||||
यदि आप **GitHub Actions में मनमाना कोड निष्पादित कर सकते हैं** एक **रेपो** के भीतर, तो आप सक्षम हो सकते हैं:
|
||||
|
||||
- **गुप्त जानकारी चुराना** जो पाइपलाइन में माउंट की गई है और **पाइपलाइन के विशेषाधिकारों का दुरुपयोग करना** ताकि AWS और GCP जैसे बाहरी प्लेटफार्मों तक अनधिकृत पहुँच प्राप्त कर सकें।
|
||||
- **डिप्लॉयमेंट्स और अन्य **कलाकृतियों** का समझौता करना।
|
||||
- यदि पाइपलाइन संपत्तियों को तैनात या संग्रहीत करती है, तो आप अंतिम उत्पाद को बदल सकते हैं, जिससे आपूर्ति श्रृंखला हमले की अनुमति मिलती है।
|
||||
- **कस्टम वर्कर्स में कोड निष्पादित करना** ताकि कंप्यूटिंग शक्ति का दुरुपयोग किया जा सके और अन्य सिस्टम पर पिवट किया जा सके।
|
||||
- `GITHUB_TOKEN` से संबंधित अनुमतियों के आधार पर **रिपॉजिटरी कोड को ओवरराइट करना**।
|
||||
- **गुप्त जानकारी चुराना** जो पाइपलाइन में माउंट की गई है और **पाइपलाइन के विशेषाधिकारों का दुरुपयोग** करके बाहरी प्लेटफार्मों, जैसे AWS और GCP, तक अनधिकृत पहुँच प्राप्त करना।
|
||||
- **डिप्लॉयमेंट्स और अन्य **कलाकृतियों** को समझौता करना।
|
||||
- यदि पाइपलाइन संपत्तियों को तैनात या संग्रहीत करती है, तो आप अंतिम उत्पाद को बदल सकते हैं, जिससे एक सप्लाई चेन हमला सक्षम हो सकता है।
|
||||
- **कस्टम वर्कर्स में कोड निष्पादित करना** ताकि कंप्यूटिंग शक्ति का दुरुपयोग किया जा सके और अन्य सिस्टम में पिवोट किया जा सके।
|
||||
- `GITHUB_TOKEN` से संबंधित अनुमतियों के आधार पर **रेपो कोड को ओवरराइट करना**।
|
||||
|
||||
## GITHUB_TOKEN
|
||||
|
||||
यह "**गुप्त**" (जो `${{ secrets.GITHUB_TOKEN }}` और `${{ github.token }}` से आता है) तब दिया जाता है जब व्यवस्थापक इस विकल्प को सक्षम करता है:
|
||||
यह "**गुप्त**" (`${{ secrets.GITHUB_TOKEN }}` और `${{ github.token }}` से आने वाला) तब दिया जाता है जब व्यवस्थापक इस विकल्प को सक्षम करता है:
|
||||
|
||||
<figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
यह टोकन वही है जो एक **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_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)
|
||||
|
||||
@@ -81,11 +91,11 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
|
||||
{{#endtabs }}
|
||||
|
||||
> [!CAUTION]
|
||||
> ध्यान दें कि कई अवसरों पर आप **Github Actions envs या secrets के अंदर github user tokens पा सकते हैं**। ये tokens आपको repository और organization पर अधिक अधिकार दे सकते हैं।
|
||||
> ध्यान दें कि कई अवसरों पर आप **Github Actions envs या secrets के अंदर github उपयोगकर्ता टोकन पा सकते हैं**। ये टोकन आपको रिपॉजिटरी और संगठन पर अधिक विशेषाधिकार दे सकते हैं।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Github Action output में secrets की सूची</summary>
|
||||
<summary>Github Action आउटपुट में secrets की सूची</summary>
|
||||
```yaml
|
||||
name: list_env
|
||||
on:
|
||||
@@ -134,26 +144,26 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
|
||||
```
|
||||
</details>
|
||||
|
||||
यह संभव है कि आप अन्य उपयोगकर्ताओं के रिपॉजिटरी में Github Token को दिए गए अनुमतियों की **लॉग्स** की जांच करके जांच कर सकें:
|
||||
यह संभव है कि आप अन्य उपयोगकर्ताओं के रिपॉजिटरी में Github Token को दिए गए अनुमतियों की जांच करें **एक्शन के लॉग** की जांच करके:
|
||||
|
||||
<figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
|
||||
|
||||
## अनुमत निष्पादन
|
||||
|
||||
> [!NOTE]
|
||||
> यह Github क्रियाओं को समझौता करने का सबसे आसान तरीका होगा, क्योंकि इस मामले में यह मान लिया गया है कि आपके पास **संगठन में एक नया रिपॉजिटरी बनाने का अधिकार** है, या आपके पास **एक रिपॉजिटरी पर लिखने के अधिकार** हैं।
|
||||
> यह Github एक्शन को समझौता करने का सबसे आसान तरीका होगा, क्योंकि इस मामले में यह मान लिया गया है कि आपके पास **संगठन में एक नया रिपॉजिटरी बनाने का अधिकार** है, या आपके पास **एक रिपॉजिटरी पर लिखने के अधिकार** हैं।
|
||||
>
|
||||
> यदि आप इस परिदृश्य में हैं, तो आप बस [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) की जांच कर सकते हैं।
|
||||
|
||||
### रिपॉजिटरी निर्माण से निष्पादन
|
||||
|
||||
यदि संगठन के सदस्य **नए रिपॉजिटरी बना सकते हैं** और आप Github क्रियाएँ निष्पादित कर सकते हैं, तो आप **एक नया रिपॉजिटरी बना सकते हैं और संगठन स्तर पर सेट किए गए रहस्यों को चुरा सकते हैं**।
|
||||
यदि संगठन के सदस्य **नए रिपॉजिटरी बना सकते हैं** और आप github एक्शन निष्पादित कर सकते हैं, तो आप **एक नया रिपॉजिटरी बना सकते हैं और संगठन स्तर पर सेट किए गए रहस्यों को चुरा सकते हैं**।
|
||||
|
||||
### नए शाखा से निष्पादन
|
||||
|
||||
यदि आप **एक रिपॉजिटरी में एक नई शाखा बना सकते हैं जिसमें पहले से एक Github Action** कॉन्फ़िगर किया गया है, तो आप इसे **संशोधित** कर सकते हैं, **सामग्री अपलोड** कर सकते हैं, और फिर **नई शाखा से उस क्रिया को निष्पादित** कर सकते हैं। इस तरह आप **रिपॉजिटरी और संगठन स्तर के रहस्यों को निकाल सकते हैं** (लेकिन आपको यह जानना होगा कि उन्हें क्या कहा जाता है)।
|
||||
यदि आप **एक रिपॉजिटरी में एक नई शाखा बना सकते हैं जिसमें पहले से एक Github Action** कॉन्फ़िगर किया गया है, तो आप इसे **संशोधित** कर सकते हैं, **सामग्री अपलोड** कर सकते हैं, और फिर **नई शाखा से उस एक्शन को निष्पादित** कर सकते हैं। इस तरह आप **रिपॉजिटरी और संगठन स्तर के रहस्यों को निकाल सकते हैं** (लेकिन आपको यह जानना होगा कि उन्हें क्या कहा जाता है)।
|
||||
|
||||
आप संशोधित क्रिया को **हाथ से** निष्पादित कर सकते हैं, जब **PR बनाया जाता है** या जब **कुछ कोड पुश किया जाता है** (इस पर निर्भर करता है कि आप कितने शोर करना चाहते हैं):
|
||||
आप संशोधित एक्शन को **हाथ से** निष्पादित कर सकते हैं, जब **PR बनाया जाता है** या जब **कुछ कोड पुश किया जाता है** (इस पर निर्भर करता है कि आप कितने शोर करना चाहते हैं):
|
||||
```yaml
|
||||
on:
|
||||
workflow_dispatch: # Launch manually
|
||||
@@ -170,24 +180,24 @@ branches:
|
||||
## Forked Execution
|
||||
|
||||
> [!NOTE]
|
||||
> विभिन्न ट्रिगर्स हैं जो एक हमलावर को **दूसरे रिपॉजिटरी का Github Action निष्पादित करने** की अनुमति दे सकते हैं। यदि उन ट्रिगर करने योग्य क्रियाओं को खराब तरीके से कॉन्फ़िगर किया गया है, तो एक हमलावर उन्हें समझौता कर सकता है।
|
||||
> विभिन्न ट्रिगर्स हैं जो एक हमलावर को **दूसरे रिपॉजिटरी के Github Action को निष्पादित** करने की अनुमति दे सकते हैं। यदि उन ट्रिगर करने योग्य क्रियाओं को खराब तरीके से कॉन्फ़िगर किया गया है, तो एक हमलावर उन्हें समझौता करने में सक्षम हो सकता है।
|
||||
|
||||
### `pull_request`
|
||||
|
||||
कार्यप्रवाह ट्रिगर **`pull_request`** हर बार कार्यप्रवाह को निष्पादित करेगा जब एक पुल अनुरोध प्राप्त होता है, कुछ अपवादों के साथ: डिफ़ॉल्ट रूप से यदि यह **पहली बार** है जब आप **सहयोग कर रहे हैं**, तो कुछ **रखरखावकर्ता** को कार्यप्रवाह के **चलाने** को **स्वीकृत** करने की आवश्यकता होगी:
|
||||
कार्यप्रवाह ट्रिगर **`pull_request`** हर बार कार्यप्रवाह को निष्पादित करेगा जब एक पुल अनुरोध प्राप्त होता है, कुछ अपवादों के साथ: डिफ़ॉल्ट रूप से यदि यह **पहली बार** है जब आप **सहयोग कर रहे हैं**, तो कुछ **रखरखावकर्ता** को कार्यप्रवाह के **निष्पादन** को **स्वीकृत** करने की आवश्यकता होगी:
|
||||
|
||||
<figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
> [!NOTE]
|
||||
> चूंकि **डिफ़ॉल्ट सीमा** **पहली बार** योगदानकर्ताओं के लिए है, आप **एक मान्य बग/टाइपो को ठीक करके** योगदान कर सकते हैं और फिर **अपने नए `pull_request` विशेषाधिकारों का दुरुपयोग करने के लिए अन्य PR भेज सकते हैं**।
|
||||
> चूंकि **डिफ़ॉल्ट सीमा** **पहली बार** योगदानकर्ताओं के लिए है, आप **एक वैध बग/टाइपो को ठीक करने** में योगदान कर सकते हैं और फिर **अपने नए `pull_request` विशेषाधिकारों का दुरुपयोग करने के लिए अन्य PR भेज सकते हैं**।
|
||||
>
|
||||
> **मैंने इसका परीक्षण किया और यह काम नहीं करता**: ~~एक और विकल्प होगा किसी ऐसे व्यक्ति का नाम लेकर एक खाता बनाना जिसने परियोजना में योगदान दिया और उसका खाता हटा दिया।~~
|
||||
|
||||
इसके अलावा, डिफ़ॉल्ट रूप से **लिखने की अनुमति** और **गुप्त पहुंच** को लक्षित रिपॉजिटरी में रोकता है जैसा कि [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories) में उल्लेख किया गया है:
|
||||
|
||||
> `GITHUB_TOKEN` को छोड़कर, **गुप्त को रनर को नहीं भेजा जाता** जब कार्यप्रवाह एक **फोर्क किए गए** रिपॉजिटरी से ट्रिगर किया जाता है। **`GITHUB_TOKEN` में पुल अनुरोधों में **पढ़ने की केवल अनुमति** होती है **फोर्क किए गए रिपॉजिटरी** से।
|
||||
> `GITHUB_TOKEN` को छोड़कर, **गुप्त को रनर को नहीं भेजा जाता** जब एक कार्यप्रवाह **फोर्क की गई** रिपॉजिटरी से ट्रिगर किया जाता है। **`GITHUB_TOKEN` में पुल अनुरोधों में **पढ़ने की केवल अनुमति** होती है **फोर्क की गई रिपॉजिटरी** से।
|
||||
|
||||
एक हमलावर Github Action की परिभाषा को संशोधित कर सकता है ताकि मनमाने कार्यों को निष्पादित किया जा सके और मनमाने कार्यों को जोड़ा जा सके। हालाँकि, वह गुप्त चुराने या रिपॉजिटरी को ओवरराइट करने में असमर्थ होगा क्योंकि उल्लेखित सीमाएँ हैं।
|
||||
एक हमलावर Github Action की परिभाषा को संशोधित कर सकता है ताकि मनमाने कार्यों को निष्पादित किया जा सके और मनमाने कार्यों को जोड़ा जा सके। हालाँकि, वह गुप्त चुराने या रिपॉजिटरी को ओवरराइट करने में सक्षम नहीं होगा क्योंकि उल्लेखित सीमाएँ हैं।
|
||||
|
||||
> [!CAUTION]
|
||||
> **हाँ, यदि हमलावर PR में उस github action को बदलता है जो ट्रिगर किया जाएगा, तो उसका Github Action उपयोग किया जाएगा और मूल रिपॉजिटरी का नहीं!**
|
||||
@@ -198,10 +208,10 @@ branches:
|
||||
|
||||
कार्यप्रवाह ट्रिगर **`pull_request_target`** को लक्षित रिपॉजिटरी में **लिखने की अनुमति** और **गुप्तों तक पहुंच** होती है (और अनुमति नहीं मांगता)।
|
||||
|
||||
ध्यान दें कि कार्यप्रवाह ट्रिगर **`pull_request_target`** **बेस संदर्भ में चलता है** और PR द्वारा दिए गए संदर्भ में नहीं (ताकि **अविश्वसनीय कोड निष्पादित न हो**)। `pull_request_target` के बारे में अधिक जानकारी के लिए [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target) देखें।\
|
||||
ध्यान दें कि कार्यप्रवाह ट्रिगर **`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 +219,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:
|
||||
@@ -217,29 +227,29 @@ workflows: [Run Tests]
|
||||
types:
|
||||
- completed
|
||||
```
|
||||
इसके अलावा, दस्तावेज़ों के अनुसार: `workflow_run` इवेंट द्वारा शुरू किया गया वर्कफ़्लो **गुप्त कोड और टोकन लिखने तक पहुँच सकता है, भले ही पिछले वर्कफ़्लो नहीं था**।
|
||||
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**.
|
||||
|
||||
इस प्रकार का वर्कफ़्लो हमला किया जा सकता है यदि यह एक **वर्कफ़्लो** पर **निर्भर** करता है जिसे एक बाहरी उपयोगकर्ता द्वारा **`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 के लिए कमजोर** हो जाता है।
|
||||
This kind of workflow could be attacked if it's **depending** on a **workflow** that can be **triggered** by an external user via **`pull_request`** or **`pull_request_target`**. A couple of vulnerable examples can be [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** The first one consist on the **`workflow_run`** triggered workflow downloading out the attackers code: `${{ github.event.pull_request.head.sha }}`\
|
||||
The second one consist on **passing** an **artifact** from the **untrusted** code to the **`workflow_run`** workflow and using the content of this artifact in a way that makes it **vulnerable to RCE**.
|
||||
|
||||
### `workflow_call`
|
||||
|
||||
TODO
|
||||
|
||||
TODO: जांचें कि क्या `pull_request` से निष्पादित होने पर उपयोग किया गया/डाउनलोड किया गया कोड मूल से है या फोर्क किए गए 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
|
||||
|
||||
हमने सभी तरीकों का उल्लेख किया है जिनसे एक बाहरी हमलावर एक गिटहब वर्कफ़्लो को निष्पादित करने में सक्षम हो सकता है, अब आइए देखें कि यदि ये निष्पादन, यदि गलत तरीके से कॉन्फ़िगर किए गए हैं, तो कैसे दुरुपयोग किया जा सकता है:
|
||||
We have mentioned all the ways an external attacker could manage to make a github workflow to execute, now let's take a look about how this executions, if bad configured, could be abused:
|
||||
|
||||
### अविश्वसनीय चेकआउट निष्पादन
|
||||
### Untrusted checkout execution
|
||||
|
||||
**`pull_request`** के मामले में, वर्कफ़्लो **PR के संदर्भ में** निष्पादित होगा (इसलिए यह **दुष्ट PRs कोड** को निष्पादित करेगा), लेकिन किसी को इसे **पहले अधिकृत** करना होगा और यह कुछ [सीमाओं](#pull_request) के साथ चलेगा।
|
||||
In the case of **`pull_request`,** the workflow is going to be executed in the **context of the PR** (so it'll execute the **malicious PRs code**), but someone needs to **authorize it first** and it will run with some [limitations](#pull_request).
|
||||
|
||||
यदि एक वर्कफ़्लो **`pull_request_target` या `workflow_run`** का उपयोग करता है जो एक वर्कफ़्लो पर निर्भर करता है जिसे **`pull_request_target` या `pull_request`** से प्रेरित किया जा सकता है, तो मूल रेपो का कोड निष्पादित होगा, इसलिए **हमलावर निष्पादित कोड को नियंत्रित नहीं कर सकता**।
|
||||
In case of a workflow using **`pull_request_target` or `workflow_run`** that depends on a workflow that can be triggered from **`pull_request_target` or `pull_request`** the code from the original repo will be executed, so the **attacker cannot control the executed code**.
|
||||
|
||||
> [!CAUTION]
|
||||
> हालाँकि, यदि **क्रिया** में एक **स्पष्ट PR चेकआउट** है जो **PR से कोड प्राप्त करेगा** (और आधार से नहीं), तो यह हमलावर द्वारा नियंत्रित कोड का उपयोग करेगा। उदाहरण के लिए (लाइन 12 देखें जहां PR कोड डाउनलोड किया गया है):
|
||||
> However, if the **action** has an **explicit PR checkout** that will **get the code from the PR** (and not from base), it will use the attackers controlled code. For example (check line 12 where the PR code is downloaded):
|
||||
|
||||
<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
|
||||
on:
|
||||
@@ -269,38 +279,78 @@ message: |
|
||||
Thank you!
|
||||
</code></pre>
|
||||
|
||||
संभावित रूप से **अविश्वसनीय कोड `npm install` या `npm build` के दौरान चलाया जा रहा है** क्योंकि निर्माण स्क्रिप्ट और संदर्भित **पैकेज PR के लेखक द्वारा नियंत्रित हैं**।
|
||||
The potentially **untrusted code is being run during `npm install` or `npm build`** as the build scripts and referenced **packages are controlled by the author of the PR**.
|
||||
|
||||
> [!WARNING]
|
||||
> कमजोर क्रियाओं की खोज के लिए एक गिटहब डॉर्क है: `event.pull_request pull_request_target extension:yml` हालाँकि, भले ही क्रिया को असुरक्षित रूप से कॉन्फ़िगर किया गया हो, फिर भी कार्यों को सुरक्षित रूप से निष्पादित करने के लिए विभिन्न तरीके हैं (जैसे कि यह देखने के लिए कि PR उत्पन्न करने वाला अभिनेता कौन है)।
|
||||
> A github dork to search for vulnerable actions is: `event.pull_request pull_request_target extension:yml` however, there are different ways to configure the jobs to be executed securely even if the action is configured insecurely (like using conditionals about who is the actor generating the PR).
|
||||
|
||||
### संदर्भ स्क्रिप्ट इंजेक्शन <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
|
||||
### Context Script Injections <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
|
||||
|
||||
ध्यान दें कि कुछ [**गिटहब संदर्भ**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) हैं जिनके मान **उपयोगकर्ता** द्वारा नियंत्रित होते हैं जो PR बना रहा है। यदि गिटहब क्रिया उस **डेटा का उपयोग करके कुछ निष्पादित कर रही है**, तो यह **मनमाने कोड निष्पादन** की ओर ले जा सकता है:
|
||||
Note that there are certain [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) whose values are **controlled** by the **user** creating the PR. If the github action is using that **data to execute anything**, it could lead to **arbitrary code execution:**
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-context-script-injections.md
|
||||
{{#endref}}
|
||||
|
||||
### **GITHUB_ENV स्क्रिप्ट इंजेक्शन** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
|
||||
### **GITHUB_ENV Script Injection** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
|
||||
|
||||
दस्तावेज़ों से: आप किसी वर्कफ़्लो नौकरी में किसी भी बाद के चरणों के लिए एक **पर्यावरण चर उपलब्ध** करा सकते हैं, इसे परिभाषित या अपडेट करके और इसे **`GITHUB_ENV`** पर्यावरण फ़ाइल में लिखकर।
|
||||
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.
|
||||
|
||||
यदि एक हमलावर इस **env** चर के अंदर **कोई भी मान** **इंजेक्ट** कर सकता है, तो वह ऐसे env चर इंजेक्ट कर सकता है जो अगले चरणों में कोड निष्पादित कर सकते हैं जैसे **LD_PRELOAD** या **NODE_OPTIONS**।
|
||||
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**.
|
||||
|
||||
उदाहरण के लिए ([**यह**](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 चर के अंदर संग्रहीत की जा सके। एक हमलावर इसे समझौता करने के लिए कुछ इस तरह अपलोड कर सकता है:
|
||||
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:
|
||||
|
||||
<figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### कमजोर तृतीय पक्ष गिटहब क्रियाएँ
|
||||
### Dependabot and other trusted bots
|
||||
|
||||
As indicated in [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), several organizations have a Github Action that merges any PRR from `dependabot[bot]` like in:
|
||||
```yaml
|
||||
on: pull_request_target
|
||||
jobs:
|
||||
auto-merge:
|
||||
runs-on: ubuntu-latest
|
||||
if: ${ { github.actor == 'dependabot[bot]' }}
|
||||
steps:
|
||||
- run: gh pr merge $ -d -m
|
||||
```
|
||||
यह एक समस्या है क्योंकि `github.actor` फ़ील्ड उस उपयोगकर्ता को दर्शाती है जिसने वर्कफ़्लो को ट्रिगर करने वाली नवीनतम घटना का कारण बना। और `dependabot[bot]` उपयोगकर्ता को PR को संशोधित करने के कई तरीके हैं। उदाहरण के लिए:
|
||||
|
||||
- पीड़ित रिपॉजिटरी को फोर्क करें
|
||||
- अपनी कॉपी में दुर्भावनापूर्ण पेलोड जोड़ें
|
||||
- अपने फोर्क पर एक पुरानी निर्भरता जोड़कर Dependabot को सक्षम करें। Dependabot एक शाखा बनाएगा जो दुर्भावनापूर्ण कोड के साथ निर्भरता को ठीक करेगा।
|
||||
- उस शाखा से पीड़ित रिपॉजिटरी के लिए एक पुल अनुरोध खोलें (PR उपयोगकर्ता द्वारा बनाया जाएगा इसलिए अभी कुछ नहीं होगा)
|
||||
- फिर, हमलावर अपने फोर्क में Dependabot द्वारा खोले गए प्रारंभिक PR पर वापस जाता है और `@dependabot recreate` चलाता है
|
||||
- फिर, Dependabot उस शाखा में कुछ क्रियाएँ करता है, जिसने पीड़ित रिपॉजिटरी पर PR को संशोधित किया, जिससे `dependabot[bot]` नवीनतम घटना का अभिनेता बन जाता है जिसने वर्कफ़्लो को ट्रिगर किया (और इसलिए, वर्कफ़्लो चलता है)।
|
||||
|
||||
आगे बढ़ते हैं, अगर Github Action के बजाय एक कमांड इंजेक्शन होता जैसे:
|
||||
```yaml
|
||||
on: pull_request_target
|
||||
jobs:
|
||||
just-printing-stuff:
|
||||
runs-on: ubuntu-latest
|
||||
if: ${ { github.actor == 'dependabot[bot]' }}
|
||||
steps:
|
||||
- run: echo ${ { github.event.pull_request.head.ref }}
|
||||
```
|
||||
अच्छा, मूल ब्लॉगपोस्ट इस व्यवहार का दुरुपयोग करने के लिए दो विकल्प प्रस्तुत करता है, जिसमें दूसरा है:
|
||||
|
||||
- पीड़ित रिपॉजिटरी को फोर्क करें और कुछ पुराने निर्भरता के साथ Dependabot को सक्षम करें।
|
||||
- दुर्भावनापूर्ण शेल इंजेक्शन कोड के साथ एक नई शाखा बनाएं।
|
||||
- उस शाखा को रिपॉजिटरी की डिफ़ॉल्ट शाखा के रूप में बदलें।
|
||||
- इस शाखा से पीड़ित रिपॉजिटरी के लिए एक PR बनाएं।
|
||||
- PR में `@dependabot merge` चलाएं जिसे Dependabot ने अपने फोर्क में खोला था।
|
||||
- Dependabot आपके फोर्क की डिफ़ॉल्ट शाखा में अपने परिवर्तनों को मर्ज करेगा, पीड़ित रिपॉजिटरी में PR को अपडेट करेगा और अब `dependabot[bot]` को कार्यप्रवाह को ट्रिगर करने वाले नवीनतम घटना का अभिनेता बना देगा और एक दुर्भावनापूर्ण शाखा नाम का उपयोग करेगा।
|
||||
|
||||
### कमजोर तृतीय पक्ष Github क्रियाएँ
|
||||
|
||||
#### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
|
||||
|
||||
जैसा कि [**इस ब्लॉग पोस्ट**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) में उल्लेख किया गया है, यह गिटहब क्रिया विभिन्न वर्कफ़्लो और यहां तक कि रिपॉजिटरी से कलाकृतियों तक पहुँचने की अनुमति देती है।
|
||||
जैसा कि [**इस ब्लॉग पोस्ट**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) में उल्लेख किया गया है, यह Github क्रिया विभिन्न कार्यप्रवाहों और यहां तक कि रिपॉजिटरी से कलाकृतियों तक पहुंचने की अनुमति देती है।
|
||||
|
||||
समस्या यह है कि यदि **`path`** पैरामीटर सेट नहीं किया गया है, तो कलाकृति वर्तमान निर्देशिका में निकाली जाती है और यह उन फ़ाइलों को ओवरराइट कर सकती है जो बाद में वर्कफ़्लो में उपयोग की जा सकती हैं या यहां तक कि निष्पादित की जा सकती हैं। इसलिए, यदि कलाकृति कमजोर है, तो एक हमलावर इसका दुरुपयोग करके अन्य वर्कफ़्लो को समझौता कर सकता है जो कलाकृति पर भरोसा करते हैं।
|
||||
समस्या यह है कि यदि **`path`** पैरामीटर सेट नहीं किया गया है, तो कलाकृति वर्तमान निर्देशिका में निकाली जाती है और यह उन फ़ाइलों को ओवरराइट कर सकती है जो बाद में कार्यप्रवाह में उपयोग की जा सकती हैं या यहां तक कि निष्पादित की जा सकती हैं। इसलिए, यदि कलाकृति कमजोर है, तो एक हमलावर इसका दुरुपयोग करके अन्य कार्यप्रवाहों को समझौता कर सकता है जो कलाकृति पर भरोसा करते हैं।
|
||||
|
||||
कमजोर वर्कफ़्लो का उदाहरण:
|
||||
कमजोर कार्यप्रवाह का उदाहरण:
|
||||
```yaml
|
||||
on:
|
||||
workflow_run:
|
||||
@@ -344,23 +394,23 @@ path: ./script.py
|
||||
|
||||
### हटाए गए Namespace Repo Hijacking
|
||||
|
||||
यदि एक खाता अपना नाम बदलता है, तो कोई अन्य उपयोगकर्ता कुछ समय बाद उस नाम के साथ एक खाता पंजीकृत कर सकता है। यदि एक रिपॉजिटरी के पास **नाम परिवर्तन से पहले 100 से कम सितारे** थे, तो Github नए पंजीकृत उपयोगकर्ता को उसी नाम के साथ एक **रिपॉजिटरी बनाने** की अनुमति देगा जो हटाई गई थी।
|
||||
यदि एक खाता अपना नाम बदलता है, तो कुछ समय बाद कोई अन्य उपयोगकर्ता उस नाम के साथ एक खाता पंजीकृत कर सकता है। यदि एक रिपॉजिटरी के पास **नाम परिवर्तन से पहले 100 से कम सितारे** थे, तो Github नए पंजीकृत उपयोगकर्ता को उसी नाम के साथ एक **रिपॉजिटरी बनाने** की अनुमति देगा जो हटाई गई थी।
|
||||
|
||||
> [!CAUTION]
|
||||
> इसलिए यदि कोई क्रिया एक गैर-मौजूद खाते से एक रिपॉजिटरी का उपयोग कर रही है, तो यह संभव है कि एक हमलावर उस खाते को बना सके और क्रिया को समझौता कर सके।
|
||||
|
||||
यदि अन्य रिपॉजिटरी **इस उपयोगकर्ता के रिपॉजिटरी से निर्भरताएँ** का उपयोग कर रही हैं, तो एक हमलावर उन्हें हाइजैक करने में सक्षम होगा। यहाँ आपके पास एक अधिक पूर्ण व्याख्या है: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
|
||||
यदि अन्य रिपॉजिटरी **इस उपयोगकर्ता के रिपॉजिटरी से निर्भरताएँ** का उपयोग कर रही हैं, तो एक हमलावर उन्हें हाइजैक कर सकेगा। यहाँ आपके पास एक अधिक पूर्ण व्याख्या है: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
|
||||
|
||||
---
|
||||
|
||||
## Repo Pivoting
|
||||
|
||||
> [!NOTE]
|
||||
> इस अनुभाग में हम उन तकनीकों के बारे में बात करेंगे जो **एक रिपॉजिटरी से दूसरी रिपॉजिटरी में पिवट** करने की अनुमति देंगी, मानते हुए कि हमारे पास पहले वाले पर कुछ प्रकार की पहुँच है (पिछले अनुभाग की जाँच करें)।
|
||||
> इस अनुभाग में हम उन तकनीकों के बारे में बात करेंगे जो **एक रिपॉजिटरी से दूसरी रिपॉजिटरी में पिवट** करने की अनुमति देंगी, मानते हुए कि हमारे पास पहले वाले पर कुछ प्रकार की पहुँच है (पिछली अनुभाग देखें)।
|
||||
|
||||
### कैश पॉइज़निंग
|
||||
|
||||
एक कैश **समान शाखा में वर्कफ़्लो रन के बीच** बनाए रखा जाता है। जिसका अर्थ है कि यदि एक हमलावर **एक पैकेज को समझौता करता है** जो फिर कैश में संग्रहीत होता है और **डाउनलोड** और **अधिक विशेषाधिकार प्राप्त** वर्कफ़्लो द्वारा निष्पादित होता है, तो वह उस वर्कफ़्लो को भी **समझौता** कर सकेगा।
|
||||
एक कैश **समान शाखा में वर्कफ़्लो रन के बीच** बनाए रखा जाता है। जिसका अर्थ है कि यदि एक हमलावर **एक पैकेज को समझौता करता है** जो फिर कैश में संग्रहीत होता है और **डाउनलोड** और **अधिक विशेषाधिकार प्राप्त** वर्कफ़्लो द्वारा निष्पादित किया जाता है, तो वह उस वर्कफ़्लो को भी **समझौता** कर सकेगा।
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-cache-poisoning.md
|
||||
@@ -368,7 +418,7 @@ gh-actions-cache-poisoning.md
|
||||
|
||||
### आर्टिफैक्ट पॉइज़निंग
|
||||
|
||||
वर्कफ़्लो **अन्य वर्कफ़्लो और यहां तक कि रिपॉजिटरी से आर्टिफैक्ट्स** का उपयोग कर सकते हैं, यदि एक हमलावर **उस Github Action को समझौता करने में सफल होता है** जो एक आर्टिफैक्ट **अपलोड करता है** जो बाद में किसी अन्य वर्कफ़्लो द्वारा उपयोग किया जाता है, तो वह **अन्य वर्कफ़्लो को समझौता** कर सकता है:
|
||||
वर्कफ़्लो **अन्य वर्कफ़्लो और यहां तक कि रिपॉजिटरी से आर्टिफैक्ट्स** का उपयोग कर सकते हैं, यदि एक हमलावर **Github Action को समझौता करने में सफल होता है** जो एक आर्टिफैक्ट **अपलोड करता है** जो बाद में किसी अन्य वर्कफ़्लो द्वारा उपयोग किया जाता है, तो वह **अन्य वर्कफ़्लो को समझौता** कर सकता है:
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-artifact-poisoning.md
|
||||
@@ -394,7 +444,7 @@ gh-actions-artifact-poisoning.md
|
||||
|
||||
यदि आप एक स्क्रिप्ट में सामग्री इंजेक्ट कर रहे हैं, तो यह जानना दिलचस्प है कि आप रहस्यों तक कैसे पहुँच सकते हैं:
|
||||
|
||||
- यदि रहस्य या टोकन को **पर्यावरण चर** पर सेट किया गया है, तो इसे **`printenv`** का उपयोग करके सीधे पर्यावरण के माध्यम से पहुँचा जा सकता है।
|
||||
- यदि रहस्य या टोकन को **पर्यावरण चर** में सेट किया गया है, तो इसे **`printenv`** का उपयोग करके सीधे पर्यावरण के माध्यम से एक्सेस किया जा सकता है।
|
||||
|
||||
<details>
|
||||
|
||||
@@ -448,7 +498,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
|
||||
```
|
||||
</details>
|
||||
|
||||
- यदि गुप्त को **एक्सप्रेशन में सीधे** उपयोग किया जाता है, तो उत्पन्न शेल स्क्रिप्ट **ऑन-डिस्क** संग्रहीत होती है और इसे एक्सेस किया जा सकता है।
|
||||
- यदि गुप्त को **एक्सप्रेशन में सीधे** उपयोग किया जाता है, तो उत्पन्न शेल स्क्रिप्ट **डिस्क पर** संग्रहीत होती है और इसे एक्सेस किया जा सकता है।
|
||||
- ```bash
|
||||
cat /home/runner/work/_temp/*
|
||||
```
|
||||
@@ -456,7 +506,7 @@ cat /home/runner/work/_temp/*
|
||||
- ```bash
|
||||
ps axe | grep node
|
||||
```
|
||||
- एक **कस्टम क्रिया** के लिए, जोखिम इस बात पर निर्भर कर सकता है कि एक प्रोग्राम ने **आर्गुमेंट** से प्राप्त गुप्त का उपयोग कैसे किया:
|
||||
- एक **कस्टम क्रिया** के लिए, जोखिम इस पर निर्भर कर सकता है कि एक प्रोग्राम ने **आर्गुमेंट** से प्राप्त गुप्त का उपयोग कैसे किया है:
|
||||
|
||||
```yaml
|
||||
uses: fakeaction/publish@v3
|
||||
@@ -468,14 +518,14 @@ key: ${{ secrets.PUBLISH_KEY }}
|
||||
|
||||
यह पता लगाने का तरीका कि कौन सी **Github Actions गैर-github अवसंरचना में निष्पादित हो रही हैं** वह है कि Github Action कॉन्फ़िगरेशन yaml में **`runs-on: self-hosted`** के लिए खोजें।
|
||||
|
||||
**स्वयं-होस्टेड** रनर्स को **अतिरिक्त संवेदनशील जानकारी** तक पहुंच हो सकती है, अन्य **नेटवर्क सिस्टम** (नेटवर्क में कमजोर एंडपॉइंट? मेटाडेटा सेवा?) या, भले ही यह अलग-थलग और नष्ट हो जाए, **एक से अधिक क्रियाएं एक ही समय में चलाई जा सकती हैं** और दुर्भावनापूर्ण एक **दूसरे के गुप्त चुराने** में सक्षम हो सकता है।
|
||||
**स्वयं-होस्टेड** रनर्स को **अतिरिक्त संवेदनशील जानकारी** तक पहुंच हो सकती है, अन्य **नेटवर्क सिस्टम** (नेटवर्क में कमजोर एंडपॉइंट? मेटाडेटा सेवा?) या, भले ही यह अलग-थलग और नष्ट हो जाए, **एक से अधिक क्रियाएं एक ही समय में चलाई जा सकती हैं** और दुर्भावनापूर्ण एक **दूसरे के गुप्त चुरा सकती है**।
|
||||
|
||||
स्वयं-होस्टेड रनर्स में यह भी संभव है कि **\_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 }')"
|
||||
```
|
||||
चेक करें [**इस पोस्ट के लिए अधिक जानकारी**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/)।
|
||||
चेक करें [**इस पोस्ट में अधिक जानकारी के लिए**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/)।
|
||||
|
||||
### Github Docker Images Registry
|
||||
|
||||
@@ -522,7 +572,7 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
|
||||
echo $gh_token | docker login ghcr.io -u <username> --password-stdin
|
||||
docker pull ghcr.io/<org-name>/<repo_name>:<tag>
|
||||
```
|
||||
फिर, उपयोगकर्ता **Docker छवि परतों में लीक हुए रहस्यों** के लिए खोज कर सकता है:
|
||||
फिर, उपयोगकर्ता **Docker इमेज लेयर्स में लीक हुए रहस्यों** की खोज कर सकता है:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
|
||||
@@ -530,24 +580,15 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens
|
||||
|
||||
### 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 द्वारा निलंबित** हैं, उनके सभी **PRs स्वचालित रूप से हटा दिए जाते हैं** और इंटरनेट से हटा दिए जाते हैं। इसलिए अपनी गतिविधियों को छुपाने के लिए आपको या तो अपने **GitHub खाते को निलंबित कराना होगा या अपने खाते को झंडा लगवाना होगा**। यह **आपकी सभी गतिविधियों** को GitHub से इंटरनेट से छुपा देगा (बुनियादी रूप से आपके सभी शोषण PR को हटा देगा)
|
||||
(तकनीक [**यहां**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit) से) सबसे पहले, कोई भी PR जो उठाया गया है, वह Github में सार्वजनिक रूप से और लक्षित GitHub खाते के लिए स्पष्ट रूप से दिखाई देता है। GitHub में डिफ़ॉल्ट रूप से, हम **इंटरनेट से एक PR को हटा नहीं सकते**, लेकिन इसमें एक मोड़ है। Github द्वारा **सस्पेंड** किए गए खातों के लिए, उनके सभी **PRs स्वचालित रूप से हटा दिए जाते हैं** और इंटरनेट से हटा दिए जाते हैं। इसलिए अपनी गतिविधियों को छिपाने के लिए आपको या तो अपने **GitHub खाते को सस्पेंड** कराना होगा या अपने खाते को **फ्लैग** कराना होगा। यह **आपकी सभी गतिविधियों** को GitHub से इंटरनेट से छिपा देगा (बुनियादी रूप से आपके सभी एक्सप्लॉइट PR को हटा देगा)
|
||||
|
||||
GitHub में एक संगठन खातों की रिपोर्ट करने में बहुत सक्रिय है। आपको बस "कुछ चीजें" Issue में साझा करनी हैं और वे सुनिश्चित करेंगे कि आपका खाता 12 घंटे में निलंबित हो जाए :p और आपके पास है, अपने शोषण को github पर अदृश्य बना दिया।
|
||||
GitHub में एक संगठन खातों की रिपोर्ट करने में बहुत सक्रिय है। आपको बस "कुछ चीजें" Issue में साझा करनी हैं और वे सुनिश्चित करेंगे कि आपका खाता 12 घंटे में सस्पेंड हो जाए :p और वहां आपने, अपने एक्सप्लॉइट को github पर अदृश्य बना दिया।
|
||||
|
||||
> [!WARNING]
|
||||
> एक संगठन के लिए यह पता लगाने का एकमात्र तरीका कि उन्हें लक्षित किया गया है, SIEM से GitHub लॉग की जांच करना है क्योंकि GitHub UI से PR हटा दिया जाएगा।
|
||||
|
||||
## उपकरण
|
||||
|
||||
निम्नलिखित उपकरण GitHub Action वर्कफ़्लो खोजने और यहां तक कि कमजोर लोगों को खोजने के लिए उपयोगी हैं:
|
||||
|
||||
- [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)
|
||||
> एक संगठन के लिए यह पता लगाने का एकमात्र तरीका है कि वे लक्षित हुए हैं, SIEM से GitHub लॉग की जांच करना है क्योंकि GitHub UI से PR हटा दिया जाएगा।
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user