Github Security

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

What is Github

(From here) At a high level, GitHub एक वेबसाइट और क्लाउड-आधारित सेवा है जो डेवलपर्स को उनके कोड को स्टोर और प्रबंधित करने में मदद करती है, साथ ही उनके कोड में परिवर्तनों को ट्रैक और नियंत्रित करने में भी।

Basic Information

Basic Github Information

External Recon

Github repositories को सार्वजनिक, निजी और आंतरिक के रूप में कॉन्फ़िगर किया जा सकता है।

• Private का मतलब है कि केवल संस्थान के लोग ही उन्हें एक्सेस कर सकेंगे।

• Internal का मतलब है कि केवल उद्यम के लोग (एक उद्यम में कई संस्थान हो सकते हैं) इसे एक्सेस कर सकेंगे।

• Public का मतलब है कि सभी इंटरनेट इसे एक्सेस कर सकेगा।

यदि आप जानते हैं कि कौन सा उपयोगकर्ता, रिपॉजिटरी या संगठन आप लक्षित करना चाहते हैं, तो आप github dorks का उपयोग करके संवेदनशील जानकारी खोज सकते हैं या प्रत्येक रिपॉजिटरी पर संवेदनशील जानकारी लीक के लिए खोज सकते हैं।

Github Dorks

Github किसी चीज़ को खोजने की अनुमति देता है, जिसमें एक उपयोगकर्ता, एक रिपॉजिटरी या एक संगठन को स्कोप के रूप में निर्दिष्ट किया गया है। इसलिए, संवेदनशील जानकारी के करीब आने वाले स्ट्रिंग्स की एक सूची के साथ, आप आसानी से अपने लक्ष्य में संभावित संवेदनशील जानकारी खोज सकते हैं।

Tools (प्रत्येक टूल में इसके dorks की सूची होती है):

• https://github.com/obheda12/GitDorker (Dorks list)

• https://github.com/techgaun/github-dorks (Dorks list)

• https://github.com/hisxo/gitGraber (Dorks list)

Github Leaks

कृपया ध्यान दें कि github dorks का उपयोग लीक खोजने के लिए भी किया जाता है, जो github खोज विकल्पों का उपयोग करते हैं। यह अनुभाग उन उपकरणों के लिए समर्पित है जो प्रत्येक रिपॉजिटरी को डाउनलोड करेंगे और उनमें संवेदनशील जानकारी की खोज करेंगे (यहां तक कि कुछ गहराई के कमिट्स की जांच भी करेंगे)।

Tools (प्रत्येक टूल में इसके regexes की सूची होती है):

• https://github.com/zricethezav/gitleaks

• https://github.com/trufflesecurity/truffleHog

• https://github.com/eth0izzle/shhgit

• https://github.com/michenriksen/gitrob

• https://github.com/anshumanbh/git-all-secrets

• https://github.com/kootenpv/gittyleaks

• https://github.com/awslabs/git-secrets

जब आप किसी रिपॉजिटरी में लीक की तलाश करते हैं और कुछ ऐसा चलाते हैं जैसे git log -p तो न भूलें कि वहाँ अन्य शाखाएँ हो सकती हैं जिनमें अन्य कमिट्स हो सकते हैं जिनमें रहस्य हो सकते हैं!

External Forks

यह पुल अनुरोधों का दुरुपयोग करके रिपॉजिटरी को समझौता करना संभव है। यह जानने के लिए कि क्या कोई रिपॉजिटरी कमजोर है, आपको ज्यादातर Github Actions yaml कॉन्फ़िग्स को पढ़ने की आवश्यकता है। इससे संबंधित अधिक जानकारी नीचे।

Github Leaks in deleted/internal forks

यहां तक कि यदि यह हटा दिया गया है या आंतरिक है, तो github रिपॉजिटरी के forks से संवेदनशील डेटा प्राप्त करना संभव हो सकता है। इसे यहां देखें:

Accessible Deleted Data in Github

Organization Hardening

Member Privileges

