AWS - IAM Post Exploitation

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

查看 订阅计划!

加入 💬 Discord 群组 或 Telegram 群组 或在 Twitter 🐦 上关注我们 @hacktricks_live.

通过向 HackTricks 和 HackTricks Cloud GitHub 仓库提交 PR 来分享黑客技巧。

IAM

For more information about IAM access:

AWS - IAM, Identity Center & SSO Enum

Confused Deputy 问题

如果你 允许外部账户 (A) 访问你账户中的一个 role，你很可能对 究竟谁可以访问该外部账户 没有任何可见性（0 可见性）。这是一个问题，因为如果另一个外部账户 (B) 能访问外部账户 (A)，那么 B 也可能能够访问你的账户。

因此，当允许外部账户访问你账户中的角色时，可以指定一个 ExternalId。这是一个“秘密”字符串，外部账户 (A) 需要在 assume the role in your organization 时指定该字符串。由于 外部账户 B 不会知道这个字符串，即使他可以访问 A，他也 无法访问你的角色。

但是，请注意这个 ExternalId 的“秘密”并非真正的秘密，任何能够 read the IAM assume role policy 的人都能看到它。但只要外部账户 A 知道它，而外部账户 B 不知道它，它就能 阻止 B 利用 A 来访问你的角色。

示例：

{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"AWS": "Example Corp's AWS Account ID"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "12345"
}
}
}
}

Warning

要让 attacker 利用 confused deputy，他需要想办法确认当前 account 的 principals 是否可以冒充其他 account 中的 roles。

非预期的信任

服务作为主体

{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": { "Service": "apigateway.amazonaws.com" },
"Resource": "arn:aws:lambda:000000000000:function:foo"
}

此策略 允许任何账户 配置其 apigateway 来调用此 Lambda.

S3 作为主体

"Condition": {
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}

如果将 S3 bucket 指定为 principal，由于 S3 buckets 没有 Account ID，如果你 deleted your bucket and the attacker created 它并在他们自己的账号中创建了该 bucket，那么他们可能会滥用这一点。

不支持

{
"Effect": "Allow",
"Principal": { "Service": "cloudtrail.amazonaws.com" },
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
}

通常避免 Confused Deputy 问题的一种方法是使用带有 AWS:SourceArn 的条件来检查来源 ARN。然而，某些服务可能不支持这一点（据某些来源称，如 CloudTrail）。

拥有以下任一权限 — iam:DeleteAccessKey, iam:DeleteLoginProfile, iam:DeleteSSHPublicKey, iam:DeleteServiceSpecificCredential, iam:DeleteInstanceProfile, iam:DeleteServerCertificate, iam:DeleteCloudFrontPublicKey, iam:RemoveRoleFromInstanceProfile — 攻击者可以删除访问密钥、登录配置文件、SSH 密钥、服务特定凭证、实例配置文件、证书或 CloudFront 公钥，或将角色与实例配置文件解除关联。此类操作可以立即阻止合法用户和应用程序并导致 denial-of-service 或依赖这些凭证的系统失去访问，因此这些 IAM 权限必须被严格限制并进行监控。

# Remove Access Key of a user
aws iam delete-access-key \
--user-name <Username> \
--access-key-id AKIAIOSFODNN7EXAMPLE

## Remove ssh key of a user
aws iam delete-ssh-public-key \
--user-name <Username> \
--ssh-public-key-id APKAEIBAERJR2EXAMPLE

身份删除

具有如 iam:DeleteUser、iam:DeleteGroup、iam:DeleteRole 或 iam:RemoveUserFromGroup 等权限的主体，可以删除用户、角色或组——或更改组成员——从而移除身份及其关联的痕迹。这可能会立即中断依赖这些身份的人员和服务的访问，导致拒绝服务或访问丢失，因此这些 IAM 操作必须受到严格限制和监控。

# Delete a user
aws iam delete-user \
--user-name <Username>

# Delete a group
aws iam delete-group \
--group-name <Username>

# Delete a role
aws iam delete-role \
--role-name <Role>

