Github Security
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)
(From here) At a high level, GitHub एक वेबसाइट और क्लाउड-आधारित सेवा है जो डेवलपर्स को उनके कोड को स्टोर और प्रबंधित करने में मदद करती है, साथ ही उनके कोड में परिवर्तनों को ट्रैक और नियंत्रित करने में भी।
Github repositories को सार्वजनिक, निजी और आंतरिक के रूप में कॉन्फ़िगर किया जा सकता है।
Private का मतलब है कि केवल संस्थान के लोग ही इन तक पहुँच सकते हैं।
Internal का मतलब है कि केवल उद्यम के लोग (एक उद्यम में कई संस्थान हो सकते हैं) ही इसे एक्सेस कर सकते हैं।
Public का मतलब है कि सभी इंटरनेट इसे एक्सेस कर सकेगा।
यदि आप जानते हैं कि कौन सा उपयोगकर्ता, रेपो या संगठन आप लक्षित करना चाहते हैं, तो आप github dorks का उपयोग करके संवेदनशील जानकारी खोज सकते हैं या प्रत्येक रेपो पर संवेदनशील जानकारी लीक के लिए खोज सकते हैं।
Github आपको किसी चीज़ को खोजने की अनुमति देता है, जिसमें एक उपयोगकर्ता, एक रेपो या एक संगठन को स्कोप के रूप में निर्दिष्ट किया गया है। इसलिए, संवेदनशील जानकारी के करीब आने वाले स्ट्रिंग्स की एक सूची के साथ, आप आसानी से अपने लक्ष्य में संभावित संवेदनशील जानकारी खोज सकते हैं।
Tools (प्रत्येक टूल में इसके dorks की सूची होती है):
कृपया ध्यान दें कि github dorks का उपयोग लीक खोजने के लिए भी किया जाता है, जो github खोज विकल्पों का उपयोग करते हैं। यह अनुभाग उन उपकरणों के लिए समर्पित है जो प्रत्येक रेपो को डाउनलोड करेंगे और उनमें संवेदनशील जानकारी की खोज करेंगे (यहां तक कि कमिट्स की निश्चित गहराई की जांच करना)।
Tools (प्रत्येक टूल में इसके regexes की सूची होती है):
जब आप किसी रेपो में लीक की खोज करते हैं और कुछ ऐसा चलाते हैं जैसे git log -p तो न भूलें कि वहाँ अन्य शाखाएँ हो सकती हैं जिनमें अन्य कमिट्स हो सकते हैं जिनमें रहस्य हो सकते हैं!
यह पुल अनुरोधों का दुरुपयोग करके रेपो को समझौता करना संभव है। यह जानने के लिए कि क्या कोई रेपो कमजोर है, आपको ज्यादातर Github Actions yaml कॉन्फ़िगरेशन पढ़ने की आवश्यकता है। इससे संबंधित अधिक जानकारी नीचे है.
यहां तक कि यदि यह हटा दिया गया है या आंतरिक है, तो github रेपो के forks से संवेदनशील डेटा प्राप्त करना संभव हो सकता है। इसे यहाँ देखें:
Accessible Deleted Data in Githubसंस्थान के सदस्यों को कुछ डिफ़ॉल्ट विशेषाधिकार सौंपे जा सकते हैं। इन्हें पृष्ठ 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 प्रतिक्रिया में यह जानकारी नहीं पाई, यदि आप करते हैं तो साझा करें
इस पृष्ठ पर और चीजें कॉन्फ़िगर की जा सकती हैं लेकिन पिछले अधिकतर सुरक्षा से संबंधित हैं।
कई सुरक्षा से संबंधित सेटिंग्स को पृष्ठ https://github.com/organizations/<org_name>/settings/actions से कॉन्फ़िगर किया जा सकता है।
ध्यान दें कि ये सभी कॉन्फ़िगरेशन प्रत्येक रेपो पर स्वतंत्र रूप से भी सेट किए जा सकते हैं
Github actions policies: यह आपको यह संकेत देने की अनुमति देता है कि कौन से रेपो वर्कफ़्लो चला सकते हैं और कौन से वर्कफ़्लो की अनुमति दी जानी चाहिए। अनुशंसित है कि कौन से रेपो की अनुमति दी जानी चाहिए, इसे निर्दिष्ट करें और सभी कार्यों को चलाने की अनुमति न दें।
Fork pull request workflows from outside collaborators: यह अनुशंसित है कि सभी बाहरी सहयोगियों के लिए अनुमोदन की आवश्यकता हो।
मैंने इस जानकारी के साथ कोई API नहीं पाई, यदि आप करते हैं तो साझा करें
Run workflows from fork pull requests: यह अत्यधिक निषेधित है कि पुल अनुरोधों से वर्कफ़्लो चलाए जाएं क्योंकि फोर्क मूल के रखरखावकर्ताओं को स्रोत रेपो पर पढ़ने की अनुमतियों के साथ टोकन का उपयोग करने की क्षमता दी जाएगी।
मैंने इस जानकारी के साथ कोई API नहीं पाई, यदि आप करते हैं तो साझा करें
Workflow permissions: यह अत्यधिक अनुशंसित है कि केवल पढ़ने की रेपो अनुमतियाँ दी जाएं। GITHUB_TOKEN का दुरुपयोग करने से बचने के लिए लिखने और पुल अनुरोधों को बनाने/अनुमोदित करने की अनुमतियाँ देना हतोत्साहित किया जाता है।
यदि आप इस जानकारी तक पहुँचने के लिए API एंडपॉइंट जानते हैं तो मुझे बताएं!
Third-party application access policy: यह अनुशंसित है कि हर एप्लिकेशन तक पहुँच को प्रतिबंधित करें और केवल आवश्यक एप्लिकेशन की अनुमति दें (उनकी समीक्षा के बाद)।
Installed GitHub Apps: यह अनुशंसित है कि केवल आवश्यक एप्लिकेशन की अनुमति दें (उनकी समीक्षा के बाद)।
इस परिदृश्य के लिए हम मान लेंगे कि आपने github खाते तक कुछ पहुँच प्राप्त की है।
यदि आपके पास किसी संगठन के भीतर एक उपयोगकर्ता के लिए क्रेडेंशियल्स हैं, तो आप बस लॉगिन कर सकते हैं और देख सकते हैं कि आपके पास कौन से उद्यम और संगठन भूमिकाएँ हैं, यदि आप एक सामान्य सदस्य हैं, तो देख सकते हैं कि सामान्य सदस्यों के पास कौन सी अनुमतियाँ हैं, आप किस समूहों में हैं, आपके पास किन रेपो पर कौन सी अनुमतियाँ हैं, और रेपो कैसे सुरक्षित हैं।
ध्यान दें कि 2FA का उपयोग किया जा सकता है इसलिए आप केवल तभी इस जानकारी तक पहुँच सकते हैं जब आप उस जांच को भी पास कर सकें।
ध्यान दें कि यदि आप user_session कुकी चुराने में सफल होते हैं (जो वर्तमान में SameSite: Lax के साथ कॉन्फ़िगर की गई है) तो आप बिना क्रेडेंशियल्स या 2FA की आवश्यकता के उपयोगकर्ता का पूरी तरह से अनुकरण कर सकते हैं।
यदि यह उपयोगी हो तो branch protections bypasses के बारे में नीचे दिए गए अनुभाग की जाँच करें।
Github उपयोगकर्ताओं को SSH कुंजी सेट करने की अनुमति देता है जो उनके पक्ष में कोड तैनात करने के लिए प्रमाणन विधि के रूप में उपयोग की जाएगी (कोई 2FA लागू नहीं होता)।
इस कुंजी के साथ आप उन रेपो में परिवर्तन कर सकते हैं जहाँ उपयोगकर्ता के पास कुछ विशेषाधिकार हैं, हालाँकि आप इसका उपयोग github api तक पहुँचने के लिए नहीं कर सकते हैं ताकि वातावरण को सूचीबद्ध किया जा सके। हालाँकि, आप स्थानीय सेटिंग्स को सूचीबद्ध कर सकते हैं ताकि उन रेपो और उपयोगकर्ता के बारे में जानकारी प्राप्त की जा सके जिन तक आपकी पहुँच है:
यदि उपयोगकर्ता ने अपना उपयोगकर्ता नाम अपने github उपयोगकर्ता नाम के रूप में कॉन्फ़िगर किया है, तो आप उसके खाते में सेट किए गए सार्वजनिक कुंजियों को https://github.com/<github_username>.keys पर एक्सेस कर सकते हैं, आप यह पुष्टि करने के लिए इसे चेक कर सकते हैं कि जो निजी कुंजी आपने पाई है वह उपयोग की जा सकती है।
SSH कुंजियाँ को डिप्लॉय कुंजियों के रूप में रिपॉजिटरी में भी सेट किया जा सकता है। इस कुंजी तक पहुँच रखने वाला कोई भी व्यक्ति एक रिपॉजिटरी से प्रोजेक्ट लॉन्च कर सकेगा। आमतौर पर, विभिन्न डिप्लॉय कुंजियों के साथ एक सर्वर में स्थानीय फ़ाइल ~/.ssh/config आपको संबंधित कुंजी के बारे में जानकारी देगी।
जैसा कि यहाँ समझाया गया है, कभी-कभी कमिट्स पर हस्ताक्षर करना आवश्यक होता है या आप खोजे जा सकते हैं।
स्थानीय रूप से चेक करें कि क्या वर्तमान उपयोगकर्ता के पास कोई कुंजी है:
यूजर टोकन के बारे में बुनियादी जानकारी के लिए यहाँ देखें।
एक यूजर टोकन को पासवर्ड के बजाय Git over HTTPS के लिए उपयोग किया जा सकता है, या बेसिक ऑथेंटिकेशन के माध्यम से API के लिए प्रमाणित करने के लिए उपयोग किया जा सकता है। इसके साथ जुड़े विशेषाधिकारों के आधार पर, आप विभिन्न क्रियाएँ करने में सक्षम हो सकते हैं।
एक यूजर टोकन इस तरह दिखता है: ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123
Github Oauth एप्लिकेशनों के बारे में बुनियादी जानकारी के लिए यहाँ देखें।
एक हमलावर एक दुष्ट Oauth एप्लिकेशन बना सकता है ताकि उन उपयोगकर्ताओं के विशेषाधिकार प्राप्त डेटा/क्रियाओं तक पहुँच सके जो संभवतः उन्हें एक फ़िशिंग अभियान के हिस्से के रूप में स्वीकार करते हैं।
ये स्कोप हैं जो एक Oauth एप्लिकेशन अनुरोध कर सकता है। एक को हमेशा स्वीकार करने से पहले अनुरोधित स्कोप की जांच करनी चाहिए।
इसके अलावा, जैसा कि बुनियादी जानकारी में समझाया गया है, संस्थाएँ तीसरे पक्ष के एप्लिकेशनों को जानकारी/रेपोज/क्रियाओं तक पहुँच देने/नकारने का अधिकार रखती हैं जो संगठन से संबंधित हैं।
Github एप्लिकेशनों के बारे में बुनियादी जानकारी के लिए यहाँ देखें।
एक हमलावर एक दुष्ट Github एप्लिकेशन बना सकता है ताकि उन उपयोगकर्ताओं के विशेषाधिकार प्राप्त डेटा/क्रियाओं तक पहुँच सके जो संभवतः उन्हें एक फ़िशिंग अभियान के हिस्से के रूप में स्वीकार करते हैं।
इसके अलावा, जैसा कि बुनियादी जानकारी में समझाया गया है, संस्थाएँ तीसरे पक्ष के एप्लिकेशनों को जानकारी/रेपोज/क्रियाओं तक पहुँच देने/नकारने का अधिकार रखती हैं जो संगठन से संबंधित हैं।
Github Action को समझौता करने और दुरुपयोग करने के लिए कई तकनीकें हैं, उन्हें यहाँ देखें:
Abusing Github Actionsअनुमोदनों की संख्या की आवश्यकता: यदि आपने कई खातों से समझौता किया है, तो आप बस अन्य खातों से अपने PRs को स्वीकार कर सकते हैं। यदि आपके पास केवल वही खाता है जिससे आपने PR बनाया है, तो आप अपने स्वयं के PR को स्वीकार नहीं कर सकते। हालाँकि, यदि आपके पास रेपो के अंदर एक Github Action वातावरण तक पहुँच है, तो GITHUB_TOKEN का उपयोग करते हुए आप अपने PR को अनुमोदित कर सकते हैं और इस तरह 1 अनुमोदन प्राप्त कर सकते हैं।
इस और कोड मालिकों की प्रतिबंध के लिए नोट करें कि आमतौर पर एक उपयोगकर्ता अपने स्वयं के PRs को अनुमोदित नहीं कर सकेगा, लेकिन यदि आप कर सकते हैं, तो आप इसका दुरुपयोग कर सकते हैं अपने PRs को स्वीकार करने के लिए।
नए कमिट्स धकेलने पर अनुमोदनों को अस्वीकार करें: यदि यह सेट नहीं है, तो आप वैध कोड सबमिट कर सकते हैं, किसी के अनुमोदित होने की प्रतीक्षा कर सकते हैं, और फिर दुष्ट कोड डाल सकते हैं और इसे संरक्षित शाखा में मिला सकते हैं।
कोड मालिकों से समीक्षाओं की आवश्यकता: यदि यह सक्रिय है और आप एक कोड मालिक हैं, तो आप एक Github Action बना सकते हैं जो आपका PR बनाए और फिर इसे स्वयं अनुमोदित करें।
जब एक CODEOWNER फ़ाइल गलत कॉन्फ़िगर की जाती है, Github शिकायत नहीं करता है लेकिन इसका उपयोग नहीं करता है। इसलिए, यदि यह गलत कॉन्फ़िगर है, तो कोड मालिकों की सुरक्षा लागू नहीं होती है।
निर्धारित अभिनेताओं को पुल अनुरोध आवश्यकताओं को बायपास करने की अनुमति दें: यदि आप इनमें से एक अभिनेता हैं, तो आप पुल अनुरोध सुरक्षा को बायपास कर सकते हैं।
व्यवस्थापकों को शामिल करें: यदि यह सेट नहीं है और आप रेपो के व्यवस्थापक हैं, तो आप इस शाखा की सुरक्षा को बायपास कर सकते हैं।
PR हाईजैकिंग: आप किसी और के PR को संशोधित करने में सक्षम हो सकते हैं, दुष्ट कोड जोड़कर, परिणामस्वरूप PR को स्वयं अनुमोदित करके और सब कुछ मिला सकते हैं।
शाखा सुरक्षा को हटाना: यदि आप रेपो के व्यवस्थापक हैं, तो आप सुरक्षा को अक्षम कर सकते हैं, अपने PR को मिला सकते हैं और सुरक्षा को फिर से सेट कर सकते हैं।
धकेलने की सुरक्षा को बायपास करना: यदि एक रेपो केवल कुछ उपयोगकर्ताओं को शाखाओं में धकेलने (कोड मिलाना) की अनुमति देता है (शाखा सुरक्षा सभी शाखाओं की सुरक्षा कर सकती है जो वाइल्डकार्ड * निर्दिष्ट करती है)।
यदि आपके पास रेपो पर लिखने की पहुँच है लेकिन आपको कोड धकेलने की अनुमति नहीं है क्योंकि शाखा सुरक्षा के कारण, आप अभी भी एक नई शाखा बना सकते हैं और इसके भीतर एक github action बना सकते हैं जो कोड धकेलने पर ट्रिगर होता है। चूंकि शाखा सुरक्षा तब तक शाखा की सुरक्षा नहीं करेगी जब तक कि इसे बनाया नहीं गया है, इस शाखा में पहले कोड धकेलने से github action निष्पादित होगा।
Github Environment के बारे में बुनियादी जानकारी के लिए यहाँ देखें।
यदि कोई वातावरण सभी शाखाओं से पहुँच योग्य है, तो यह सुरक्षित नहीं है और आप आसानी से वातावरण के अंदर रहस्यों तक पहुँच सकते हैं। ध्यान दें कि आप उन रेपोज़ को पा सकते हैं जहाँ सभी शाखाएँ सुरक्षित हैं (उनके नाम निर्दिष्ट करके या * का उपयोग करके) उस परिदृश्य में, एक शाखा खोजें जहाँ आप कोड धकेल सकते हैं और आप रहस्यों को निकाल सकते हैं एक नया github action बनाकर (या एक को संशोधित करके)।
ध्यान दें, कि आप उस किनारे के मामले को पा सकते हैं जहाँ सभी शाखाएँ सुरक्षित हैं (वाइल्डकार्ड * के माध्यम से) यह निर्दिष्ट किया गया है कौन शाखाओं में कोड धकेल सकता है (आप इसे शाखा सुरक्षा में निर्दिष्ट कर सकते हैं) और आपका उपयोगकर्ता अनुमति नहीं है। आप अभी भी एक कस्टम github action चला सकते हैं क्योंकि आप एक शाखा बना सकते हैं और इसके ऊपर धकेलने के ट्रिगर का उपयोग कर सकते हैं। शाखा सुरक्षा एक नई शाखा में धकेलने की अनुमति देती है इसलिए github action ट्रिगर होगा।
ध्यान दें कि शाखा के निर्माण के बाद शाखा सुरक्षा नए शाखा पर लागू होगी और आप इसे संशोधित नहीं कर पाएंगे, लेकिन उस समय तक आप पहले ही रहस्यों को डंप कर चुके होंगे।
उपयोगकर्ता टोकन उत्पन्न करें
रहस्यों से गिटहब टोकन चुराएं
कार्यप्रवाह परिणामों और शाखाओं का हटाना
सभी संगठन को अधिक अनुमति दें
जानकारी को निकालने के लिए वेबहुक बनाएं
बाहरी सहयोगियों को आमंत्रित करें
SIEM द्वारा उपयोग किए गए वेबहुक को हटाएं
बैकडोर के साथ गिटहब क्रिया बनाएं/संशोधित करें
गुप्त मान संशोधन के माध्यम से कमांड इंजेक्शन के लिए कमजोर गिटहब क्रिया खोजें
गिटहब में यह संभव है कि एक फोर्क से एक रेपो के लिए PR बनाया जाए। भले ही PR स्वीकृत न हो, एक कमिट आईडी मूल रेपो के लिए कोड के फोर्क संस्करण के लिए बनाई जाएगी। इसलिए, एक हमलावर ऐसे विशेष कमिट का उपयोग करने के लिए पिन कर सकता है जो एक स्पष्ट रूप से वैध रेपो से है जिसे रेपो के मालिक द्वारा नहीं बनाया गया था।
जैसे यह:
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)
