mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat
This commit is contained in:
Translator
@@ -6,9 +6,9 @@
|
||||
|
||||
### `sts:AssumeRole`
|
||||
|
||||
Кожна роль створюється з **політикою довіри ролі**, ця політика вказує **хто може прийняти створену роль**. Якщо роль з **того самого акаунту** вказує, що акаунт може її приймати, це означає, що цей акаунт зможе отримати доступ до ролі (і потенційно **privesc**).
|
||||
Кожна роль створюється з **політикою довіри ролі**, ця політика вказує **хто може прийняти створену роль**. Якщо роль з **того самого акаунта** вказує, що якийсь акаунт може її прийняти, це означає, що цей акаунт зможе отримати доступ до ролі (і потенційно виконати **privesc**).
|
||||
|
||||
Наприклад, наступна політика довіри ролі вказує, що будь-хто може її прийняти, отже **будь-який користувач зможе здійснити privesc** до дозволів, пов'язаних з цією роллю.
|
||||
Наприклад, наступна політика довіри ролі показує, що будь-хто може її прийняти, тому **будь-який користувач зможе privesc** до прав, пов'язаних із цією роллю.
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -23,20 +23,20 @@
|
||||
]
|
||||
}
|
||||
```
|
||||
Ви можете видаватися за роль, запустивши:
|
||||
Ви можете вдавати роль, що виконується:
|
||||
```bash
|
||||
aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
|
||||
```
|
||||
**Потенційний вплив:** Privesc до ролі.
|
||||
**Можливий вплив:** Privesc до ролі.
|
||||
|
||||
> [!CAUTION]
|
||||
> Зауважте, що в цьому випадку дозвіл `sts:AssumeRole` має бути **вказаний у ролі, яку збираються зловживати**, а не в політиці, що належить зловмиснику.\
|
||||
> За одним винятком, щоб **прийняти роль з іншого облікового запису** обліковий запис зловмисника **також повинен** мати **`sts:AssumeRole`** щодо цієї ролі.
|
||||
> Зауважте, що в цьому випадку дозвіл `sts:AssumeRole` має бути **вказаний у ролі, яку планують зловживати**, а не в політиці, що належить атакуючому.\
|
||||
> За одним винятком, щоб **прийняти роль з іншого облікового запису** обліковий запис зловмисника **також повинен** мати **`sts:AssumeRole`** над роллю.
|
||||
|
||||
|
||||
### `sts:AssumeRoleWithSAML`
|
||||
|
||||
Політика довіри для цієї ролі надає **користувачам, автентифікованим через SAML, можливість діяти від імені ролі.**
|
||||
Політика довіри для цієї ролі надає **користувачам, автентифікованим через SAML, можливість виступати від імені цієї ролі.**
|
||||
|
||||
Приклад політики довіри з цим дозволом:
|
||||
```json
|
||||
@@ -59,21 +59,21 @@ aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
|
||||
]
|
||||
}
|
||||
```
|
||||
Щоб згенерувати облікові дані для імітації ролі, можна використати щось на кшталт:
|
||||
Щоб згенерувати credentials для impersonate the role, загалом ви можете використати щось на кшталт:
|
||||
```bash
|
||||
aws sts assume-role-with-saml --role-arn <value> --principal-arn <value>
|
||||
```
|
||||
Але **провайдери** можуть мати **власні інструменти**, щоб полегшити це, наприклад [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role):
|
||||
Але **провайдери** можуть мати **власні інструменти**, щоб зробити це простіше, наприклад [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role):
|
||||
```bash
|
||||
onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600
|
||||
```
|
||||
**Потенційний вплив:** Privesc to the role.
|
||||
**Можливий вплив:** Privesc до role.
|
||||
|
||||
### `sts:AssumeRoleWithWebIdentity`
|
||||
|
||||
Цей дозвіл дає можливість отримати набір тимчасових облікових даних безпеки для **користувачів, які були автентифіковані у мобільному, веб-застосунку, EKS...** з використанням провайдера web identity. [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
|
||||
Цей дозвіл дозволяє отримати набір тимчасових облікових даних безпеки для **користувачів, які були автентифіковані в мобільному або веб‑застосунку, EKS...** за допомогою провайдера web identity. [Дізнатися більше тут.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
|
||||
|
||||
Наприклад, якщо **EKS service account** має мати можливість **impersonate an IAM role**, він матиме токен у **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** і може **assume the role and get credentials**, виконавши щось на кшталт:
|
||||
Наприклад, якщо **EKS service account** має можливість **impersonate an IAM role**, він матиме токен у **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** і може **assume the role and get credentials**, роблячи щось на кшталт:
|
||||
```bash
|
||||
aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/<role_name> --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token
|
||||
# The role name can be found in the metadata of the configuration of the pod
|
||||
@@ -86,9 +86,13 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/
|
||||
|
||||
### IAM Roles Anywhere Privesc
|
||||
|
||||
AWS IAM RolesAnywhere дозволяє робочим навантаженням поза AWS assume IAM roles за допомогою X.509 certificates. Але коли trust policies не належним чином обмежені, їх можна зловживати для privilege escalation.
|
||||
AWS IAM Roles Anywhere дозволяє робочим навантаженням поза AWS assume IAM roles за допомогою X.509 сертифікатів. Але коли trust policies не мають належної обмежувальної області, їх можна зловживати для privilege escalation.
|
||||
|
||||
Ця policy не містить обмежень щодо того, який trust anchor або які certificate attributes дозволені. В результаті будь-який certificate, пов'язаний з будь-яким trust anchor в акаунті, може бути використаний, щоб assume this role.
|
||||
Щоб зрозуміти цю атаку, необхідно пояснити, що таке trust anchor. Trust anchor в AWS IAM Roles Anywhere — це кореневий елемент довіри; він містить публічний сертифікат Certificate Authority (CA), зареєстрованої в обліковому записі, щоб AWS міг перевірити надані X.509 сертифікати. Таким чином, якщо клієнтський сертифікат був виданий цим CA і trust anchor активний, AWS визнає його дійсним.
|
||||
|
||||
Крім того, profile — це конфігурація, яка визначає, які атрибути X.509 сертифіката (наприклад, CN, OU або SAN) будуть перетворені в session tags, а ці теги потім порівнюються з умовами trust policy.
|
||||
|
||||
Ця policy не містить обмежень щодо того, який trust anchor або атрибути сертифіката дозволені. Внаслідок цього будь-який сертифікат, прив'язаний до будь-якого trust anchor в обліковому записі, може бути використаний, щоб assume this role.
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -108,9 +112,9 @@ AWS IAM RolesAnywhere дозволяє робочим навантаженням
|
||||
}
|
||||
|
||||
```
|
||||
Щоб виконати privesc, `aws_signing_helper` потрібен з https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html
|
||||
Для privesc потрібен `aws_signing_helper` з https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html
|
||||
|
||||
Потім, використовуючи дійсний сертифікат, зловмисник може pivot у role з вищими привілеями
|
||||
Потім, використовуючи дійсний сертифікат, зловмисник може перейти в роль із вищими привілеями.
|
||||
```bash
|
||||
aws_signing_helper credential-process \
|
||||
--certificate readonly.pem \
|
||||
@@ -119,13 +123,13 @@ aws_signing_helper credential-process \
|
||||
--profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
|
||||
--role-arn arn:aws:iam::123456789012:role/Admin
|
||||
```
|
||||
Точка довіри перевіряє, що клієнтський сертифікат `readonly.pem` походить від його авторизованого CA; коли точку довіри створювали, був включений публічний сертифікат CA (який тепер використовується для валідації `readonly.pem`). Усередині `readonly.pem` міститься відкритий ключ, який AWS використовує для перевірки того, що підпис було зроблено відповідним приватним ключем `readonly.key`.
|
||||
Якір довіри перевіряє, що сертифікат клієнта `readonly.pem` походить від його авторизованого CA, і всередині цього сертифіката `readonly.pem` міститься публічний ключ, який AWS використовує для перевірки того, що підпис було зроблено відповідним приватним ключем `readonly.key`.
|
||||
|
||||
Сертифікат також підтверджує ідентичність і надає атрибути (наприклад CN або OU), які профіль `default` перетворює на теги — політика довіри ролі може використовувати ці теги, щоб вирішити, чи надавати доступ; якщо в політиці довіри немає умов, ці теги ігноруються і будь-хто з дійсним сертифікатом допускається.
|
||||
Сертифікат також надає атрибути (наприклад CN або OU), які профіль `default` перетворює на теги, і які політика довіри ролі може використовувати для вирішення питання про надання доступу. Якщо в політиці довіри немає умов, ці теги не мають значення, і доступ надається будь-кому з дійсним сертифікатом.
|
||||
|
||||
Щоб ця атака була можливою, і точка довіри, і профіль `default` повинні бути активними.
|
||||
Щоб ця атака була можлива, і якір довіри, і профіль `default` мають бути активними.
|
||||
|
||||
### References
|
||||
### Посилання
|
||||
|
||||
- [https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation](https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user