GCP - Basic Information

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Підтримати HackTricks

• Перевірте плани підписки!

• Приєднуйтесь до 💬 групи Discord або групи Telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.

• Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.

Ієрархія ресурсів

Google Cloud використовує Ієрархію ресурсів, яка концептуально схожа на традиційну файлову систему. Це забезпечує логічний робочий процес батьків/дочок з конкретними точками прив'язки для політик і дозволів.

На високому рівні це виглядає так:

Organization
--> Folders
--> Projects
--> Resources

Віртуальна машина (називається Compute Instance) є ресурсом. Ресурс знаходиться в проекті, ймовірно, поряд з іншими Compute Instances, сховищами, тощо.

https://cloud.google.com/static/resource-manager/img/cloud-hierarchy.svg

Міграція проектів

Можливо мігрувати проект без організації в організацію з правами roles/resourcemanager.projectCreator та roles/resourcemanager.projectMover. Якщо проект знаходиться в іншій організації, потрібно зв'язатися з підтримкою GCP, щоб спочатку перемістити їх з організації. Для отримання додаткової інформації перегляньте це.

Політики організації

Дозволяють централізувати контроль над ресурсами хмари вашої організації:

• Централізувати контроль для налаштування обмежень на те, як можуть використовуватися ресурси вашої організації.

• Визначити та встановити обмеження для ваших команд розробників, щоб залишатися в межах відповідності.

• Допомогти власникам проектів та їх командам швидко рухатися без побоювань про порушення відповідності.

Ці політики можуть бути створені для впливу на всю організацію, папки або проекти. Наслідники цільового вузла ієрархії ресурсів успадковують політику організації.

Щоб визначити політику організації, ви вибираєте обмеження, яке є певним типом обмеження щодо або служби Google Cloud, або групи служб Google Cloud. Ви налаштовуєте це обмеження з вашими бажаними обмеженнями.

https://cloud.google.com/resource-manager/img/org-policy-concepts.svg

Загальні випадки використання

• Обмежити обмін ресурсами на основі домену.

• Обмежити використання облікових записів служби управління ідентифікацією та доступом.

• Обмежити фізичне розташування новостворених ресурсів.

• Вимкнути створення облікових записів служби.

Існує багато інших обмежень, які надають вам детальний контроль над ресурсами вашої організації. Для додаткової інформації дивіться список усіх обмежень служби політики організації.

Політики організації за замовчуванням

Це політики, які Google додасть за замовчуванням при налаштуванні вашої організації GCP:

Політики управління доступом

• Обмежені контакти домену: Запобігає додаванню користувачів до Основних контактів за межами ваших вказаних доменів. Це обмежує Основні контакти лише для управлінь користувачів у ваших вибраних доменах для отримання сповіщень платформи.

• Обмежене спільне використання домену: Запобігає додаванню користувачів до політик IAM за межами ваших вказаних доменів. Це обмежує політики IAM лише для управлінь користувачів у ваших вибраних доменах для доступу до ресурсів у цій організації.

• Запобігання публічному доступу: Запобігає експонуванню сховищ Cloud Storage для публіки. Це забезпечує, що розробник не може налаштувати сховища Cloud Storage для неавтентифікованого доступу в Інтернеті.

• Уніфікований доступ на рівні сховища: Запобігає спискам контролю доступу на рівні об'єктів (ACL) у сховищах Cloud Storage. Це спрощує управління доступом, застосовуючи політики IAM послідовно до всіх об'єктів у сховищах Cloud Storage.

• Вимагати вхід в ОС: Віртуальні машини, створені в нових проектах, матимуть увімкнений вхід в ОС. Це дозволяє вам керувати доступом SSH до ваших екземплярів, використовуючи IAM, без необхідності створювати та керувати окремими ключами SSH.

Додаткові політики безпеки для облікових записів служби

• Вимкнути автоматичні надання IAM: Запобігає автоматичному наданню ролі редактора IAM для облікових записів служби App Engine та Compute Engine під час створення проекту. Це забезпечує, що облікові записи служби не отримують надто широкі ролі IAM під час створення.

• Вимкнути створення ключів облікових записів служби: Запобігає створенню публічних ключів облікових записів служби. Це допомагає зменшити ризик експонування постійних облікових даних.

