GCP - Storage Privesc
Сховище
Основна інформація:
pageGCP - Storage Enumstorage.objects.get
storage.objects.get
Ця дозвіл дозволяє вам завантажувати файли, збережені в Cloud Storage. Це потенційно дозволить вам підвищити привілеї, оскільки у деяких випадках чутлива інформація зберігається там. Крім того, деякі служби GCP зберігають свою інформацію в відрах:
GCP Composer: При створенні середовища Composer код всіх DAG буде збережено в відро. Ці завдання можуть містити цікаву інформацію у своєму коді.
GCR (Container Registry): Зображення контейнерів зберігаються в відрах, що означає, що якщо ви можете читати відра, ви зможете завантажити зображення та шукати витоки та/або вихідний код.
storage.objects.setIamPolicy
storage.objects.setIamPolicy
Ви можете дати собі дозвіл на зловживання будь-якими зазначеними сценаріями цього розділу.
storage.buckets.setIamPolicy
storage.buckets.setIamPolicy
Для прикладу того, як змінити дозволи за цим дозволом, перегляньте цю сторінку:
pageGCP - Public Buckets Privilege Escalationstorage.hmacKeys.create
storage.hmacKeys.create
Функція "взаємодія" Cloud Storage, призначена для міжхмарних взаємодій, наприклад з AWS S3, передбачає створення HMAC-ключів для Службових облікових записів та користувачів. Атакувальник може використовувати це, створюючи HMAC-ключ для Службового облікового запису з підвищеними привілеями, тим самим підвищуючи привілеї в межах Cloud Storage. Хоча HMAC-ключі, пов'язані з користувачем, можна отримати лише через веб-консоль, обидва ключі доступу та секретні ключі залишаються постійно доступними, що дозволяє зберігати потенційний резервний доступ. Навпаки, HMAC-ключі, пов'язані з Службовим обліковим записом, доступні через API, але їх ключі доступу та секретні ключі не можна отримати після створення, що додає складність для постійного доступу.
Інший скрипт вразливості для цього методу можна знайти тут.
storage.objects.create
, storage.objects.delete
= Дозволи на запис у сховище
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
(Верхні піддомени вказані тут).
Посилання
Last updated