GCP - IAM, Principals & Org Policies Enum
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Для вступу про те, що таке обліковий запис служби, перегляньте:
Обліковий запис служби завжди належить проекту:
Для вступу про те, як працюють Користувачі та Групи в GCP, перегляньте:
З правами serviceusage.services.enable
та serviceusage.services.use
можливо увімкнути сервіси в проекті та використовувати їх.
Зверніть увагу, що за замовчуванням користувачам Workspace надається роль Створювач проекту, що дає їм доступ до створення нових проектів. Коли користувач створює проект, йому надається роль owner
над ним. Отже, він може увімкнути ці сервіси в проекті, щоб мати можливість перерахувати Workspace.
Однак зверніть увагу, що також потрібно мати достатньо прав у Workspace, щоб мати можливість викликати ці API.
Якщо ви можете увімкнути сервіс admin
і якщо ваш користувач має достатні привілеї в workspace, ви можете перерахувати всі групи та користувачів за допомогою наступних рядків.
Навіть якщо вказано identity groups
, це також повертає користувачів без жодних груп:
У попередніх прикладах параметр --labels
є обов'язковим, тому використовується загальне значення (це не потрібно, якщо ви використовуєте API безпосередньо, як PurplePanda робить тут.
Навіть з увімкненою службою адміністратора, можливо, ви отримаєте помилку при їх перерахунку, оскільки ваш скомпрометований користувач робочого простору не має достатніх прав:
Перевірте це для основної інформації про IAM.
З документації: Коли створюється ресурс організації, всі користувачі у вашому домені автоматично отримують ролі Створювач облікового запису для виставлення рахунків та Створювач проекту. Ці ролі за замовчуванням дозволяють вашим користувачам почати використовувати Google Cloud негайно, але не призначені для використання в регулярній роботі вашого ресурсу організації.
Ці ролі надають дозволи:
billing.accounts.create
та resourcemanager.organizations.get
resourcemanager.organizations.get
та resourcemanager.projects.create
Більше того, коли користувач створює проект, він автоматично отримує права власника цього проекту відповідно до документації. Тому за замовчуванням користувач зможе створити проект і запустити будь-яку службу на ньому (майнери? Перерахунок робочого простору? ...)
Найвищий привілей в організації GCP - це роль Адміністратор організації.
У більшості служб ви зможете змінити дозволи над ресурсом, використовуючи метод add-iam-policy-binding
або set-iam-policy
. Головна різниця полягає в тому, що add-iam-policy-binding
додає нове зв'язування ролі до існуючої політики IAM, тоді як set-iam-policy
видалить раніше надані дозволи та встановить лише ті, що вказані в команді.
Існують різні способи перевірити всі дозволи користувача в різних ресурсах (таких як організації, папки, проекти...) за допомогою цього сервісу.
Дозвіл cloudasset.assets.searchAllIamPolicies
може запитувати всі політики iam всередині ресурсу.
Дозвіл cloudasset.assets.analyzeIamPolicy
може запитувати всі політики iam суб'єкта всередині ресурсу.
Дозвіл cloudasset.assets.searchAllResources
дозволяє перераховувати всі ресурси організації, папки або проєкту. Ресурси, пов'язані з IAM (такі як ролі), включені.
Дозвіл cloudasset.assets.analyzeMove
може бути корисним для отримання політик, що впливають на ресурс, такий як проект.
Я припускаю, що дозвіл cloudasset.assets.queryIamPolicy
також може надати доступ для знаходження дозволів принципів
Якщо ви не можете отримати доступ до інформації IAM за допомогою попередніх методів і ви в Red Team. Ви можете використати інструмент https://github.com/carlospolop/bf_my_gcp_perms для брутфорсу ваших поточних дозволів.
Однак зверніть увагу, що сервіс cloudresourcemanager.googleapis.com
повинен бути увімкнений.
На наступній сторінці ви можете перевірити, як зловживати дозволами IAM для ескалації привілеїв:
Якщо у вас високі привілеї, ви можете:
Створити нові SAs (або користувачів, якщо в Workspace)
Надати принципалам, контрольованим вами, більше дозволів
Надати більше привілеїв вразливим SAs (SSRF у vm, вразлива Cloud Function…)
…
Для вступу про те, що таке Org Policies, перегляньте:
Політики IAM вказують на дозволи, які мають принципали над ресурсами через ролі, які мають призначені детальні дозволи. Політики організації обмежують, як ці сервіси можуть використовуватися або які функції вимкнені. Це допомагає покращити принцип найменших привілеїв для кожного ресурсу в середовищі GCP.
In the following page you can check how to зловживати дозволами політик організації для ескалації привілеїв:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)