攻击向量简介

通过我们的云安全研究，我们在犀牛安全实验室（Rhino Security Lab）开发出了一个概念验证的”云勒索软件"，该勒索软件使用 KMS 加密亚马逊 S3存储桶内的 AWS 帐户对象。 攻击者利用这个勒索软件获得对受害者系统的访问控制权限，并对受害者系统上的敏感数据进行加密。 与此同时，攻击者还会威胁受害者，告知受害者，如果受害者不在某一时限内付款，就会删除或公开发布数据。 通常，这些攻击的目标是服务器、工作站和类似的设置，但与许多攻击一样，这种攻击也有"云等效"的性质。

S3勒索软件是非常具有破坏性的，我们的研究和博客文章并不打算以任何方式协助攻击者实施攻击。 由于这个原因，本博客只发布一个缓慢的概念验证脚本，因此辩护者可以测试他们的防御。 对于防御者和蓝队，我们在这篇文章的第二部分中讨论了如何防止和防御 S3勒索软件。

亚马逊 S3 和 AWS KMS

对于那些不熟悉 Amazon S3 的用户来说，你们可以将 Amazon Simple Storage Service (简称 Amazon S3)理解为是一种通过 Amazon Web Services 提供的一个健壮的静态文件托管服务。 亚马逊表示，S3可以用于"存储和保护任何数量的数据，用于一系列用例，如网站、移动应用程序、备份和恢复、存档、企业应用程序、物联网设备和大数据分析"。 在较高的级别上，S3由"桶（bucket）"和"对象（objects）"组成，其中对象是存储在桶中的文件。

AWS 密钥管理服务(AWS KMS)本质上是 AWS 提供的一种托管加密密钥服务。 亚马逊将其定义为一种服务,"使你可以轻松地创建和管理密钥，并在各种 AWS 服务和应用程序中控制加密的使用"。

S3 存储桶

S3 bucket 不会自动在服务端进行加密，这意味着在没有配置的情况下，所有文件都将以明文形式存储在 亚马逊的服务器上。 Bucket 可以有一个"默认"的加密设置，当某个人试图上传一个没有加密的文件时，这个设置可以用作回滚机制。 在这种情况下，默认的加密方法将生效，并确保文件没有以明文的形式存储在服务器上。

S3 存储对象

单个对象也可以与存储桶上的"默认"加密分开加密，除非在存储桶的策略中强制执行。 这意味着，如果在 存储桶上设置了默认加密方法(或者根本没有) ，文件的上传工具可以决定在上传时如何加密文件，这将覆盖 存储桶 的默认设置。

KMS 加密

AWS KMS 与 S3对象加密集成在一起，因为你可以指定一个特定的 KMS 密钥来加密存储桶中的对象。 在这种情况下，试图在 S3中查看文件的用户既需要特定的 S3对象的"S3: GetObject"权限，也需要特定的 KMS 密钥的"KMS: Decrypt"权限。 正确实施 KMS 密钥策略可以阻止攻击者读取 S3中的敏感文件。 如果攻击者升级了他们的访问权限并获得了"S3: GetObject"权限，他们仍然可能无法读取 S3中的文件，因为他们没有正确的 KMS 密钥的解密权限。

KMS 密钥也可以使用交叉帐户，因此，如果攻击者获得了对你的 S3 存储桶的访问权限，他们可以使用只为你提供"加密"权限的交叉帐户的 KMS 密钥对你的存储对象进行加密。 因为你不能控制用于加密文件的 KMS 密钥，这意味着你无法查看自己的文件。

攻击路径

作为这项研究的一部分，我们编写了一个针对 S3存储桶和对象执行勒索软件攻击的高级工具。 该工具可以处理目标环境中的各种选项和配置，并且是专门为提高速度而编写的。 然而，因为我们的研究和发表博客文章的目的不是在协助攻击者，因此，我们将不会发布该攻击工具。 相反，你可以在下面的"测试你的存储桶"部分中找到一个测试脚本，该脚本旨在帮助防御者和蓝队防范这种攻击。

攻击步骤

1. 攻击者创建一个 KMS 密钥在他们自己的"个人"AWS 帐户(或其他被黑掉的帐户) ，并提供”公开"访问权限，之后使用该 KMS 密钥进行加密。 这意味着任何 AWS 用户 / 角色 / 帐户都可以使用它进行加密，但是不能解密 S3 存储桶中的对象。

2. 攻击者确定一个 S3 存储桶作为攻击目标并获得对它的写操作访问权限，通过各种不同的手段是可以做到的。 这可能包括利用已经公开曝光的配置不当的存储桶 或者攻击者获得对 AWS 环境本身的访问权。通常来说，攻击者会将敏感信息作为攻击目标，比如 PII、 PHI、日志、备份数据等等

