GCP - Storage Privesc

Support HackTricks

Storage

बुनियादी जानकारी:

GCP - Storage Enum

storage.objects.get

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

  • GCP Composer: जब आप एक Composer Environment बनाते हैं, तो सभी DAGs का कोड एक बकेट के अंदर संग्रहीत किया जाएगा। इन कार्यों में उनके कोड के अंदर दिलचस्प जानकारी हो सकती है।

  • GCR (Container Registry): कंटेनरों की छवि बकेट के अंदर संग्रहीत होती है, जिसका अर्थ है कि यदि आप बकेट को पढ़ सकते हैं, तो आप छवियों को डाउनलोड कर सकेंगे और लीक और/या स्रोत कोड की खोज कर सकेंगे।

storage.objects.setIamPolicy

आपको इस अनुभाग के पिछले परिदृश्यों का दुरुपयोग करने की अनुमति दे सकते हैं।

storage.buckets.setIamPolicy

इस अनुमति के साथ अनुमतियों को संशोधित करने के लिए एक उदाहरण के लिए इस पृष्ठ की जांच करें:

GCP - Public Buckets Privilege Escalation

storage.hmacKeys.create

Cloud Storage की "इंटरऑपरेबिलिटी" विशेषता, जो AWS S3 के साथ क्रॉस-क्लाउड इंटरैक्शन के लिए डिज़ाइन की गई है, में सेवा खातों और उपयोगकर्ताओं के लिए HMAC कुंजी का निर्माण शामिल है। एक हमलावर इसका लाभ उठाकर उच्च विशेषाधिकार वाले सेवा खाते के लिए HMAC कुंजी उत्पन्न कर सकता है, इस प्रकार Cloud Storage के भीतर विशेषाधिकार बढ़ा सकता है। जबकि उपयोगकर्ता से संबंधित HMAC कुंजी केवल वेब कंसोल के माध्यम से प्राप्त की जा सकती हैं, दोनों एक्सेस और गुप्त कुंजी सदा के लिए सुलभ रहती हैं, जिससे संभावित बैकअप एक्सेस स्टोरेज की अनुमति मिलती है। इसके विपरीत, सेवा खाता से जुड़े HMAC कुंजी API-सुलभ होती हैं, लेकिन उनकी एक्सेस और गुप्त कुंजी निर्माण के बाद प्राप्त नहीं की जा सकती, जिससे निरंतर एक्सेस के लिए जटिलता का एक स्तर जुड़ता है।

# 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

इस विधि के लिए एक और शोषण स्क्रिप्ट यहाँ मिल सकती है।

storage.objects.create, storage.objects.delete = स्टोरेज लिखने की अनुमति

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

क्लाउड में लिखने के लिए बकेट का एक बहुत सामान्य शोषण तब होता है जब बकेट वेब सर्वर फ़ाइलों को सहेज रहा है, आप नया कोड स्टोर करने में सक्षम हो सकते हैं जो वेब एप्लिकेशन द्वारा उपयोग किया जाएगा।

Composer

Composer Apache Airflow है जो GCP के अंदर प्रबंधित है। इसमें कई दिलचस्प विशेषताएँ हैं:

  • यह एक GKE क्लस्टर के अंदर चलता है, इसलिए क्लस्टर द्वारा उपयोग किया जाने वाला SA कोड के द्वारा पहुंच योग्य है जो Composer के अंदर चल रहा है

  • Composer वातावरण के सभी घटक (DAGs का कोड, प्लगइन्स और डेटा) एक GCP बकेट के अंदर संग्रहीत होते हैं। यदि हमलावर के पास इसके ऊपर पढ़ने और लिखने की अनुमति है, तो वह बकेट की निगरानी कर सकता है और जब भी एक DAG बनाया या अपडेट किया जाता है, एक बैकडोर संस्करण सबमिट कर सकता है ताकि Composer वातावरण स्टोरेज से बैकडोर संस्करण प्राप्त कर सके।

आप इस हमले का PoC इस रिपॉजिटरी में पा सकते हैं: https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs

Cloud Functions

  • Cloud Functions का कोड स्टोरेज में संग्रहीत होता है और जब भी एक नया संस्करण बनाया जाता है, कोड बकेट में पुश किया जाता है और फिर इस कोड से नया कंटेनर बनाया जाता है। इसलिए, नए संस्करण के बनने से पहले कोड को ओवरराइट करना क्लाउड फ़ंक्शन को मनमाने कोड को निष्पादित करने में सक्षम बनाता है

