GCP - local privilege escalation ssh pivoting

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

इस परिदृश्य में हम मानने जा रहे हैं कि आपने एक गैर विशेषाधिकार खाता को एक Compute Engine प्रोजेक्ट के अंदर एक VM में समझौता किया है।

अद्भुत रूप से, आपके द्वारा समझौता किए गए Compute Engine के GPC अनुमतियाँ आपको एक मशीन के अंदर स्थानीय रूप से विशेषाधिकार बढ़ाने में मदद कर सकती हैं। भले ही यह हमेशा एक क्लाउड वातावरण में बहुत सहायक न हो, यह जानना अच्छा है कि यह संभव है।

स्क्रिप्ट पढ़ें

Compute Instances शायद वहाँ कुछ स्क्रिप्ट्स को निष्पादित करने के लिए हैं ताकि उनके सेवा खातों के साथ क्रियाएँ की जा सकें।

चूंकि IAM बहुत बारीक है, एक खाते के पास एक संसाधन पर पढ़ने/लिखने के विशेषाधिकार हो सकते हैं लेकिन कोई सूची विशेषाधिकार नहीं

इसका एक शानदार काल्पनिक उदाहरण एक Compute Instance है जिसे instance82736-long-term-xyz-archive-0332893 नामक एक स्टोरेज बकेट में बैकअप पढ़ने/लिखने की अनुमति है।

कमांड लाइन से gsutil ls चलाने पर कुछ भी नहीं लौटता है, क्योंकि सेवा खाते के पास storage.buckets.list IAM अनुमति नहीं है। हालाँकि, यदि आपने gsutil ls gs://instance82736-long-term-xyz-archive-0332893 चलाया, तो आप एक पूर्ण फ़ाइल सिस्टम बैकअप पा सकते हैं, जो आपको उस डेटा तक स्पष्ट-पाठ पहुंच देता है जो आपके स्थानीय Linux खाते के पास नहीं है।

आप इस बकेट नाम को एक स्क्रिप्ट (bash, Python, Ruby...) के अंदर पा सकते हैं।

कस्टम मेटाडेटा

प्रशासक इंस्टेंस और प्रोजेक्ट स्तर पर कस्टम मेटाडेटा जोड़ सकते हैं। यह बस एक तरीके से मनमाने कुंजी/मान जोड़े को एक इंस्टेंस में पास करने का तरीका है, और इसे आमतौर पर पर्यावरण चर और स्टार्टअप/शटडाउन स्क्रिप्ट के लिए उपयोग किया जाता है।

इसके अलावा, userdata जोड़ना संभव है, जो एक स्क्रिप्ट है जो हर बार मशीन शुरू या पुनः प्रारंभ होने पर निष्पादित की जाएगी और जिसे मेटाडेटा एंडपॉइंट से भी एक्सेस किया जा सकता है।

अधिक जानकारी के लिए देखें:

IAM अनुमतियों का दुरुपयोग करना

निम्नलिखित प्रस्तावित अनुमतियों में से अधिकांश डिफ़ॉल्ट Compute SA को दी गई हैं, केवल समस्या यह है कि डिफ़ॉल्ट एक्सेस स्कोप SA को उनका उपयोग करने से रोकता है। हालाँकि, यदि cloud-platform स्कोप सक्षम है या केवल compute स्कोप सक्षम है, तो आप उनका दुरुपयोग करने में सक्षम होंगे

निम्नलिखित अनुमतियों की जांच करें:

फ़ाइल सिस्टम में कुंजियों की खोज करें

जांचें कि क्या अन्य उपयोगकर्ताओं ने बॉक्स के अंदर gcloud में लॉगिन किया है और फ़ाइल सिस्टम में अपनी क्रेडेंशियल्स छोड़ दी हैं:

sudo find / -name "gcloud"

ये सबसे दिलचस्प फ़ाइलें हैं:

  • ~/.config/gcloud/credentials.db

  • ~/.config/gcloud/legacy_credentials/[ACCOUNT]/adc.json

  • ~/.config/gcloud/legacy_credentials/[ACCOUNT]/.boto

  • ~/.credentials.json

अधिक API Keys regexes

TARGET_DIR="/path/to/whatever"

# Service account keys
grep -Pzr "(?s){[^{}]*?service_account[^{}]*?private_key.*?}" \
"$TARGET_DIR"

# Legacy GCP creds
grep -Pzr "(?s){[^{}]*?client_id[^{}]*?client_secret.*?}" \
"$TARGET_DIR"

# Google API keys
grep -Pr "AIza[a-zA-Z0-9\\-_]{35}" \
"$TARGET_DIR"

# Google OAuth tokens
grep -Pr "ya29\.[a-zA-Z0-9_-]{100,200}" \
"$TARGET_DIR"

# Generic SSH keys
grep -Pzr "(?s)-----BEGIN[ A-Z]*?PRIVATE KEY[a-zA-Z0-9/\+=\n-]*?END[ A-Z]*?PRIVATE KEY-----" \
"$TARGET_DIR"

# Signed storage URLs
grep -Pir "storage.googleapis.com.*?Goog-Signature=[a-f0-9]+" \
"$TARGET_DIR"

# Signed policy documents in HTML
grep -Pzr '(?s)<form action.*?googleapis.com.*?name="signature" value=".*?">' \
"$TARGET_DIR"

संदर्भ

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

Last updated