Ukranian - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

GCP - Storage Privesc

Support HackTricks

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 (Верхні піддомени вказані тут).

Ця служба застаріла, тому цей напад більше не є корисним. Більше того, Artifact Registry, служба, яка замінює цю, не зберігає зображення в бакетах.

Посилання

Підтримка HackTricks
PreviousGCP - Sourcerepos PrivescNextGCP - Workflows Privesc

Last updated