GCP - IAM Privesc

जानें AWS हैकिंग को शून्य से हीरो तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

• यदि आप अपनी कंपनी का विज्ञापन HackTricks में देखना चाहते हैं या HackTricks को PDF में डाउनलोड करना चाहते हैं तो सब्सक्रिप्शन प्लान्स देखें!

• आधिकारिक PEASS और HackTricks स्वैग प्राप्त करें

• हमारे विशेष NFTs कलेक्शन, The PEASS Family खोजें

• शामिल हों 💬 डिस्कॉर्ड समूह या टेलीग्राम समूह या हमें ट्विटर 🐦 @hacktricks_live** पर फॉलो करें।

• हैकिंग ट्रिक्स साझा करें, HackTricks और HackTricks Cloud github repos में PRs सबमिट करके।

IAM

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

pageGCP - IAM, Principals & Org Policies Enum

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

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

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

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

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

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

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

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

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

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

iam.serviceAccounts.implicitDelegation

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

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

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

iam.serviceAccounts.signBlob

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

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

iam.serviceAccounts.signJwt

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

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

iam.serviceAccounts.setIamPolicy

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

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

iam.serviceAccounts.actAs

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

सेवा खाता प्रतिनिधित्व

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

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

• Cloud IAM नीतियों का उपयोग करके अधिकृति (यहाँ चर्चा की गई है)

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

iam.serviceAccounts.getOpenIdToken

उल्लिखित अनुमतियों वाले एक हमलावर एक ओपनआईडी जेडडब्ल्यूटी उत्पन्न कर सकेगा। ये पहचान को दावा करने के लिए उपयोग किए जाते हैं और किसी संसाधन के खिलाफ कोई शर्तमुक्त अधिकृति नहीं लेते।

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

आप एक ओपनआईडीटोकन उत्पन्न कर सकते हैं (यदि आपके पास पहुंच है) के साथ:

# 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 का उपयोग किया जा रहा है)

आप एक उदाहरण यहाँ सेवा खाता के पक्ष से ओपनआईडी टोकन बनाने के लिए कैसे कर सकते हैं यहाँ.

संदर्भ

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

जानें AWS हैकिंग को शून्य से हीरो तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks को समर्थन करने के अन्य तरीके:

• यदि आप अपनी कंपनी का विज्ञापन HackTricks में देखना चाहते हैं या HackTricks को PDF में डाउनलोड करना चाहते हैं तो सब्सक्रिप्शन प्लान्स देखें!

• आधिकारिक PEASS & HackTricks स्वैग प्राप्त करें

• हमारे विशेष NFTs संग्रह The PEASS Family खोजें

• शामिल हों 💬 डिस्कॉर्ड समूह या टेलीग्राम समूह या हमें ट्विटर 🐦 @hacktricks_live** पर फॉलो** करें।

• हैकिंग ट्रिक्स साझा करें HackTricks और HackTricks Cloud github repos को PR जमा करके।