GCP - IAM Privesc
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Знайдіть більше інформації про IAM у:
iam.roles.update
(iam.roles.get
)Зловмисник з вказаними дозволами зможе оновити роль, призначену вам, і надати вам додаткові дозволи на інші ресурси, такі як:
Ви можете знайти скрипт для автоматизації створення, експлуатації та очищення вразливого середовища тут і python-скрипт для зловживання цими привілеями тут. Для отримання додаткової інформації перегляньте оригінальне дослідження.
iam.serviceAccounts.getAccessToken
(iam.serviceAccounts.get
)Зловмисник з вказаними дозволами зможе запросити токен доступу, що належить обліковому запису служби, тому можливо запросити токен доступу облікового запису служби з більшими привілеями, ніж у нас.
Ви можете знайти скрипт для автоматизації створення, експлуатації та очищення вразливого середовища тут та python-скрипт для зловживання цим привілеєм тут. Для отримання додаткової інформації перегляньте оригінальне дослідження.
iam.serviceAccountKeys.create
Зловмисник з вказаними дозволами зможе створити ключ, керований користувачем, для облікового запису служби, що дозволить нам отримати доступ до GCP як цей обліковий запис служби.
Ви можете знайти скрипт для автоматизації створення, експлуатації та очищення вразливого середовища тут та python-скрипт для зловживання цим привілеєм тут. Для отримання додаткової інформації перегляньте оригінальне дослідження.
Зверніть увагу, що iam.serviceAccountKeys.update
не працюватиме для зміни ключа SA, оскільки для цього також потрібні дозволи iam.serviceAccountKeys.create
.
iam.serviceAccounts.implicitDelegation
Якщо у вас є iam.serviceAccounts.implicitDelegation
дозвіл на обліковий запис служби, який має дозвіл iam.serviceAccounts.getAccessToken
на третьому обліковому записі служби, тоді ви можете використовувати implicitDelegation для створення токена для цього третього облікового запису служби. Ось діаграма, яка допоможе пояснити.
Зверніть увагу, що відповідно до документації, делегування gcloud
працює лише для генерації токена за допомогою методу generateAccessToken(). Отже, ось як отримати токен, використовуючи API безпосередньо:
Ви можете знайти скрипт для автоматизації створення, експлуатації та очищення вразливого середовища тут та python-скрипт для зловживання цим привілеєм тут. Для отримання додаткової інформації перегляньте оригінальне дослідження.
iam.serviceAccounts.signBlob
Зловмисник з вказаними дозволами зможе підписувати довільні корисні навантаження в GCP. Отже, буде можливим створити непідписаний JWT SA, а потім надіслати його як блоб, щоб отримати підписаний JWT від SA, на який ми націлюємося. Для отримання додаткової інформації читайте це.
Ви можете знайти скрипт для автоматизації створення, експлуатації та очищення вразливого середовища тут та python-скрипт для зловживання цим привілеєм тут і тут. Для отримання додаткової інформації перегляньте оригінальне дослідження.
iam.serviceAccounts.signJwt
Зловмисник з вказаними дозволами зможе підписувати коректно сформовані JSON веб-токени (JWT). Різниця з попереднім методом полягає в тому, що замість того, щоб змусити Google підписати блоб, що містить JWT, ми використовуємо метод signJWT, який вже очікує JWT. Це робить його простішим у використанні, але ви можете підписувати лише JWT, а не будь-які байти.
Ви можете знайти скрипт для автоматизації створення, експлуатації та очищення вразливого середовища тут та python-скрипт для зловживання цим привілеєм тут. Для отримання додаткової інформації перегляньте оригінальне дослідження.
iam.serviceAccounts.setIamPolicy
Зловмисник з вказаними дозволами зможе додавати IAM політики до облікових записів служби. Ви можете зловживати цим, щоб наділити себе дозволами, необхідними для наслідування облікового запису служби. У наступному прикладі ми наділяємо себе роллю roles/iam.serviceAccountTokenCreator
над цікавим SA:
Ви можете знайти скрипт для автоматизації створення, експлуатації та очищення вразливого середовища тут.
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 (якщо у вас є доступ) за допомогою:
Тоді ви можете просто використовувати це для доступу до сервісу за допомогою:
Деякі сервіси, які підтримують аутентифікацію через такі токени:
Google Cloud Endpoints (якщо використовується Google OIDC)
Ви можете знайти приклад того, як створити OpenID токен від імені облікового запису служби тут.
Вчіться та практикуйте Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Вчіться та практикуйте Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)