GCP - Storage Privesc
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Основна інформація:
GCP - Storage Enumstorage.objects.get
Цей дозвіл дозволяє вам завантажувати файли, збережені в Cloud Storage. Це потенційно дозволить вам підвищити привілеї, оскільки в деяких випадках чутлива інформація зберігається там. Більше того, деякі сервіси GCP зберігають свою інформацію в бакетах:
GCP Composer: Коли ви створюєте середовище Composer, код усіх DAG буде збережено в бакеті. Ці завдання можуть містити цікаву інформацію в своєму коді.
GCR (Container Registry): Зображення контейнерів зберігаються в бакетах, що означає, що якщо ви можете читати бакети, ви зможете завантажити зображення та шукати витоки та/або вихідний код.
storage.objects.setIamPolicy
Ви можете надати собі дозвіл на зловживання будь-яким з попередніх сценаріїв цього розділу.
storage.buckets.setIamPolicy
Для прикладу, як змінити дозволи за допомогою цього дозволу, перегляньте цю сторінку:
GCP - Public Buckets Privilege Escalationstorage.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
, щоб модифікувати існуючий об'єкт.
Дуже поширене використання бакетів, в які можна записувати в хмарі, відбувається у випадку, якщо бакет зберігає файли веб-сервера, ви можете бути в змозі зберегти новий код, який буде використовуватися веб-додатком.
Composer - це Apache Airflow, керований у GCP. Він має кілька цікавих функцій:
Він працює всередині GKE кластера, тому SA, який використовує кластер, доступний коду, що виконується всередині Composer
Усі компоненти середовища композера (код DAGs, плагіни та дані) зберігаються всередині бакета GCP. Якщо зловмисник має права на читання та запис, він може моніторити бакет і коли DAG створюється або оновлюється, подати версію з бекдором, щоб середовище композера отримало зберігання версію з бекдором.
Ви можете знайти PoC цього нападу в репозиторії: https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs
Код Cloud Functions зберігається у Storage, і коли створюється нова версія, код надсилається до бакета, а потім новий контейнер створюється з цього коду. Тому, перезаписуючи код перед створенням нової версії, можна змусити хмарну функцію виконувати довільний код.
Ви можете знайти PoC цього нападу в репозиторії: https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions
Версії 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
Google Container Registry зберігає зображення всередині бакетів, якщо ви можете записувати в ці бакети, ви можете бути в змозі переміститися вбік до того, де ці бакети виконуються.
Бакет, що використовується GCR, матиме URL, подібний до gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com
(Верхні піддомени вказані тут).
Ця служба застаріла, тому цей напад більше не є корисним. Більше того, Artifact Registry, служба, яка замінює цю, не зберігає зображення в бакетах.
Вивчайте та практикуйте Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)