GCP - IAM Privesc

Reading time: 10 minutes

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"]
}'

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

iam.serviceAccounts.signBlob

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

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

iam.serviceAccounts.signJwt

उपरोक्त अनुमतियों के साथ एक हमलावर सही ढंग से निर्मित JSON वेब टोकन (JWTs) पर हस्ताक्षर करने में सक्षम होगा। पिछले तरीके के साथ अंतर यह है कि JWT पर हस्ताक्षर करने के लिए हम google को एक ब्लॉब पर हस्ताक्षर करने के बजाय signJWT विधि का उपयोग करते हैं, जो पहले से ही एक JWT की अपेक्षा करता है। यह उपयोग में आसान बनाता है लेकिन आप केवल JWT पर हस्ताक्षर कर सकते हैं न कि किसी भी बाइट पर।

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

iam.serviceAccounts.setIamPolicy

उपरोक्त अनुमतियों के साथ एक हमलावर सेवा खातों में 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"

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

iam.serviceAccounts.actAs

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

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

• 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/