AWS - IAM & STS Універсальна Перевірка

Reading time: 5 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

Перерахунок ролей та імен користувачів в обліковому записі

Брутфорс для припущення ролі

caution

Ця техніка більше не працює, оскільки, незалежно від того, чи існує роль, ви завжди отримуєте цю помилку:

An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::947247140022:user/testenv is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::429217632764:role/account-balanceasdas

Ви можете перевірити це, запустивши:

aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example

Спроба припустити роль без необхідних дозволів викликає повідомлення про помилку AWS. Наприклад, якщо немає авторизації, AWS може повернути:

ruby
An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::012345678901:user/MyUser is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS

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

less
An error occurred (AccessDenied) when calling the AssumeRole operation: Not authorized to perform sts:AssumeRole

Цей метод розрізнення між існуючими та неіснуючими ролями застосовується навіть між різними AWS обліковими записами. З дійсним ідентифікатором облікового запису AWS та цільовим словником можна перерахувати ролі, присутні в обліковому записі, не стикаючись з жодними вродженими обмеженнями.

Ви можете використовувати цей скрипт для перерахунку потенційних принципалів, зловживаючи цією проблемою.

Політики довіри: Брутфорс крос-облікові ролі та користувачі

Налаштування або оновлення політики довіри IAM ролі передбачає визначення, які ресурси або сервіси AWS можуть приймати цю роль та отримувати тимчасові облікові дані. Якщо вказаний ресурс у політиці існує, політика довіри зберігається успішно. Однак, якщо ресурс не існує, генерується помилка, що вказує на те, що було надано недійсний принципал.

warning

Зверніть увагу, що в цьому ресурсі ви можете вказати крос-облікову роль або користувача:

  • arn:aws:iam::acc_id:role/role_name
  • arn:aws:iam::acc_id:user/user_name

Це приклад політики:

json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::216825089941:role/Test"
},
"Action": "sts:AssumeRole"
}
]
}

GUI

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

CLI

bash
### You could also use: aws iam update-assume-role-policy
# When it works
aws iam create-role --role-name Test-Role --assume-role-policy-document file://a.json
{
"Role": {
"Path": "/",
"RoleName": "Test-Role",
"RoleId": "AROA5ZDCUJS3DVEIYOB73",
"Arn": "arn:aws:iam::947247140022:role/Test-Role",
"CreateDate": "2022-05-03T20:50:04Z",
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::316584767888:role/account-balance"
},
"Action": [
"sts:AssumeRole"
]
}
]
}
}
}

# When it doesn't work
aws iam create-role --role-name Test-Role2 --assume-role-policy-document file://a.json
An error occurred (MalformedPolicyDocument) when calling the CreateRole operation: Invalid principal in policy: "AWS":"arn:aws:iam::316584767888:role/account-balanceefd23f2"

Ви можете автоматизувати цей процес за допомогою https://github.com/carlospolop/aws_tools

  • bash unauth_iam.sh -t user -i 316584767888 -r TestRole -w ./unauth_wordlist.txt

Наше використання Pacu:

  • run iam__enum_users --role-name admin --account-id 229736458923 --word-list /tmp/names.txt
  • run iam__enum_roles --role-name admin --account-id 229736458923 --word-list /tmp/names.txt
  • Роль admin, використана в прикладі, є роллю у вашому обліковому записі, яка може бути використана pacu для створення політик, які йому потрібні для перерахунку

Privesc

У випадку, якщо роль була неправильно налаштована і дозволяє будь-кому її приймати:

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

Атакуючий міг би просто припустити це.

Федерація OIDC третьої сторони

Уявіть, що вам вдалося прочитати Github Actions workflow, який отримує доступ до ролі всередині AWS.
Ця довіра може надати доступ до ролі з наступною політикою довіри:

json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::<acc_id>:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
}
}
}
]
}

Ця політика довіри може бути правильною, але відсутність додаткових умов повинна викликати у вас недовіру.
Це пов'язано з тим, що попередню роль може прийняти КОЖЕН з Github Actions! Ви повинні вказати в умовах також інші речі, такі як назва організації, назва репозиторію, середовище, гілка...

Ще однією потенційною помилкою конфігурації є додавання умови на зразок наступної:

json
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:org_name*:*"
}

Зверніть увагу на додатковий символ (*) перед двоеточі (:). Ви можете створити організацію, таку як org_name1, і прийняти роль з Github Action.

Посилання

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