GCP - Storage Privesc

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

Сховище

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

pageGCP - Storage Enum

storage.objects.get

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

  • GCP Composer: При створенні середовища Composer код всіх DAG буде збережено в відро. Ці завдання можуть містити цікаву інформацію у своєму коді.

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

storage.objects.setIamPolicy

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

storage.buckets.setIamPolicy

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

pageGCP - 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>

# Configure gsutil to use it
gsutil config -a

# Use it
gsutil ls gs://[BUCKET_NAME]

Інший скрипт вразливості для цього методу можна знайти тут.

storage.objects.create, storage.objects.delete = Дозволи на запис у сховище

Для створення нового об'єкту всередині відра вам потрібно мати storage.objects.create і, згідно з документацією, вам також потрібно storage.objects.delete для зміни існуючого об'єкту.

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

Composer

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

  • Він працює всередині кластера GKE, тому СА, який використовує кластер, доступний для коду, що виконується всередині Composer.

  • Він зберігає код у відро, отже, будь-хто з правами на запис у це відро зможе змінити/додати код DGA (код, який виконає Apache Airflow) Таким чином, якщо у вас є права на запис у відро, яке використовує Composer для зберігання коду, ви можете піднятися в привілеї до СА, що працює в кластері GKE.

Cloud Functions

  • Код Cloud Functions зберігається в сховищі, тому переписавши його, можна виконати довільний код.

App Engine

  • Вихідний код App Engine зберігається в відрах, переписавши код, можливо виконати довільний код. ЦЕ НЕМОЖЛИВО

  • Здається, що шари контейнера зберігаються в відрі, можливо, змінивши їх?

GCR

  • Google Container Registry зберігає зображення всередині відер, якщо ви можете писати в ці відра, ви, можливо, зможете переміститися бічно туди, де вони виконуються.

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

Посилання

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

Last updated