Ukranian - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

AWS - IAM & STS Unauthenticated Enum

Support HackTricks

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

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

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

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 може повернути:

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

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

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

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

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

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

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

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

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

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

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

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

GUI

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

CLI

### 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

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

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

Зловмисник міг би просто припустити це.

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

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

{
"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! Ви повинні вказати в умовах також інші речі, такі як назва організації, назва репозиторію, середовище, гілка...

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

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

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

Посилання

Підтримайте HackTricks
PreviousAWS - Elasticsearch Unauthenticated EnumNextAWS - Identity Center & SSO Unauthenticated Enum

Last updated