mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-12 04:55:32 -08:00
Translated ['src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting
This commit is contained in:
Translator
@@ -2,11 +2,11 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## **Від GCP до GWS**
|
||||
## **З GCP до GWS**
|
||||
|
||||
### **Основи делегування на рівні домену**
|
||||
|
||||
Делегування на рівні домену Google Workspace дозволяє об'єкту ідентифікації, або **зовнішньому додатку** з Google Workspace Marketplace, або внутрішньому **обліковому запису служби GCP**, **отримувати доступ до даних у Workspace від імені користувачів**.
|
||||
Делегування на рівні домену Google Workspace дозволяє об'єкту ідентичності, або **зовнішньому додатку** з Google Workspace Marketplace, або внутрішньому **обліковому запису служби GCP**, **отримувати доступ до даних у Workspace від імені користувачів**.
|
||||
|
||||
> [!NOTE]
|
||||
> Це в основному означає, що **облікові записи служби** всередині проектів GCP організації можуть мати можливість **видавати себе за користувачів Workspace** тієї ж організації (або навіть з іншої).
|
||||
@@ -19,12 +19,12 @@ gcp-understanding-domain-wide-delegation.md
|
||||
|
||||
### Компрометація існуючого делегування
|
||||
|
||||
Якщо зловмисник **компрометував доступ до GCP** і **знає дійсну електронну адресу користувача Workspace** (бажано **суперадміністратора**) компанії, він міг би **перерахувати всі проекти**, до яких має доступ, **перерахувати всі облікові записи служби** проектів, перевірити, до яких **облікових записів служби має доступ**, і **повторити** всі ці кроки з кожним обліковим записом служби, за яким він може видавати себе.\
|
||||
Якщо зловмисник **компрометував доступ до GCP** і **знає дійсну електронну адресу користувача Workspace** (бажано **супер адміністратора**) компанії, він міг би **перерахувати всі проекти**, до яких має доступ, **перерахувати всі облікові записи Служби** проектів, перевірити, до яких **облікових записів служби має доступ**, і **повторити** всі ці кроки з кожним обліковим записом Служби, за яким він може видавати себе.\
|
||||
З **переліком всіх облікових записів служби**, до яких він має **доступ**, і списком **електронних адрес Workspace**, зловмисник міг би спробувати **видавати себе за користувача з кожним обліковим записом служби**.
|
||||
|
||||
> [!CAUTION]
|
||||
> Зверніть увагу, що при налаштуванні делегування на рівні домену жоден користувач Workspace не потрібен, тому просто знати **одного дійсного достатньо і необхідно для видавання себе**.\
|
||||
> Однак, **привілеї виданого користувача будуть використані**, тому якщо це суперадміністратор, ви зможете отримати доступ до всього. Якщо у нього немає доступу, це буде марно.
|
||||
> Однак, **привілеї виданого користувача будуть використані**, тому якщо це Супер Адміністратор, ви зможете отримати доступ до всього. Якщо у нього немає доступу, це буде марно.
|
||||
|
||||
#### [GCP Generate Delegation Token](https://github.com/carlospolop/gcp_gen_delegation_token)
|
||||
|
||||
@@ -42,10 +42,10 @@ python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-ke
|
||||
|
||||
1. **Перерахувати GCP проекти** за допомогою Resource Manager API.
|
||||
2. Ітерація по кожному ресурсу проекту та **перерахування ресурсів облікових записів сервісу GCP**, до яких має доступ початковий IAM користувач, використовуючи _GetIAMPolicy_.
|
||||
3. Ітерація по **кожній ролі облікового запису сервісу** та знаходження вбудованих, базових і кастомних ролей з дозволом _**serviceAccountKeys.create**_ на цільовому ресурсі облікового запису сервісу. Слід зазначити, що роль редактора за замовчуванням має цей дозвіл.
|
||||
3. Ітерація по **кожній ролі облікового запису сервісу** та знаходження вбудованих, базових і кастомних ролей з дозволом _**serviceAccountKeys.create**_ на цільовому ресурсі облікового запису сервісу. Слід зазначити, що роль Editor за замовчуванням має цей дозвіл.
|
||||
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 достатньо для продовження.\
|
||||
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 та перевірити токен за допомогою tokeninfo API.
|
||||
|
||||
@@ -80,9 +80,9 @@ pip install --upgrade --user oauth2client
|
||||
Зловмисник, який має можливість **створювати облікові записи служб у проекті GCP** та **привілеї супер адміністратора в GWS, може створити нову делегацію, що дозволяє СА наслідувати деяких користувачів GWS:**
|
||||
|
||||
1. **Генерація нового облікового запису служби та відповідної пари ключів:** У GCP нові ресурси облікових записів служб можуть бути створені або інтерактивно через консоль, або програмно за допомогою прямих API викликів та CLI інструментів. Це вимагає **ролі `iam.serviceAccountAdmin`** або будь-якої кастомної ролі, оснащеної **дозволом `iam.serviceAccounts.create`**. Після створення облікового запису служби ми перейдемо до генерації **пов'язаної пари ключів** (**дозвіл `iam.serviceAccountKeys.create`**).
|
||||
2. **Створення нової делегації**: Важливо розуміти, що **тільки роль супер адміністратора має можливість налаштувати глобальну делегацію на рівні домену в Google Workspace** і делегацію на рівні домену **не можна налаштувати програмно,** її можна створити та налаштувати **вручну** через консоль Google Workspace.
|
||||
2. **Створення нової делегації:** Важливо розуміти, що **тільки роль супер адміністратора має можливість налаштувати глобальну делегацію на рівні домену в Google Workspace** і делегацію на рівні домену **не можна налаштувати програмно,** її можна створити та налаштувати **вручну** через консоль Google Workspace.
|
||||
- Створення правила можна знайти на сторінці **API controls → Manage Domain-Wide delegation in Google Workspace Admin console**.
|
||||
3. **Прикріплення привілеїв OAuth scopes**: При налаштуванні нової делегації Google вимагає лише 2 параметри: ідентифікатор клієнта, який є **OAuth ID ресурсу облікового запису служби GCP**, та **OAuth scopes**, які визначають, які API виклики потрібні для делегації.
|
||||
3. **Прикріплення привілеїв OAuth scopes:** При налаштуванні нової делегації Google вимагає лише 2 параметри: ідентифікатор клієнта, який є **OAuth ID ресурсу облікового запису служби GCP**, та **OAuth scopes**, які визначають, які API виклики потрібні для делегації.
|
||||
- **Повний список OAuth scopes** можна знайти [**тут**](https://developers.google.com/identity/protocols/oauth2/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`
|
||||
4. **Дії від імені цільової особи:** На цьому етапі у нас є функціонуючий делегований об'єкт у GWS. Тепер, **використовуючи приватний ключ облікового запису служби GCP, ми можемо виконувати API виклики** (в межах, визначених у параметрі OAuth scope), щоб активувати його та **діяти від імені будь-якої особи, яка існує в Google Workspace**. Як ми дізналися, обліковий запис служби генеруватиме токени доступу відповідно до своїх потреб і згідно з дозволами, які він має для REST API додатків.
|
||||
- Перевірте **попередній розділ** для деяких **інструментів** для використання цієї делегації.
|
||||
@@ -124,14 +124,14 @@ gcloud beta identity groups preview --customer <org-cust-id>
|
||||
|
||||
### Зловживання обліковими даними Gcloud
|
||||
|
||||
Ви можете знайти додаткову інформацію про потік `gcloud` для входу в:
|
||||
Ви можете знайти додаткову інформацію про процес входу в `gcloud` у:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-persistence/gcp-non-svc-persistance.md
|
||||
../gcp-persistence/gcp-non-svc-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
Як пояснено там, gcloud може запитувати область **`https://www.googleapis.com/auth/drive`**, що дозволить користувачу отримати доступ до диска користувача.\
|
||||
Якщо ви атакуючий і фізично скомпрометували комп'ютер користувача, а **користувач все ще увійшов** зі своїм обліковим записом, ви можете увійти, згенерувавши токен з доступом до диска, використовуючи:
|
||||
Як атакуючий, якщо ви фізично скомпрометували комп'ютер користувача і **користувач все ще увійшов** зі своїм обліковим записом, ви могли б увійти, згенерувавши токен з доступом до диска, використовуючи:
|
||||
```bash
|
||||
gcloud auth login --enable-gdrive-access
|
||||
```
|
||||
@@ -148,11 +148,11 @@ gcloud auth login --enable-gdrive-access
|
||||
|
||||
### Доступ до привілейованих користувачів GCP
|
||||
|
||||
Якщо зловмисник має повний доступ до GWS, він зможе отримати доступ до груп з привілейованим доступом до GCP або навіть до користувачів, тому перехід від GWS до GCP зазвичай є більш "простим" лише тому, що **користувачі в GWS мають високі привілеї над GCP**.
|
||||
Якщо зловмисник має повний доступ до GWS, він зможе отримати доступ до груп з привілейованим доступом до GCP або навіть до користувачів, тому перехід від GWS до GCP зазвичай є більш "простим", просто тому що **користувачі в GWS мають високі привілеї над GCP**.
|
||||
|
||||
### Підвищення привілеїв Google Groups
|
||||
|
||||
За замовчуванням користувачі можуть **вільно приєднуватися до груп Workspace Організації** і ці групи **можуть мати призначені дозволи GCP** (перевірте свої групи на [https://groups.google.com/](https://groups.google.com/)).
|
||||
За замовчуванням користувачі можуть **вільно приєднуватися до груп Workspace Організації** і ці групи **можуть мати призначені дозволи GCP** (перевірте свої групи в [https://groups.google.com/](https://groups.google.com/)).
|
||||
|
||||
Зловживаючи **google groups privesc**, ви можете мати можливість підвищити привілеї до групи з якимось видом привілейованого доступу до GCP.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user