GCP <--> Workspace Pivoting

जानें AWS हैकिंग को शून्य से हीरो तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

• यदि आप अपनी कंपनी का विज्ञापन HackTricks में देखना चाहते हैं या HackTricks को PDF में डाउनलोड करना चाहते हैं तो सब्सक्रिप्शन प्लान्स देखें!

• आधिकारिक PEASS & HackTricks स्वैग प्राप्त करें

• हमारे विशेष NFTs कलेक्शन, The PEASS Family खोजें

• शामिल हों 💬 डिस्कॉर्ड समूह या टेलीग्राम समूह या मुझे ट्विटर 🐦 @carlospolopm** पर फॉलो** करें।

• हैकिंग ट्रिक्स साझा करें द्वारा PRs सबमिट करके HackTricks और HackTricks Cloud github repos में।

GCP से GWS तक

डोमेन वाइड डेलीगेशन की मूल बातें

Google Workspace का डोमेन-वाइड डेलीगेशन एक पहचान वस्तु को, या तो Google Workspace Marketplace से एक बाह्य ऐप या एक आंतरिक GCP सेवा खाता, उपयोगकर्ताओं के पक्ष में Workspace पर डेटा तक पहुंचने की अनुमति देता है।

यह मुख्य रूप से यह अर्थ है कि सेवा खाते जो किसी संगठन के GCP परियोजनाओं में हो सकते हैं, वे उसी संगठन के Workspace उपयोगकर्ताओं का अनुकरण कर सकते हैं (या यहां तक कि एक अलग संगठन से भी)।

इसके बारे में अधिक जानकारी के लिए यह सुनिश्चित करें:

pageGCP - Understanding Domain-Wide Delegation

मौजूदा डेलीगेशन को क्षति पहुंचाएं

यदि किसी हमलावर ने GCP पर कुछ पहुंच हासिल किया है और किसी मान्य Workspace उपयोगकर्ता ईमेल (पसंदीदा सुपर व्यवस्थापक हो) का पता लगाया है, तो वह उन सभी परियोजनाओं की सूची को जांच सकता है जिनका उसे पहुंच है, सभी SAs की सूची को जांच सकता है, जांच सकता है कि किस सेवा खातों का उसे पहुंच है, और प्रत्येक SA के साथ इन सभी कदमों को दोहराने की कोशिश कर सकता है। उसके पास उपयोग के लिए सभी सेवा खातों की सूची है और Workspace ईमेल की सूची है, हमलावर को प्रत्येक सेवा खाते के साथ उपयोगकर्ता का अनुकरण करने की कोशिश कर सकता है।

ध्यान दें कि डोमेन वाइड डेलीगेशन को कॉन्फ़िगर करते समय कोई Workspace उपयोगकर्ता की आवश्यकता नहीं है, इसलिए एक मान्य उपयोगकर्ता का पता चलाना केवल एक ही पर्याप्त है और अनुकरण के लिए आवश्यक है। हालांकि, अनुकरण किए गए उपयोगकर्ता की विशेषाधिकार का उपयोग किया जाएगा, इसलिए यदि यह सुपर व्यवस्थापक है तो आपको सब कुछ तक पहुंचने की अनुमति होगी। यदि इसके पास कोई पहुंच नहीं है तो यह अफ़सोसनाक होगा।

GCP डेलीगेशन टोकन जनरेट करें

यह सरल स्क्रिप्ट उपयोगकर्ता के रूप में एक OAuth टोकन उत्पन्न करेगा जिसका आप फिर अन्य Google APIs तक पहुंचने के लिए gcloud के साथ या बिना उपयोग कर सकते हैं:

# Impersonate indicated user
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file>

# Impersonate indicated user and add additional scopes
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file> --scopes "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"

DeleFriend

यह एक टूल है जो निम्नलिखित चरणों का अटैक कर सकता है:

1. संसाधन प्रबंधक API का उपयोग करके GCP परियोजनाओं की जांच करें।

2. प्रत्येक परियोजना संसाधन पर चलना, और प्रारंभिक IAM उपयोक्ता के पहुंच के साथ GCP सेवा खाता संसाधनों की जांच करें GetIAMPolicy का उपयोग करके।

3. प्रत्येक सेवा खाता भूमिका पर चलना, और serviceAccountKeys.create अनुमति के साथ लक्ष्य सेवा खाता संसाधन पर निर्मित, मूल, और कस्टम भूमिकाएं खोजें। यह ध्यान देने योग्य है कि संपादक भूमिका में इस अनुमति को स्वाभाविक रूप से होता है।

