GCP - Storage Privesc

Tip

सीखें और अभ्यास करें AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
सीखें और अभ्यास करें GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
सीखें और अभ्यास करें Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

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

Storage

Basic Information:

GCP - Storage Enum

storage.objects.get

यह permission आपको Cloud Storage के अंदर स्टोर की गई फाइलें download करने की अनुमति देता है। यह संभावित रूप से आपको privileges escalate करने की अनुमति दे सकता है क्योंकि कुछ मामलों में संवेदनशील जानकारी वहाँ सेव रहती है। इसके अलावा, कुछ GCP services अपनी जानकारी buckets में स्टोर करती हैं:

  • GCP Composer: जब आप एक Composer Environment बनाते हैं तो सभी DAGs का code एक bucket के अंदर सेव हो जाएगा। इन tasks के code में दिलचस्प जानकारी हो सकती है।
  • GCR (Container Registry): कंटेनरों की image buckets में स्टोर होती हैं, जिसका मतलब है कि अगर आप इन buckets को पढ़ सकते हैं तो आप images डाउनलोड करके leaks और/या source code खोज सकेंगे।

storage.objects.setIamPolicy

यह permission आपको इस सेक्शन के पूर्व वर्णित किसी भी परिदृश्य को abuse करने की अनुमति दे सकता है।

# Add binding
gcloud storage objects add-iam-policy-binding gs://<BUCKET_NAME>/<OBJECT_NAME> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role="<ROLE>" \
--project=<PROJECT_ID>

# Remove binding
gcloud storage objects remove-iam-policy-binding gs://<BUCKET_NAME>/<OBJECT_NAME> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role="<ROLE>" \
--project=<PROJECT_ID>

# Change Policy
gcloud storage objects set-iam-policy gs://<BUCKET_NAME>/<OBJECT_NAME> - \
--project=<PROJECT_ID> <<'POLICY'
{
"bindings": [
{
"role": "<ROLE>",
"members": [
"<MEMBER_TYPE>:<MEMBER_IDENTIFIER>"
]
}
]
}
POLICY

storage.buckets.setIamPolicy

इस permission check के साथ permissions को modify करने का उदाहरण देखने के लिए इस पेज को देखें:

# Add binding
gcloud storage buckets add-iam-policy-binding gs://<MY_BUCKET> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role=<ROLE> \
--project=<MY_PROJECT>

# Remove binding
gcloud storage buckets remove-iam-policy-binding gs://<MY_BUCKET> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role=<ROLE> \
--project=<MY_PROJECT>

# Change policy
gcloud storage buckets set-iam-policy gs://<BUCKET_NAME> - \
--project=<PROJECT_ID> <<'POLICY'
{
"bindings": [
{
"role": "<ROLE>",
"members": [
"<MEMBER_TYPE>:<MEMBER_IDENTIFIER>"
]
}
]
}
POLICY

GCP - Public Buckets Privilege Escalation

storage.hmacKeys.create

Cloud Storage की “interoperability” फीचर, जो AWS S3 जैसे cross-cloud interactions के लिए डिज़ाइन की गई है, में Service Accounts और उपयोगकर्ताओं के लिए HMAC keys का निर्माण शामिल है। एक हमलावर इसका फायदा उठा सकता है, elevated privileges वाले Service Account के लिए HMAC key generate करके, और इस प्रकार Cloud Storage के भीतर privileges escalate कर सकता है। जबकि उपयोगकर्ता-सम्बन्धित HMAC keys केवल web console के माध्यम से ही retrievable हैं, दोनों access और secret keys स्थायी रूप से उपलब्ध रहती हैं, जो संभावित बैकअप access storage की अनुमति देती हैं। इसके विपरीत, Service Account-से जुड़ी HMAC keys API-accessible होती हैं, लेकिन उनके access और secret keys creation के बाद retrievable नहीं होते, जो continuous access के लिए एक अतिरिक्त जटिलता जोड़ता है।

# Create key
gsutil hmac create <sa-email> # You might need to execute this inside a VM instance

## If you have TROUBLES creating the HMAC key this was you can also do it contacting the API directly:
PROJECT_ID = '$PROJECT_ID'
TARGET_SERVICE_ACCOUNT = f"storage-sa@{PROJECT_ID}.iam.gserviceaccount.com"
ACCESS_TOKEN = "$CLOUDSDK_AUTH_ACCESS_TOKEN"
import requests
import json
key = requests.post(
f'https://www.googleapis.com/storage/v1/projects/{PROJECT_ID}/hmacKeys',
params={'access_token': ACCESS_TOKEN, 'serviceAccountEmail': TARGET_SERVICE_ACCOUNT}
).json()
#print(json.dumps(key, indent=4))
print(f'ID: {key["metadata"]["accessId"]}')
print(f'Secret: {key["secret"]}')


# Configure gsutil to use the HMAC key
gcloud config set pass_credentials_to_gsutil false
gsutil config -a

