Ukranian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP - IAM Privesc

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

Підтримайте 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-скрипт для зловживання цим привілеєм тут. Для отримання додаткової інформації перегляньте оригінальне дослідження.

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

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

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

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

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

iam.serviceAccounts.implicitDelegation

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

Зверніть увагу, що згідно з документацією, делегування 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"]
}'

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

iam.serviceAccounts.signBlob

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

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

iam.serviceAccounts.signJwt

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

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

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"

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

iam.serviceAccounts.actAs

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

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

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

  • Аутентифікація використовуючи приватні ключі RSA (розглянуто вище)

  • Авторизація використовуючи Cloud IAM policies (розглянуто тут)

  • Розгортання завдань на GCP services (більш застосовно до компрометації облікового запису користувача)

iam.serviceAccounts.getOpenIdToken

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

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

Посилання

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

Підтримайте HackTricks
PreviousGCP - Deploymentmaneger PrivescNextGCP - KMS Privesc

Last updated