GCP - Storage 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)
बुनियादी जानकारी:
GCP - Storage Enumstorage.objects.get
यह अनुमति आपको Cloud Storage के अंदर संग्रहीत फ़ाइलों को डाउनलोड करने की अनुमति देती है। यह संभावित रूप से आपको विशेषाधिकार बढ़ाने की अनुमति देगी क्योंकि कुछ अवसरों पर संवेदनशील जानकारी वहाँ संग्रहीत होती है। इसके अलावा, कुछ GCP सेवाएँ अपनी जानकारी बकेट में संग्रहीत करती हैं:
GCP Composer: जब आप एक Composer Environment बनाते हैं, तो सभी DAGs का कोड एक बकेट के अंदर संग्रहीत किया जाएगा। इन कार्यों में उनके कोड के अंदर दिलचस्प जानकारी हो सकती है।
GCR (Container Registry): कंटेनरों की छवि बकेट के अंदर संग्रहीत होती है, जिसका अर्थ है कि यदि आप बकेट पढ़ सकते हैं, तो आप छवियों को डाउनलोड कर सकेंगे और लीक और/या स्रोत कोड की खोज कर सकेंगे।
storage.objects.setIamPolicy
आपको इस अनुभाग के पिछले परिदृश्यों का दुरुपयोग करने की अनुमति देने के लिए आप अनुमति दे सकते हैं।
storage.buckets.setIamPolicy
इस अनुमति के साथ अनुमतियों को संशोधित करने के लिए एक उदाहरण के लिए इस पृष्ठ की जांच करें:
GCP - Public Buckets Privilege Escalationstorage.hmacKeys.create
Cloud Storage की "इंटरऑपरेबिलिटी" विशेषता, जो AWS S3 के साथ क्रॉस-क्लाउड इंटरैक्शन के लिए डिज़ाइन की गई है, में सेवा खातों और उपयोगकर्ताओं के लिए HMAC कुंजी का निर्माण शामिल है। एक हमलावर इसका लाभ उठा सकता है उच्च विशेषाधिकार वाले सेवा खाते के लिए HMAC कुंजी उत्पन्न करके, इस प्रकार Cloud Storage के भीतर विशेषाधिकार बढ़ाना। जबकि उपयोगकर्ता से संबंधित HMAC कुंजी केवल वेब कंसोल के माध्यम से पुनः प्राप्त की जा सकती हैं, दोनों एक्सेस और गुप्त कुंजी सदा के लिए सुलभ रहती हैं, जिससे संभावित बैकअप एक्सेस स्टोरेज की अनुमति मिलती है। इसके विपरीत, सेवा खाता से जुड़े HMAC कुंजी API-सुलभ हैं, लेकिन उनकी एक्सेस और गुप्त कुंजी निर्माण के बाद पुनः प्राप्त नहीं की जा सकती, जिससे निरंतर पहुँच के लिए जटिलता का एक स्तर जुड़ता है।
इस विधि के लिए एक और शोषण स्क्रिप्ट यहाँ मिल सकती है।
storage.objects.create
, storage.objects.delete
= स्टोरेज लिखने की अनुमतिएक बकेट के अंदर नया ऑब्जेक्ट बनाने के लिए आपको storage.objects.create
की आवश्यकता है और, दस्तावेज़ों के अनुसार, आपको एक मौजूदा ऑब्जेक्ट को संशोधित करने के लिए storage.objects.delete
की भी आवश्यकता है।
क्लाउड में लिखने के लिए बकेट का एक बहुत सामान्य शोषण तब होता है जब बकेट वेब सर्वर फ़ाइलों को सहेज रहा है, आप नया कोड स्टोर करने में सक्षम हो सकते हैं जो वेब एप्लिकेशन द्वारा उपयोग किया जाएगा।
Composer Apache Airflow है जो GCP के अंदर प्रबंधित है। इसमें कई दिलचस्प विशेषताएँ हैं:
यह एक GKE क्लस्टर के अंदर चलता है, इसलिए क्लस्टर द्वारा उपयोग किया जाने वाला SA कोड के द्वारा पहुँच योग्य है जो Composer के अंदर चल रहा है
Composer वातावरण के सभी घटक (DAGs का कोड, प्लगइन्स और डेटा) एक GCP बकेट के अंदर संग्रहीत होते हैं। यदि हमलावर के पास इसके ऊपर पढ़ने और लिखने की अनुमति है, तो वह बकेट की निगरानी कर सकता है और जब भी एक DAG बनाया या अपडेट किया जाता है, एक बैकडोर संस्करण सबमिट कर सकता है ताकि Composer वातावरण स्टोरेज से बैकडोर संस्करण प्राप्त कर सके।
आप इस हमले का PoC इस रिपॉजिटरी में पा सकते हैं: https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs
Cloud Functions का कोड स्टोरेज में संग्रहीत होता है और जब भी एक नया संस्करण बनाया जाता है, तो कोड बकेट में पुश किया जाता है और फिर नए कंटेनर का निर्माण इस कोड से किया जाता है। इसलिए, नए संस्करण के निर्माण से पहले कोड को ओवरराइट करना क्लाउड फ़ंक्शन को मनमाने कोड को निष्पादित करने में सक्षम बनाता है।
आप इस हमले का PoC इस रिपॉजिटरी में पा सकते हैं: https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions
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 संस्करण का पूरा नया कोड एक अलग और उपलब्ध बकेट में अपलोड करें और manifest.json
फ़ाइल को नए बकेट नाम और उनके sha1 हैश के साथ तैयार करें। फिर, जब बकेट के अंदर एक नया संस्करण बनाया जाता है, तो आपको बस manifest.json
फ़ाइल को संशोधित करना है और दुर्भावनापूर्ण फ़ाइल अपलोड करनी है।
एक संशोधित requirements.txt
संस्करण अपलोड करें जो दुर्भावनापूर्ण निर्भरताओं के कोड का उपयोग करेगा और manifest.json
फ़ाइल को नए फ़ाइल नाम, URL और इसके हैश के साथ अपडेट करेगा।
एक संशोधित main.py
या app.yaml
फ़ाइल अपलोड करें जो दुर्भावनापूर्ण कोड को निष्पादित करेगी और manifest.json
फ़ाइल को नए फ़ाइल नाम, URL और इसके हैश के साथ अपडेट करेगी।
आप इस हमले का PoC इस रिपॉजिटरी में पा सकते हैं: https://github.com/carlospolop/Monitor-Backdoor-AppEngine
Google Container Registry बकेट के अंदर छवियों को संग्रहीत करता है, यदि आप उन बकेट्स में लिख सकते हैं तो आप उन बकेट्स के चलने के स्थान पर लेटरली मूव करने में सक्षम हो सकते हैं।
GCR द्वारा उपयोग किया जाने वाला बकेट एक URL के समान होगा gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com
(शीर्ष स्तर के उपडोमेन यहाँ निर्दिष्ट हैं)।
यह सेवा अप्रचलित है इसलिए यह हमला अब उपयोगी नहीं है। इसके अलावा, आर्टिफैक्ट रजिस्ट्री, जो इस सेवा का स्थानापन्न है, बकेट में छवियों को संग्रहीत नहीं करता है।
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)