在AWS中，将支持MFA的IAM用户与IAM角色链接起来，以实现潜在的权限升级
概述
在AWS中，sts:AssumeRole是 AWS 安全令牌服务中的一项操作，通过一组临时安全凭证，您可以使用它们来访问您通常无法访问的 AWS 资源。例如，角色 A 可以代入角色 B，然后使用角色 B 的权限访问 AWS 资源。
多个sts:AssumeRole调用可以把角色链接到一起。如果角色 A 可以带入角色 B，而角色 B 可以带入角色 C，则有权访问角色 A 的人可以通过调用sts:AssumeRole角色链接一起获得角色 C 的权限。对攻击者来说，这是一条可以利用来提升权限的途径；对于企业安全团队来说，这恰好是经常忽略的地方。
在这篇文中，我们将讨论一种特定的角色链接路径，该路径从具有 MFA 的 IAM 用户开始。在研究此权限提升路径时，Praetorian 注意到与 sts:GetSessionToken 和 Policy Simulator 相关的文档和权限不一致，并将这些情况报告给 AWS Security。
由于与 AWS 文档和策略模拟器的不一致，AWS 客户可能会错误配置安全控制并忽略 AWS IAM 用户，但这些用户却可以通过角色链来提升权限。
时间线
2022 年 5 月
Praetorian 向 AWS Security 报告了这些问题。
2022 年 5 月
AWS 更新了文档以阐明 sts:GetSessionToken。
已计划
AWS 计划为 sts:GetSessionToken 和 sts:GetCallerIdentity 更新 IAM 策略模拟器。
复现过程
AWS 和 MFA
AWS 建议配置多重身份验证(MFA) 以帮助保护 AWS 资源。在 AWS 中，安全团队可以为 IAM 用户或 AWS 账户根用户启用 MFA。
下图为AWS中的MFA提示：
验证IAM 用户的 MFA
AWS IAM 策略支持多种 MFA 条件，包括：
- aws:MultiFactorAuthPresent 存在
- aws:MultiFactorAuthAge 持续时间
这些 MFA 条件验证 AWS API 和 CLI 操作上是否存在 MFA。在这个角色链的例子中，这些条件适用于几个地方：
- 直接基于 IAM 用户的权限。下图显示了一个示例 IAM 策略片段(需要对用户权限进行 MFA 的源代码)：
- 在 sts:AssumeRole 调用期间检查角色的信任策略。有关示例信任策略，请参见下图：
临时安全凭证与长期凭证
AWS 进行身份验证可能会产生临时安全凭证或长期凭证，AWS 中使用的凭证类型对 MFA 有影响，即：AWS 将 MFA 保护设计为仅适用于临时安全凭证，此外，受 MFA 保护的 API 访问不能与 AWS 账户根用户凭证或 U2F 安全密钥一起使用。
对于IAM用户，IAM的密钥Access Key 和 Secret Access Key 是长期凭证，没有可用的 aws:MultiFactorAuthPresent 条件密钥。但是，在使用 AWS 管理控制台时，AWS会为IAM用户生成临时安全凭证，因此aws:MultiFactorAuthPresent的condition key是可用的。
但是，当使用AWS CLI或API与IAM的Access Key 和 Secret Access Key一起使用时，由于Access Key 和 Secret Access Key是长期凭证，所以aws:MultiFactorAuthPresent的condition key 不会出现在请求中。在这种情况下，用户必须再次调用以生成临时凭证。
获取 IAM 用户的临时安全凭证
在 AWS 中，有两种不同的方法来生成临时安全凭证。
- sts:GetSessionToken
注意：stsGetSessionToken 与sts:GetCallerIdentity类似，其中调用无法由 IAM 策略控制。这意味着sts:GetSessionToken不能主动拒绝，只要调用形式正确，IAM用户总是能够调用sts:GetSessionToken。
- sts:AssumeRole
因此，如果已为 IAM 用户设置了 MFA，那么我们可以通过以下两个过程之一将角色链接到具有 MFA 的 IAM 用户：
- 使用用户的Access Key 和 Secret Access Key。
- 使用相应的 MFA 设备和代码调用 sts:GetSessionToken。
- 使用上述命令中的凭据将 sts:AssumeRole 转换为角色 B。
- 使用上述命令中的凭据将 sts:AssumeRole 转换为角色 C。
对比官方文档不一致处
Praetorian 注意到 AWS 文档中关于 sts:GetSessionToken 的使用和权限模型的文档不一致（如下图所示）。这可能会导致部署团队误解和错误配置 sts:GetSessionToken 权限。
另一个突出的例子是有关 IAM 策略如何与 sts:GetCallerIdentity 交互的注释，这是另一个无法由 IAM 策略控制的 sts 调用（如下图所示）
Praetorian 与 AWS 合作，在 sts:GetSessionToken 文档中添加了类似的注释（如下图所示）。
AWS 策略模拟器
Praetorian 经常使用 AWS 策略模拟器来测试和验证 IAM 权限。在验证 sts:GetSessionToken 和 sts:AssumeRole 的使用时，Praetorian 注意到由于 sts:GetSessionToken 的文档不一致以及没有附加的 IAM 策略可以明确拒绝它的方式，将具有 MFA 的 IAM 用户链接到多个角色的能力可能是被误解和错误配置。
此外，Praetorian 注意到将 IAM 策略模拟器用于 sts:GetSessionToken 和 sts:GetCallerIdentity 的结果不一致。两者的 IAM 策略模拟器结果取决于传递给模拟器的 IAM 策略（参见下图），但它们都应始终返回权限允许结果。AWS 正在努力为 sts:GetCallerIdentity 和 sts:GetSessionToken 修复 IAM 策略模拟器。
上图展示为：sts:GetSessionToken 和 sts:GetCallerIdentity 的权限结果不正确。
结论
Praetorian 和AWS都建议从 IAM 用户和长期凭证转向 IAM 角色和其他短期凭证。如果组织必须使用 IAM 用户，Praetorian 建议确保修复角色链和其他权限提升路径。
