Ukranian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP <--> Workspace Pivoting

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

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

З GCP до GWS

Основи делегування на рівні домену

Делегування на рівні домену Google Workspace дозволяє об'єкту ідентичності, будь то зовнішній додаток з Google Workspace Marketplace або внутрішній Сервісний обліковий запис GCP, отримувати доступ до даних по всьому Робочому простору від імені користувачів.

Це в основному означає, що сервісні облікові записи всередині проектів GCP організації можуть видаавати себе за користувачів Робочого простору цієї ж організації (або навіть з іншої).

Для отримання додаткової інформації про те, як саме це працює, перевірте:

pageGCP - Understanding Domain-Wide Delegation

Компрометація існуючого делегування

Якщо зловмисник отримав доступ до GCP і знає дійсну електронну адресу користувача Робочого простору (найкраще суперадміністратора), він може перелічити всі проекти, до яких він має доступ, перелічити всі СО проектів, перевірити, до яких сервісних облікових записів він має доступ, і повторити всі ці кроки з кожним СО, яким він може видаавати себе. Зі списком всіх сервісних облікових записів, до яких він має доступ, і списком електронних адрес Робочого простору, зловмисник може спробувати видаавати себе за користувача з кожним сервісним обліковим записом.

Зверніть увагу, що при налаштуванні делегування на рівні домену не потрібен користувач Робочого простору, тому достатньо знати одного дійсного користувача, що є обов'язковим для видачі себе за нього. Однак привілеї видааного користувача будуть використані, тому якщо це Суперадміністратор, ви зможете отримати доступ до всього. Якщо у нього немає доступу, це буде некорисно.

GCP Generate Delegation Token

Цей простий скрипт генерує токен OAuth в якості делегованого користувача, який ви потім можете використовувати для доступу до інших Google API з або без gcloud:

# Impersonate indicated user
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file>

# Impersonate indicated user and add additional scopes
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file> --scopes "https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid"

DeleFriend

Це інструмент, який може виконати атаку, виконуючи ці кроки:

  1. Перелічіть проекти GCP, використовуючи API Resource Manager.

  2. Перебирайте кожний ресурс проекту та перелічіть ресурси облікових записів служб GCP, до яких має доступ початковий користувач IAM, використовуючи GetIAMPolicy.

  3. Перебирайте кожну роль облікового запису служби та знаходьте вбудовані, базові та користувацькі ролі з дозволом serviceAccountKeys.create на цільовому ресурсі облікового запису служби. Слід зауважити, що роль Редактора інтегрально має цей дозвіл.

  4. Створіть новий приватний ключ KEY_ALG_RSA_2048 для кожного ресурсу облікового запису служби, який знайдено з відповідним дозволом в полі IAM.

  5. Перебирайте кожен новий обліковий запис служби та створіть JWT об'єкт для нього, який складається з облікових даних приватного ключа SA та області OAuth. Процес створення нового JWT об'єкта буде перебирати всі існуючі комбінації областей OAuth зі списку oauth_scopes.txt, щоб знайти всі можливості делегування. Список oauth_scopes.txt оновлюється всіма областями OAuth, які ми вважаємо важливими для зловживання ідентичностями Workspace.

  6. Метод _make_authorization_grant_assertion показує необхідність вказати цільового користувача робочого простору, який називається subject, для генерування JWT під DWD. Хоча це може здатися вимагати конкретного користувача, важливо усвідомити, що DWD впливає на кожну ідентичність в домені. Відповідно, створення JWT для будь-якого користувача домену впливає на всі ідентичності в цьому домені, відповідно до нашої перевірки переліку комбінацій. Просто кажучи, один дійсний користувач Workspace є достатнім для продовження. Цього користувача можна визначити в файлі config.yaml DeleFriend. Якщо цільовий користувач робочого простору вже не відомий, інструмент сприяє автоматичному визначенню дійсних користувачів робочого простору шляхом сканування користувачів домену з ролями в проектах GCP. Важливо зауважити (знову), що JWT є специфічними для домену і не генеруються для кожного користувача; отже, автоматичний процес спрямований на одну унікальну ідентичність на домен.

  7. Перелічте та створіть новий токен доступу до носія для кожного JWT та перевірте токен за допомогою API tokeninfo.

Python-скрипт Gitlab

Gitlab створив цей Python-скрипт, який може робити дві речі - перелік каталогу користувачів та створення нового облікового запису адміністратора, вказуючи json з обліковими даними SA та користувачем для підроблення. Ось як ви його використовуватимете:

# Install requirements
pip install --upgrade --user oauth2client

# Validate access only
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com

# List the directory
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--list

# Create a new admin account
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--account pwned

Створення нової делегації (Постійність)

Можливо перевірити делегації на рівні домену в https://admin.google.com/u/1/ac/owl/domainwidedelegation.

