Chinese - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

AWS - IAM & STS Unauthenticated Enum

支持 HackTricks

枚举账户中的角色和用户名

Assume Role Brute-Force

此技术不再有效，因为无论角色是否存在，你总是会得到这个错误：

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账户ID和一个目标词表，就可以在不受任何固有限制的情况下枚举账户中的角色。

你可以使用这个脚本来枚举潜在的主体滥用这个问题。

信任策略：暴力破解跨账户角色和用户

配置或更新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 联邦

想象一下，你设法读取了一个访问 AWS 内部 role 的 Github Actions workflow。 这种信任可能会授予具有以下 trust policy 的角色的访问权限：

{
"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