# Use it
gsutil ls gs://[BUCKET_NAME]

# Restore
gcloud config set pass_credentials_to_gsutil true

Another exploit script for this method can be found यहाँ.

storage.objects.create, storage.objects.delete = Storage Write permissions

bucket के अंदर नया object बनाने के लिए आपको storage.objects.create चाहिए और, the docs के अनुसार मौजूदा object को संशोधित करने के लिए आपको storage.objects.delete भी चाहिए।

यदि किसी bucket में cloud पर लिखने की अनुमति है और वह bucket वेब सर्वर फाइलें सहेज रहा है, तो आमतौर पर आप नया कोड स्टोर कर सकते हैं जिसे वेब एप्लिकेशन उपयोग करेगा — यह बहुत सामान्य exploitation है।

Composer

Composer GCP के अंदर managed Apache Airflow है। इसके कुछ दिलचस्प फीचर्स हैं:

  • यह एक GKE cluster के अंदर चलता है, इसलिए cluster जो SA उपयोग करता है वह Composer के अंदर चल रहे कोड द्वारा access किया जा सकता है।
  • एक composer environment के सभी components (code of DAGs, plugins और data) एक GCP bucket में store होते हैं। अगर attacker के पास उस पर read और write permissions हैं, तो वह bucket को monitor कर सकता है और जब भी कोई DAG create या update होता है, तो एक backdoored version submit कर सकता है ताकि composer environment storage से backdoored version ले ले।

You can find a PoC of this attack in the repo: https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs

Cloud Functions

  • Cloud Functions का code Storage में store होता है और जब भी नया version बनाया जाता है तो code bucket में push किया जाता है और फिर इस code से नया container build होता है। इसलिए, नए version के build होने से पहले code को overwrite कर देना संभव है — इससे cloud function arbitrary code execute करवा सकता है।

You can find a PoC of this attack in the repo: https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions

App Engine

AppEngine versions कुछ data उस bucket के अंदर generate करते हैं जिसका नाम format होता है: staging.<project-id>.appspot.com। इस bucket के अंदर ae नाम का एक folder मिल सकता है जो AppEngine app के हर version के लिए एक फोल्डर रखेगा और इन फोल्डरों के अंदर manifest.json फाइल मिलेगी। यह फाइल एक json रखती है जिसमें उन सभी files की सूची होती है जो किसी specific version को बनाने के लिए उपयोग होंगी। इसके अलावा, यहाँ फाइलों के real names, GCP bucket के अंदर उनके URL (bucket के अंदर फाइलों के नाम उनके sha1 hash में बदल दिए जाते हैं) और हर फाइल का sha1 hash भी मिल सकता है।

ध्यान दें कि इस bucket को पहले से takeover करना संभव नहीं है क्योंकि GCP users को appspot.com डोमेन नाम का उपयोग करके buckets बनाने की अनुमति नहीं है।

हालाँकि, इस bucket पर read & write access होने पर आप bucket को monitor करके App Engine version से जुड़े SA तक privileges escalate कर सकते हैं और जब भी कोई change हो (नया version), नई version को जितनी जल्दी हो सके modify कर दें। इस तरह उस code से बनाया गया container backdoored code execute करेगा।

उल्लेखित attack कई तरीकों से किया जा सकता है, जिनकी शुरुआत सभी में staging.<project-id>.appspot.com bucket को monitor करने से होती है:

  • AppEngine version का पूरा नया code किसी अलग उपलब्ध bucket में upload करें और एक manifest.json फाइल तैयार करें जिसमें नया bucket name और उनकी sha1 hashes हों। फिर, जब bucket के अंदर नया version बनाया जाए, आप manifest.json को modify करके malicious वाला अपलोड कर दें।
  • एक modified requirements.txt upload करें जो malicious dependencies का code उपयोग करे और manifest.json फाइल को नए filename, URL और उसके hash के साथ update करें।
  • एक modified main.py या app.yaml फाइल upload करें जो malicious code execute करे और manifest.json फाइल को नए filename, URL और उसके hash के साथ update करें।

You can find a PoC of this attack in the repo: https://github.com/carlospolop/Monitor-Backdoor-AppEngine

GCR

  • Google Container Registry images को buckets में store करता है; अगर आप उन buckets में write कर सकते हैं तो आप संभवतः move laterally कर सकते हैं जहाँ उन buckets को run किया जा रहा है।
  • GCR द्वारा उपयोग किया गया bucket एक URL जैसा होगा: gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com (The top level subdomains are specified यहाँ).

Tip

यह सेवा deprecated है इसलिए यह attack अब उपयोगी नहीं है। इसके अलावा, Artifact Registry, जो इस सेवा का विकल्प है, images को buckets में store नहीं करती।

References

Tip

सीखें और अभ्यास करें AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
सीखें और अभ्यास करें GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
सीखें और अभ्यास करें Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

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