GCP - IAM Privesc

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure 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>

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

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)

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

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

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

iam.serviceAccountKeys.create

Атакуючий з наведеними правами зможе створити ключ, керований користувачем, для 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 won’t work to modify the key облікового запису сервісу (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"]
}'

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.serviceAccounts.signBlob

Атакуючий з наведеними дозволами зможе підписувати довільні payloads у GCP. Тому стане можливим створити unsigned JWT сервісного акаунта і потім відправити його як blob, щоб JWT було підписано цільовим SA. Для детальнішої інформації read this.

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 and here. For more information check the original research.

iam.serviceAccounts.signJwt

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

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.serviceAccounts.setIamPolicy

Атакуючий з наведеними дозволами зможе додавати IAM політики до service accounts. Це можна використати, щоб надати собі необхідні дозволи для імперсонування service account. У наступному прикладі ми надаємо собі роль 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

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

Service account impersonation

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

  • Authentication using RSA private keys (covered above)
  • Authorization using Cloud IAM policies (covered here)
  • Deploying jobs on GCP services (more applicable to the compromise of a user account)

iam.serviceAccounts.getOpenIdToken

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

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

You can generate an OpenIDToken (if you have the access) with:

# 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 token від імені service account можна знайти тут.

Джерела

Tip

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

Підтримка HackTricks