Translated ['', 'src/pentesting-cloud/gcp-security/gcp-privilege-escalat

This commit is contained in:
Translator
2025-11-15 11:49:05 +00:00
parent 90b28e8884
commit 10fe8ee551
2 changed files with 39 additions and 9 deletions

View File

@@ -1,4 +1,4 @@
# GCP - Загальні дозволи Privesc
# GCP - Generic Permissions Privesc
{{#include ../../../banners/hacktricks-training.md}}
@@ -6,20 +6,27 @@
### \*.setIamPolicy
Якщо ви володієте користувачем, який має дозвіл **`setIamPolicy`** в ресурсі, ви можете **підвищити привілеї в цьому ресурсі**, оскільки зможете змінити IAM політику цього ресурсу і надати собі більше привілеїв над ним.\
Цей дозвіл також може дозволити **підвищити привілеї до інших принципів**, якщо ресурс дозволяє виконувати код, а iam.ServiceAccounts.actAs не є необхідним.
Якщо у вас є користувач, який має дозвіл **`setIamPolicy`** на ресурсі, ви можете **підвищити привілеї в цьому ресурсі**, оскільки зможете змінити IAM-політику ресурсу та надати собі більше привілеїв щодо нього.\
Цей дозвіл також може дозволити **ескалювати до інших принципалів**, якщо ресурс дозволяє виконувати код і `iam.ServiceAccounts.actAs` не потрібен.
- _cloudfunctions.functions.setIamPolicy_
- Змінити політику Cloud Function, щоб дозволити собі її викликати.
- Змінити політику Cloud Function, щоб дозволити собі викликати її.
Існує десятки типів ресурсів з таким видом дозволу, ви можете знайти всі з них на [https://cloud.google.com/iam/docs/permissions-reference](https://cloud.google.com/iam/docs/permissions-reference), шукаючи setIamPolicy.
Існує десятки типів ресурсів з таким дозволом; ви можете знайти їх усі на [https://cloud.google.com/iam/docs/permissions-reference](https://cloud.google.com/iam/docs/permissions-reference), шукаючи setIamPolicy.
### \*.create, \*.update
Ці дозволи можуть бути дуже корисними для спроби підвищити привілеї в ресурсах, **створюючи новий або оновлюючи новий**. Ці види дозволів особливо корисні, якщо ви також маєте дозвіл **iam.serviceAccounts.actAs** над обліковим записом служби, а ресурс, над яким ви маєте .create/.update, може прикріпити обліковий запис служби.
Ці дозволи можуть бути дуже корисними для спроб підвищення привілеїв у ресурсах шляхом **створення нового ресурсу або оновлення існуючого**. Ці типи дозволів особливо корисні, якщо у вас також є дозвіл **iam.serviceAccounts.actAs** щодо Service Account і ресурс, над яким у вас є .create/.update, може прикріпити Service Account.
### \*ServiceAccount\*
Цей дозвіл зазвичай дозволяє вам **доступ або змінення облікового запису служби в деякому ресурсі** (наприклад: compute.instances.setServiceAccount). Це **може призвести до вектора підвищення привілеїв**, але це залежатиме від кожного випадку.
Цей дозвіл зазвичай дозволяє вам **доступатися або змінювати Service Account у певному ресурсі** (наприклад: compute.instances.setServiceAccount). Це **може призвести до вектора підвищення привілеїв**, але все залежатиме від конкретного випадку.
### iam.ServiceAccounts.actAs
Цей дозвіл дозволяє прикріплювати Service Account до ресурсу, який це підтримує (наприклад: Compute Engine VM, Cloud Function, Cloud Run тощо).\
Якщо ви можете прикріпити Service Account, який має більше привілеїв, ніж ваш користувач, до ресурсу, що може виконувати код, ви зможете підвищити свої привілеї, виконуючи код від імені цього Service Account.
Пошукайте в Cloud Hacktricks `iam.ServiceAccounts.actAs`, щоб знайти кілька прикладів, як ескалювати привілеї з цим дозволом.
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -6,7 +6,7 @@
### `orgpolicy.policy.set`
Зловмисник, що використовує **orgpolicy.policy.set**, може маніпулювати організаційними політиками, що дозволить йому зняти певні обмеження, які заважають конкретним операціям. Наприклад, обмеження **appengine.disableCodeDownload** зазвичай блокує завантаження вихідного коду App Engine. Однак, використовуючи **orgpolicy.policy.set**, зловмисник може деактивувати це обмеження, отримавши доступ до завантаження вихідного коду, незважаючи на те, що спочатку він був захищений.
attacker, який використовує **orgpolicy.policy.set**, може маніпулювати організаційними політиками, що дозволяє йому знімати певні обмеження, які перешкоджають виконанню конкретних операцій. Наприклад, обмеження **appengine.disableCodeDownload** зазвичай блокує завантаження вихідного коду App Engine. Однак, використовуючи **orgpolicy.policy.set**, attacker може деактивувати це обмеження й отримати доступ до завантаження вихідного коду, навіть якщо він спочатку був захищений.
```bash
# Get info
gcloud resource-manager org-policies describe <org-policy> [--folder <id> | --organization <id> | --project <id>]
@@ -14,8 +14,31 @@ gcloud resource-manager org-policies describe <org-policy> [--folder <id> | --or
# Disable
gcloud resource-manager org-policies disable-enforce <org-policy> [--folder <id> | --organization <id> | --project <id>]
```
Скрипт на python для цього методу можна знайти [тут](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/orgpolicy.policy.set.py).
Скрипт на Python для цього методу можна знайти [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/orgpolicy.policy.set.py).
### `orgpolicy.policy.set`, `iam.serviceAccounts.actAs`
Зазвичай неможливо прив'язати service account із іншого проекту до ресурсу, оскільки діє політичне обмеження під назвою **`iam.disableCrossProjectServiceAccountUsage`**, яке запобігає цій дії.
Можна перевірити, чи застосовується це обмеження, виконавши наступну команду:
```bash
gcloud resource-manager org-policies describe \
constraints/iam.disableCrossProjectServiceAccountUsage \
--project=<project-id> \
--effective
booleanPolicy:
enforced: true
constraint: constraints/iam.disableCrossProjectServiceAccountUsage
```
Це перешкоджає зловмисникові зловживати дозволом **`iam.serviceAccounts.actAs`**, щоб видавати себе за service account з іншого проекту без потрібних додаткових інфраструктурних дозволів — наприклад, щоб запустити новий VM — що могло б призвести до підвищення привілеїв.
Однак зловмисник із дозволами **`orgpolicy.policy.set`** може обійти це обмеження, відключивши constraint **`iam.disableServiceAccountProjectWideAccess``. Це дозволяє йому прив'язати service account з іншого проекту до ресурсу в його власному проекті, фактично підвищивши свої привілеї.
```bash
gcloud resource-manager org-policies disable-enforce \
iam.disableCrossProjectServiceAccountUsage \
--project=<project-id>
```
## Посилання
- [https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/](https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/)