4. उस सेवा खाता संसाधन के लिए एक नया KEY_ALG_RSA_2048 निजी कुंजी बनाएं जिसे IAM नीति में संबंधित अनुमति के साथ पाया गया है।

5. प्रत्येक नए सेवा खाते पर चलना और उसके लिए एक JWT **ऑब्ज

# Install requirements
pip install --upgrade --user oauth2client

# Validate access only
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate [e-mail] \
--domain target-org.com

# List the directory
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate [e-mail] \
--domain target-org.com \
--list

# Create a new admin account
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate [e-mail] \
--domain target-org.com \
--account pwned

एक नया प्रतिनिधित्व (स्थायित्व) बनाएं

https://admin.google.com/u/1/ac/owl/domainwidedelegation में डोमेन व्यापक प्रतिनिधित्व की जाँच की जा सकती है।

एक हमलावर जिसके पास GCP परियोजना में सेवा खाते बनाने और GWS में सुपर व्यवस्थापक विशेषाधिकार हो वह किसी GWS उपयोगकर्ताओं को अनुकरण करने की अनुमति देने वाले एक नया प्रतिनिधित्व बना सकता है:

1. नया सेवा खाता और संबंधित कुंजी जोड़ना: GCP पर, नए सेवा खाते संसाधन कंसोल के माध्यम से या सीधे API कॉल्स और CLI उपकरणों का उपयोग करके कार्यक्रमात्मक रूप से उत्पन्न किए जा सकते हैं। इसके लिए भूमिका iam.serviceAccountAdmin या किसी भी अनुकूल भूमिका की आवश्यकता है जिसमें iam.serviceAccounts.create अनुमति शामिल है। एक बार सेवा खाता बनाया गया है, हम संबंधित कुंजी जोड़ेंगे (iam.serviceAccountKeys.create अनुमति).

2. नया प्रतिनिधित्व बनाना: यह महत्वपूर्ण है कि केवल सुपर व्यवस्थापक भूमिका के पास Google Workspace में वैश्विक डोमेन-व्यापक प्रतिनिधित्व स्थापित करने की क्षमता है और डोमेन-व्यापक प्रतिनिधित्व कार्यक्रमात्मक रूप से स्थापित नहीं किया जा सकता है, यह केवल Google Workspace कंसोल के माध्यम से मैन्युअल रूप से बनाया और समायोजित किया जा सकता है।

• नियम का निर्माण पृष्ठ पर API नियंत्रण → Google Workspace व्यवस्थापक कंसोल में डोमेन-व्यापक प्रतिनिधित्व प्रबंधित करें में मिल सकता है।

3. 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

4. लक्ष्य पहचान के पक्ष में कार्रवाई: इस समय, हमारे पास GWS में एक कार्यक्षम प्रतिनिधित्व है। अब, GCP सेवा खाते की निजी कुंजी का उपयोग करके हम API कॉल्स कर सकते हैं (जो OAuth दायित्व पैरामीटर में परिभाषित किए गए दायित्व के दायरे में हैं) और Google Workspace में मौजूद किसी भी पहचान के पक्ष में कार्रवाई कर सकते हैं। जैसा कि हमने सीखा, सेवा खाता अपनी आवश्यकताओं के अनुसार पहुंच टोकन उत्पन्न करेगा और जिसके पास REST API एप्लिकेशन्स के लिए अनुमति है उसके अनुसार।

• इस प्रतिनिधित्व का उपयोग करने के लिए कुछ उपकरणों के लिए पिछले खंड की जाँच करें।

संगठनात्मक प्रतिनिधित्व

OAuth SA आईडी वैश्विक है और संगठनात्मक प्रतिनिधित्व के लिए उपयोग किया जा सकता है। कोई प्रतिबंध लागू नहीं किया गया है जो संगठनात्मक प्रतिनिधित्व को रोकने के लिए। सरल शब्दों में, विभिन्न GCP संगठनों से सेवा खातों का उपयोग करके अन्य Workspace संगठनों पर डोमेन-व्यापक प्रतिनिधित्व को कॉन्फ़िगर किया जा सकता है। इससे Workspace के लिए केवल सुपर व्यवस्थापक उपयुक्त होगा, और उसी गCP खाते तक पहुंच की आवश्यकता नहीं होगी, क्योंकि विरोधी सेवा खाते और निजी कुंजी अपने व्यक्तिगत नियंत्रित GCP खाते पर बना सकते हैं।