संस्थान के सदस्यों को कुछ डिफ़ॉल्ट विशेषाधिकार सौंपे जा सकते हैं। इन्हें पृष्ठ https://github.com/organizations/<org_name>/settings/member_privileges या Organizations API से नियंत्रित किया जा सकता है।

• Base permissions: सदस्यों को org रिपॉजिटरी पर None/Read/write/Admin की अनुमति होगी। अनुशंसित है None या Read।

• Repository forking: यदि आवश्यक नहीं है, तो सदस्यों को संगठन की रिपॉजिटरी को fork करने की अनुमति नहीं देना बेहतर है।

• Pages creation: यदि आवश्यक नहीं है, तो सदस्यों को org रिपॉजिटरी से पृष्ठ प्रकाशित करने की अनुमति नहीं देना बेहतर है। यदि आवश्यक हो, तो आप सार्वजनिक या निजी पृष्ठ बनाने की अनुमति दे सकते हैं।

• Integration access requests: यदि यह सक्षम है, तो बाहरी सहयोगियों को इस संगठन और इसके संसाधनों तक पहुँच के लिए GitHub या OAuth ऐप्स के लिए अनुरोध करने की अनुमति होगी। यह आमतौर पर आवश्यक होता है, लेकिन यदि नहीं, तो इसे बंद करना बेहतर है।

• मैंने APIs प्रतिक्रिया में यह जानकारी नहीं पाई, यदि आप पाते हैं तो साझा करें

• Repository visibility change: यदि सक्षम है, तो सदस्य जिनके पास रिपॉजिटरी के लिए admin अनुमतियाँ हैं, वे इसके दृश्यता को बदलने में सक्षम होंगे। यदि अक्षम है, तो केवल संगठन के मालिक ही रिपॉजिटरी की दृश्यता बदल सकते हैं। यदि आप नहीं चाहते कि लोग चीजों को सार्वजनिक बनाएं, तो सुनिश्चित करें कि यह अक्षम है।

• मैंने APIs प्रतिक्रिया में यह जानकारी नहीं पाई, यदि आप पाते हैं तो साझा करें

• Repository deletion and transfer: यदि सक्षम है, तो सदस्यों के पास admin अनुमतियाँ होने पर वे सार्वजनिक और निजी रिपॉजिटरी को हटाने या स्थानांतरित करने में सक्षम होंगे।

• मैंने APIs प्रतिक्रिया में यह जानकारी नहीं पाई, यदि आप पाते हैं तो साझा करें

• Allow members to create teams: यदि सक्षम है, तो संगठन का कोई भी सदस्य नए टीम बनाने में सक्षम होगा। यदि अक्षम है, तो केवल संगठन के मालिक नए टीम बना सकते हैं। इसे अक्षम रखना बेहतर है।

• मैंने APIs प्रतिक्रिया में यह जानकारी नहीं पाई, यदि आप पाते हैं तो साझा करें

• इस पृष्ठ पर और भी चीजें कॉन्फ़िगर की जा सकती हैं लेकिन पिछले अधिकतर सुरक्षा से संबंधित हैं।

Actions Settings

कई सुरक्षा से संबंधित सेटिंग्स को पृष्ठ https://github.com/organizations/<org_name>/settings/actions से कॉन्फ़िगर किया जा सकता है।

ध्यान दें कि ये सभी कॉन्फ़िगरेशन प्रत्येक रिपॉजिटरी पर स्वतंत्र रूप से भी सेट किए जा सकते हैं

• Github actions policies: यह आपको यह संकेत देने की अनुमति देता है कि कौन सी रिपॉजिटरी कार्यप्रवाह चला सकती हैं और कौन से कार्यप्रवाह की अनुमति होनी चाहिए। अनुशंसित है कि कौन सी रिपॉजिटरी की अनुमति दी जानी चाहिए, इसे निर्दिष्ट करें और सभी कार्यों को चलाने की अनुमति न दें।

• API-1, API-2

