AWS - STS Privesc

Reading time: 6 minutes

tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримка HackTricks

STS

sts:AssumeRole

Кожна роль створюється з політикою довіри ролі, ця політика вказує хто може прийняти створену роль. Якщо роль з того ж облікового запису вказує, що інший обліковий запис може її прийняти, це означає, що цей обліковий запис зможе отримати доступ до ролі (і потенційно privesc).

Наприклад, наступна політика довіри ролі вказує, що будь-хто може її прийняти, отже будь-який користувач зможе privesc до дозволів, пов'язаних з цією роллю.

json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "sts:AssumeRole"
}
]
}

Ви можете видати себе за роль, виконавши:

bash
aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname

Потенційний вплив: Privesc до ролі.

caution

Зауважте, що в цьому випадку дозвіл sts:AssumeRole має бути вказаний у ролі для зловживання і не в політиці, що належить атакуючому.
За одним винятком, щоб взяти на себе роль з іншого облікового запису, обліковий запис атакуючого також має мати sts:AssumeRole на цю роль.

sts:AssumeRoleWithSAML

Політика довіри з цією роллю надає користувачам, аутентифікованим через SAML, доступ для імітації ролі.

Приклад політики довіри з цим дозволом:

json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "OneLogin",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::290594632123:saml-provider/OneLogin"
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
}

Щоб згенерувати облікові дані для імітації ролі, загалом можна використати щось на кшталт:

bash
aws sts  assume-role-with-saml --role-arn <value> --principal-arn <value>

Але провайдери можуть мати свої власні інструменти, щоб полегшити це, наприклад, onelogin-aws-assume-role:

bash
onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600

Потенційний вплив: Privesc до ролі.

sts:AssumeRoleWithWebIdentity

Ця дозволяє отримати набір тимчасових облікових даних безпеки для користувачів, які були автентифіковані в мобільному додатку, веб-застосунку, EKS... за допомогою провайдера веб-ідентичності. Дізнатися більше тут.

Наприклад, якщо 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

Federation Abuse

AWS - Federation Abuse

IAM Roles Anywhere Privesc

AWS IAM RolesAnywhere дозволяє робочим навантаженням поза AWS assume IAM roles за допомогою X.509 сертифікатів. Однак якщо trust policies не обмежені належним чином, їх можна зловживати для privilege escalation.

Щоб зрозуміти цю атаку, необхідно пояснити, що таке trust anchor. Trust anchor в AWS IAM RolesAnywhere — це коренева сутність довіри: вона містить публічний сертифікат 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",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rolesanywhere.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity",
"sts:TagSession"
]
}
]
}

Для privesc потрібен aws_signing_helper з https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html

Потім, використовуючи дійсний сертифікат, attacker може pivot у роль з вищими привілеями

bash
aws_signing_helper credential-process \
--certificate readonly.pem \
--private-key readonly.key \
--trust-anchor-arn arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/ta-id \
--profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
--role-arn arn:aws:iam::123456789012:role/Admin

Довірчий корінь перевіряє, що сертифікат клієнта readonly.pem походить від його авторизованого CA, і всередині цього сертифіката readonly.pem міститься відкритий ключ, який AWS використовує для перевірки, що підпис було зроблено відповідним приватним ключем readonly.key.

Сертифікат також містить атрибути (наприклад CN або OU), які профіль default перетворює на теги, які політика довіри ролі може використовувати, щоб вирішити, чи авторизувати доступ. Якщо в політиці довіри немає умов, ці теги не використовуються, і доступ надається будь-кому з дійсним сертифікатом.

Щоб ця атака була можлива, обидва — довірчий корінь і профіль default — повинні бути активні.

Посилання

tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримка HackTricks