Workspace की जांच करने के लिए परियोजना बनाना

डिफ़ॉल्ट रूप से Workspace उपयोगकर्ता को नई परियोजनाएँ बनाने की अनुमति होती है, और जब एक नई परियोजना बनाई जाती है तो निर्माता को उस परियोजना पर मालिक भूमिका मिलती है।

इसलिए, एक उपयोगकर्ता परियोजना बना सकता है, APIs को सक्रिय कर सकता है ताकि वह अपनी नई परियोजना में Workspace को जांचने की कोशिश कर सके।

एक उपयोगकर्ता को Workspace की जांच करने की क्षमता होने के लिए उसे पर्याप्त Workspace अनुमतियाँ भी चाहिए होती हैं (हर उपयोगकर्ता निर्देशिका को जांचने की क्षमता रखेगा नहीं)।

# Create project
gcloud projects create <uniq-projec-name> --name=proj-name
# Set project
gcloud config set project <uniq-projec-name>
# Enable svcs
gcloud services enable admin.googleapis.com
gcloud services enable cloudidentity.googleapis.com
# Get org ID
gcloud organizations list
# Get currents email user groups (at least you can check the groups and members of the groups you belong to)
gcloud identity groups memberships search-transitive-groups --member-email <email> --labels=cloudidentity.googleapis.com/groups.discussion_forum
gcloud identity groups memberships list --group-email=g<group-email>

# FROM HERE THE USER NEEDS TO HAVE ENOUGH WORKSPACE ACCESS
gcloud beta identity groups preview --customer <org-cust-id>

जांचें और जांच:

pageGCP - IAM, Principals & Org Policies Enum

Gcloud का दुरुपयोग

आप लॉगिन करने के लिए gcloud फ्लो के बारे में अधिक जानकारी पा सकते हैं:

pageGCP - Non-svc Persistance

जैसा कि वहाँ स्पष्ट किया गया है, gcloud यूजर के ड्राइव तक पहुंचने की अनुमति देने वाली स्कोप https://www.googleapis.com/auth/drive का अनुरोध कर सकता है। एक हमलावर के रूप में, यदि आपने किसी उपयोगकर्ता के कंप्यूटर को भौतिक रूप से कंप्रमाइज़ किया है और उपयोगकर्ता अभी भी अपने खाते में लॉग इन हैं तो आप एक टोकन उत्पन्न करके ड्राइव तक पहुंच के लिए उपयोग कर सकते हैं:

gcloud auth login --enable-gdrive-access

यदि कोई हमलावर किसी उपयोगकर्ता के कंप्यूटर को कंप्रोमाइज़ करता है तो वह फ़ाइल 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 तक

विशेषाधिकारित GCP उपयोगकर्ताओं तक पहुंच

यदि किसी हमलावर के पास GWS पर पूर्ण पहुंच है तो वह GCP पर विशेषाधिकारित उपयोगकर्ताओं या समेत समूहों तक पहुंच सकेगा, इसलिए GWS से GCP तक जाना आमतौर पर अधिक "सरल" होता है क्योंकि GWS में उपयोगकर्ताओं के पास GCP पर उच्च विशेषाधिकार होते हैं।

Google समूह विशेषाधिकार उन्नयन

डिफ़ॉल्ट रूप से उपयोगकर्ता संगठन के Workspace समूहों में स्वतंत्र रूप से शामिल हो सकते हैं और उन समूहों में GCP अनुमतियाँ भी हो सकती हैं (अपने समूहों की जाँच करें https://groups.google.com/)।

Google समूह विशेषाधिकार उन्नयन का दुरुपयोग करके आप GCP में किसी प्रकार के विशेषाधिकार वाले समूह तक उन्नयन कर सकते हैं।

संदर्भ

• https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover

जानें AWS हैकिंग को शून्य से हीरो तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

• यदि आप अपनी कंपनी का विज्ञापन HackTricks में देखना चाहते हैं या HackTricks को PDF में डाउनलोड करना चाहते हैं तो सब्सक्रिप्शन प्लान की जाँच करें!

• आधिकारिक PEASS और HackTricks swag प्राप्त करें

• हमारे विशेष NFTs कलेक्शन The PEASS Family खोजें

• शामिल हों 💬 डिस्कॉर्ड समूह या टेलीग्राम समूह या मेरा ट्विटर 🐦 @carlospolopm** का** अनुसरण करें।

• अपने हैकिंग ट्रिक्स साझा करें HackTricks और HackTricks Cloud github repos को PRs सबमिट करके।