3. 攻击者会检查存储桶的配置来确定它是否能成为勒索软件的攻击目标。 检查工作包括检查是否启用了 S3对象版本控制，是否启用了双重身份验证删除(MFA delete)。 如果没有启用对象版本控制，那么它们就可以将该存储桶作为攻击目标。 如果启用了对象版本控制，但禁用了 MFA 删除，则攻击者只能禁用对象版本控制。 如果同时启用了对象版本控制和 MFA 删除，则需要很多额外的工作才能实现对指定存储桶实施勒索软件攻击。

4. 攻击者使用 AWS API 用自身的新副本替换存储桶中的每个对象，注意这里攻击者是使用自己的 KMS 密钥进行了加密。

5. 攻击者定期删除用于这次攻击的 KMS 密钥，给他们的目标设置一个7天的时间窗口，直到密钥被完全删除，那个时候，数据将会永远丢失。

6. 攻击者上传最终文件，例如：未加密的“ransom-note.txt” ，在该文件中告诉受害者如何获取他们自己的文件。 

下面的屏幕截图显示了一个被勒索软件攻击或文件被加密的例子。 如你所见，拥有用于加密对象的 KMS 密钥的帐户 ID (7 * * * * * * * * * * 2)与拥有对象的帐户 ID (2 * * * * * * * * * 1)并不是同一个。

下一个屏幕截图中显示了当对象所有者使用预签名 URL 试图查看对象时发生的事情。 访问被拒绝，因为即使对象所有者拥有查看对象的权限，他们也没有使用 KMS 密钥解密已经被加密的对象的权限，因此系统阻止了对这些已经被加密了的对象的访问。

攻击特征

为了测试这种攻击并查看其可行性，我们对某个 S3存储桶运行了 Rhino 开发的一个内部工具，该存储桶存储了大约2000个不同大小的文件，总共大约100GB 的数据。 勒索软件对整个存储桶实施攻击(加密每一个单独的对象)的过程只需要1分47秒。

常见的 CloudTrail 日志可能需要15分钟才能传递到一个 S3存储桶中，但在测试中发现，CloudTrail S3数据事件日志的传递大约只需要5分钟。 5分钟发送日志比15分钟好得多，但问题是5分钟仍然太长。 我们上面的测试显示，大约2000个文件，总共大约100GB 的数据可以在1分钟47秒内赎回，这远远低于5分钟的限制。 通过跟踪这些数字(理论上——实际结果根据单个文件的大小而略有不同) ，攻击者每秒可以对超过900 MB 的数据执行勒索攻击。 这意味着在5分钟的时间内，他们可以在你有机会看到发生了什么之前，就对大约270GB的数据执行勒索攻击。

接下来要考虑的事情是，一旦你知道发生了什么后，你的反应需要有多快。 例如，从第一次日志传递到攻击者试图勒索你的数据并阻止他们访问你的环境，你可能需要5分钟的时间来采取行动。 基于这一点，攻击开始10分钟后，大约有540GB 的数据已经被加密。 为了给出一些透视图，下面的列表是根据“一个 G 的数据有多大?——来自 iClick”中的数据计算出来的。

540GB 的数据，以常见的文件类型表示如下:

· 3 60,000张 1.5 MB 照片

· 360部1.5 GB 的电影

· 135,0004mb 的歌曲

当然，这只是一个估值，还有许多因素需要考虑，但这只是给出了一个关于540GB 数据实际上是多少的概念。 上面的列表表明，无论你的响应速度有多快，攻击者仍然能够对大量的数据执行勒索软件攻击。 这就是为什么除了实施事件响应计划之外，你还需要尽可能的防御这种攻击，这一点是极其重要的。

S3勒索软件概念证明（PoC）

我们还编写了一个简单的概念验证脚本来演示这种攻击，以便防御者能够测试它，并希望能够围绕它构建检测方案。 此脚本只对禁用了对象版本控制的存储桶有效。

这个脚本可以在我们的 GitHub 上找到，它会执行以下操作:

1. 收集存储桶中的前100个对象(如果存储桶中的对象少于100个，则收集所有对象)

2. 使用新的 KMS 加密密钥一个一个地覆盖每个对象

脚本使用

要使用 PoC 脚本，请修改"aws_cli_profile"、"bucket_name"和"kms_key_arn"的值以匹配你的环境，然后使用 Python 3.6 + 运行该脚本。

变量说明:

· aws_cli_profile：用于 AWS 身份认证的 AWS CLI 配置文件 (~/.aws/credentials).

· bucket_name:目标 S3 存储桶的名称

