GCP - IAM Privesc

IAM

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

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

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

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

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

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

एक हमलावर जिसके पास उल्लेखित अनुमतियाँ हैं, एक सेवा खाते से संबंधित एक एक्सेस टोकन का अनुरोध करने में सक्षम होगा, इसलिए यह संभव है कि एक सेवा खाते का एक्सेस टोकन अनुरोध किया जाए जिसमें हमारे से अधिक विशेषाधिकार हों।

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

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

iam.serviceAccountKeys.create

एक हमलावर जिसके पास उल्लेखित अनुमतियाँ हैं, एक सेवा खाते के लिए एक उपयोगकर्ता-प्रबंधित कुंजी बनाने में सक्षम होगा, जो हमें उस सेवा खाते के रूप में GCP तक पहुँचने की अनुमति देगा।

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

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

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

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

iam.serviceAccounts.implicitDelegation

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

ध्यान दें कि दस्तावेज़ीकरण के अनुसार, gcloud का प्रतिनिधित्व केवल 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"]
}'

You can find a script to automate the creation, exploit and cleaning of a vuln environment here and a python script to abuse this privilege here. For more information check the original research.

iam.serviceAccounts.signBlob

An attacker with the mentioned permissions will be able to GCP में मनमाने पेलोड्स पर हस्ताक्षर करने में सक्षम होगा। इसलिए यह संभव होगा कि SA का एक असाइन किया हुआ JWT बनाएं और फिर इसे एक ब्लॉब के रूप में भेजें ताकि हम जिस SA को लक्षित कर रहे हैं, उसके द्वारा JWT पर हस्ताक्षर किया जा सके। For more information read this.

You can find a script to automate the creation, exploit and cleaning of a vuln environment here and a python script to abuse this privilege here and here. For more information check the original research.

iam.serviceAccounts.signJwt

An attacker with the mentioned permissions will be able to सही तरीके से बनाए गए JSON वेब टोकन (JWTs) पर हस्ताक्षर करने में सक्षम होगा। पिछले तरीके के साथ अंतर यह है कि JWT पर हस्ताक्षर करने के लिए हम google को एक ब्लॉब पर हस्ताक्षर करने के बजाय signJWT विधि का उपयोग करते हैं, जो पहले से ही एक JWT की अपेक्षा करता है। यह उपयोग में आसान बनाता है लेकिन आप केवल JWT पर हस्ताक्षर कर सकते हैं न कि किसी भी बाइट्स पर।

You can find a script to automate the creation, exploit and cleaning of a vuln environment here and a python script to abuse this privilege here. For more information check the original research.

iam.serviceAccounts.setIamPolicy

An attacker with the mentioned permissions will be able to सेवा खातों में IAM नीतियाँ जोड़ने में सक्षम होगा। आप इसका दुरुपयोग कर सकते हैं अपने लिए उन अनुमतियों को देने के लिए जिनकी आपको सेवा खाते का अनुकरण करने की आवश्यकता है। निम्नलिखित उदाहरण में हम अपने लिए 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"

You can find a script to automate the creation, exploit and cleaning of a vuln environment here.

iam.serviceAccounts.actAs

The iam.serviceAccounts.actAs permission is like the iam:PassRole permission from AWS. It's essential for executing tasks, like initiating a Compute Engine instance, as it grants the ability to "actAs" a Service Account, ensuring secure permission management. Without this, users might gain undue access. Additionally, exploiting the iam.serviceAccounts.actAs involves various methods, each requiring a set of permissions, contrasting with other methods that need just one.

Service account impersonation

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

• प्रमाणीकरण RSA निजी कुंजी का उपयोग करके (ऊपर कवर किया गया)

• प्राधिकरण Cloud IAM नीतियों का उपयोग करके (यहां कवर किया गया)

• GCP सेवाओं पर कार्यों को तैनात करना (एक उपयोगकर्ता खाते के समझौते के लिए अधिक लागू)

iam.serviceAccounts.getOpenIdToken

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

इस दिलचस्प पोस्ट के अनुसार, यह आवश्यक है कि आप दर्शक (सेवा जहां आप टोकन का उपयोग करके प्रमाणित होना चाहते हैं) को इंगित करें और आपको एक JWT प्राप्त होगा जो google द्वारा हस्ताक्षरित होगा, जो सेवा खाते और 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

कुछ सेवाएँ जो इस प्रकार के टोकन के माध्यम से प्रमाणीकरण का समर्थन करती हैं:

• Google Cloud Run

• Google Cloud Functions

• Google Identity Aware Proxy

• Google Cloud Endpoints (यदि Google OIDC का उपयोग कर रहे हैं)

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

संदर्भ

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