针对 Qubole 客户的供应链攻击

一个被盗的供应商密钥，每个客户的数据都被暴露：Qubole 供应链攻击内部第三方妥协如何创建进入多个组织的路径，以及 Sentra 如何在不到 24 小时内发现它。 Asaf Rozali 和 Riva Kranz Sentra 最近与 Sagy Drucker 合着，发现了一次非常广泛的供应链攻击，该攻击在一个又一个组织中蔓延。数十名 Qubole 客户受到影响。攻击者掌握了大数据平台 Qubole 的凭据，并使用一家又一家公司曾经授予 Qubole 的访问权限来悄悄提取他们的数据。没有人直接闯入这些公司。攻击者是通过他们都信任的供应商进来的。这种风险很容易被忽视。您的云充满了非人的身份：供应商集成、自动化和人工智能代理，每个身份都拥有对您的数据的长期访问权限。大多数时候，他们在同一个地方、按照同样的时间表做同样的事情。危险在于其中一个人开始做其他事情的那一天，而很少有团队会关注这一点。其中风险最大的是你忘记的那些。您曾经连接到云的每个供应商都留下了一扇门。大多数这些门仍然存在，值得信赖，很少被监视，并且通常能够访问您最敏感的数据。 Sentra 发现了该活动并向 Wiz 报告，Wiz 与 Sentra 和 Mandiant 一起对此进行了调查。 Wiz 发布了完整的研究：默认信任：Qubole 跨帐户访问在野外被滥用。这篇文章不是一家公司的故事。这就是我们在袭击中看到的情况：攻击者如何进入，他们如何移动，他们追寻什么，以及最终出卖他们的东西。攻击概览 十多个组织在一次攻击中遭到黑客攻击，所有攻击都是通过他们曾经授予 Qubole 的访问权限进行的。大约需要一秒钟的时间来承担每个 Qubole 信任的角色，因此攻击者几乎可以立即从一家公司转移到下一家公司。 7 分钟内从三个不同的存储位置读取了大约 100 个密码和密钥，以及攻击者下载的文件中的数千条凭据记录。 0 次写入操作。没有任何内容被更改或删除，只是被盗，这使得人们更难注意到。被遗忘的供应商信任 攻击者使用的门是旧门。在公司停止使用 Qubole 很久之后，Qubole 角色仍然存在，并且这些角色几乎可以读取攻击者追踪的所有数据。自春季以来，库博勒的角色一直处于休眠状态。然后他们又复活了。 Sentra 预见到了这种风险的到来。在攻击之前，它已经将 Qubole 的一个角色标记为数月未使用，但仍然能够访问敏感数据。有效的凭据，错误的网络 受到此次攻击的组织并非粗心大意。他们按照 AWS 推荐的方式设置 Qubole 集成，包括一项名为“ExternalId”的附加检查，这是供应商在进入之前必须提供的代码。每个 Qubole 角色都有它，攻击者每次都会提供正确的代码。据 AWS 所知，攻击者是 Qubole。所有活动都不是来自 Qubole 自己的网络。这一切都来自租用的 OVH 服务器和 Mulvad VPN，并且该窗口中根本没有正常的 Qubole 活动。每个会话都是攻击者。这就是供应链攻击如此危险的原因。当受信任的供应商受到威胁时，遵循最佳实践是不够的，因为攻击者的访问是真实的，并且在每个日志中看起来都是合法的。只有两件事阻止了它。零信任限制每个供应商只能获取其真正需要的数据，因此被盗的密钥会尽可能少地打开。数据检测和响应 (DDR) 会监视每个身份实际如何使用数据，并在受信任的身份开始表现得像攻击者时进行标记。在这次攻击中，访问看起来是有效的。行为却没有。静静地测试，然后横扫攻击者慢慢开始。他们在一个低价值的 Qubole 角色上测试了被盗的凭据，安静地环顾四周，并首次窃取了数千个客户配置文件。然后他们动作很快。几分钟之内，他们就进入了 Qubole 信任的每个角色，并开始在接下来的几天里在后台运行批量下载。最后一次从不同的 VPN 地址提取生产数据库备份。然后活动就停止了。信任仍然存在，因此攻击者保持安静而不会失去访问权限。攻击者如何窃取凭证仅仅窃取数据还不够。我们看到攻击者使用多种不同的技术来窃取凭证，从而打开更多大门：从 Secrets Manager 中批量提取机密：源代码控制、身份提供商、CI 和数据库凭证，甚至供应商自己的令牌和ExternalId。从 SSM 参数存储中读取解密参数，包括监控和扫描器代理密钥。收集 Lambda 环境变量，当第一个路由被阻止时切换到第二个路由。抓取 EC2 用户数据、令牌和密码经常隐藏的启动脚本。我们如何追踪它 第一个 j