在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 建議確保修復角色鏈和其他權限提升路徑。
