GCP <--> Workspace Pivoting
{{#include ../../../banners/hacktricks-training.md}}
GCP से GWS तक
डोमेन वाइड डेलीगेशन के मूल बातें
Google Workspace का डोमेन-वाइड डेलीगेशन एक पहचान वस्तु, या तो एक बाहरी ऐप जो Google Workspace मार्केटप्लेस से है या एक आंतरिक GCP सेवा खाता, को उपयोगकर्ताओं की ओर से Workspace में डेटा तक पहुंचने की अनुमति देता है।
Note
इसका मतलब यह है कि GCP परियोजनाओं के भीतर सेवा खाते एक संगठन के Workspace उपयोगकर्ताओं की नकल कर सकते हैं (या यहां तक कि किसी अन्य से भी)।
इसकी कार्यप्रणाली के बारे में अधिक जानकारी के लिए देखें:
{{#ref}} gcp-understanding-domain-wide-delegation.md {{#endref}}
मौजूदा डेलीगेशन का समझौता
यदि एक हमलावर ने GCP पर कुछ पहुंच का समझौता किया और कंपनी के एक मान्य Workspace उपयोगकर्ता का ईमेल (अधिमानतः सुपर एडमिन) जानता है, तो वह सभी परियोजनाओं की सूची बना सकता है जिन तक उसे पहुंच है, परियोजनाओं के सभी SAs की सूची बना सकता है, यह जांच सकता है कि उसे कौन से सेवा खातों तक पहुंच है, और हर SA के साथ इन सभी चरणों को दोहरा सकता है जिसे वह नकल कर सकता है।
उसके पास सभी सेवा खातों की एक सूची और Workspace ईमेल की सूची होने पर, हमलावर प्रत्येक सेवा खाते के साथ उपयोगकर्ता की नकल करने की कोशिश कर सकता है।
Caution
ध्यान दें कि डोमेन वाइड डेलीगेशन को कॉन्फ़िगर करते समय किसी 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
यह एक उपकरण है जो निम्नलिखित चरणों का पालन करके हमले को अंजाम दे सकता है:
- 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 के रूप में संदर्भित किया गया है, को JWTs उत्पन्न करने के लिए घोषित करने की आवश्यकता को प्रकट करती है। जबकि यह एक विशिष्ट उपयोगकर्ता की आवश्यकता प्रतीत हो सकती है, यह समझना महत्वपूर्ण है कि DWD एक डोमेन के भीतर हर पहचान को प्रभावित करता है। परिणामस्वरूप, किसी भी डोमेन उपयोगकर्ता के लिए JWT बनाना उस डोमेन में सभी पहचानों को प्रभावित करता है, जो हमारे संयोजन गणना जांच के अनुरूप है। सीधे शब्दों में कहें, एक मान्य Workspace उपयोगकर्ता आगे बढ़ने के लिए पर्याप्त है।
इस उपयोगकर्ता को DeleFriend के config.yaml फ़ाइल में परिभाषित किया जा सकता है। यदि लक्षित कार्यक्षेत्र उपयोगकर्ता पहले से ज्ञात नहीं है, तो उपकरण GCP प्रोजेक्ट्स पर भूमिकाओं के साथ डोमेन उपयोगकर्ताओं को स्कैन करके मान्य कार्यक्षेत्र उपयोगकर्ताओं की स्वचालित पहचान की सुविधा प्रदान करता है। यह ध्यान रखना महत्वपूर्ण है (फिर से) कि JWTs डोमेन-विशिष्ट होते हैं और हर उपयोगकर्ता के लिए उत्पन्न नहीं होते; इसलिए, स्वचालित प्रक्रिया प्रति डोमेन एक अद्वितीय पहचान को लक्षित करती है।- प्रत्येक 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
एक नई प्रतिनिधित्व बनाएँ (Persistence)
यह संभव है कि Domain Wide Delegations की जांच करें 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 में वैश्विक Domain-Wide प्रतिनिधित्व स्थापित करने की क्षमता है और Domain-Wide प्रतिनिधित्व प्रोग्रामेटिक रूप से स्थापित नहीं किया जा सकता, इसे केवल Google Workspace कंसोल के माध्यम से हाथ से बनाया और समायोजित किया जा सकता है।
- नियम का निर्माण API controls → Manage Domain-Wide delegation in Google Workspace Admin console पृष्ठ के तहत पाया जा सकता है।
- OAuth स्कोप विशेषाधिकार संलग्न करना: एक नई प्रतिनिधित्व को कॉन्फ़िगर करते समय, Google केवल 2 पैरामीटर की आवश्यकता होती है, क्लाइंट आईडी, जो GCP सेवा खाता संसाधन का OAuth ID है, और 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 को सूचीबद्ध कर सके और इसे सूचीबद्ध करने की कोशिश कर सके।
Caution
एक उपयोगकर्ता के लिए 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>
चेक करें अधिक एन्यूमरेशन में:
{{#ref}} ../gcp-services/gcp-iam-and-org-policies-enum.md {{#endref}}
Gcloud क्रेडेंशियल्स का दुरुपयोग
आप लॉगिन के लिए gcloud प्रवाह के बारे में और जानकारी पा सकते हैं:
{{#ref}} ../gcp-persistence/gcp-non-svc-persistance.md {{#endref}}
जैसा कि वहां समझाया गया है, 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' जोड़ सकता है:
Warning
इसलिए, अगली बार जब उपयोगकर्ता लॉग इन करेगा, तो वह ड्राइव तक पहुंच के साथ एक टोकन बनाएगा जिसका उपयोग हमलावर ड्राइव तक पहुंच प्राप्त करने के लिए कर सकता है। स्पष्ट रूप से, ब्राउज़र यह संकेत देगा कि उत्पन्न टोकन को ड्राइव तक पहुंच प्राप्त होगी, लेकिन चूंकि उपयोगकर्ता स्वयं
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 समूहों में विशेषाधिकार वृद्धि
डिफ़ॉल्ट रूप से, उपयोगकर्ता संगठन के कार्यक्षेत्र समूहों में स्वतंत्र रूप से शामिल हो सकते हैं और उन समूहों को GCP अनुमतियाँ असाइन की जा सकती हैं (अपने समूहों की जांच करें https://groups.google.com/)।
google groups privesc का दुरुपयोग करके, आप GCP पर कुछ प्रकार की विशेषाधिकार पहुंच वाले समूह में वृद्धि करने में सक्षम हो सकते हैं।
संदर्भ
{{#include ../../../banners/hacktricks-training.md}}