GCP <--> Workspace Pivoting
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)
Google Workspace का Domain-Wide delegation एक पहचान वस्तु, चाहे वह external app हो जो Google Workspace Marketplace से हो या एक आंतरिक GCP Service Account, को उपयोगकर्ताओं की ओर से Workspace में डेटा तक पहुंचने की अनुमति देता है।
इसका मतलब यह है कि GCP परियोजनाओं के अंदर service accounts एक संगठन के Workspace उपयोगकर्ताओं की नकल कर सकते हैं (या यहां तक कि किसी अन्य संगठन के उपयोगकर्ताओं की)।
इसके बारे में अधिक जानकारी के लिए कि यह कैसे काम करता है देखें:
GCP - Understanding Domain-Wide Delegationयदि एक हमलावर ने GCP पर कुछ पहुंच को समझौता किया और कंपनी के एक मान्य Workspace उपयोगकर्ता ईमेल (अधिमानतः super admin) को जानता है, तो वह सभी परियोजनाओं की सूची बना सकता है जिन तक उसे पहुंच है, परियोजनाओं के सभी SAs की सूची बना सकता है, देख सकता है कि उसे कौन से service accounts तक पहुंच है, और हर SA के साथ इन सभी चरणों को दोहरा सकता है जिसे वह नकल कर सकता है। उसके पास सभी service accounts की एक सूची और Workspace ईमेल की सूची होने पर, हमलावर प्रत्येक service account के साथ उपयोगकर्ता की नकल करने की कोशिश कर सकता है।
ध्यान दें कि जब डोमेन वाइड डेलीगेशन को कॉन्फ़िगर किया जाता है, तो किसी Workspace उपयोगकर्ता की आवश्यकता नहीं होती है, इसलिए केवल एक मान्य उपयोगकर्ता जानना पर्याप्त और आवश्यक है नकल के लिए। हालांकि, नकली उपयोगकर्ता के विशेषाधिकार का उपयोग किया जाएगा, इसलिए यदि यह Super Admin है तो आप सब कुछ एक्सेस कर सकेंगे। यदि इसके पास कोई पहुंच नहीं है तो यह बेकार होगा।
यह सरल स्क्रिप्ट delegated user के रूप में एक OAuth token उत्पन्न करेगी जिसे आप फिर अन्य Google APIs तक पहुंचने के लिए उपयोग कर सकते हैं या बिना gcloud के:
यह एक उपकरण है जो निम्नलिखित चरणों का पालन करके हमला कर सकता है:
GCP प्रोजेक्ट्स की गणना करें Resource Manager API का उपयोग करके।
प्रत्येक प्रोजेक्ट संसाधन पर इटरेट करें, और GCP सेवा खाता संसाधनों की गणना करें जिन तक प्रारंभिक IAM उपयोगकर्ता की पहुंच है GetIAMPolicy का उपयोग करके।
प्रत्येक सेवा खाता भूमिका पर इटरेट करें, और लक्षित सेवा खाता संसाधन पर serviceAccountKeys.create अनुमति के साथ अंतर्निहित, बुनियादी, और कस्टम भूमिकाएँ खोजें। यह ध्यान रखना चाहिए कि संपादक भूमिका स्वाभाविक रूप से इस अनुमति को रखती है।
प्रत्येक सेवा खाता संसाधन के लिए एक नया KEY_ALG_RSA_2048 निजी कुंजी बनाएं जो IAM नीति में प्रासंगिक अनुमति के साथ पाया गया है।
प्रत्येक नए सेवा खाते पर इटरेट करें और इसके लिए एक JWT ऑब्जेक्ट बनाएं जो SA निजी कुंजी क्रेडेंशियल्स और एक OAuth स्कोप से बना है। एक नए JWT ऑब्जेक्ट को बनाने की प्रक्रिया oauth_scopes.txt सूची से सभी मौजूदा OAuth स्कोप के संयोजनों पर इटरेट करेगी, ताकि सभी प्रतिनिधित्व संभावनाओं को खोजा जा सके। सूची oauth_scopes.txt को उन सभी OAuth स्कोप के साथ अपडेट किया गया है जो हमने Workspace पहचानियों का दुरुपयोग करने के लिए प्रासंगिक पाया है।
_make_authorization_grant_assertion विधि एक लक्षित कार्यक्षेत्र उपयोगकर्ता, जिसे subject के रूप में संदर्भित किया गया है, को घोषित करने की आवश्यकता को प्रकट करती है, ताकि DWD के तहत JWT उत्पन्न किए जा सकें। जबकि यह एक विशिष्ट उपयोगकर्ता की आवश्यकता प्रतीत हो सकती है, यह समझना महत्वपूर्ण है कि DWD एक डोमेन के भीतर हर पहचान को प्रभावित करता है। परिणामस्वरूप, किसी भी डोमेन उपयोगकर्ता के लिए JWT बनाना उस डोमेन में सभी पहचानों को प्रभावित करता है, जो हमारे संयोजन गणना जांच के अनुरूप है। सीधे शब्दों में कहें, एक मान्य Workspace उपयोगकर्ता आगे बढ़ने के लिए पर्याप्त है।
इस उपयोगकर्ता को DeleFriend के config.yaml फ़ाइल में परिभाषित किया जा सकता है। यदि लक्षित कार्यक्षेत्र उपयोगकर्ता पहले से ज्ञात नहीं है, तो उपकरण GCP प्रोजेक्ट्स पर भूमिकाओं के साथ डोमेन उपयोगकर्ताओं को स्कैन करके मान्य कार्यक्षेत्र उपयोगकर्ताओं की स्वचालित पहचान की सुविधा प्रदान करता है। यह फिर से ध्यान देने योग्य है कि JWT डोमेन-विशिष्ट होते हैं और हर उपयोगकर्ता के लिए उत्पन्न नहीं होते; इसलिए, स्वचालित प्रक्रिया प्रति डोमेन एक अद्वितीय पहचान को लक्षित करती है।
प्रत्येक JWT के लिए एक नया बियरर एक्सेस टोकन की गणना करें और टोकन को tokeninfo API के खिलाफ मान्य करें।
Gitlab ने यह Python स्क्रिप्ट बनाई है जो दो चीजें कर सकती है - उपयोगकर्ता निर्देशिका की सूची बनाना और SA क्रेडेंशियल्स और अनुकरण करने के लिए उपयोगकर्ता के साथ एक नया प्रशासनिक खाता बनाना। यहाँ इसका उपयोग कैसे करें:
यह संभव है कि डोमेन वाइड प्रतिनिधित्व की जांच करें https://admin.google.com/u/1/ac/owl/domainwidedelegation.
एक हमलावर जिसके पास GCP प्रोजेक्ट में सेवा खातों को बनाने की क्षमता और GWS के लिए सुपर एडमिन विशेषाधिकार है, वह एक नई प्रतिनिधित्व बना सकता है जो SAs को कुछ GWS उपयोगकर्ताओं का अनुकरण करने की अनुमति देती है:
एक नया सेवा खाता और संबंधित कुंजी जोड़ी उत्पन्न करना: GCP पर, नए सेवा खाता संसाधन या तो इंटरैक्टिव रूप से कंसोल के माध्यम से या सीधे API कॉल और CLI उपकरणों का उपयोग करके प्रोग्रामेटिक रूप से उत्पन्न किए जा सकते हैं। इसके लिए भूमिका iam.serviceAccountAdmin या किसी भी कस्टम भूमिका की आवश्यकता होती है जिसमें iam.serviceAccounts.create अनुमति हो। एक बार सेवा खाता बन जाने के बाद, हम एक संबंधित कुंजी जोड़ी उत्पन्न करने के लिए आगे बढ़ेंगे (iam.serviceAccountKeys.create अनुमति)।
नई प्रतिनिधित्व का निर्माण: यह समझना महत्वपूर्ण है कि केवल सुपर एडमिन भूमिका के पास Google Workspace में वैश्विक डोमेन-व्यापी प्रतिनिधित्व स्थापित करने की क्षमता है और डोमेन-व्यापी प्रतिनिधित्व प्रोग्रामेटिक रूप से स्थापित नहीं किया जा सकता, इसे केवल Google Workspace कंसोल के माध्यम से हाथ से बनाया और समायोजित किया जा सकता है।
नियम का निर्माण API नियंत्रण → Google Workspace Admin कंसोल में डोमेन-व्यापी प्रतिनिधित्व प्रबंधित करें पृष्ठ के तहत पाया जा सकता है।
OAuth स्कोप विशेषाधिकार संलग्न करना: एक नई प्रतिनिधित्व को कॉन्फ़िगर करते समय, Google को केवल 2 पैरामीटर की आवश्यकता होती है, क्लाइंट आईडी, जो GCP सेवा खाता संसाधन का OAuth आईडी है, और OAuth स्कोप जो परिभाषित करता है कि प्रतिनिधित्व को कौन से API कॉल की आवश्यकता है।
OAuth स्कोप की पूरी सूची यहाँ पाई जा सकती है, लेकिन यहाँ एक सिफारिश है: https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid
लक्ष्य पहचान के पक्ष में कार्य करना: इस बिंदु पर, हमारे पास GWS में एक कार्यशील प्रतिनिधित्व वस्तु है। अब, GCP सेवा खाता निजी कुंजी का उपयोग करके, हम API कॉल कर सकते हैं (OAuth स्कोप पैरामीटर में परिभाषित स्कोप में) इसे सक्रिय करने के लिए और Google Workspace में मौजूद किसी भी पहचान के पक्ष में कार्य कर सकते हैं। जैसा कि हमने सीखा, सेवा खाता अपनी आवश्यकताओं के अनुसार और REST API अनुप्रयोगों के लिए उसके पास मौजूद अनुमति के अनुसार एक्सेस टोकन उत्पन्न करेगा।
इस प्रतिनिधित्व का उपयोग करने के लिए कुछ उपकरणों के लिए पिछले अनुभाग की जांच करें।
OAuth SA ID वैश्विक है और इसका उपयोग क्रॉस-ऑर्गनाइजेशनल प्रतिनिधित्व के लिए किया जा सकता है। क्रॉस-वैश्विक प्रतिनिधित्व को रोकने के लिए कोई प्रतिबंध लागू नहीं किया गया है। सरल शब्दों में, विभिन्न GCP संगठनों के सेवा खातों का उपयोग अन्य Workspace संगठनों पर डोमेन-व्यापी प्रतिनिधित्व कॉन्फ़िगर करने के लिए किया जा सकता है। इसका परिणाम होगा कि Workspace के लिए केवल सुपर एडमिन पहुंच की आवश्यकता है, और उसी GCP खाते तक पहुंच की आवश्यकता नहीं है, क्योंकि प्रतिकूल व्यक्ति अपने व्यक्तिगत रूप से नियंत्रित GCP खाते पर सेवा खातों और निजी कुंजियों को बना सकता है।
डिफ़ॉल्ट रूप से Workspace उपयोगकर्ताओं को नए प्रोजेक्ट बनाने की अनुमति होती है, और जब एक नया प्रोजेक्ट बनाया जाता है तो निर्माता को उस पर मालिक की भूमिका मिलती है।
इसलिए, एक उपयोगकर्ता एक प्रोजेक्ट बना सकता है, अपने नए प्रोजेक्ट में Workspace को सूचीबद्ध करने के लिए APIs को सक्षम कर सकता है और इसे सूचीबद्ध करने का प्रयास कर सकता है।
एक उपयोगकर्ता के लिए Workspace को सूचीबद्ध करने के लिए, उसे पर्याप्त Workspace अनुमतियों की भी आवश्यकता होती है (हर उपयोगकर्ता निर्देशिका को सूचीबद्ध करने में सक्षम नहीं होगा)।
चेक करें और अधिक एन्यूमरेशन में:
GCP - IAM, Principals & Org Policies Enumआप gcloud लॉगिन के प्रवाह के बारे में और जानकारी पा सकते हैं:
जैसा कि वहां समझाया गया है, gcloud स्कोप https://www.googleapis.com/auth/drive का अनुरोध कर सकता है जो एक उपयोगकर्ता को उपयोगकर्ता के ड्राइव तक पहुंचने की अनुमति देगा।
एक हमलावर के रूप में, यदि आपने किसी उपयोगकर्ता के कंप्यूटर को शारीरिक रूप से समझौता किया है और उपयोगकर्ता अभी भी लॉग इन है अपने खाते के साथ, तो आप ड्राइव तक पहुंच के लिए एक टोकन उत्पन्न करके लॉगिन कर सकते हैं:
यदि एक हमलावर एक उपयोगकर्ता के कंप्यूटर को समझौता करता है, तो वह फ़ाइल google-cloud-sdk/lib/googlecloudsdk/core/config.py को भी संशोधित कर सकता है और CLOUDSDK_SCOPES में स्कोप 'https://www.googleapis.com/auth/drive' जोड़ सकता है:
इसलिए, अगली बार जब उपयोगकर्ता लॉग इन करेगा, तो वह ड्राइव तक पहुंच के साथ एक टोकन बनाएगा जिसका उपयोग हमलावर ड्राइव तक पहुंचने के लिए कर सकता है। स्पष्ट रूप से, ब्राउज़र यह संकेत देगा कि उत्पन्न टोकन ड्राइव तक पहुंच रखेगा, लेकिन जब उपयोगकर्ता स्वयं gcloud auth login करेगा, तो वह शायद कुछ भी संदेह नहीं करेगा।
ड्राइव फ़ाइलों की सूची बनाने के लिए: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"
यदि एक हमलावर GWS पर पूर्ण पहुंच रखता है, तो वह GCP पर विशेषाधिकार पहुंच वाले समूहों या यहां तक कि उपयोगकर्ताओं तक पहुंच प्राप्त कर सकेगा, इसलिए GWS से GCP में जाना आमतौर पर अधिक "सरल" होता है क्योंकि GWS में उपयोगकर्ताओं के पास GCP पर उच्च विशेषाधिकार होते हैं।
डिफ़ॉल्ट रूप से, उपयोगकर्ता संगठन के कार्यक्षेत्र समूहों में स्वतंत्र रूप से शामिल हो सकते हैं और उन समूहों को GCP अनुमतियाँ असाइन की जा सकती हैं (अपने समूहों की जांच करें https://groups.google.com/)।
google groups privesc का दुरुपयोग करके, आप GCP पर कुछ प्रकार की विशेषाधिकार पहुंच वाले समूह में वृद्धि करने में सक्षम हो सकते हैं।
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
