GCP <--> Workspace Pivoting

Reading time: 10 minutes

tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримка HackTricks

З GCP до GWS

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

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

note

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

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

GCP - Understanding Domain-Wide Delegation

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

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

caution

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

GCP Generate Delegation Token

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

bash
# 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"

DelePwn

На основі наступного інструменту DeleFriend, але з деякими доповненнями, такими як можливість перераховувати домен, диск, gmail, календар та виконувати інші операції.

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.

Gitlab's Python script

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

bash
# 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 викликів та CLI інструментів. Це вимагає ролі iam.serviceAccountAdmin або будь-якої кастомної ролі, оснащеної дозволом iam.serviceAccounts.create. Після створення облікового запису служби ми перейдемо до генерації пов'язаної пари ключів (дозвіл iam.serviceAccountKeys.create).
  2. Створення нової делегації: Важливо розуміти, що тільки роль супер адміністратора має можливість налаштувати глобальну делегацію на рівні домену в Google Workspace і делегацію на рівні домену не можна налаштувати програмно, її можна створити та налаштувати вручну через консоль Google Workspace.
  • Створення правила можна знайти на сторінці API controls → Manage Domain-Wide delegation in Google Workspace Admin console.
  1. Прикріплення привілеїв OAuth scopes: При налаштуванні нової делегації Google вимагає лише 2 параметри: ідентифікатор клієнта, який є OAuth ID ресурсу облікового запису служби GCP, та OAuth scopes, які визначають, які API виклики потрібні для делегації.
  • Повний список OAuth 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
  1. Дії від імені цільової особи: На цьому етапі у нас є функціонуючий делегований об'єкт у GWS. Тепер, використовуючи приватний ключ облікового запису служби GCP, ми можемо виконувати API виклики (в межах, визначених у параметрі OAuth scope), щоб активувати його та діяти від імені будь-якої особи, яка існує в Google Workspace. Як ми дізналися, обліковий запис служби генеруватиме токени доступу відповідно до своїх потреб і згідно з дозволами, які він має для REST API додатків.
  • Перевірте попередній розділ для деяких інструментів для використання цієї делегації.

Делегація між організаціями

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

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

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

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

caution

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

bash
# 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>

Перевірте додаткову енумерацію в:

GCP - IAM, Principals & Org Policies Enum

Зловживання обліковими даними Gcloud

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

GCP - Token Persistence

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

bash
gcloud auth login --enable-gdrive-access

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

warning

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

Щоб перерахувати файли на drive: 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 privesc, ви можете мати можливість підвищити привілеї до групи з якимось видом привілейованого доступу до GCP.

Посилання

tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримка HackTricks