Newshot 黑客利用 Qubole 受信任的 AWS 访问权限入侵客户账户并窃取数据
云安全公司 Wiz 今天表示，一名攻击者在 10 月 14 日至 10 月 26 日期间侵入了属于多个 Qubole 客户的 AWS 账户，并窃取了存储的机密和数据。
攻击者使用了 Qubole 平台用于访问这些客户的一个 AWS 账户的凭证。攻击者如何获得这些凭证尚未披露。
Qubole 是 Idera 旗下的一款数据湖平台，在其客户的 AWS 账户内运行。为了让 Qubole 进入，客户会创建一个 IAM 角色，这是一个拥有自己一组权限的 AWS 身份。
该角色的信任策略允许 Qubole 的 AWS 账户代入该角色，从而授予这些权限。每次执行此操作的请求（称为 AssumeRole）都必须包含 Qubole 提供的匹配代码，即 External ID。
据 Wiz 的研究人员称，除了这次攻击之外，攻击者代入的大多数角色都未被使用。但每个角色仍然信任 Qubole 的账户，因此攻击者的请求得以成功。
任何曾将 Qubole 连接到 AWS 的组织，即使已不再使用它，都应检查其 10 月 1 日之后的 CloudTrail 日志。需要寻找的迹象是来自 Qubole 平台使用的账户 805246085872 的 AssumeRole 请求，且该请求来自 AWS 之外的地址。
研究人员没有说明这些凭证此后是否已被禁用，也没有说明该活动是否已经停止。截至 The Hacker News 今日查看时，Qubole 和 Idera 均未在其网站上发布有关此次攻击的声明。
为什么这些角色让攻击者得以进入
研究人员在其技术分析中表示，与攻击者相关的每个 AssumeRole 请求都带有 External ID，并且都被接受。
当此类角色的 AssumeRole 请求来自受信任账户并包含正确的 External ID 时，AWS 会接受该请求。根据 AWS 关于外部 ID 的指南，该代码不被视为机密，任何有权访问该角色的人都可以查看它。
Sentra 在其多个客户环境中发现了该活动，并向研究人员发出警报。
在研究人员检查的账户中，攻击者寻找存储的凭证。它读取了 Lambda 函数的环境变量，从 Secrets Manager 获取机密，并从 SSM Parameter Store 读取值。
随后，它用 TruffleHog 运行找到的凭证，以测试它们是否有效。这些是受害者自己的 AWS 访问密钥、Entra ID 客户端密钥和 Okta 客户端凭证。
攻击者还从 S3 复制数据。它从角色可访问的任何存储桶中获取数据，而不是搜索特定数据，有时在单次会话中下载整个存储桶。
研究人员未将此次行动与任何其他公开报道的活动联系起来，并表示其目标选择与国家支持的团体通常针对的目标不符。
Qubole 还允许客户使用 AWS 访问密钥而非角色进行连接。10 月 8 日至 10 月 11 日，一名攻击者使用了客户自己的 AWS 访问密钥，研究人员认为这些密钥是为 Qubole 设置的。
该攻击者随后入侵了少数受害者的云环境。该活动尚未与 AssumeRole 滥用行为联系起来。
如何检查你的账户
Wiz 的狩猎指南涵盖每个拥有 Qubole 角色的 AWS 账户中 10 月 1 日之后的 CloudTrail 日志。请查找：
- 账户：userIdentity.accountId 为 805246085872 且 sourceIPAddress 不是 AWS 地址的 AssumeRole 请求。研究人员看到 Qubole 的真实流量仅来自 AWS。
- IAM 主体 ID：AIDA3W7DIFLYOLTK63SFS。应调查来自该 IAM 用户的任何活动，因为在研究人员检查的账户中，只有攻击者使用了它。
黑客利用 Qubole 受信任的 AWS 访问权限入侵客户账户并窃取数据
- IAM principal ID：AIDAJYRRH5Y3A7AAJM2HW，当源地址位于 AWS 之外时。攻击者从 10 月 18 日起使用了该 IAM 用户，但 Qubole 的正常流量也会使用它。
- IP：57.129.54[.]120 和 2001:41d0:70d[:]7800::，攻击者使用的由 OVH 托管的地址。
- IP：45.83.220[.]211、185.209.199[.]73 和 89.37.63[.]175，这些是 Mullvad VPN 地址。其他 VPN 用户也共用这些地址，因此仅凭匹配不能作为证据。
- 会话名称：以 quiam- 开头的角色会话，例如 quiam-enum。
- 用户代理：来自上述某个 IP 地址的 GetCallerIdentity 调用上的 TruffleHog。在身份提供商的登录日志中查找相同的用户代理。
对于每个可疑会话，审查其之后所做的所有操作，尤其是在 Secrets Manager、SSM Parameter Store、Lambda 和 S3 中。
CloudTrail 管理事件会记录每次 AssumeRole 请求和存储桶列出操作，但不会记录读取了哪些 S3 对象。这需要 S3 数据事件或 S3 服务器访问日志。多个受害者缺少所需的日志，因此响应人员无法确定攻击者读取了哪些对象。
如何封堵这条路径
研究人员建议采取以下步骤：
- 如果攻击者代入了你的某个 Qubole 角色，请轮换该角色有权访问的所有机密、参数和 Lambda 环境变量，并撤销该角色的活动会话。轮换凭证不会终止已经签发的会话。
- 删除不再需要的任何 Qubole 角色，或将 Qubole 的账户从其信任策略中移除。
- 在 Qubole 支持的情况下，将信任策略中账户范围的 :root 主体替换为 Qubole 使用的特定 IAM 主体。
- 添加 aws:SourceIp 或 aws:SourceVpce 条件，将 AssumeRole 请求限制为供应商文档中记录的网络范围。研究人员表示，在此次攻击中，“仅凭源 IP 条件就能阻止我们观察到的每一次角色代入。”
- 假设其他人可以看到 External ID。它会以明文记录在 CloudTrail 中，供应商和基础设施即代码文件也经常存储它，因此不要将其作为唯一的控制措施。在此类事件发生后，将其更改为 Qubole，并在可能的情况下为每个角色使用不同的值。
- 审查每个供应商角色可以访问什么。Qubole 的设置指南包含一个示例 S3 策略，该策略允许该角色读取账户中的每个存储桶。研究人员称，为方便起见，供应商角色通常会被授予对 Lambda 设置、Secrets Manager、SSM 参数以及广泛的 S3 读取权限的访问权。
- 为来自供应商账户、经由该供应商此前未使用过的 VPN 或托管公司到达的 AssumeRole 请求设置告警。
- 使用组织跟踪记录每个账户和区域，并为存储敏感数据的存储桶启用 S3 数据事件或服务器访问日志。