GCP <--> Workspace Pivoting

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Від GCP до GWS

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

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

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

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

GCP - Understanding Domain-Wide Delegation

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

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

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

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

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

Перерахувати GCP проекти за допомогою API Resource Manager.
Ітерація по кожному ресурсу проекту та перерахування ресурсів облікових записів сервісу GCP, до яких має доступ початковий IAM користувач, використовуючи GetIAMPolicy.
Ітерація по кожній ролі облікового запису сервісу та знаходження вбудованих, базових і кастомних ролей з дозволом serviceAccountKeys.create на цільовому ресурсі облікового запису сервісу. Слід зазначити, що роль редактора за замовчуванням має цей дозвіл.
Створення нового KEY_ALG_RSA_2048 приватного ключа для кожного ресурсу облікового запису сервісу, який знайдено з відповідним дозволом у політиці IAM.
Ітерація по кожному новому обліковому запису сервісу та створення об'єкта JWT для нього, який складається з облікових даних приватного ключа SA та області OAuth. Процес створення нового об'єкта JWT ітераційно перевіряє всі існуючі комбінації областей OAuth зі списку oauth_scopes.txt, щоб знайти всі можливості делегування. Список oauth_scopes.txt оновлюється всіма областями OAuth, які ми вважаємо релевантними для зловживання ідентичностями Workspace.
Метод _make_authorization_grant_assertion вказує на необхідність оголосити цільового користувача робочого простору, відомого як subject, для генерації JWT під DWD. Хоча це може здаватися, що вимагає конкретного користувача, важливо усвідомити, що DWD впливає на кожну ідентичність у домені. Відповідно, створення JWT для будь-якого користувача домену впливає на всі ідентичності в цьому домені, відповідно до нашої перевірки комбінацій. Простими словами, одного дійсного користувача Workspace достатньо для продовження. Цей користувач може бути визначений у файлі config.yaml DeleFriend. Якщо цільовий користувач робочого простору ще не відомий, інструмент полегшує автоматичну ідентифікацію дійсних користувачів робочого простору, скануючи користувачів домену з ролями на GCP проектах. Важливо зазначити (знову), що JWT є специфічними для домену і не генеруються для кожного користувача; отже, автоматичний процес націлений на одну унікальну ідентичність на домен.
Перерахувати та створити новий токен доступу для кожного 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:

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

Створення правила можна знайти на сторінці API controls → Manage Domain-Wide delegation in Google Workspace Admin console.

Прикріплення привілеїв 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

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

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

Крос-організаційна делегація

OAuth SA ID є глобальним і може бути використаний для крос-організаційної делегації. Не було впроваджено жодних обмежень, щоб запобігти крос-глобальній делегації. Простими словами, облікові записи служби з різних організацій 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>

Перевірте більше перерахувань у:

GCP - IAM, Principals & Org Policies Enum

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

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

GCP - Token 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':

Отже, наступного разу, коли користувач увійде в систему, він створить токен з доступом до 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.

Посилання

https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover

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

Підтримати HackTricks

Перевірте плани підписки!
Приєднуйтесь до 💬 групи Discord або групи Telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на GitHub.

PreviousGCP - Workflows Enum NextGCP - Understanding Domain-Wide Delegation

Last updated 7 days ago