• Fork pull request workflows from outside collaborators: अनुशंसित है कि सभी बाहरी सहयोगियों के लिए अनुमोदन की आवश्यकता हो।

• मैंने इस जानकारी के साथ कोई API नहीं पाई, यदि आप पाते हैं तो साझा करें

• Run workflows from fork pull requests: यह अत्यधिक निषेधित है कि पुल अनुरोधों से कार्यप्रवाह चलाए जाएं क्योंकि fork मूल के रखरखावकर्ताओं को स्रोत रिपॉजिटरी पर पढ़ने की अनुमतियों के साथ टोकन का उपयोग करने की क्षमता दी जाएगी।

• मैंने इस जानकारी के साथ कोई API नहीं पाई, यदि आप पाते हैं तो साझा करें

• Workflow permissions: यह अत्यधिक अनुशंसित है कि केवल पढ़ने की रिपॉजिटरी अनुमतियाँ दी जाएं। GITHUB_TOKEN के दुरुपयोग से बचने के लिए लिखने और पुल अनुरोधों को बनाने/स्वीकृत करने की अनुमतियाँ देना हतोत्साहित किया जाता है।

• API

Integrations

यदि आप इस जानकारी तक पहुँचने के लिए API एंडपॉइंट जानते हैं तो मुझे बताएं!

• Third-party application access policy: अनुशंसित है कि हर एप्लिकेशन तक पहुँच को प्रतिबंधित करें और केवल आवश्यक एप्लिकेशनों की अनुमति दें (उनकी समीक्षा के बाद)।

• Installed GitHub Apps: अनुशंसित है कि केवल आवश्यक एप्लिकेशनों की अनुमति दें (उनकी समीक्षा के बाद)।

Recon & Attacks abusing credentials

इस परिदृश्य के लिए हम मान लेंगे कि आपने github खाते तक कुछ पहुँच प्राप्त कर ली है।

With User Credentials

यदि आपके पास किसी संगठन के भीतर एक उपयोगकर्ता के लिए क्रेडेंशियल्स हैं, तो आप बस लॉगिन कर सकते हैं और देख सकते हैं कि आपके पास कौन से उद्यम और संगठन की भूमिकाएँ हैं, यदि आप एक सामान्य सदस्य हैं, तो देखें कि सामान्य सदस्यों के पास कौन सी अनुमतियाँ हैं, आप किस समूहों में हैं, आपके पास किस रिपॉजिटरी पर कौन सी अनुमतियाँ हैं, और रिपॉजिटरी कैसे सुरक्षित हैं।

ध्यान दें कि 2FA का उपयोग किया जा सकता है इसलिए आप केवल तभी इस जानकारी तक पहुँच सकते हैं जब आप उस जांच को भी पास कर सकें।

ध्यान दें कि यदि आप user_session कुकी चुराने में सफल होते हैं (जो वर्तमान में SameSite: Lax के साथ कॉन्फ़िगर की गई है) तो आप बिना क्रेडेंशियल्स या 2FA की आवश्यकता के उपयोगकर्ता का पूरी तरह से अनुकरण कर सकते हैं।

यदि यह उपयोगी हो तो branch protections bypasses के बारे में नीचे दिए गए अनुभाग की जांच करें।

With User SSH Key

Github उपयोगकर्ताओं को SSH कुंजी सेट करने की अनुमति देता है जो उनके पक्ष में कोड तैनात करने के लिए प्रमाणन विधि के रूप में उपयोग की जाएगी (कोई 2FA लागू नहीं होता)।

इस कुंजी के साथ आप उन रिपॉजिटरी में परिवर्तन कर सकते हैं जहां उपयोगकर्ता के पास कुछ विशेषाधिकार हैं, हालाँकि आप इसका उपयोग github api तक पहुँचने के लिए नहीं कर सकते हैं ताकि वातावरण को सूचीबद्ध किया जा सके। हालाँकि, आप स्थानीय सेटिंग्स को सूचीबद्ध कर सकते हैं ताकि उन रिपॉजिटरी और उपयोगकर्ता के बारे में जानकारी प्राप्त की जा सके जिन तक आपकी पहुँच है:

