GCP - IAM Privesc

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

IAM

Дізнайтеся більше про IAM в:

pageGCP - 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)

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

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

iam.serviceAccountKeys.create

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

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 не працюватиме для зміни ключа облікового запису служби, оскільки для цього також потрібно дозвіл iam.serviceAccountKeys.create.

iam.serviceAccounts.implicitDelegation

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

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

Зауважте, що згідно з документацією, делегація працює лише для генерації токену за допомогою методу generateAccessToken().

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 для цікавого облікового запису служби:

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

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

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.

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

# 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 від імені облікового запису служби можна знайти тут.

References

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

Other ways to support HackTricks:

Last updated