GCP - Storage Privesc
Storage
Основна інформація:
GCP - 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
Для прикладу, як змінити дозволи за допомогою цього дозволу, перегляньте цю сторінку:
GCP - 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 кластера, тому 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, служба, яка замінює цю, не зберігає зображення в бакетах.
Посилання
Last updated