GCP - IAM Privesc

Reading time: 8 minutes

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)

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

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

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

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

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

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

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

iam.serviceAccountKeys.create

Зловмисник з вказаними правами зможе створити ключ, керований користувачем, для облікового запису служби, що дозволить нам отримати доступ до GCP як цей обліковий запис служби.

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

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

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

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

iam.serviceAccounts.implicitDelegation

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

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

bash
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"]
}'

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

iam.serviceAccounts.signBlob

Зловмисник з вказаними дозволами зможе підписувати довільні дані в GCP. Отже, буде можливим створити непідписаний JWT сервісного облікового запису, а потім надіслати його як блоб, щоб отримати підписаний JWT від сервісного облікового запису, на який ми націлюємося. Для отримання додаткової інформації читайте це.

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

iam.serviceAccounts.signJwt

Зловмисник з вказаними дозволами зможе підписувати коректно сформовані JSON веб-токени (JWT). Різниця з попереднім методом полягає в тому, що замість того, щоб змусити Google підписати блоб, що містить JWT, ми використовуємо метод signJWT, який вже очікує JWT. Це робить його простішим у використанні, але ви можете підписувати лише JWT, а не будь-які байти.

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

iam.serviceAccounts.setIamPolicy

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

bash
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"

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

iam.serviceAccounts.actAs

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

Імітація облікового запису служби

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

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

iam.serviceAccounts.getOpenIdToken

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

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

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

bash
# 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

Тоді ви можете просто використовувати це для доступу до сервісу за допомогою:

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

Підтримка HackTricks