Github Security

Reading time: 17 minutes

tip

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

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

What is Github

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

Basic Information

Basic Github Information

External Recon

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

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

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

Github Dorks

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

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

Github Leaks

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

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

warning

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

External Forks

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

Github Leaks in deleted/internal forks

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

Accessible Deleted Data in Github

Organization Hardening

Member Privileges

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

  • Base permissions: सदस्यों को संगठन की रिपॉजिटरी पर None/Read/write/Admin की अनुमति होगी। अनुशंसित है None या Read
  • Repository forking: यदि आवश्यक नहीं है, तो सदस्यों को संगठन की रिपॉजिटरी को फोर्क करने की अनुमति न दें
  • Pages creation: यदि आवश्यक नहीं है, तो सदस्यों को संगठन की रिपॉजिटरी से पृष्ठ प्रकाशित करने की अनुमति न दें। यदि आवश्यक हो, तो आप सार्वजनिक या निजी पृष्ठ बनाने की अनुमति दे सकते हैं।
  • 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 से कॉन्फ़िगर किया जा सकता है।

note

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

  • Github actions policies: यह आपको यह संकेत करने की अनुमति देता है कि कौन सी रिपॉजिटरी कार्यप्रवाह चला सकती हैं और कौन से कार्यप्रवाह की अनुमति दी जानी चाहिए। अनुशंसित है कि कौन सी रिपॉजिटरी की अनुमति दी जानी चाहिए, इसे निर्दिष्ट करें और सभी कार्यों को चलाने की अनुमति न दें।
  • API-1, API-2
  • Fork pull request workflows from outside collaborators: अनुशंसित है कि सभी बाहरी सहयोगियों के लिए अनुमोदन की आवश्यकता हो।
  • मैंने इस जानकारी के साथ कोई API नहीं पाई, यदि आप करते हैं तो साझा करें
  • Run workflows from fork pull requests: यह अत्यधिक निषेधित है कि पुल अनुरोधों से कार्यप्रवाह चलाए जाएं क्योंकि फोर्क मूल के रखरखावकर्ताओं को स्रोत रिपॉजिटरी पर पढ़ने की अनुमतियों के साथ टोकन का उपयोग करने की क्षमता दी जाएगी।
  • मैंने इस जानकारी के साथ कोई 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 का उपयोग किया जा सकता है इसलिए आप केवल तभी इस जानकारी तक पहुँच सकते हैं जब आप उस जांच को भी पास कर सकें।

note

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

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

With User SSH Key

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

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

bash
# 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 कुंजियाँ

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

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

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

With User Token

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

एक यूजर टोकन को पासवर्ड के बजाय Git over 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 ट्रिगर होगा

yaml
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 स्वीकृत न हो, एक कमिट आईडी मूल रेपो के लिए कोड के फोर्क संस्करण के लिए बनाई जाएगी। इसलिए, एक हमलावर ऐसे विशेष कमिट का उपयोग करने के लिए पिन कर सकता है जो एक स्पष्ट रूप से वैध रेपो से है जिसे रेपो के मालिक द्वारा नहीं बनाया गया था

जैसे यह:

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

अधिक जानकारी के लिए देखें https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd

tip

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

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