Basic Github Information
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
एक बड़े कंपनी का बुनियादी गिटहब वातावरण संरचना एक उद्यम है जो कई संगठनों का मालिक है और उनमें से प्रत्येक में कई रिपॉजिटरी और कई टीमें हो सकती हैं। छोटे कंपनियों के पास केवल एक संगठन और कोई उद्यम हो सकता है।
एक उपयोगकर्ता के दृष्टिकोण से, एक उपयोगकर्ता विभिन्न उद्यमों और संगठनों का सदस्य हो सकता है। उनके भीतर, उपयोगकर्ता के पास विभिन्न उद्यम, संगठन और रिपॉजिटरी भूमिकाएँ हो सकती हैं।
इसके अलावा, एक उपयोगकर्ता विभिन्न टीमों का भाग हो सकता है जिनकी विभिन्न उद्यम, संगठन या रिपॉजिटरी भूमिकाएँ हैं।
और अंत में, रिपॉजिटरी में विशेष सुरक्षा तंत्र हो सकते हैं।
Enterprise owner: इस भूमिका वाले लोग प्रशासकों का प्रबंधन कर सकते हैं, उद्यम के भीतर संगठनों का प्रबंधन कर सकते हैं, उद्यम सेटिंग्स का प्रबंधन कर सकते हैं, संगठनों के बीच नीति लागू कर सकते हैं। हालाँकि, वे संगठन सेटिंग्स या सामग्री तक पहुँच नहीं सकते जब तक कि उन्हें संगठन का मालिक नहीं बनाया जाता या संगठन-स्वामित्व वाली रिपॉजिटरी तक सीधी पहुँच नहीं दी जाती।
Enterprise members: आपके उद्यम द्वारा स्वामित्व वाले संगठनों के सदस्य भी स्वचालित रूप से उद्यम के सदस्य होते हैं।
एक संगठन में उपयोगकर्ताओं के पास विभिन्न भूमिकाएँ हो सकती हैं:
Organization owners: संगठन के मालिकों के पास आपके संगठन तक पूर्ण प्रशासनिक पहुँच होती है। इस भूमिका को सीमित किया जाना चाहिए, लेकिन आपके संगठन में दो से कम लोगों के लिए नहीं।
Organization members: डिफ़ॉल्ट, गैर-प्रशासनिक भूमिका संगठन में लोगों के लिए संगठन सदस्य है। डिफ़ॉल्ट रूप से, संगठन के सदस्यों के पास कई अनुमतियाँ होती हैं।
Billing managers: बिलिंग प्रबंधक वे उपयोगकर्ता होते हैं जो आपके संगठन के लिए बिलिंग सेटिंग्स का प्रबंधन कर सकते हैं, जैसे भुगतान जानकारी।
Security Managers: यह एक भूमिका है जिसे संगठन के मालिक किसी भी टीम को सौंप सकते हैं। जब लागू किया जाता है, तो यह टीम के प्रत्येक सदस्य को आपके संगठन में सुरक्षा अलर्ट और सेटिंग्स का प्रबंधन करने की अनुमति देता है, साथ ही संगठन में सभी रिपॉजिटरी के लिए पढ़ने की अनुमतियाँ।
यदि आपके संगठन में एक सुरक्षा टीम है, तो आप सुरक्षा प्रबंधक भूमिका का उपयोग टीम के सदस्यों को संगठन तक पहुँच देने के लिए कर सकते हैं।
Github App managers: अतिरिक्त उपयोगकर्ताओं को संगठन द्वारा स्वामित्व वाले GitHub ऐप्स का प्रबंधन करने की अनुमति देने के लिए, एक मालिक उन्हें GitHub ऐप प्रबंधक अनुमतियाँ दे सकता है।
Outside collaborators: एक बाहरी सहयोगी वह व्यक्ति है जिसके पास एक या अधिक संगठन रिपॉजिटरी तक पहुँच है लेकिन वह स्पष्ट रूप से संगठन का सदस्य नहीं है।
आप इन भूमिकाओं के अनुमतियों की तुलना इस तालिका में कर सकते हैं: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles
https://github.com/organizations/<org_name>/settings/member_privileges में आप देख सकते हैं कि संगठन का हिस्सा होने के नाते उपयोगकर्ताओं के पास क्या अनुमतियाँ होंगी।
यहाँ कॉन्फ़िगर की गई सेटिंग्स संगठन के सदस्यों की निम्नलिखित अनुमतियों को इंगित करेंगी:
सभी संगठन रिपॉजिटरी पर व्यवस्थापक, लेखक, पाठक या कोई अनुमति नहीं होना।
यदि सदस्यों को निजी, आंतरिक या सार्वजनिक रिपॉजिटरी बनाने की अनुमति है।
यदि रिपॉजिटरी का फोर्किंग संभव है।
यदि बाहरी सहयोगियों को आमंत्रित करना संभव है।
यदि सार्वजनिक या निजी साइटों को प्रकाशित किया जा सकता है।
रिपॉजिटरी पर प्रशासकों के पास क्या अनुमतियाँ हैं।
यदि सदस्यों को नई टीमें बनाने की अनुमति है।
डिफ़ॉल्ट रूप से रिपॉजिटरी भूमिकाएँ बनाई जाती हैं:
Read: गैर-कोड योगदानकर्ताओं के लिए अनुशंसित जो आपके प्रोजेक्ट को देखना या उस पर चर्चा करना चाहते हैं।
Triage: योगदानकर्ताओं के लिए अनुशंसित जिन्हें मुद्दों और पुल अनुरोधों का सक्रिय रूप से प्रबंधन करने की आवश्यकता होती है बिना लिखने की पहुँच के।
Write: उन योगदानकर्ताओं के लिए अनुशंसित जो आपके प्रोजेक्ट में सक्रिय रूप से धक्का देते हैं।
Maintain: प्रोजेक्ट प्रबंधकों के लिए अनुशंसित जिन्हें संवेदनशील या विनाशकारी कार्यों तक पहुँच के बिना रिपॉजिटरी का प्रबंधन करने की आवश्यकता होती है।
Admin: उन लोगों के लिए अनुशंसित जिन्हें प्रोजेक्ट तक पूर्ण पहुँच की आवश्यकता होती है, जिसमें सुरक्षा का प्रबंधन या एक रिपॉजिटरी को हटाने जैसे संवेदनशील और विनाशकारी कार्य शामिल हैं।
आप इस तालिका में प्रत्येक भूमिका के अनुमतियों की तुलना कर सकते हैं https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role
आप https://github.com/organizations/<org_name>/settings/roles में अपनी स्वयं की भूमिकाएँ भी बना सकते हैं।
आप https://github.com/orgs/<org_name>/teams में एक संगठन में बनाई गई टीमों की सूची देख सकते हैं। ध्यान दें कि अन्य टीमों के बच्चों को देखने के लिए आपको प्रत्येक माता-पिता टीम तक पहुँचने की आवश्यकता है।
एक संगठन के उपयोगकर्ताओं को https://github.com/orgs/<org_name>/people में सूचीबद्ध किया जा सकता है।
प्रत्येक उपयोगकर्ता की जानकारी में आप देख सकते हैं कि उपयोगकर्ता किस टीम का सदस्य है, और उपयोगकर्ता को किन रिपॉजिटरी तक पहुँच है।
Github आपके खाते में प्रमाणित होने और आपकी ओर से क्रियाएँ करने के लिए विभिन्न तरीके प्रदान करता है।
github.com पर पहुँचते समय आप अपने उपयोगकर्ता नाम और पासवर्ड (और एक 2FA संभावित) का उपयोग करके लॉगिन कर सकते हैं।
आप अपने खाते को एक या एक से अधिक सार्वजनिक कुंजियों के साथ कॉन्फ़िगर कर सकते हैं जिससे संबंधित निजी कुंजी आपकी ओर से क्रियाएँ करने की अनुमति देती है। https://github.com/settings/keys
आप इन कुंजियों के साथ उपयोगकर्ता का प्रतिनिधित्व नहीं कर सकते लेकिन यदि आप इसका उपयोग नहीं करते हैं तो यह संभव हो सकता है कि आप बिना हस्ताक्षर के कमिट भेजने के लिए खोजे जाएँ। विजिलेंट मोड के बारे में अधिक जानें।
आप व्यक्तिगत पहुँच टोकन उत्पन्न कर सकते हैं ताकि एक एप्लिकेशन को आपके खाते तक पहुँच प्रदान की जा सके। व्यक्तिगत पहुँच टोकन बनाते समय, उपयोगकर्ता को अनुमतियों को टोकन के लिए निर्धारित करने की आवश्यकता होती है। https://github.com/settings/tokens
Oauth एप्लिकेशन आपसे अनुमतियाँ मांग सकते हैं आपकी गिटहब जानकारी के एक भाग तक पहुँचने या आपको प्रतिनिधित्व करने के लिए कुछ क्रियाएँ करने के लिए। इस कार्यक्षमता का एक सामान्य उदाहरण गिटहब के साथ लॉगिन बटन है जो आप कुछ प्लेटफार्मों पर पा सकते हैं।
आप https://github.com/settings/developers में अपने स्वयं के Oauth एप्लिकेशन बना सकते हैं।
आप https://github.com/settings/applications में अपने खाते तक पहुँच रखने वाले सभी Oauth एप्लिकेशन देख सकते हैं।
आप https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps में Oauth ऐप्स के लिए पूछे जाने वाले स्कोप देख सकते हैं।
आप https://github.com/organizations/<org_name>/settings/oauth_application_policy में एक संगठन में एप्लिकेशनों की तीसरे पक्ष की पहुँच देख सकते हैं।
कुछ सुरक्षा सिफारिशें:
एक OAuth App को हमेशा GitHub पर सभी GitHub उपयोगकर्ता के रूप में कार्य करना चाहिए (उदाहरण के लिए, जब उपयोगकर्ता सूचनाएँ प्रदान करते हैं) और केवल निर्दिष्ट स्कोप तक पहुँच के साथ।
एक OAuth App को एक पहचान प्रदाता के रूप में उपयोग किया जा सकता है जो प्रमाणित उपयोगकर्ता के लिए "GitHub के साथ लॉगिन" सक्षम करता है।
नहीं बनाएं एक OAuth App यदि आप चाहते हैं कि आपका एप्लिकेशन एकल रिपॉजिटरी पर कार्य करे। repo OAuth स्कोप के साथ, OAuth Apps प्रमाणित उपयोगकर्ता के सभी रिपॉजिटरी पर कार्य कर सकते हैं।
नहीं बनाएं एक OAuth App जो आपके टीम या कंपनी के लिए एक एप्लिकेशन के रूप में कार्य करे। OAuth Apps एक एकल उपयोगकर्ता के रूप में प्रमाणित होते हैं, इसलिए यदि एक व्यक्ति कंपनी के उपयोग के लिए एक OAuth App बनाता है, और फिर वह कंपनी छोड़ देता है, तो कोई और इसके लिए पहुँच नहीं रखेगा।
अधिक यहाँ यहाँ।
Github एप्लिकेशन आपकी गिटहब जानकारी तक पहुँचने या आपको प्रतिनिधित्व करने के लिए अनुमतियाँ मांग सकते हैं ताकि विशिष्ट संसाधनों पर विशिष्ट क्रियाएँ की जा सकें। Github Apps में आपको उन रिपॉजिटरी को निर्दिष्ट करना होगा जिन तक ऐप पहुँच रखेगा।
एक GitHub ऐप स्थापित करने के लिए, आपको संगठन का मालिक या एक रिपॉजिटरी में प्रशासनिक अनुमतियाँ होनी चाहिए।
GitHub ऐप को एक व्यक्तिगत खाते या एक संगठन से कनेक्ट करना चाहिए।
आप https://github.com/settings/apps में अपना स्वयं का Github एप्लिकेशन बना सकते हैं।
आप https://github.com/settings/apps/authorizations में अपने खाते तक पहुँच रखने वाले सभी Github एप्लिकेशन देख सकते हैं।
ये हैं Github एप्लिकेशनों के लिए API एंडपॉइंट्स https://docs.github.com/en/rest/overview/endpoints-available-for-github-app। ऐप की अनुमतियों के आधार पर, यह उनमें से कुछ तक पहुँच प्राप्त कर सकेगा।
आप https://github.com/organizations/<org_name>/settings/installations में एक संगठन में स्थापित ऐप्स देख सकते हैं।
कुछ सुरक्षा सिफारिशें:
एक GitHub ऐप को एक उपयोगकर्ता से स्वतंत्र रूप से कार्य करना चाहिए (जब तक ऐप उपयोगकर्ता-से-सरवर टोकन का उपयोग नहीं कर रहा है)। उपयोगकर्ता-से-सरवर पहुँच टोकन को अधिक सुरक्षित रखने के लिए, आप ऐसे पहुँच टोकन का उपयोग कर सकते हैं जो 8 घंटे बाद समाप्त हो जाएँगे, और एक रिफ्रेश टोकन जो नए पहुँच टोकन के लिए विनिमय किया जा सकता है। अधिक जानकारी के लिए, "उपयोगकर्ता-से-सरवर पहुँच टोकन को ताज़ा करना" देखें।
सुनिश्चित करें कि GitHub ऐप विशिष्ट रिपॉजिटरी के साथ एकीकृत है।
GitHub ऐप को एक व्यक्तिगत खाते या एक संगठन से कनेक्ट करना चाहिए।
GitHub ऐप से यह उम्मीद न करें कि वह सब कुछ जानता है और वह सब कुछ कर सकता है जो एक उपयोगकर्ता कर सकता है।
यदि आपको केवल "GitHub के साथ लॉगिन" सेवा की आवश्यकता है तो GitHub ऐप का उपयोग न करें। लेकिन एक GitHub ऐप एक उपयोगकर्ता पहचान प्रवाह का उपयोग करके उपयोगकर्ताओं को लॉगिन कर सकता है और अन्य चीजें कर सकता है।
यदि आप अपने ऐप का उपयोग GitHub Actions के साथ कर रहे हैं और वर्कफ़्लो फ़ाइलों को संशोधित करना चाहते हैं, तो आपको एक OAuth टोकन के माध्यम से उपयोगकर्ता की ओर से प्रमाणित करना होगा जिसमें workflow स्कोप शामिल है। उपयोगकर्ता को उस रिपॉजिटरी में प्रशासनिक या लिखने की अनुमति होनी चाहिए जिसमें वर्कफ़्लो फ़ाइल है। अधिक जानकारी के लिए, "OAuth ऐप्स के लिए स्कोप को समझना" देखें।
अधिक यहाँ यहाँ।
यह गिटहब में प्रमाणित होने का एक तरीका नहीं है, लेकिन एक दुष्ट GitHub Action गिटहब तक अनधिकृत पहुँच प्राप्त कर सकता है और अनुमतियों के आधार पर जो Action को दी गई हैं, कई विभिन्न हमले किए जा सकते हैं। अधिक जानकारी के लिए नीचे देखें।
Git actions जब कोई घटना होती है तब कोड के निष्पादन को स्वचालित करने की अनुमति देते हैं। आमतौर पर निष्पादित कोड रिपॉजिटरी के कोड से किसी न किसी तरह संबंधित होता है (शायद एक डॉकर कंटेनर बनाना या यह जांचना कि PR में कोई रहस्य नहीं है)।
https://github.com/organizations/<org_name>/settings/actions में संगठन के लिए गिटहब क्रियाओं की कॉन्फ़िगरेशन की जाँच करना संभव है।
गिटहब क्रियाओं के उपयोग को पूरी तरह से अस्वीकार करना, सभी गिटहब क्रियाओं की अनुमति देना, या केवल कुछ क्रियाओं की अनुमति देना संभव है।
यह भी संभव है कि किसे GitHub Action चलाने के लिए अनुमोदन की आवश्यकता है और जब GitHub Action चलाया जाता है तो GITHUB_TOKEN की अनुमतियाँ कॉन्फ़िगर की जा सकें।
GitHub Action आमतौर पर गिटहब या तीसरे पक्ष के एप्लिकेशनों के साथ बातचीत करने के लिए कुछ प्रकार के रहस्यों की आवश्यकता होती है। उन्हें स्पष्ट पाठ में रखने से बचने के लिए, गिटहब उन्हें Secrets के रूप में रखने की अनुमति देता है।
ये रहस्य रिपॉजिटरी या सभी संगठन के लिए कॉन्फ़िगर किए जा सकते हैं। फिर, Action को रहस्य तक पहुँच प्राप्त करने के लिए आपको इसे इस तरह घोषित करने की आवश्यकता है:
Secrets केवल उन Github Actions से एक्सेस किए जा सकते हैं जिनमें उन्हें घोषित किया गया है।
एक बार जब उन्हें repo या संगठनों में कॉन्फ़िगर किया जाता है, तो github के उपयोगकर्ता उन्हें फिर से एक्सेस नहीं कर पाएंगे, वे केवल उन्हें बदलने में सक्षम होंगे।
इसलिए, github secrets चुराने का एकमात्र तरीका है कि आप उस मशीन तक पहुँच सकें जो Github Action को निष्पादित कर रही है (उस परिदृश्य में आप केवल Action के लिए घोषित किए गए secrets तक पहुँच पाएंगे)।
Github पर्यावरण बनाने की अनुमति देता है जहाँ आप secrets को सहेज सकते हैं। फिर, आप github action को पर्यावरण के अंदर secrets तक पहुँच देने के लिए कुछ इस तरह कर सकते हैं:
You can configure an environment to be accessed by all branches (default), only protected branches or specify which branches can access it. It can also set a number of required reviews before executing an action using an environment or wait some time before allowing deployments to proceed.
A Github Action can be executed inside the github environment or can be executed in a third party infrastructure configured by the user.
Several organizations will allow to run Github Actions in a third party infrastructure as it use to be cheaper.
You can list the self-hosted runners of an organization in https://github.com/organizations/<org_name>/settings/actions/runners
The way to find which Github Actions are being executed in non-github infrastructure is to search for runs-on: self-hosted in the Github Action configuration yaml.
It's not possible to run a Github Action of an organization inside a self hosted box of a different organization because a unique token is generated for the Runner when configuring it to know where the runner belongs.
If the custom Github Runner is configured in a machine inside AWS or GCP for example, the Action could have access to the metadata endpoint and steal the token of the service account the machine is running with.
If all actions (or a malicious action) are allowed a user could use a Github action that is malicious and will compromise the container where it's being executed.
A malicious Github Action run could be abused by the attacker to:
Steal all the secrets the Action has access to
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 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.
The branch protections of a repository can be found in https://github.com/<orgname>/<reponame>/settings/branches
It's not possible to set a branch protection at organization level. So all of them must be declared on each repo.
Different protections can be applied to a branch (like to master):
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 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 needs to pass before being able to merge the commit (like a github action checking there isn't any cleartext secret).
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.
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.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