Атакуючий з можливістю створювати облікові записи служб в проекті GCP та суперадміністративними привілеями до GWS може створити нову делегацію, що дозволить обліковим записам служб піддаватися під впливом деяких користувачів GWS:

  1. Створення нового облікового запису служби та відповідної пари ключів: На GCP ресурси нового облікового запису служби можуть бути створені або інтерактивно через консоль, або програмно за допомогою прямих викликів API та інструментів командного рядка. Це вимагає ролі iam.serviceAccountAdmin або будь-якої користувацької ролі, обладнаної дозволом iam.serviceAccounts.create. Після створення облікового запису служби ми перейдемо до створення відповідної пари ключів (дозвіл iam.serviceAccountKeys.create).

  2. Створення нової делегації: Важливо розуміти, що лише роль Суперадміна має можливість налаштувати глобальну делегацію на рівні домену в Google Workspace і делегацію на рівні домену не можна налаштувати програмно, Її можна лише створити та налаштувати вручну через консоль Google Workspace.

  • Створення правила можна знайти на сторінці Керування API → Керування глобальною делегацією на рівні домену в консолі адміністратора Google Workspace.

  1. Надання привілеїв областей OAuth: При налаштуванні нової делегації Google вимагає лише 2 параметри, Ідентифікатор клієнта, який є OAuth ID ресурсу облікового запису служби GCP, та області OAuth, які визначають, які виклики API потрібні для делегації.

  • Повний список областей OAuth можна знайти тут, але ось рекомендація: https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid

  1. Дія від імені цільової особи: На цей момент у нас є працюючий делегований об'єкт в GWS. Тепер, використовуючи приватний ключ облікового запису служби GCP, ми можемо виконувати виклики API (в області, визначеній в параметрі області OAuth) для його запуску та діяти від імені будь-якої особи, яка існує в Google Workspace. Як ми вивчили, обліковий запис служби буде генерувати токени доступу відповідно до своїх потреб та згідно з дозволом, який він має до додатків REST API.

  • Перевірте попередній розділ для деяких інструментів, які можна використовувати для цієї делегації.

Міжорганізаційна делегація

Ідентифікатор OAuth SA є глобальним і може бути використаний для міжорганізаційної делегації. Наразі не було введено обмежень для запобігання міжглобальній делегації. Простими словами, облікові записи служб з різних організацій GCP можуть бути використані для налаштування глобальної делегації на рівні домену в інших організаціях Workspace. Це призведе до того, що для доступу до Workspace потрібно лише суперадміністративний доступ, а не доступ до того ж облікового запису GCP, оскільки зловмисник може створювати облікові записи служб та приватні ключі на своєму особисто контрольованому обліковому записі GCP.

Створення проекту для переліку Workspace

За замовчуванням користувачі Workspace мають дозвіл на створення нових проектів, і коли створюється новий проект, творець отримує роль Власника над ним.

Отже, користувач може створити проект, активувати API, щоб перелічити Workspace у своєму новому проекті та спробувати перелічити його.

Для того, щоб користувач міг перелічити Workspace, йому також потрібно мати достатньо дозволів Workspace (не кожен користувач зможе перелічити каталог).

# Create project
gcloud projects create <uniq-projec-name> --name=proj-name
# Set project
gcloud config set project <uniq-projec-name>
# Enable svcs
gcloud services enable admin.googleapis.com
gcloud services enable cloudidentity.googleapis.com
# Get org ID
gcloud organizations list
# Get currents email user groups (at least you can check the groups and members of the groups you belong to)
gcloud identity groups memberships search-transitive-groups --member-email <email> --labels=cloudidentity.googleapis.com/groups.discussion_forum
gcloud identity groups memberships list --group-email=g<group-email>

# FROM HERE THE USER NEEDS TO HAVE ENOUGH WORKSPACE ACCESS
gcloud beta identity groups preview --customer <org-cust-id>

Перевірте додаткове вивчення в:

pageGCP - IAM, Principals & Org Policies Enum

Зловживання Gcloud

Ви можете знайти додаткову інформацію про потік gcloud для входу в систему:

pageGCP - Non-svc Persistance

Як пояснено там, gcloud може запитати область https://www.googleapis.com/auth/drive, що дозволить користувачеві отримати доступ до диска користувача. Як зловмисник, якщо ви скомпрометували фізично комп'ютер користувача і користувач все ще увійшов у свій обліковий запис, ви можете увійти, створивши токен з доступом до диска за допомогою:

gcloud auth login --enable-gdrive-access

Якщо зловмисник скомпрометував комп'ютер користувача, він також може змінити файл google-cloud-sdk/lib/googlecloudsdk/core/config.py та додати в CLOUDSDK_SCOPES область 'https://www.googleapis.com/auth/drive':

Отже, наступного разу, коли користувач увійде в систему, він створить токен з доступом до диска, який зловмисник може використовувати для доступу до диска. Очевидно, що браузер вказуватиме, що згенерований токен матиме доступ до диска, але оскільки користувач викличе gcloud auth login, він, ймовірно, не підозрюватиме нічого.

Для переліку файлів на диску: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"

Від GWS до GCP

Доступ до привілейованих користувачів GCP

Якщо зловмисник має повний доступ до GWS, він зможе отримати доступ до груп з привілейованим доступом до GCP або навіть користувачів, тому перехід від GWS до GCP зазвичай є більш "простим", оскільки користувачі в GWS мають високі привілеї в GCP.

Підвищення привілеїв Google Groups

За замовчуванням користувачі можуть вільно приєднуватися до груп Workspace організації, і ці групи можуть мати призначені дозволи GCP (перевірте свої групи за адресою https://groups.google.com/).

Зловживаючи підвищенням привілеїв google groups, ви можете здати до групи з певним привілеєм доступу до GCP.

Посилання

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

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

PreviousGCP - Storage EnumNextGCP - Understanding Domain-Wide Delegation

Last updated