# Go to the the repository folder
# Get repo config and current user name and email
git config --list

यदि उपयोगकर्ता ने अपना उपयोगकर्ता नाम अपने github उपयोगकर्ता नाम के रूप में कॉन्फ़िगर किया है, तो आप उसके खाते में सेट किए गए सार्वजनिक कुंजियों को https://github.com/<github_username>.keys पर एक्सेस कर सकते हैं, आप यह पुष्टि करने के लिए इसे चेक कर सकते हैं कि जो निजी कुंजी आपने पाई है वह उपयोग की जा सकती है।

SSH कुंजियाँ को डिप्लॉय कुंजियों के रूप में रिपॉजिटरी में भी सेट किया जा सकता है। इस कुंजी तक पहुँच रखने वाला कोई भी व्यक्ति एक रिपॉजिटरी से प्रोजेक्ट लॉन्च कर सकेगा। आमतौर पर विभिन्न डिप्लॉय कुंजियों के साथ एक सर्वर में स्थानीय फ़ाइल ~/.ssh/config आपको कुंजी से संबंधित जानकारी देगी।

GPG कुंजियाँ

जैसा कि यहाँ समझाया गया है, कभी-कभी कमिट्स पर हस्ताक्षर करना आवश्यक होता है या आप खोजे जा सकते हैं।

स्थानीय रूप से चेक करें कि क्या वर्तमान उपयोगकर्ता के पास कोई कुंजी है:

gpg --list-secret-keys --keyid-format=long

With User Token

यूजर टोकन के बारे में बुनियादी जानकारी के लिए यहाँ देखें।

एक यूजर टोकन को पासवर्ड के बजाय Git के लिए HTTPS पर उपयोग किया जा सकता है, या बेसिक ऑथेंटिकेशन के माध्यम से API के लिए प्रमाणित करने के लिए उपयोग किया जा सकता है। इसके साथ जुड़े विशेषाधिकारों के आधार पर, आप विभिन्न क्रियाएँ करने में सक्षम हो सकते हैं।

एक यूजर टोकन इस तरह दिखता है: ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123

With Oauth Application

Github Oauth एप्लिकेशनों के बारे में बुनियादी जानकारी के लिए यहाँ देखें।

एक हमलावर एक दुष्ट Oauth एप्लिकेशन बना सकता है ताकि उन उपयोगकर्ताओं के विशेषाधिकार प्राप्त डेटा/क्रियाओं तक पहुँच प्राप्त कर सके जो संभवतः उन्हें फ़िशिंग अभियान के हिस्से के रूप में स्वीकार करते हैं।

ये हैं Oauth एप्लिकेशन द्वारा अनुरोधित स्कोप। एक को हमेशा स्वीकार करने से पहले अनुरोधित स्कोप की जांच करनी चाहिए।

इसके अलावा, जैसा कि बुनियादी जानकारी में समझाया गया है, संस्थाएँ तीसरे पक्ष के एप्लिकेशनों को जानकारी/रेपो/क्रियाओं तक पहुँच देने/नकारने का अधिकार रखती हैं जो संगठन से संबंधित हैं।

With Github Application

Github एप्लिकेशनों के बारे में बुनियादी जानकारी के लिए यहाँ देखें।

एक हमलावर एक दुष्ट Github एप्लिकेशन बना सकता है ताकि उन उपयोगकर्ताओं के विशेषाधिकार प्राप्त डेटा/क्रियाओं तक पहुँच प्राप्त कर सके जो संभवतः उन्हें फ़िशिंग अभियान के हिस्से के रूप में स्वीकार करते हैं।

इसके अलावा, जैसा कि बुनियादी जानकारी में समझाया गया है, संस्थाएँ तीसरे पक्ष के एप्लिकेशनों को जानकारी/रेपो/क्रियाओं तक पहुँच देने/नकारने का अधिकार रखती हैं जो संगठन से संबंधित हैं।

