From a353a8b3b0f553266bf3255f1ba0bc1c83339850 Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 30 Sep 2025 19:16:33 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat --- .../aws-sts-privesc.md | 45 ++++++++++--------- 1 file changed, 24 insertions(+), 21 deletions(-) diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md index 6ff63c3fc..209abdaa9 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md @@ -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 --principal-arn ``` -但 **提供商** 可能有他们 **自己的工具** 来使这更容易，比如 [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-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)