• Вимкнути завантаження ключів облікових записів служби: Запобігає завантаженню публічних ключів облікових записів служби. Це допомагає зменшити ризик витоку або повторного використання матеріалів ключів.

Політики конфігурації безпечних мереж VPC

• Визначити дозволені зовнішні IP-адреси для екземплярів ВМ: Запобігає створенню екземплярів Compute з публічною IP-адресою, що може піддати їх інтернет-трафіку.

• Вимкнути вкладену віртуалізацію ВМ: Запобігає створенню вкладених ВМ на ВМ Compute Engine. Це зменшує ризик безпеки від наявності непідконтрольних вкладених ВМ.

• Вимкнути серійний порт ВМ: Запобігає доступу до серійного порту ВМ Compute Engine. Це запобігає введенню даних у серійний порт сервера за допомогою API Compute Engine.

• Обмежити авторизовані мережі на екземплярах Cloud SQL: Запобігає доступу публічних або не внутрішніх мереж до ваших баз даних Cloud SQL.

• Обмежити пересилання протоколів на основі типу IP-адреси: Запобігає пересиланню протоколів ВМ для зовнішніх IP-адрес.

• Обмежити доступ до публічних IP на екземплярах Cloud SQL: Запобігає створенню екземплярів Cloud SQL з публічною IP-адресою, що може піддати їх інтернет-трафіку.

• Обмежити видалення ліній проекту спільного VPC: Запобігає випадковому видаленню проектів-хостів Shared VPC.

• Встановлює налаштування внутрішнього DNS для нових проектів на лише зональний DNS: Запобігає використанню застарілого налаштування DNS, яке зменшило доступність служби.

• Пропустити створення мережі за замовчуванням: Запобігає автоматичному створенню мережі VPC за замовчуванням та супутніх ресурсів. Це уникає надто широких правил брандмауера за замовчуванням.

• Вимкнути використання зовнішнього IPv6 VPC: Запобігає створенню зовнішніх підмереж IPv6, які можуть бути піддані несанкціонованому доступу в Інтернет.

Ролі IAM

Це схоже на політики IAM в AWS, оскільки кожна роль містить набір дозволів.

Однак, на відміну від AWS, немає централізованого репозиторію ролей. Замість цього, ресурси надають X ролей доступу Y принципалам, і єдиний спосіб дізнатися, хто має доступ до ресурсу, - це використовувати метод get-iam-policy для цього ресурсу. Це може бути проблемою, оскільки це означає, що єдиний спосіб дізнатися, які дозволи має принципал, - це запитати кожен ресурс, кому він надає дозволи, і користувач може не мати дозволів, щоб отримати дозволи з усіх ресурсів.

Існує три типи ролей в IAM:

• Основні/примітивні ролі, які включають ролі Власника, Редактора та Переглядача, що існували до впровадження IAM.

• Попередньо визначені ролі, які надають детальний доступ до конкретної служби та керуються Google Cloud. Існує багато попередньо визначених ролей, ви можете переглянути всі з них з привілеями, які вони мають тут.

• Користувацькі ролі, які надають детальний доступ відповідно до списку дозволів, вказаного користувачем.

В GCP є тисячі дозволів. Щоб перевірити, чи має роль дозволи, ви можете шукати дозвіл тут і подивитися, які ролі його мають.

Ви також можете шукати тут попередньо визначені ролі пропоновані кожним продуктом. Зверніть увагу, що деякі ролі не можуть бути прикріплені до користувачів і тільки до СА через деякі дозволи, які вони містять. Крім того, зверніть увагу, що дозволи набудуть чинності лише якщо вони прикріплені до відповідної служби.

Або перевірте, чи може користувацька роль використовувати конкретний дозвіл тут.

GCP - IAM, Principals & Org Policies Enum

Користувачі

У консолі GCP немає управління Користувачами або Групами, це робиться в Google Workspace. Хоча ви можете синхронізувати інший постачальник ідентичності в Google Workspace.

Ви можете отримати доступ до користувачів і груп Workspace за адресою https://admin.google.com.

MFA може бути вимушена для користувачів Workspace, однак зловмисник може використовувати токен для доступу до GCP через cli, який не буде захищений MFA (він буде захищений MFA лише тоді, коли користувач входить для його генерації: gcloud auth login).

Групи

Коли створюється організація, кілька груп рекомендується створити. Якщо ви керуєте будь-якою з них, ви можете скомпрометувати всю або важливу частину організації:

Група	Функція
gcp-organization-admins (група або індивідуальні облікові записи потрібні для контрольного списку)	Адміністрування будь-якого ресурсу, що належить організації. Призначайте цю роль обережно; адміністратори організації мають доступ до всіх ваших ресурсів Google Cloud. Альтернативно, оскільки ця функція має високі привілеї, розгляньте можливість використання індивідуальних облікових записів замість створення групи.
gcp-network-admins (потрібно для контрольного списку)	Створення мереж, підмереж, правил брандмауера та мережевих пристроїв, таких як Cloud Router, Cloud VPN та балансувальники навантаження в хмарі.
gcp-billing-admins (потрібно для контрольного списку)	Налаштування облікових записів для виставлення рахунків та моніторинг їх використання.
gcp-developers (потрібно для контрольного списку)	Проектування, кодування та тестування додатків.
gcp-security-admins	Встановлення та управління політиками безпеки для всієї організації, включаючи управління доступом та політики обмежень організації. Дивіться посібник з основ безпеки Google Cloud для отримання додаткової інформації про планування вашої інфраструктури безпеки Google Cloud.
gcp-devops	Створення або управління кінцевими конвеєрами, які підтримують безперервну інтеграцію та доставку, моніторинг та постачання систем.
gcp-logging-admins
gcp-logging-viewers
gcp-monitor-admins
gcp-billing-viewer (більше не за замовчуванням)	Моніторинг витрат на проекти. Типові учасники є частиною фінансової команди.
gcp-platform-viewer (більше не за замовчуванням)	Перегляд інформації про ресурси в організації Google Cloud.
gcp-security-reviewer (більше не за замовчуванням)	Перегляд безпеки хмари.
gcp-network-viewer (більше не за замовчуванням)	Перегляд конфігурацій мережі.
grp-gcp-audit-viewer (більше не за замовчуванням)	Перегляд журналів аудиту.
gcp-scc-admin (більше не за замовчуванням)	Адміністрування Центру команд безпеки.
gcp-secrets-admin (більше не за замовчуванням)	Управління секретами в Secret Manager.

Політика паролів за замовчуванням

• Вимагати сильні паролі

• Від 8 до 100 символів

• Без повторного використання

• Без терміну дії

• Якщо люди отримують доступ до Workspace через стороннього постачальника, ці вимоги не застосовуються.

Облікові записи служби

Це принципали, які ресурси можуть мати прикріпленими та отримувати доступ для легкого взаємодії з GCP. Наприклад, можливо отримати доступ до токена автентифікації облікового запису служби прикріпленого до ВМ в метаданих. Можливо зіткнутися з деякими конфліктами при використанні як IAM, так і обсягів доступу. Наприклад, ваш обліковий запис служби може мати роль IAM compute.instanceAdmin, але екземпляр, до якого ви отримали доступ, має обмеження обсягу https://www.googleapis.com/auth/compute.readonly. Це завадить вам вносити будь-які зміни, використовуючи токен OAuth, який автоматично призначається вашому екземпляру.

Це схоже на ролі IAM з AWS. Але не так, як в AWS, будь-який обліковий запис служби може бути прикріплений до будь-якої служби (не потрібно дозволяти це через політику).

Декілька облікових записів служби, які ви знайдете, насправді автоматично генеруються GCP при початку використання служби, як:

[e-mail]
[e-mail]

Однак також можливо створювати та приєднуватися до ресурсів кастомних облікових записів служби, які виглядатимуть так:

SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com

Ключі та Токени

Існує 2 основні способи доступу до GCP як до облікового запису служби:

• Через OAuth токени: Це токени, які ви отримаєте з таких місць, як кінцеві точки метаданих або шляхом викрадення http запитів, і вони обмежені обсягами доступу.

• Ключі: Це пари публічних і приватних ключів, які дозволять вам підписувати запити як обліковий запис служби і навіть генерувати OAuth токени для виконання дій як обліковий запис служби. Ці ключі небезпечні, оскільки їх складніше обмежити і контролювати, тому GCP рекомендує не генерувати їх.

• Зверніть увагу, що кожного разу, коли створюється SA, GCP генерує ключ для облікового запису служби, до якого користувач не має доступу (і який не буде вказано в веб-додатку). Згідно з цією темою, цей ключ використовується внутрішньо GCP для надання доступу кінцевим точкам метаданих для генерації доступних OAuth токенів.

Обсяги доступу

Обсяги доступу прикріплені до згенерованих OAuth токенів для доступу до кінцевих точок API GCP. Вони обмежують дозволи OAuth токена. Це означає, що якщо токен належить Власнику ресурсу, але не має в обсязі токена доступу до цього ресурсу, токен не може бути використаний для (зловживання) цих привілеїв.

Google насправді рекомендує, щоб обсяги доступу не використовувалися і щоб повністю покладатися на IAM. Веб-портал управління насправді це забезпечує, але обсяги доступу все ще можуть бути застосовані до екземплярів за допомогою програмних облікових записів служби.

Ви можете побачити, які обсяги призначені, запитуючи:

curl 'https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=<access_token>'

{
"issued_to": "223044615559.apps.googleusercontent.com",
"audience": "223044615559.apps.googleusercontent.com",
"user_id": "139746512919298469201",
"scope": "openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/appengine.admin https://www.googleapis.com/auth/sqlservice.login https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/accounts.reauth",
"expires_in": 2253,
"email": "[e-mail]",
"verified_email": true,
"access_type": "offline"
}

Попередні scopes - це ті, що генеруються за замовчуванням за допомогою gcloud для доступу до даних. Це тому, що коли ви використовуєте gcloud, спочатку ви створюєте OAuth токен, а потім використовуєте його для зв'язку з кінцевими точками.

Найважливіший scope з цих потенційно є cloud-platform, що в основному означає, що можливо отримати доступ до будь-якої служби в GCP.

Ви можете знайти список усіх можливих scopes тут.

Якщо у вас є gcloud облікові дані браузера, можливо отримати токен з іншими scopes, зробивши щось на кшталт:

# Maybe you can get a user token with other scopes changing the scopes array from ~/.config/gcloud/credentials.db

# Set new scopes for SDKs credentials
gcloud auth application-default login --scopes=https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/sqlservice.login,https://www.googleapis.com/auth/appengine.admin,https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/accounts.reauth,https://www.googleapis.com/auth/admin.directory.user,https://www.googleapis.com/auth/admin.directory.group,https://www.googleapis.com/auth/admin.directory.domain,https://www.googleapis.com/auth/admin.directory.user

# Print new token
gcloud auth application-default print-access-token

# To use this token with some API you might need to use curl to indicate the project header with --header "X-Goog-User-Project: <project-name>"

Terraform IAM Політики, Прив'язки та Членства

Як визначено terraform в https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam, використовуючи terraform з GCP, існують різні способи надання доступу принципалу до ресурсу:

• Членства: Ви встановлюєте принципалів як членів ролей без обмежень щодо ролі або принципалів. Ви можете призначити користувача членом ролі, а потім призначити групу членом тієї ж ролі, а також встановити цих принципалів (користувача та групу) членами інших ролей.

• Прив'язки: Кілька принципалів можуть бути прив'язані до ролі. Ці принципали все ще можуть бути прив'язані або бути членами інших ролей. Однак, якщо принципал, який не прив'язаний до ролі, встановлений як член прив'язаної ролі, наступного разу, коли прив'язка буде застосована, членство зникне.

• Політики: Політика є авторитетною, вона вказує ролі та принципали, і тоді ці принципали не можуть мати більше ролей, а ці ролі не можуть мати більше принципалів, якщо ця політика не буде змінена (навіть в інших політиках, прив'язках або членствах). Тому, коли роль або принципал вказані в політиці, всі їхні привілеї є обмеженими цією політикою. Очевидно, це можна обійти, якщо принципалу надано можливість змінювати політику або права на ескалацію привілеїв (наприклад, створити нового принципала та прив'язати його до нової ролі).

Посилання

• https://about.gitlab.com/blog/2020/02/12/plundering-gcp-escalating-privileges-in-google-cloud-platform/

• https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.