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.
На наступній сторінці ви можете перевірити, як зловживати дозволами організаційних політик для ескалації привілеїв:
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
