GCP <--> Workspace Pivoting

From GCP to GWS

Domain Wide Delegation basics

Google Workspace का Domain-Wide delegation एक पहचान वस्तु, या तो एक external app जो Google Workspace Marketplace से है या एक आंतरिक GCP Service Account, को उपयोगकर्ताओं की ओर से Workspace में डेटा तक पहुंचने की अनुमति देता है।

इसके बारे में अधिक जानकारी के लिए कि यह कैसे काम करता है, देखें:

Compromise existing delegation

यदि एक हमलावर ने GCP पर कुछ पहुंच को समझौता किया और कंपनी के एक मान्य Workspace उपयोगकर्ता का ईमेल (अधिमानतः super admin) जानता है, तो वह सभी प्रोजेक्ट्स की सूची बना सकता है जिन तक उसे पहुंच है, प्रोजेक्ट्स के सभी SAs की सूची बना सकता है, देख सकता है कि उसे कौन से service accounts तक पहुंच है, और हर SA के साथ इन सभी चरणों को दोहरा सकता है। उसके पास सभी service accounts की एक सूची और Workspace ईमेल्स की सूची होने पर, हमलावर प्रत्येक service account के साथ उपयोगकर्ता की नकल करने की कोशिश कर सकता है।

GCP Generate Delegation Token

यह सरल स्क्रिप्ट delegated user के रूप में एक OAuth token उत्पन्न करेगी जिसे आप अन्य 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. GCP प्रोजेक्ट्स की गणना करें Resource Manager API का उपयोग करके।

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

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

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

5. प्रत्येक नए सेवा खाते पर इटरेट करें और इसके लिए एक JWT ऑब्जेक्ट बनाएं जो SA निजी कुंजी क्रेडेंशियल्स और एक OAuth स्कोप से बना है। एक नया JWT ऑब्जेक्ट बनाने की प्रक्रिया oauth_scopes.txt सूची से OAuth स्कोप के सभी मौजूदा संयोजनों पर इटरेट करेगी, ताकि सभी प्रतिनिधित्व संभावनाओं को खोजा जा सके। सूची oauth_scopes.txt को उन सभी OAuth स्कोप के साथ अपडेट किया गया है जो हमने Workspace पहचानियों का दुरुपयोग करने के लिए प्रासंगिक पाया है।

6. _make_authorization_grant_assertion विधि एक लक्षित कार्यक्षेत्र उपयोगकर्ता, जिसे subject के रूप में संदर्भित किया गया है, को घोषित करने की आवश्यकता को प्रकट करती है, ताकि DWD के तहत JWT उत्पन्न किया जा सके। जबकि यह एक विशिष्ट उपयोगकर्ता की आवश्यकता प्रतीत हो सकती है, यह समझना महत्वपूर्ण है कि DWD एक डोमेन के भीतर हर पहचान को प्रभावित करता है। परिणामस्वरूप, किसी भी डोमेन उपयोगकर्ता के लिए JWT बनाना उस डोमेन में सभी पहचानों को प्रभावित करता है, जो हमारे संयोजन गणना जांच के अनुरूप है। सीधे शब्दों में कहें, एक मान्य Workspace उपयोगकर्ता आगे बढ़ने के लिए पर्याप्त है। इस उपयोगकर्ता को DeleFriend के config.yaml फ़ाइल में परिभाषित किया जा सकता है। यदि लक्षित कार्यक्षेत्र उपयोगकर्ता पहले से ज्ञात नहीं है, तो उपकरण GCP प्रोजेक्ट्स पर भूमिकाओं के साथ डोमेन उपयोगकर्ताओं को स्कैन करके मान्य कार्यक्षेत्र उपयोगकर्ताओं की स्वचालित पहचान की सुविधा प्रदान करता है। यह ध्यान रखना महत्वपूर्ण है (फिर से) कि JWT डोमेन-विशिष्ट होते हैं और हर उपयोगकर्ता के लिए उत्पन्न नहीं होते; इसलिए, स्वचालित प्रक्रिया प्रति डोमेन एक अद्वितीय पहचान को लक्षित करती है।

7. प्रत्येक JWT के लिए एक नया बियरर एक्सेस टोकन की गणना करें और टोकन को tokeninfo API के खिलाफ मान्य करें।

Gitlab का Python स्क्रिप्ट

Gitlab ने यह Python स्क्रिप्ट बनाई है जो दो चीजें कर सकती है - उपयोगकर्ता निर्देशिका की सूची बनाना और SA क्रेडेंशियल्स और अनुकरण करने के लिए उपयोगकर्ता के साथ एक नया प्रशासनिक खाता बनाना। यहाँ आप इसका उपयोग कैसे करेंगे:

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

# Validate access only
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com

# List the directory
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--list

# Create a new admin account
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--account pwned

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

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

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

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

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

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

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

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

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

क्रॉस-ऑर्गनाइजेशनल प्रतिनिधित्व

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

Workspace को सूचीबद्ध करने के लिए एक प्रोजेक्ट बनाना

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

इसलिए, एक उपयोगकर्ता एक प्रोजेक्ट बना सकता है, अपने नए प्रोजेक्ट में Workspace को सूचीबद्ध करने के लिए APIs को सक्षम कर सकता है और इसे सूचीबद्ध करने का प्रयास कर सकता है।

# 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>

Check अधिक एन्यूमरेशन में:

Gcloud क्रेडेंशियल्स का दुरुपयोग

आप gcloud लॉगिन के प्रवाह के बारे में और जानकारी पा सकते हैं:

जैसा कि वहां समझाया गया है, 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' जोड़ सकता है:

GWS से GCP तक

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

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

Google समूहों में विशेषाधिकार वृद्धि

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

google groups privesc का दुरुपयोग करके, आप GCP पर कुछ प्रकार की विशेषाधिकार प्राप्त पहुंच वाले समूह में वृद्धि करने में सक्षम हो सकते हैं।

संदर्भ

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