去年 11 月，Wiz机构 枚举了亚马逊云中允许从其他账户访问的所有服务，检查是否有任何服务可能无意中暴露客户，并在不同的亚马逊云服务中发现了3个漏洞，允许任何人读取或写入其他亚马逊云客户的账户。

亚马逊云 账户的隔离程度如何？

因此，去年 11 月，我们的研究团队枚举了亚马逊云中允许从其他账户访问的所有服务，以查看是否有任何服务可能会无意中暴露客户。 在短短 10 天的研究中，我们在不同的亚马逊云服务中发现了三个漏洞，允许任何人读取或写入其他亚马逊云客户的账户。

尽管黑客在现实世界中利用此漏洞会很困难，但可以对其他客户帐户执行未经授权的操作这一事实让人吃惊。这是一个新的暴露向量，可能允许黑客从高度安全的环境中泄露数据而不留下痕迹。

我们于 2020 年 11 月向亚马逊报告了这些问题，亚马逊云迅速采取行动解决了这些问题。但是，亚马逊云无法单独修复其中一个漏洞——每个易受攻击的用户都必须更新他们现有的策略。我们的研究表明， 直到今天，超过 90% 的客户仍然容易受到攻击。

此外，我们强烈怀疑更多亚马逊云的服务容易受到此类跨账户漏洞的攻击。

跨账户访问如何工作——以及如何被利用

简单地说，资源策略允许不同的亚马逊云服务相互访问。为什么这很重要？如今，大多数云客户都采用多帐户方法。他们不是在一个云帐户中管理所有操作，而是将活动划分为多个云帐户，每个帐户都有用于特定目的的特定环境。一家公司在亚马逊云中拥有数百或数千个账户是很常见的。为了使其更易于管理，客户授予亚马逊云服务访问权限以跨其多个账户执行操作。

例如，流行的CloudTrail服务允许客户从多个账户收集日志并将它们集中在一个桶中。

当客户对官方亚马逊云服务授予访问权限时，他们完全信任它。在授予亚马逊云CloudTrail对我们的S3存储桶和其他云资源的访问权限之前，我们大多数人都不会三思。因此，我们惊讶地发现，在某些情况下， 亚马逊云服务（CloudTrail、亚马逊云Config和 无服务仓库）可能会被操纵，让任何人都能访问其他客户的特定资源。

漏洞

在CloudTrail和 亚马逊云Config这两个易受攻击的服务中，亚马逊云自动设置的资源策略允许任何人将服务日志写入其他客户账户。以下是易受攻击流程的细分：

1. 黑客在其帐户上配置CloudTrail以将日志写入目标存储桶。所选目标存储桶位于客户帐户中。

2.CloudTrail收集日志并写入客户存储桶，在不知不觉中为黑客服务并代表他行事。

3. 存储桶允许访问，因为CloudTrail受存储桶信任。

最严重的是，这漏洞影响了亚马逊云的无服务存储库，这是一种允许客户存储和部署无服务器应用程序的平台服务。为了正常工作，该服务需要从客户的S3存储桶中提取对象。我们找到了一种利用该服务读取其他客户私有S3存储桶的方法，这些存储桶通常包含敏感信息，如源代码、密码和其他工件。

根本原因

这些漏洞的根本原因是亚马逊云服务可能会被诱骗代表黑客执行操作，并且目标存储桶无条件地信任该服务。

例如，截至去年 11 月，这是 亚马逊云针对S3存储桶的默认资源策略。

它允许名为无服务存储库的亚马逊云服务访问存储桶中的任何对象。问题是，它非常开放。此策略没有任何地方定义或限制谁可以使用该服务从任何给定客户的 S3 存储桶中访问信息。

简而言之，默认的亚马逊云策略是不安全的，黑客可以毫不费力地从一个账户横向到另一个账户，从而造成损害。客户从来没有机会安全地配置他们的资源策略——默认情况下他们是不安全的。

问题解决了……是吗？

值得赞扬的是，亚马逊迅速采取行动修复了漏洞，向策略添加条件,更好地限制基础资源的访问。

但是，亚马逊云 无法自行解决此问题。只有客户自己可以修改和更新他们的资源策略。当需要用户交互时，解决漏洞总是不太有效。在这种情况下，亚马逊通过电子邮件和亚马逊Personal Health Dashboard中的安全通知向易受攻击的用户发送如下所示的警报。

然而，在政策修复 5 个月后，我们对 亚马逊云 环境进行的一项调查显示，超过 90% 的无服务存储的存储桶仍然存在配置不当的漏洞。我们的调查还发现，超过 25% 的环境仍在使用配置错误的CloudTrail策略。

请点一下右下角的“在看”，谢谢！！

请帮忙点赞， 谢谢！！

请帮忙转发，谢谢！！

暗号: 729582