Github Security
What is Github
(From here) At a high level, GitHub एक वेबसाइट और क्लाउड-आधारित सेवा है जो डेवलपर्स को उनके कोड को स्टोर और प्रबंधित करने में मदद करती है, साथ ही उनके कोड में परिवर्तनों को ट्रैक और नियंत्रित करने में भी।
Basic Information
Basic Github InformationExternal Recon
Github repositories को सार्वजनिक, निजी और आंतरिक के रूप में कॉन्फ़िगर किया जा सकता है।
Private का मतलब है कि केवल संस्थान के लोग ही इन तक पहुँच सकते हैं।
Internal का मतलब है कि केवल उद्यम के लोग (एक उद्यम में कई संस्थान हो सकते हैं) ही इसे एक्सेस कर सकते हैं।
Public का मतलब है कि सभी इंटरनेट इसे एक्सेस कर सकेगा।
यदि आप जानते हैं कि कौन सा उपयोगकर्ता, रिपॉजिटरी या संगठन आप लक्षित करना चाहते हैं, तो आप github dorks का उपयोग करके संवेदनशील जानकारी खोज सकते हैं या प्रत्येक रिपॉजिटरी पर संवेदनशील जानकारी लीक के लिए खोज सकते हैं।
Github Dorks
Github आपको किसी चीज़ को खोजने की अनुमति देता है, जिसमें एक उपयोगकर्ता, एक रिपॉजिटरी या एक संगठन को स्कोप के रूप में निर्दिष्ट किया गया है। इसलिए, संवेदनशील जानकारी के करीब आने वाले स्ट्रिंग्स की एक सूची के साथ, आप आसानी से अपने लक्ष्य में संभावित संवेदनशील जानकारी खोज सकते हैं।
Tools (प्रत्येक टूल में इसके dorks की सूची होती है):
Github Leaks
कृपया ध्यान दें कि github dorks का उपयोग लीक खोजने के लिए भी किया जाता है, जो github खोज विकल्पों का उपयोग करते हैं। यह अनुभाग उन उपकरणों के लिए समर्पित है जो प्रत्येक रिपॉजिटरी को डाउनलोड करेंगे और उनमें संवेदनशील जानकारी की खोज करेंगे (यहां तक कि कुछ गहराई की कमिट्स की जांच भी करेंगे)।
Tools (प्रत्येक टूल में इसके regexes की सूची होती है):
जब आप किसी रिपॉजिटरी में लीक की खोज करते हैं और कुछ ऐसा चलाते हैं जैसे git log -p
तो न भूलें कि वहाँ अन्य शाखाएँ हो सकती हैं जिनमें अन्य कमिट्स हो सकते हैं जिनमें रहस्य हो सकते हैं!
External Forks
यह पुल अनुरोधों का दुरुपयोग करके रिपॉजिटरी को समझौता करना संभव है। यह जानने के लिए कि क्या कोई रिपॉजिटरी कमजोर है, आपको ज्यादातर Github Actions yaml कॉन्फ़िग्स को पढ़ने की आवश्यकता है। इससे संबंधित अधिक जानकारी नीचे।
Github Leaks in deleted/internal forks
यहां तक कि यदि यह हटा दिया गया है या आंतरिक है, तो github रिपॉजिटरी के forks से संवेदनशील डेटा प्राप्त करना संभव हो सकता है। इसे यहां देखें:
Accessible Deleted Data in GithubOrganization 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 प्रतिक्रिया में यह जानकारी नहीं पाई, यदि आप पाते हैं तो साझा करें
More things can be configured in this page but the previous are the ones more security related.
Actions Settings
कई सुरक्षा से संबंधित सेटिंग्स को पृष्ठ 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: यह अत्यधिक निषेधित है कि पुल अनुरोधों से कार्यप्रवाह चलाए जाएं क्योंकि fork मूल के रखरखावकर्ताओं को स्रोत रिपॉजिटरी पर पढ़ने के अधिकारों के साथ टोकन का उपयोग करने की अनुमति दी जाएगी।
मैंने इस जानकारी के साथ कोई API नहीं पाई, यदि आप पाते हैं तो साझा करें
Workflow permissions: यह अत्यधिक अनुशंसित है कि केवल पढ़ने की रिपॉजिटरी अनुमतियाँ दी जाएं। GITHUB_TOKEN का दुरुपयोग करने से बचने के लिए लिखने और पुल अनुरोधों को बनाने/स्वीकृत करने की अनुमति देना हतोत्साहित किया जाता है।
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 तक पहुँचने के लिए नहीं कर सकते हैं ताकि वातावरण को सूचीबद्ध किया जा सके। हालाँकि, आप स्थानीय सेटिंग्स को सूचीबद्ध कर सकते हैं ताकि उन रिपॉजिटरी और उपयोगकर्ता के बारे में जानकारी प्राप्त की जा सके जिन तक आपकी पहुँच है:
यदि उपयोगकर्ता ने अपना उपयोगकर्ता नाम अपने github उपयोगकर्ता नाम के रूप में कॉन्फ़िगर किया है, तो आप उसके खाते में सेट किए गए सार्वजनिक कुंजियों को https://github.com/<github_username>.keys पर एक्सेस कर सकते हैं, आप यह पुष्टि करने के लिए इसे चेक कर सकते हैं कि जो निजी कुंजी आपने पाई है वह उपयोग की जा सकती है।
SSH कुंजियाँ को डिप्लॉय कुंजियों के रूप में रिपॉजिटरी में भी सेट किया जा सकता है। इस कुंजी तक पहुँच रखने वाला कोई भी व्यक्ति एक रिपॉजिटरी से प्रोजेक्ट लॉन्च कर सकेगा। आमतौर पर, विभिन्न डिप्लॉय कुंजियों के साथ एक सर्वर में स्थानीय फ़ाइल ~/.ssh/config
आपको संबंधित कुंजी के बारे में जानकारी देगी।
GPG कुंजियाँ
जैसा कि यहाँ समझाया गया है, कभी-कभी कमिट्स पर हस्ताक्षर करना आवश्यक होता है या आप खोजे जा सकते हैं।
स्थानीय रूप से चेक करें कि क्या वर्तमान उपयोगकर्ता के पास कोई कुंजी है:
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 ActionsBranch 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 ट्रिगर होगा।
Note that branch के निर्माण के बाद branch सुरक्षा नए branch पर लागू होगी और आप इसे संशोधित नहीं कर पाएंगे, लेकिन उस समय तक आप पहले ही रहस्यों को डंप कर चुके होंगे।
Persistence
उपयोगकर्ता टोकन उत्पन्न करें
रहस्यों से github टोकन चुराएं
कार्यप्रवाह परिणामों और branches का हटाना
सभी संगठन को अधिक अनुमतियाँ दें
जानकारी को बाहर निकालने के लिए webhooks बनाएं
बाहरी सहयोगियों को आमंत्रित करें
SIEM द्वारा उपयोग किए गए webhooks को हटाएं
बैकडोर के साथ Github Action बनाएं/संशोधित करें
गुप्त मान संशोधन के माध्यम से कमांड इंजेक्शन के लिए कमजोर Github Action खोजें
Imposter Commits - repo commits के माध्यम से बैकडोर
Github में fork से repo के लिए एक PR बनाना संभव है। भले ही PR स्वीकृत न हो, एक commit आईडी मूल repo के लिए fork संस्करण के लिए बनाई जाएगी। इसलिए, एक हमलावर ऐसे विशेष commit का उपयोग करने के लिए पिन कर सकता है जो एक स्पष्ट रूप से वैध repo से है जिसे repo के मालिक द्वारा नहीं बनाया गया था।
जैसे यह:
For more info check https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd
Last updated