Compromise & Abuse Github Action

Github Action को समझौता करने और दुरुपयोग करने के लिए कई तकनीकें हैं, उन्हें यहाँ देखें:

Abusing Github Actions

Branch Protection Bypass

• अनुमोदनों की संख्या की आवश्यकता: यदि आपने कई खातों से समझौता किया है, तो आप बस अन्य खातों से अपने PRs को स्वीकार कर सकते हैं। यदि आपके पास केवल वही खाता है जिससे आपने PR बनाया है, तो आप अपने स्वयं के PR को स्वीकार नहीं कर सकते। हालाँकि, यदि आपके पास रेपो के अंदर एक Github Action वातावरण तक पहुँच है, तो GITHUB_TOKEN का उपयोग करते हुए आप अपने PR को अनुमोदित कर सकते हैं और इस तरह 1 अनुमोदन प्राप्त कर सकते हैं।

• इस और कोड मालिकों की प्रतिबंध के लिए नोट करें कि आमतौर पर एक उपयोगकर्ता अपने स्वयं के PRs को अनुमोदित नहीं कर सकेगा, लेकिन यदि आप कर सकते हैं, तो आप इसका दुरुपयोग कर सकते हैं अपने PRs को स्वीकार करने के लिए।

• नए कमिट्स धकेलने पर अनुमोदनों को अस्वीकार करें: यदि यह सेट नहीं है, तो आप वैध कोड सबमिट कर सकते हैं, किसी के अनुमोदित होने की प्रतीक्षा कर सकते हैं, और फिर दुष्ट कोड डाल सकते हैं और इसे संरक्षित शाखा में मिला सकते हैं।

• कोड मालिकों से समीक्षाओं की आवश्यकता: यदि यह सक्रिय है और आप एक कोड मालिक हैं, तो आप एक Github Action बना सकते हैं जो आपका PR बनाए और फिर इसे स्वयं अनुमोदित करें।

• जब एक CODEOWNER फ़ाइल गलत कॉन्फ़िगर की जाती है, Github शिकायत नहीं करता है लेकिन इसका उपयोग नहीं करता है। इसलिए, यदि यह गलत कॉन्फ़िगर है, तो कोड मालिकों की सुरक्षा लागू नहीं होती।

• निर्धारित अभिनेताओं को पुल अनुरोध आवश्यकताओं को बायपास करने की अनुमति दें: यदि आप इनमें से एक अभिनेता हैं, तो आप पुल अनुरोध सुरक्षा को बायपास कर सकते हैं।

• व्यवस्थापकों को शामिल करें: यदि यह सेट नहीं है और आप रेपो के व्यवस्थापक हैं, तो आप इस शाखा की सुरक्षा को बायपास कर सकते हैं।

• PR हाईजैकिंग: आप किसी और के PR को संशोधित करने में सक्षम हो सकते हैं, दुष्ट कोड जोड़कर, परिणामस्वरूप PR को स्वयं अनुमोदित करके और सब कुछ मिला सकते हैं।

• शाखा सुरक्षा को हटाना: यदि आप रेपो के व्यवस्थापक हैं, तो आप सुरक्षा को अक्षम कर सकते हैं, अपने PR को मिला सकते हैं और सुरक्षा को फिर से सेट कर सकते हैं।

• धकेलने की सुरक्षा को बायपास करना: यदि एक रेपो केवल कुछ उपयोगकर्ताओं को शाखाओं में धकेलने (कोड मिलाना) की अनुमति देता है (शाखा सुरक्षा सभी शाखाओं की सुरक्षा कर सकती है जो वाइल्डकार्ड * निर्दिष्ट करती है)।

• यदि आपके पास रेपो पर लिखने की पहुँच है लेकिन आपको कोड धकेलने की अनुमति नहीं है क्योंकि शाखा सुरक्षा है, तो आप अभी भी एक नई शाखा बना सकते हैं और इसके भीतर एक github action बना सकते हैं जो कोड धकेलने पर ट्रिगर होता है। चूंकि शाखा सुरक्षा तब तक शाखा की सुरक्षा नहीं करेगी जब तक कि इसे बनाया न जाए, इस शाखा पर कोड का पहला धक्का github action को निष्पादित करेगा।

