Ukranian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

AWS - IAM & STS Unauthenticated Enum

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки 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

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

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 для створення необхідних політик для переліку

Підвищення привілеїв

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

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

Атакувальник може просто припустити це.

Федерація OIDC стороннього постачальника

Уявіть, що вам вдалося прочитати робочий процес Github Actions, який отримує доступ до ролі всередині 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.

Посилання

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

PreviousAWS - Elasticsearch Unauthenticated EnumNextAWS - IoT Unauthenticated Enum

Last updated