GCP - IAM Privesc
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
IAM के बारे में अधिक जानकारी प्राप्त करें:
GCP - IAM, Principals & Org Policies Enumiam.roles.update (iam.roles.get)उल्लेखित अनुमतियों के साथ एक हमलावर आपके लिए असाइन की गई भूमिका को अपडेट करने में सक्षम होगा और आपको अन्य संसाधनों के लिए अतिरिक्त अनुमतियाँ देगा जैसे:
आप यहां एक स्क्रिप्ट पा सकते हैं जो एक vuln वातावरण के निर्माण, शोषण और सफाई को स्वचालित करती है और इस विशेषाधिकार का दुरुपयोग करने के लिए एक पायथन स्क्रिप्ट यहां है। अधिक जानकारी के लिए मूल शोध की जांच करें।
iam.serviceAccounts.getAccessToken (iam.serviceAccounts.get)एक हमलावर जिसके पास उल्लेखित अनुमतियाँ हैं, एक सेवा खाते से संबंधित एक एक्सेस टोकन का अनुरोध करने में सक्षम होगा, इसलिए यह संभव है कि एक सेवा खाते का एक्सेस टोकन अनुरोध किया जाए जिसमें हमारे से अधिक विशेषाधिकार हों।
आप यहां एक स्क्रिप्ट पा सकते हैं जो एक vuln वातावरण के निर्माण, शोषण और सफाई को स्वचालित करती है और इस विशेषता का दुरुपयोग करने के लिए एक पायथन स्क्रिप्ट यहां है। अधिक जानकारी के लिए मूल शोध की जांच करें।
iam.serviceAccountKeys.createउपरोक्त अनुमतियों के साथ एक हमलावर एक सेवा खाते के लिए एक उपयोगकर्ता-प्रबंधित कुंजी बनाने में सक्षम होगा, जो हमें उस सेवा खाते के रूप में GCP तक पहुंचने की अनुमति देगा।
आप एक स्क्रिप्ट पा सकते हैं जो एक vuln वातावरण के निर्माण, शोषण और सफाई को स्वचालित करने के लिए यहाँ और इस विशेषता का दुरुपयोग करने के लिए एक पायथन स्क्रिप्ट यहाँ है। अधिक जानकारी के लिए मूल शोध की जांच करें।
ध्यान दें कि iam.serviceAccountKeys.update एक SA की कुंजी को संशोधित करने के लिए काम नहीं करेगा क्योंकि ऐसा करने के लिए iam.serviceAccountKeys.create अनुमति भी आवश्यक है।
iam.serviceAccounts.implicitDelegationयदि आपके पास एक सेवा खाते पर iam.serviceAccounts.implicitDelegation अनुमति है जो तीसरे सेवा खाते पर iam.serviceAccounts.getAccessToken अनुमति रखता है, तो आप उस तीसरे सेवा खाते के लिए एक टोकन बनाने के लिए implicitDelegation का उपयोग कर सकते हैं। यहाँ एक चित्र है जो समझने में मदद करता है।
ध्यान दें कि दस्तावेज़ीकरण के अनुसार, gcloud का प्रतिनिधित्व केवल generateAccessToken() विधि का उपयोग करके एक टोकन उत्पन्न करने के लिए काम करता है। तो यहाँ आपके पास API का उपयोग करके सीधे एक टोकन प्राप्त करने का तरीका है:
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.signBlobAn 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.signJwtAn attacker with the mentioned permissions will be able to सही तरीके से बनाए गए JSON वेब टोकन (JWTs) पर हस्ताक्षर करने में सक्षम होगा। पिछले तरीके के साथ अंतर यह है कि JWT पर हस्ताक्षर करने के लिए हम signJWT विधि का उपयोग करते हैं जो पहले से ही JWT की अपेक्षा करता है, इसके बजाय कि google को JWT वाले ब्लॉब पर हस्ताक्षर करने के लिए कहा जाए। This makes it easier to use but you can only sign JWT instead of any bytes.
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.setIamPolicyAn attacker with the mentioned permissions will be able to सेवा खातों के लिए IAM नीतियों को जोड़ने में सक्षम होगा। You can abuse it to अपने लिए आवश्यक अनुमतियाँ प्रदान करें ताकि सेवा खाते का अनुकरण किया जा सके। In the following example we are granting ourselves the roles/iam.serviceAccountTokenCreator role over the interesting SA:
You can find a script to automate the creation, exploit and cleaning of a vuln environment here.
iam.serviceAccounts.actAsThe 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.
Impersonating a service account can be very useful to obtain new and better privileges. There are three ways in which you can impersonate another service account:
Authentication using RSA private keys (covered above)
Authorization using Cloud IAM policies (covered here)
Deploying jobs on GCP services (more applicable to the compromise of a user account)
iam.serviceAccounts.getOpenIdTokenAn attacker with the mentioned permissions will be able to generate an OpenID JWT. These are used to assert identity and do not necessarily carry any implicit authorization against a resource.
According to this interesting post, it's necessary to indicate the audience (service where you want to use the token to authenticate to) and you will receive a JWT signed by google indicating the service account and the audience of the JWT.
You can generate an OpenIDToken (if you have the access) with:
फिर आप इसे सेवा तक पहुँचने के लिए बस उपयोग कर सकते हैं:
कुछ सेवाएँ जो इस प्रकार के टोकनों के माध्यम से प्रमाणीकरण का समर्थन करती हैं:
Google Cloud Endpoints (यदि Google OIDC का उपयोग कर रहे हैं)
आप एक सेवा खाते की ओर से OpenID टोकन बनाने का उदाहरण यहाँ पा सकते हैं।
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