拥有下列任意权限 — iam:DeleteGroupPolicy, iam:DeleteRolePolicy, iam:DeleteUserPolicy, iam:DeletePolicy, iam:DeletePolicyVersion, iam:DeleteRolePermissionsBoundary, iam:DeleteUserPermissionsBoundary, iam:DetachGroupPolicy, iam:DetachRolePolicy, iam:DetachUserPolicy — 的行为者可以删除或分离托管/内联策略、移除策略版本或权限边界，并解除策略与用户、组或角色的关联。这会销毁授权并改变权限模型，导致依赖这些策略的主体立即失去访问权限或出现拒绝服务，因此这些 IAM 操作必须严格限制并进行监控。

# Delete a group policy
aws iam delete-group-policy \
--group-name <GroupName> \
--policy-name <PolicyName>

# Delete a role policy
aws iam delete-role-policy \
--role-name <RoleName> \
--policy-name <PolicyName>

联邦身份删除

通过 iam:DeleteOpenIDConnectProvider、iam:DeleteSAMLProvider 和 iam:RemoveClientIDFromOpenIDConnectProvider，攻击者可以删除 OIDC/SAML 身份提供者或移除 client IDs。此举会破坏联邦认证，阻止令牌验证，并立即拒绝依赖 SSO 的用户和服务的访问，直到 IdP 或配置恢复为止。

# Delete OIDCP provider
aws iam delete-open-id-connect-provider \
--open-id-connect-provider-arn arn:aws:iam::111122223333:oidc-provider/accounts.google.com

# Delete SAML provider
aws iam delete-saml-provider \
--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS

未经授权的 MFA 激活

借助 iam:EnableMFADevice，攻击者可以在用户的身份上注册一个 MFA device，从而阻止合法用户登录。
一旦启用了未经授权的 MFA，用户可能会被锁定，直到该设备被移除或重置为止（注意：如果注册了多个 MFA device，登录只需要其中一个，因此此攻击不会导致拒绝访问）。

aws iam enable-mfa-device \
--user-name <Username> \
--serial-number arn:aws:iam::111122223333:mfa/alice \
--authentication-code1 123456 \
--authentication-code2 789012

证书/密钥元数据篡改

使用 iam:UpdateSSHPublicKey、iam:UpdateCloudFrontPublicKey、iam:UpdateSigningCertificate、iam:UpdateServerCertificate，攻击者可以更改公钥和证书的状态或元数据。通过将密钥/证书标记为不活跃或修改引用，他们可以破坏 SSH 认证、使 X.509/TLS 验证失效，并立即中断依赖这些凭据的服务，导致访问或可用性丧失。

aws iam update-ssh-public-key \
--user-name <Username> \
--ssh-public-key-id APKAEIBAERJR2EXAMPLE \
--status Inactive

aws iam update-server-certificate \
--server-certificate-name <Certificate_Name> \
--new-path /prod/

`iam:Delete*`

IAM 通配符 iam:Delete* 授予删除多种 IAM 资源（用户、角色、组、策略、密钥、证书、MFA 设备、策略版本等）的能力——因此具有非常高的影响范围：被授予 iam:Delete* 的行为者可以永久销毁身份、凭据、策略和相关制品，删除审计/证据，并导致服务或运营中断。一些示例包括

# Delete a user
aws iam delete-user --user-name <Username>

# Delete a role
aws iam delete-role --role-name <RoleName>

# Delete a managed policy
aws iam delete-policy --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/<PolicyName>

`iam:EnableMFADevice`

授予 iam:EnableMFADevice 操作的主体可以在账户内的某个身份上注册 MFA 设备，前提是该用户尚未启用 MFA。
这可以用来干扰用户的访问：一旦 attacker 注册了 MFA 设备，合法用户可能被阻止登录，因为他们无法控制 attacker 注册的 MFA。

这种拒绝访问的攻击只有在用户未注册任何 MFA 时才有效；如果 attacker 为该用户注册了 MFA 设备，合法用户将被锁定，无法进入任何需要该新 MFA 的流程。若该用户已经拥有一个或多个由其控制的 MFA 设备，添加 attacker 控制的 MFA 并不会阻止合法用户——他们仍可继续使用已有的任一 MFA 进行认证。

要为用户启用（注册）MFA 设备，attacker 可以运行：

aws iam enable-mfa-device \
--user-name <Username> \
--serial-number arn:aws:iam::111122223333:mfa/alice \
--authentication-code1 123456 \
--authentication-code2 789012

参考资料

https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html