GCP - IAM Privesc
IAM
Дізнайтеся більше про IAM в:
pageGCP - IAM, Principals & Org Policies Enumiam.roles.update
(iam.roles.get
)
iam.roles.update
(iam.roles.get
)Атакувальник з вказаними дозволами зможе оновити роль, призначену вам, і надати вам додаткові дозволи до інших ресурсів, наприклад:
Ви можете знайти скрипт для автоматизації створення, використання та очищення вразливого середовища тут та скрипт на Python для зловживання цими привілеями тут. Для отримання додаткової інформації перегляньте оригінальне дослідження.
iam.serviceAccounts.getAccessToken
(iam.serviceAccounts.get
)
iam.serviceAccounts.getAccessToken
(iam.serviceAccounts.get
)Атакуючий з вказаними дозволами зможе запитати токен доступу, який належить Обліковому запису служби, тому можливо запитати токен доступу Облікового запису служби з більшими привілеями, ніж у нас.
Ви можете знайти скрипт для автоматизації створення, використання та очищення вразливого середовища тут та скрипт на Python для зловживання цим привілеєм тут. Для отримання додаткової інформації перегляньте оригінальне дослідження.
iam.serviceAccountKeys.create
iam.serviceAccountKeys.create
Атакуючий з вказаними дозволами зможе створити ключ, керований користувачем, для Облікового запису служби, що дозволить нам отримати доступ до GCP як цей Обліковий запис служби.
Ви можете знайти скрипт для автоматизації створення, використання та очищення вразливого середовища тут та скрипт на Python для зловживання цими привілеями тут. Для отримання додаткової інформації перегляньте оригінальне дослідження.
Зверніть увагу, що iam.serviceAccountKeys.update
не працюватиме для зміни ключа облікового запису служби, оскільки для цього також потрібно дозвіл iam.serviceAccountKeys.create
.
iam.serviceAccounts.implicitDelegation
iam.serviceAccounts.implicitDelegation
Якщо у вас є дозвіл iam.serviceAccounts.implicitDelegation
на обліковому записі служби, який має дозвіл iam.serviceAccounts.getAccessToken
на третьому обліковому записі служби, то ви можете використовувати неявну делегацію для створення токену для цього третього облікового запису служби. Ось діаграма, щоб пояснити.
Ви можете знайти скрипт для автоматизації створення, використання та очищення вразливого середовища тут та скрипт на Python для зловживання цими привілеями тут. Для отримання додаткової інформації перегляньте оригінальне дослідження.
Зауважте, що згідно з документацією, делегація працює лише для генерації токену за допомогою методу generateAccessToken().
iam.serviceAccounts.signBlob
iam.serviceAccounts.signBlob
Атакуючий з вказаними дозволами зможе підписувати довільні дані в GCP. Таким чином буде можливо створити непідписаний JWT облікового запису служби, а потім надіслати його як блоб, щоб отримати підписаний JWT від облікового запису служби, якого ми цільово атакуємо. Для отримання додаткової інформації читайте це.
Ви можете знайти скрипт для автоматизації створення, використання та очищення вразливого середовища тут та скрипт на Python для зловживання цими привілеями тут та тут. Для отримання додаткової інформації перегляньте оригінальне дослідження.
iam.serviceAccounts.signJwt
iam.serviceAccounts.signJwt
Атакуючий з вказаними дозволами зможе підписувати добре сформовані JSON-токени (JWT). Відмінність від попереднього методу полягає в тому, що замість того, щоб Google підписував блоб, що містить JWT, ми використовуємо метод signJWT, який вже очікує JWT. Це полегшує використання, але ви можете підписувати лише JWT замість будь-яких байтів.
Ви можете знайти скрипт для автоматизації створення, використання та очищення вразливого середовища тут та скрипт на Python для зловживання цими привілеями тут. Для отримання додаткової інформації перегляньте оригінальне дослідження.
iam.serviceAccounts.setIamPolicy
iam.serviceAccounts.setIamPolicy
Атакуючий з вказаними дозволами зможе додавати політики IAM до облікових записів служб. Ви можете зловживати цим, щоб надати собі необхідні дозволи для імітації облікового запису служби. У наступному прикладі ми надаємо собі роль roles/iam.serviceAccountTokenCreator
для цікавого облікового запису служби:
Ви можете знайти скрипт для автоматизації створення, використання та очищення вразливого середовища тут.
iam.serviceAccounts.actAs
iam.serviceAccounts.actAs
Дозвіл iam.serviceAccounts.actAs схожий на дозвіл iam:PassRole від AWS. Це необхідно для виконання завдань, таких як ініціювання екземпляра Compute Engine, оскільки він надає можливість "діяти від імені" облікового запису служби, забезпечуючи безпечне управління дозволами. Без цього користувачі можуть отримати неправомірний доступ. Крім того, використання iam.serviceAccounts.actAs включає різні методи, кожен з яких потребує набору дозволів, що відрізняється від інших методів, які потребують лише одного.
Імітація облікового запису служби
Імітація облікового запису служби може бути дуже корисною для отримання нових та кращих привілеїв. Існує три способи, за допомогою яких ви можете імітувати інший обліковий запис служби:
Аутентифікація з використанням приватних ключів RSA (описано вище)
Авторизація з використанням політик Cloud IAM (описано тут)
Розгортання завдань на службах GCP (більш застосовно до компрометації облікового запису користувача)
iam.serviceAccounts.getOpenIdToken
iam.serviceAccounts.getOpenIdToken
Атакуючий з вказаними дозволами зможе створити токен OpenID JWT. Вони використовуються для підтвердження ідентичності і не обов'язково мають будь-яку імпліцитну авторизацію щодо ресурсу.
Згідно з цим цікавим постом, необхідно вказати аудиторію (сервіс, де ви хочете використовувати токен для аутентифікації) і ви отримаєте JWT, підписаний google, що вказує на обліковий запис служби та аудиторію JWT.
Ви можете створити токен OpenID (якщо у вас є доступ) за допомогою:
Потім ви можете просто використовувати його для доступу до сервісу за допомогою:
Деякі сервіси, які підтримують аутентифікацію за допомогою цих видів токенів, це:
Google Cloud Endpoints (якщо використовується Google OIDC)
Приклад створення та використання токена OpenID від імені облікового запису служби можна знайти тут.
References
Last updated