GCP - Storage Privesc

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Вивчайте та практикуйте Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

Storage

Основна інформація:

GCP - Storage Enum

storage.objects.get

Ця дозвола дозволяє вам download files stored inside Cloud Storage. Це може надати можливість підвищити права, оскільки іноді sensitive information is saved there. Крім того, деякі GCP сервіси зберігають свою інформацію в buckets:

  • GCP Composer: When you create a Composer Environment the code of all the DAGs will be saved inside a bucket. These tasks might contain interesting information inside of their code.
  • GCR (Container Registry): The image of the containers are stored inside buckets, which means that if you can read the buckets you will be able to download the images and search for leaks and/or source code.

storage.objects.setIamPolicy

Ця дозвола може дати вам змогу abuse any of the previous scenarios of this section.

# Add binding
gcloud storage objects add-iam-policy-binding gs://<BUCKET_NAME>/<OBJECT_NAME> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role="<ROLE>" \
--project=<PROJECT_ID>

# Remove binding
gcloud storage objects remove-iam-policy-binding gs://<BUCKET_NAME>/<OBJECT_NAME> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role="<ROLE>" \
--project=<PROJECT_ID>

# Change Policy
gcloud storage objects set-iam-policy gs://<BUCKET_NAME>/<OBJECT_NAME> - \
--project=<PROJECT_ID> <<'POLICY'
{
"bindings": [
{
"role": "<ROLE>",
"members": [
"<MEMBER_TYPE>:<MEMBER_IDENTIFIER>"
]
}
]
}
POLICY

storage.buckets.setIamPolicy

Для прикладу того, як змінювати дозволи за допомогою цього дозволу, перегляньте цю сторінку:

# Add binding
gcloud storage buckets add-iam-policy-binding gs://<MY_BUCKET> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role=<ROLE> \
--project=<MY_PROJECT>

# Remove binding
gcloud storage buckets remove-iam-policy-binding gs://<MY_BUCKET> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role=<ROLE> \
--project=<MY_PROJECT>

# Change policy
gcloud storage buckets set-iam-policy gs://<BUCKET_NAME> - \
--project=<PROJECT_ID> <<'POLICY'
{
"bindings": [
{
"role": "<ROLE>",
"members": [
"<MEMBER_TYPE>:<MEMBER_IDENTIFIER>"
]
}
]
}
POLICY

GCP - Public Buckets Privilege Escalation

storage.hmacKeys.create

Функція “interoperability” Cloud Storage, призначена для міжхмарних взаємодій (наприклад, з AWS S3), передбачає створення HMAC keys для Service Accounts і користувачів. Атакуючий може скористатися цим, згенерувавши HMAC key для Service Account з підвищеними привілеями, тим самим ескалювавши привілеї в Cloud Storage. Хоча HMAC keys, пов’язані з користувачами, можна отримати лише через web console, обидва access and secret keys залишаються постійно доступні, що дозволяє потенційно зберігати резервний доступ. Натомість HMAC keys, пов’язані з Service Account, доступні через API, але їх access and secret keys не можна отримати після створення, що ускладнює підтримання постійного доступу.

# 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"storage-sa@{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 Write permissions

Щоб створити новий об’єкт в bucket потрібен storage.objects.create і, згідно з документацією, також потрібен storage.objects.delete, щоб змінити існуючий об’єкт.

Дуже поширена експлуатація bucket-ів, куди можна записувати, — коли bucket зберігає файли веб-сервера: у такому випадку можна завантажити новий код, який буде використаний веб-застосунком.

Composer

Composer — це Apache Airflow, яким керують у GCP. Має кілька цікавих особливостей:

  • Воно працює всередині GKE cluster, тому SA, який використовує кластер, доступний для коду, що виконується всередині Composer.
  • Усі компоненти середовища composer (code of DAGs, плагіни та дані) зберігаються в GCP bucket. Якщо нападник має права читання та запису в ньому, він може моніторити bucket і коли створюється або оновлюється DAG, підмінити його backdoored version, щоб середовище composer отримало підмінену версію зі storage.

PoC цієї атаки можна знайти в репо: https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs

Cloud Functions

  • Код Cloud Functions зберігається в Storage і щоразу, коли створюється нова версія, код штовхається в bucket, після чого з цього коду будується новий контейнер. Тому перезаписати код до того, як буде збудовано нову версію, — це можливість змусити cloud function виконати довільний код.

PoC цієї атаки можна знайти в репо: https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions

App Engine

Версії AppEngine генерують деякі дані всередині bucket з форматом імені: staging.<project-id>.appspot.com. Усередині цього bucket можна знайти папку ae, яка міститиме папку на кожну версію додатку AppEngine, і всередині цих папок можна знайти файл manifest.json. Цей файл містить json зі списком усіх файлів, які мають використовуватися для створення конкретної версії. Крім того, в ньому можна знайти реальні імена файлів, URL до них всередині GCP bucket (файли в bucket змінюють свої імена на їх sha1 хеш) і sha1 хеш кожного файлу.

Зауваження: неможливо здійснити pre-takeover цього bucket-а, тому що користувачі GCP не мають права створювати bucket-и з доменом appspot.com.

Однак при наявності доступу на читання та запис до цього bucket можна ескалувати привілеї до SA, приєднаного до версії App Engine, шляхом моніторингу bucket-а і в будь-який момент, коли відбувається зміна (нова версія), якнайшвидше модифікувати нову версію. Таким чином контейнер, який буде створено з цього коду, виконуватиме backdoored код.

Згадана атака може бути виконана різними способами, усі вони починаються з моніторингу bucket-а staging.<project-id>.appspot.com:

  • Завантажити повний новий код версії AppEngine в інший доступний bucket і підготувати manifest.json з ім’ям нового bucket-а та sha1 хешами файлів. Коли створюється нова версія в основному bucket-і, достатньо змінити 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 зберігає образи всередині bucket-ів; якщо ви можете писати в ці bucket-и, ви можете мати можливість move laterally до місць, де ці bucket-и виконуються.
  • Bucket, який використовує GCR, матиме URL, схожий на gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com (верхні піддомени вказані тут).

Tip

Цей сервіс застарів, тож ця атака вже менш корисна. Крім того, Artifact Registry, сервіс, який його замінив, не зберігає образи в bucket-ах.

References

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Вивчайте та практикуйте Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks