gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-02-04 19:11:41 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat

Browse Source
This commit is contained in:
Translator
2025-09-30 19:16:33 +00:00
parent c5aed418a9
commit a353a8b3b0
1 changed files with 24 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

45
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
View File

@@ -6,9 +6,9 @@
### `sts:AssumeRole`
每个 role 都会创建一个 **role trust policy**，该策略指明 **谁可以 assume 所创建的 role**。如果一个来自 **same account** 的 role 指定某个 account 可以 assume 它，意味着该 account 将能够访问该 role（并可能进行 **privesc**）。
每个角色都会有一个 **角色信任策略 (role trust policy)**，该策略指明 **谁可以假定该角色**。如果来自**同一账户**的某个 role 声明某个 account 可以假定它，则意味着该 account 将能够访问该 role（并可能进行 **privesc**）。
例如，下面的 role trust policy 表明任何人都可以 assume 它，因此 **any user will be able to privesc** 到与该 role 关联的权限。
例如，下面的角色信任策略表明任何人都可以假定它，因此 **任何用户将能够 privesc** 到与该角色关联的权限。
```json
{
"Version": "2012-10-17",
@@ -23,20 +23,19 @@
]
}
```
您可以模拟正在运行的角色：
你可以通过运行以下命令来模拟某个角色：
```bash
aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
```
**Potential Impact:** Privesc 到该角色。
**潜在影响：** 对角色的 Privesc.
> [!CAUTION]
> 注意在这种情况下，权限 `sts:AssumeRole` 需要在**要滥用的角色中被指明**，而不是在属于攻击者的策略中。\
> 除非有一个例外，为了**假设来自不同账户的角色**，攻击者账户**还需要**对该角色拥有 **`sts:AssumeRole`** 权限。
> 注意，在这种情况下权限 `sts:AssumeRole` 需要**在被滥用的角色中指明**，而不是在属于攻击者的策略中。\
> 有一个例外：为了**从不同账户假设一个角色**，攻击者账户**也需要**对该角色拥有**`sts:AssumeRole`**权限。
### `sts:AssumeRoleWithSAML`
具有此角色的信任策略会授予**通过 SAML 验证的用户冒充该角色的访问权限。**
具有该角色的信任策略会授予**通过 SAML 验证的用户访问以模拟该角色的能力。**
具有此权限的信任策略示例如下：
```json
@@ -59,26 +58,26 @@ aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
]
}
```
要生成用于模拟该角色的凭证，通常可以使用类似如下的命令：
要生成凭据以模拟该角色，通常可以使用如下方式：
```bash
aws sts assume-role-with-saml --role-arn <value> --principal-arn <value>
```
但 **提供商** 可能有他们 **自己的工具** 来使这更容易，比如 [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role):
但是 **提供商** 可能有 **自己的工具** 来简化此过程，例如 [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role):
```bash
onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600
```
**潜在影响：** Privesc 到该 role。
**Potential Impact:** Privesc 到该角色。
### `sts:AssumeRoleWithWebIdentity`
此权限允许通过 web identity provider 为在 **移动设备、web 应用、EKS... 中已完成认证的用户** 获取一组临时安全凭证。 [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
此权限允许通过 web 身份提供商为 **users who have been authenticated in a mobile, web application, EKS...** 获取一组临时安全凭证。 [了解更多](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
例如，如果一个 **EKS service account** 应该能够 **impersonate an IAM role**，它会在 **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** 中有一个令牌，并且可以通过类似如下的方式 **assume the role and get credentials**：
例如，如果一个 **EKS service account** 需要能够 **impersonate an IAM role**，它会在 **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** 中有一个 token，并且可以通过类似下面的方式 **assume the role and get credentials**：
```bash
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
{{#ref}}
../aws-basic-information/aws-federation-abuse.md
@@ -86,9 +85,13 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/
### IAM Roles Anywhere Privesc
AWS IAM RolesAnywhere 允许位于 AWS 之外的工作负载使用 X.509 证书来 assume IAM roles。但当 trust policies 未被正确限定时，它们可能被滥用以实现 privilege escalation。
AWS IAM RolesAnywhere 允许 AWS 之外的工作负载使用 X.509 证书来假设 IAM 角色。但当 trust policies（信任策略）未正确限定作用范围时，可能会被滥用以进行权限提升。
该 policy 缺乏对允许的 trust anchor 或 certificate attributes 的限制。因此，任何绑定到账户中任意 trust anchor 的证书都可以用来 assume this role。
要理解此类攻击，需要解释什么是 trust anchor（信任锚）。AWS IAM RolesAnywhere 中的 trust anchor 是信任根实体，它包含在账户中注册的 Certificate Authority (CA) 的公钥证书，以便 AWS 能验证所提供的 X.509 证书。这样，如果客户端证书是由该 CA 签发且该 trust anchor 处于激活状态，AWS 会将其识别为有效。
另外，profile 是一项配置，用来定义 X.509 证书的哪些属性（例如 CN、OU 或 SAN）会被转换为 session tags（会话标签），这些标签随后会与 trust policy（信任策略）的条件进行比较。
该策略未对允许使用的 trust anchor 或证书属性作出限制。因此，任何与账户中任意 trust anchor 关联的证书都可以用来假设该角色。
```json
{
"Version": "2012-10-17",
@@ -110,7 +113,7 @@ AWS IAM RolesAnywhere 允许位于 AWS 之外的工作负载使用 X.509 证书
```
要进行 privesc，需要从 https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html 获取 `aws_signing_helper`
然后，使用有效的证书，attacker 可以 pivot 到更高权限的角色。
然后使用有效的证书，攻击者可以 pivot 到更高权限的角色
```bash
aws_signing_helper credential-process \
--certificate readonly.pem \
@@ -119,13 +122,13 @@ aws_signing_helper credential-process \
--profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
--role-arn arn:aws:iam::123456789012:role/Admin
```
信任锚验证客户端证书 `readonly.pem` 是否来自其授权的 CA，在创建信任锚时包含了该 CA 的公钥证书（现在用于验证 `readonly.pem`）。`readonly.pem` 内包含公钥，AWS 使用它来验证签名是否由对应的私钥 `readonly.key` 所生成。
信任锚验证客户端的 `readonly.pem` 证书是否来自其授权的 CA，并且在该 `readonly.pem` 证书中包含了公钥，AWS 使用该公钥来验证签名是否由对应的私钥 `readonly.key` 所生成。
该证书还证明了身份，并提供属性（例如 CN 或 OU），`default` 配置文件将这些属性转换为标签（tags），角色的信任策略可以使用这些标签来决定是否授权访问；如果信任策略中没有条件，则这些标签会被忽略，任何拥有有效证书的人都将被允许通过。
证书还提供属性（例如 CN 或 OU），`default` profile 会将这些属性转换为标签，角色的信任策略可以使用这些标签来决定是否授权访问。如果信任策略中没有条件，这些标签就没有用处，任何拥有有效证书的人都会被授予访问权限。
要使此攻击成为可能，信任锚和 `default` 配置文件都必须处于启用状态。
要使此攻击成为可能，信任锚和 `default` profile 必须同时处于活动状态。
### 参考资料
### References
- [https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation](https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation)