GCP - IAM Privesc

Support HackTricks

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 वातावरण के निर्माण, शोषण और सफाई को स्वचालित करती है और इस विशेषाधिकार का दुरुपयोग करने के लिए एक पायथन स्क्रिप्ट यहां है। अधिक जानकारी के लिए मूल शोध की जांच करें।

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 पर हस्ताक्षर करने के लिए हम signJWT विधि का उपयोग करते हैं जो पहले से ही JWT की अपेक्षा करता है, इसके बजाय कि गूगल को 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 भूमिका को दिलचस्प SA पर दे रहे हैं:

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"

आप यहां एक स्क्रिप्ट पा सकते हैं जो एक vuln वातावरण के निर्माण, शोषण और सफाई को स्वचालित करती है

iam.serviceAccounts.actAs

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

सेवा खाता अनुकरण

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

  • प्रमाणीकरण 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

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

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

संदर्भ

HackTricks का समर्थन करें

Last updated