GCP - Storage Privesc
Storage
मूल जानकारी:
pageGCP - Storage Enumstorage.objects.get
storage.objects.get
यह अनुमति आपको Cloud Storage के अंदर संग्रहीत फाइलों को डाउनलोड करने की अनुमति देती है। इससे आपको विशेषाधिकार बढ़ाने की संभावना हो सकती है क्योंकि कभी-कभी संवेदनशील जानकारी वहां संग्रहीत होती है। इसके अलावा, कुछ GCP सेवाएं अपनी जानकारी बकेट्स में संग्रहीत करती हैं:
GCP Composer: जब आप एक Composer Environment बनाते हैं तो सभी DAGs का कोड एक बकेट के अंदर संग्रहीत हो जाएगा। इन कार्यों में उनके कोड के अंदर दिलचस्प जानकारी हो सकती है।
GCR (Container Registry): कंटेनरों की इमेज बकेट्स के अंदर संग्रहीत होती हैं, जिसका मतलब है कि यदि आप बकेट्स को पढ़ सकते हैं तो आप इमेजेस को डाउनलोड कर सकते हैं और लीक्स और/या सोर्स कोड की खोज कर सकते हैं।
storage.objects.setIamPolicy
storage.objects.setIamPolicy
आप इस अनुमति का उपयोग करके इस खंड के पिछले परिदृश्यों में से किसी का भी दुरुपयोग कर सकते हैं।
storage.buckets.setIamPolicy
storage.buckets.setIamPolicy
इस अनुमति के साथ अनुमतियों को कैसे संशोधित करें, इसके उदाहरण के लिए इस पृष्ठ को देखें:
pageGCP - Public Buckets Privilege Escalationstorage.hmacKeys.create
storage.hmacKeys.create
Cloud Storage की "interoperability" सुविधा, जो क्रॉस-क्लाउड इंटरैक्शन के लिए डिजाइन की गई है, जैसे कि AWS S3 के साथ, Service Accounts और उपयोगकर्ताओं के लिए HMAC कुंजियों का निर्माण शामिल है। एक हमलावर इसका शोषण कर सकता है उच्च विशेषाधिकारों वाले Service Account के लिए एक HMAC कुंजी उत्पन्न करके, इस प्रकार Cloud Storage के भीतर विशेषाधिकारों को बढ़ाना। जबकि उपयोगकर्ता-संबद्ध HMAC कुंजियाँ केवल वेब कंसोल के माध्यम से प्राप्त की जा सकती हैं, दोनों पहुँच और गुप्त कुंजियाँ स्थायी रूप से सुलभ रहती हैं, जिससे संभावित बैकअप एक्सेस स्टोरेज के लिए अनुमति मिलती है। इसके विपरीत, Service Account-से जुड़ी HMAC कुंजियाँ API-सुलभ होती हैं, लेकिन उनकी पहुँच और गुप्त कुंजियाँ निर्माण के बाद प्राप्त नहीं की जा सकती हैं, जो निरंतर पहुँच के लिए जटिलता की एक परत जोड़ती है।
इस विधि के लिए एक और एक्सप्लॉइट स्क्रिप्ट यहाँ पाई जा सकती है।
storage.objects.create
, storage.objects.delete
= स्टोरेज लिखने की अनुमतियाँ
storage.objects.create
, storage.objects.delete
= स्टोरेज लिखने की अनुमतियाँएक बकेट के अंदर नया ऑब्जेक्ट बनाने के लिए आपको storage.objects.create
की आवश्यकता होती है और, दस्तावेज़ों के अनुसार, मौजूदा ऑब्जेक्ट को संशोधित करने के लिए आपको storage.objects.delete
की भी आवश्यकता होती है।
जहाँ आप क्लाउड में लिख सकते हैं, बकेट्स का एक बहुत सामान्य शोषण तब होता है जब बकेट वेब सर्वर फाइलों को सहेज रहा होता है, आप नया कोड स्टोर करने में सक्षम हो सकते हैं जिसका उपयोग वेब एप्लिकेशन द्वारा किया जाएगा।
Composer
Composer GCP के अंदर प्रबंधित Apache Airflow है। इसमें कई दिलचस्प विशेषताएं हैं:
यह GKE क्लस्टर के अंदर चलता है, इसलिए क्लस्टर जो SA का उपयोग करता है वह Composer के अंदर चल रहे कोड द्वारा सुलभ है
यह बकेट में कोड स्टोर करता है, इसलिए, उस बकेट पर लिखने की पहुँच वाला कोई भी DGA कोड (जो कोड Apache Airflow निष्पादित करेगा) बदलने/जोड़ने में सक्षम होगा। फिर, अगर आपके पास Composer द्वारा उपयोग किए जा रहे बकेट पर लिखने की पहुँच है, आप GKE क्लस्टर में चल रहे SA के लिए privesc कर सकते हैं।
Cloud Functions
Cloud Functions का कोड Storage में संग्रहीत होता है, इसलिए इसे ओवरराइट करने से, मनमाना कोड निष्पादित करना संभव है।
App Engine
App Engine का स्रोत कोड बकेट्स में संग्रहीत होता है, कोड को ओवरराइट करने से मनमाना कोड निष्पादित करना संभव हो सकता है। यह संभव नहीं है
ऐसा लगता है कि कंटेनर लेयर्स बकेट में संग्रहीत होते हैं, शायद उन्हें बदलना?
GCR
Google Container Registry इमेजेज को बकेट्स के अंदर संग्रहीत करता है, अगर आप उन बकेट्स को लिख सकते हैं तो आप उन बकेट्स के चलाए जा रहे स्थान पर बाद में चल सकते हैं।
GCR द्वारा उपयोग किए जा रहे बकेट का URL
gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com
जैसा होगा (शीर्ष स्तर के सबडोमेन्स यहाँ निर्दिष्ट हैं)।
संदर्भ
Last updated