आप इस हमले का PoC इस रिपॉजिटरी में पा सकते हैं: https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions

App Engine

AppEngine संस्करण एक बकेट के अंदर कुछ डेटा उत्पन्न करते हैं जिसका प्रारूप नाम है: staging.<project-id>.appspot.com। इस बकेट के अंदर, एक फ़ोल्डर पाया जा सकता है जिसे ae कहा जाता है जो AppEngine ऐप के प्रत्येक संस्करण के लिए एक फ़ोल्डर रखेगा और इन फ़ोल्डरों के अंदर manifest.json फ़ाइल पाई जा सकती है। इस फ़ाइल में एक json होता है जिसमें सभी फ़ाइलें होती हैं जो विशिष्ट संस्करण बनाने के लिए उपयोग की जानी चाहिए। इसके अलावा, फ़ाइलों के वास्तविक नाम, GCP बकेट के अंदर उनके लिए URL (बकेट के अंदर फ़ाइलों ने अपने नाम को उनके sha1 हैश के लिए बदल दिया) और प्रत्येक फ़ाइल का sha1 हैश पाया जा सकता है।

ध्यान दें कि इस बकेट को पूर्व-टेकओवर करना संभव नहीं है क्योंकि GCP उपयोगकर्ताओं को appspot.com डोमेन नाम का उपयोग करके बकेट बनाने के लिए अधिकृत नहीं किया गया है।

हालांकि, इस बकेट पर पढ़ने और लिखने की पहुंच के साथ, यह App Engine संस्करण से जुड़े SA के लिए विशेषाधिकार बढ़ाना संभव है बकेट की निगरानी करके और जब भी कोई परिवर्तन किया जाता है (नया संस्करण), नए संस्करण को यथाशीघ्र संशोधित करना। इस तरह, इस कोड से बनाया गया कंटेनर बैकडोर कोड को निष्पादित करेगा।

उल्लेखित हमला कई अलग-अलग तरीकों से किया जा सकता है, इनमें से सभी staging.<project-id>.appspot.com बकेट की निगरानी करके शुरू होते हैं:

  • AppEngine संस्करण का पूरा नया कोड एक अलग और उपलब्ध बकेट में अपलोड करें और नए बकेट नाम और उनके sha1 हैश के साथ एक manifest.json फ़ाइल तैयार करें। फिर, जब बकेट के अंदर एक नया संस्करण बनाया जाता है, तो आपको बस manifest.json फ़ाइल को संशोधित करना है और दुर्भावनापूर्ण फ़ाइल अपलोड करनी है।

  • एक संशोधित requirements.txt संस्करण अपलोड करें जो दुर्भावनापूर्ण निर्भरताओं के कोड का उपयोग करेगा और manifest.json फ़ाइल को नए फ़ाइल नाम, URL और इसके हैश के साथ अपडेट करेगा।

  • एक संशोधित main.py या app.yaml फ़ाइल अपलोड करें जो दुर्भावनापूर्ण कोड को निष्पादित करेगी और manifest.json फ़ाइल को नए फ़ाइल नाम, URL और इसके हैश के साथ अपडेट करेगी।

आप इस हमले का PoC इस रिपॉजिटरी में पा सकते हैं: https://github.com/carlospolop/Monitor-Backdoor-AppEngine

GCR

  • Google Container Registry बकेट के अंदर छवियों को संग्रहीत करता है, यदि आप उन बकेट्स में लिख सकते हैं तो आप उन बकेट्स के चलने के स्थान पर आगे बढ़ने में सक्षम हो सकते हैं।

  • GCR द्वारा उपयोग किया जाने वाला बकेट एक URL के समान होगा gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com (शीर्ष स्तर के उपडोमेन यहाँ निर्दिष्ट हैं)।

यह सेवा अप्रचलित है इसलिए यह हमला अब उपयोगी नहीं है। इसके अलावा, आर्टिफैक्ट रजिस्ट्री, जो इस सेवा का स्थानापन्न है, बकेट में छवियों को संग्रहीत नहीं करती है।

संदर्भ

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

Last updated