Bypass Environments Protections

Github Environment के बारे में बुनियादी जानकारी के लिए यहाँ देखें।

यदि कोई वातावरण सभी शाखाओं से पहुँच योग्य है, तो यह सुरक्षित नहीं है और आप आसानी से वातावरण के अंदर रहस्यों तक पहुँच सकते हैं। ध्यान दें कि आप उन रेपो को पा सकते हैं जहाँ सभी शाखाएँ सुरक्षित हैं (उनके नाम निर्दिष्ट करके या * का उपयोग करके) उस परिदृश्य में, एक शाखा खोजें जहाँ आप कोड धकेल सकते हैं और आप रहस्यों को निकाल सकते हैं एक नया github action बनाकर (या एक को संशोधित करके)।

ध्यान दें, कि आप उस किनारे के मामले को पा सकते हैं जहाँ सभी शाखाएँ सुरक्षित हैं (वाइल्डकार्ड * के माध्यम से) यह निर्दिष्ट किया गया है कौन शाखाओं में कोड धकेल सकता है (आप इसे शाखा सुरक्षा में निर्दिष्ट कर सकते हैं) और आपका उपयोगकर्ता अनुमति नहीं है। आप अभी भी एक कस्टम github action चला सकते हैं क्योंकि आप एक शाखा बना सकते हैं और इसके ऊपर धक्का ट्रिगर का उपयोग कर सकते हैं। शाखा सुरक्षा एक नई शाखा में धकेलने की अनुमति देती है इसलिए github action ट्रिगर होगा।

push: # Run it when a push is made to a branch
branches:
- current_branch_name #Use '**' to run when a push is made to any branch

ध्यान दें कि शाखा के निर्माण के बाद शाखा सुरक्षा नए शाखा पर लागू होगी और आप इसे संशोधित नहीं कर पाएंगे, लेकिन उस समय तक आप पहले ही रहस्यों को डंप कर चुके होंगे।

स्थिरता

• उपयोगकर्ता टोकन उत्पन्न करें

• गिटहब टोकन को रहस्यों से चुराएं

• कार्यप्रवाह परिणामों और शाखाओं का हटाना

• सभी संगठन को अधिक अनुमति दें

• जानकारी को बाहर निकालने के लिए वेबहुक बनाएं

• बाहरी सहयोगियों को आमंत्रित करें

• SIEM द्वारा उपयोग किए गए वेबहुक को हटाएं

• बैकडोर के साथ गिटहब क्रिया बनाएं/संशोधित करें

• गुप्त मान संशोधन के माध्यम से कमांड इंजेक्शन के लिए कमजोर गिटहब क्रिया खोजें

धोखेबाज़ कमिट - रेपो कमिट के माध्यम से बैकडोर

गिटहब में यह संभव है कि एक फोर्क से एक रेपो के लिए PR बनाया जाए। भले ही PR स्वीकृत न हो, एक कमिट आईडी मूल रेपो के लिए कोड के फोर्क संस्करण के लिए बनाई जाएगी। इसलिए, एक हमलावर ऐसे विशेष कमिट का उपयोग करने के लिए पिन कर सकता है जो एक स्पष्ट रूप से वैध रेपो से है जिसे रेपो के मालिक द्वारा नहीं बनाया गया था।

जैसे यह:

name: example
on: [push]
jobs:
commit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e
- shell: bash
run: |
echo 'hello world!'

For more info check https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)

HackTricks का समर्थन करें

• सदस्यता योजनाएँ देखें!

• हमारे 💬 Discord समूह या telegram समूह में शामिल हों या Twitter 🐦 पर हमें फॉलो करें @hacktricks_live.

• हैकिंग ट्रिक्स साझा करें और HackTricks और HackTricks Cloud github repos में PRs सबमिट करें।