· kms_key_arn: 用于攻击的 KMS 密钥的 ARN

下面是脚本运行和输出的屏幕截图:

因为你指定了要使用的 KMS 密钥和要使用的 S3存储桶，所以你不应该失去对数据的访问权限(例如，如果一个真正的攻击者在你的 S3存储桶上使用了自己的 KMS 密钥)。 但是要谨慎，不要针对生产环境或重要数据运行此脚本。

结论和防御性控制

勒索软件是一种极具威胁性的攻击载体，近年来变得越来越流行。 攻击者可以在短时间内勒索软件的数据量是非常重要的。 攻击者在持续前进，因此防御者需要领先一步，以防止一些传统的攻击方式变成基于云的攻击。

S3勒索软件对于一个组织来说是非常危险的，但是防御者可以使用各种简单和复杂的防御机制来防止这种攻击。

注意: 这篇文章不仅讨论了针对 S3勒索软件的防御机制，还提到了一些重要的且常见的安全问题，你应该在 AWS 账户中遵循这个原则。

S3 勒索软件概述

正如本博文的前文所阐述的，S3勒索软件是一种可以对公司造成极大影响的攻击。 S3勒索软件是指攻击者能够访问受害者的 S3 存储桶，然后用自身的新副本替换每个对象，但用攻击者的 KMS 密钥进行加密。 受害者将不再能够访问他们自己的 S3对象，需要服从攻击者的要求才能获得这些对象(或者花费额外的时间成本冒着去当局或 AWS 进行事件响应的风险)。

S3勒索软件安全控制

虽然 S3勒索软件对于攻击者来说可以相当直接地执行，但是如果有正确的防御措施，你可以保护自己。 有许多不同的方法来防御和预防 S3勒索软件攻击，下文旨在概述这些不同的方法。

防御及预防攻击的方法

考虑到每种方法本身的成本、努力和影响，在预防和防御 S3勒索软件时，没有某个单一的方法可以作为"防御银弹"。 相反，下面的方法意味着要遵循一系列良好的实践。 并不是每个方法都适用于每个环境，因此理解所有方法并能够选择在自己的环境中实现的最佳方法非常重要。

方法#1: 遵循安全最佳实践来防止对你的帐户的未经授权的访问

这是针对勒索攻击最明显的防御，因为它本质上意味着"不要让未经授权的人进入你的环境"，但这说起来容易做起来难。 对于这种辩护，有很多事情要做，我在这里列出了一些比较重要的事情:

· 让所有用户使用临时的方法，而不是使用长期有效的凭证(使用 IAM 角色而不是 IAM 用户)访问环境

· 在 Git 仓库中创建预接收钩子（点击这里查看更多信息）来监视可能包含预期之外的凭证的提交请求，并在开发人员发布访问密钥或凭证之前拒绝操作。

· 与你的团队一起定期进行网络钓鱼 / 社会工程学攻击培训，教会员工如何识别目标攻击

· 对每个人在任何需要身份认证的地方( AWS Web控制台和 AWS 访问密钥) 执行双重身份验证(MFA)！ 这可以让针对获取了凭证的攻击者(但仍然不是不可能)实际使用这些凭证的门槛更高。

· 如果不能尽可能的强制执行 MFA，可以强制执行长的、复杂的密码，然后强制密码在一个合理的时间间隔内过期，并且不允许重复使用密码。

· 确保对于任何具有 AWS 访问权限的应用程序具有强大的应用程序安全性。 这有助于防止服务端请求伪造(SSRF)攻击 EC2 实例的元数据或利用本地文件读取、远程代码执行漏洞从 AWS CLI 或环境变量读取凭证。

· 定期审计和监视你的帐户和组织内委派的 IAM 访问权限(使用类似Security Monkey  作者: Netflix的工具).

此外，可以考虑阅读这篇关于 AWS 账户是如何被入侵的博文。

方法 #2: 遵循最小权限原则

这种防御方法包括设置你的环境和委派访问权限，以便没有人拥有超过他们应有的访问权限。 这意味着对于任何用户(角色、用户组等) ，他们应该只拥有他们需要使用的 IAM 权限，并且这些权限应该只允许在他们需要使用的资源上使用。

例如，对任何资源("*")授予一个简单的"s3: PutObject"权限可能意味着对你帐户中的每个存储桶进行大规模勒索软件攻击。 通过将资源限制到一个特定的存储桶，比如"arn:aws:s3:::example_bucket"，那么只有那个特定的 存储桶 可以被攻击者作攻击目标。

最小特权原则应该同时应用于 IAM 策略级别和资源策略级别(例如 S3 存储桶策略) ，这样才最有效。