Ukranian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP - IAM Privesc

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

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

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

Ви можете знайти скрипт для автоматизації створення, експлуатації та очищення вразливого середовища тут та 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 не працюватиме для зміни ключа 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 сервісного облікового запису, а потім надіслати його як блоб, щоб отримати підписаний 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"

# 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 (якщо у вас є доступ) за допомогою:

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

Посилання

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

Last updated