mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-12 13:05:19 -08:00
Translated ['src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting
This commit is contained in:
Translator
@@ -6,7 +6,7 @@
|
||||
|
||||
### **Основи делегування на рівні домену**
|
||||
|
||||
Делегування на рівні домену 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** (бажано **супер адміністратора**) компанії, він міг би **перерахувати всі проекти**, до яких має доступ, **перерахувати всі облікові записи Служби** проектів, перевірити, до яких **облікових записів служби має доступ**, і **повторити** всі ці кроки з кожним обліковим записом Служби, за яким він може видавати себе.\
|
||||
З **переліком всіх облікових записів служби**, до яких він має **доступ**, і списком **електронних адрес Workspace**, зловмисник міг би спробувати **видавати себе за користувача з кожним обліковим записом служби**.
|
||||
Якщо зловмисник **компрометував доступ до GCP** і **знає дійсну електронну адресу користувача Workspace** (бажано **суперадміністра**), він може **перерахувати всі проекти**, до яких має доступ, **перерахувати всі облікові записи СА** проектів, перевірити, до яких **облікових записів служби має доступ**, і **повторити** всі ці кроки з кожним СА, за яким він може видавати себе.\
|
||||
З **переліком всіх облікових записів служби**, до яких він має **доступ**, і списком **електронних адрес Workspace**, зловмисник може спробувати **видавати себе за користувача з кожним обліковим записом служби**.
|
||||
|
||||
> [!CAUTION]
|
||||
> Зверніть увагу, що при налаштуванні делегування на рівні домену жоден користувач Workspace не потрібен, тому просто знати **одного дійсного достатньо і необхідно для видавання себе**.\
|
||||
> Однак, **привілеї виданого користувача будуть використані**, тому якщо це Супер Адміністратор, ви зможете отримати доступ до всього. Якщо у нього немає доступу, це буде марно.
|
||||
> Однак, **привілеї виданого користувача будуть використані**, тому якщо це суперадміністратор, ви зможете отримати доступ до всього. Якщо у нього немає доступу, це буде марно.
|
||||
|
||||
#### [GCP Generate Delegation Token](https://github.com/carlospolop/gcp_gen_delegation_token)
|
||||
|
||||
@@ -36,22 +36,26 @@ python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-ke
|
||||
# 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**](https://github.com/n0tspam/delepwn)
|
||||
|
||||
На основі наступного інструменту DeleFriend, але з деякими доповненнями, такими як можливість перераховувати домен, диск, gmail, календар та виконувати інші операції.
|
||||
|
||||
#### [**DeleFriend**](https://github.com/axon-git/DeleFriend)
|
||||
|
||||
Це інструмент, який може виконати атаку, слідуючи цим крокам:
|
||||
|
||||
1. **Перерахувати GCP проекти** за допомогою Resource Manager API.
|
||||
1. **Перерахувати GCP проекти** за допомогою API Resource Manager.
|
||||
2. Ітерація по кожному ресурсу проекту та **перерахування ресурсів облікових записів сервісу GCP**, до яких має доступ початковий IAM користувач, використовуючи _GetIAMPolicy_.
|
||||
3. Ітерація по **кожній ролі облікового запису сервісу** та знаходження вбудованих, базових і кастомних ролей з дозволом _**serviceAccountKeys.create**_ на цільовому ресурсі облікового запису сервісу. Слід зазначити, що роль Editor за замовчуванням має цей дозвіл.
|
||||
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 та перевірити токен за допомогою tokeninfo API.
|
||||
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](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/gcp_misc/-/blob/master/gcp_delegation.py)
|
||||
|
||||
Gitlab створив [цей Python скрипт](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp_misc/blob/master/gcp_delegation.py), який може виконати дві речі - перерахувати каталог користувачів і створити новий адміністративний обліковий запис, вказуючи json з обліковими даними SA та користувачем, якого потрібно наслідувати. Ось як ви можете його використовувати:
|
||||
Gitlab створив [цей Python скрипт](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp_misc/blob/master/gcp_delegation.py), який може виконати дві речі - перерахувати каталог користувачів та створити новий адміністративний обліковий запис, вказуючи json з обліковими даними SA та користувачем, якого потрібно наслідувати. Ось як ви можете його використовувати:
|
||||
```bash
|
||||
# Install requirements
|
||||
pip install --upgrade --user oauth2client
|
||||
@@ -80,9 +84,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 додатків.
|
||||
- Перевірте **попередній розділ** для деяких **інструментів** для використання цієї делегації.
|
||||
@@ -93,7 +97,7 @@ OAuth SA ID є глобальним і може бути використани
|
||||
|
||||
### Створення проекту для перерахунку Workspace
|
||||
|
||||
За **замовчуванням** користувачі Workspace **мають дозвіл на створення нових проектів**, і коли новий проект створюється, **творець отримує роль Власника**.
|
||||
За **замовчуванням** користувачі Workspace мають дозвіл **створювати нові проекти**, і коли новий проект створюється, **творець отримує роль Власника** над ним.
|
||||
|
||||
Отже, користувач може **створити проект**, **увімкнути** **API** для перерахунку Workspace у своєму новому проекті та спробувати **перерахувати** його.
|
||||
|
||||
@@ -124,14 +128,14 @@ gcloud beta identity groups preview --customer <org-cust-id>
|
||||
|
||||
### Зловживання обліковими даними Gcloud
|
||||
|
||||
Ви можете знайти додаткову інформацію про процес входу в `gcloud` у:
|
||||
Ви можете знайти додаткову інформацію про потік `gcloud` для входу в:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-persistence/gcp-non-svc-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
Як пояснено там, gcloud може запитувати область **`https://www.googleapis.com/auth/drive`**, що дозволить користувачу отримати доступ до диска користувача.\
|
||||
Як атакуючий, якщо ви фізично скомпрометували комп'ютер користувача і **користувач все ще увійшов** зі своїм обліковим записом, ви могли б увійти, згенерувавши токен з доступом до диска, використовуючи:
|
||||
Як зловмисник, якщо ви фізично скомпрометували комп'ютер користувача і **користувач все ще увійшов** зі своїм обліковим записом, ви могли б увійти, згенерувавши токен з доступом до диска, використовуючи:
|
||||
```bash
|
||||
gcloud auth login --enable-gdrive-access
|
||||
```
|
||||
@@ -152,7 +156,7 @@ gcloud auth login --enable-gdrive-access
|
||||
|
||||
### Підвищення привілеїв 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