AWS - STS Privesc

Tip

学习并练习 AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
学习并练习 GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
学习并练习 Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

STS

sts:AssumeRole

每个角色在创建时都会有一个角色信任策略，该策略指出谁可以假设已创建的角色。如果来自相同账户的某个角色声明某个账户可以假设它，则该账户将能够访问该角色（并可能进行 privesc）。

例如，下面的角色信任策略表示任何人都可以假设它，因此 任何用户都将能够 privesc 到与该角色关联的权限。

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

你可以通过运行以下命令模拟角色：

aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname

潜在影响： 对该角色的 Privesc。

Caution

注意，在这种情况下，权限 sts:AssumeRole 需要在要滥用的角色中指明，而不是在属于攻击者的策略中。
除了一种例外，为了从不同账号假设角色，攻击者账号还需要对该角色拥有**sts:AssumeRole**权限。

sts:AssumeRoleWithSAML

具有该角色的信任策略允许通过 SAML 认证的用户以该角色进行模拟访问。

带有此权限的信任策略示例如下：

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "OneLogin",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::290594632123:saml-provider/OneLogin"
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
}

要生成用于模拟该角色的凭据，通常可以使用如下命令：

aws sts  assume-role-with-saml --role-arn <value> --principal-arn <value>

但是 提供商 可能有他们的 自己的工具 来使这更容易，例如 onelogin-aws-assume-role:

onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600

潜在影响： Privesc to the role.

sts:AssumeRoleWithWebIdentity

该权限允许通过 web 身份提供者获取一组临时安全凭证，供 在移动、web 应用、EKS… 中已通过身份验证的用户 使用。 Learn more here.

例如，如果一个 EKS service account 应该能够 impersonate an IAM role，它将在 /var/run/secrets/eks.amazonaws.com/serviceaccount/token 拥有一个 token，并且可以通过类似下面的操作 assume the role and get credentials：

aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/<role_name> --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token
# The role name can be found in the metadata of the configuration of the pod

Federation Abuse

AWS - Federation Abuse

IAM Roles Anywhere Privesc

AWS IAM Roles Anywhere 允许 AWS 之外的工作负载使用 X.509 证书来 assume IAM roles。但当 trust policy 没有被正确限定时，这些机制可能被滥用以进行 privilege escalation。

要理解此攻击，有必要解释什么是 trust anchor。一个 trust anchor 在 AWS IAM Roles Anywhere 中是信任根实体，它包含已在账户中注册的 Certificate Authority (CA) 的公钥证书，以便 AWS 能验证提交的 X.509 证书。这样，如果客户端证书是由该 CA 签发且对应的 trust anchor 处于激活状态，AWS 就会将其识别为有效。

此外，profile 是用于定义 X.509 证书哪些属性（例如 CN、OU 或 SAN）会被转换成 session tags 的配置，这些 tags 随后会与 trust policy 的条件进行比较。

该 policy 对允许使用的 trust anchor 或证书属性缺乏限制。结果是，任何与账户中任意 trust anchor 关联的证书都可以用来 assume 该 role。

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rolesanywhere.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity",
"sts:TagSession"
]
}
]
}

要进行 privesc，需要从 https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html 获取 aws_signing_helper

然后使用有效证书，攻击者可以 pivot into 更高权限的角色

aws_signing_helper credential-process \
--certificate readonly.pem \
--private-key readonly.key \
--trust-anchor-arn arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/ta-id \
--profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
--role-arn arn:aws:iam::123456789012:role/Admin

信任锚验证客户端的 readonly.pem 证书是否来自其授权的 CA，在该 readonly.pem 证书中包含 AWS 用来验证签名是否由其对应私钥 readonly.key 创建的公钥。

证书还提供属性（例如 CN 或 OU），default 配置文件会将这些属性转换为标签，角色的信任策略可以使用这些标签来决定是否授权访问。如果信任策略中没有条件约束，这些标签就没有用途，任何拥有有效证书的人都会被授予访问权限。

要使此攻击成为可能，信任锚和 default 配置文件都必须处于激活状态。

参考资料

Tip

学习并练习 AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
学习并练习 GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
学习并练习 Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks