S3 勒索软件概述

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

方法 # 3: 在你的账户中记录和监控活动

你应该始终在你的帐户中启用 AWS CloudTrail。 理想情况下，CloudTrail 应该覆盖所有账户的所有区域，记录读写管理事件，记录 S3 存储桶 和 Lambda 函数的数据事件，启用日志文件加密，并启用日志文件验证。

根据你的预算，记录帐户中每个存储桶的数据事件可能并不总是有意义的，因为如果经常访问这些事件，那么它们可能会变得相当耗费资金成本。 如果你没有为每个存储桶记录数据事件，那么记录的存储桶包含敏感内容是非常重要的。 通过这种方式，你可以查看谁在访问你的数据、他们如何访问数据以及他们从哪里访问数据的细粒度详细信息。

Cloudtrail 中的日志文件验证可以帮助确保你的日志文件在读取之前不会被修改，因此你可以100% 信任正在查看的内容。 启用验证是非常重要的，但是要确保实际验证的确是你的日志(使用类似于"aws cloudtrail validate-logs"之类的命令) ，因为即使启用了设置，你也不会收到日志修改的警告。

除了 CloudTrail 之外，还应该启用像 AWS GuardDuty 这样的工具来监视帐户内的恶意活动。 这些警报以及你的 CloudTrail 日志应该被导出到外部的 SIEM，以便进一步检查和监视。

如果你使用 AWS 组织，你应该在组织级别启用 CloudTrail 和 GuardDuty 并将它们应用于你的子帐户。 这样，子帐户中的攻击者就不能修改或禁用任何重要设置。

根据你的预算和其他因素，可以考虑为其他资源启用其他类型的日志和监视工具。 这可能包括像弹性负载均衡器（Elastic Load Balancer）访问日志或基于主机的 EC2实例日志之类的东西，或者可能启用像 AWS Inspector 或 AWS Config 之类的东西。

方法 # 4: S3对象版本控制和 MFA 删除

这可能是针对 S3勒索软件防御的最重要的方法，但可能非常昂贵的防御方法。 S3 对象版本控制允许 S3对象被"版本化"，这意味着如果一个文件被修改，那么两个副本都作为一种"历史"保存在存储桶中。 如果上传的文件与存储桶中已经存在的文件名相同，也会发生同样的情况。 这里的一个示例场景是一个存储 CloudTrail 日志的存储桶版本。 如果攻击者修改了一个日志文件以删除他们活动的痕迹，那么防御者可以比较文件的旧版本和当前版本，以确切地看到攻击者删除了什么。

S3对象版本控制本身是不够的，因为理论上，攻击者可以禁用版本控制并覆盖或删除存储桶中的任何现有版本，而不用担心会创建新的版本。 为了解决这个问题，AWS 提供了 S3 存储桶中的双重身份验证删除功能。启用 MFA 删除功能将迫使 MFA 被用来做以下两件事中的一件:

1. 更改指定 S3存储桶的版本控制状态(即禁用版本控制)。

2. 永久删除对象版本。

如果版本控制和 MFA 删除都在存储桶上启用，那就意味着攻击者需要拿到 root 用户及其 MFA 设备来禁用版本控制和 MFA 删除。 这在理论上是可能的，但在实践中是不太可能的。

方法 # 5: 存储桶策略和 ACL

眼下的当务之急是不要让公众接触到你的存储桶。 可以通过各种不同的方式公开访问存储桶及存储桶中的对象，造成这种风险最常见的罪魁祸首是存储桶 ACL 或存储桶策略。

在大多数情况下，你应该完全避免使用存储桶 ACL，但有时由于几个不同的原因，这是不可能的。 这是一种管理访问存储桶的旧的"托管"方式，它不允许细粒度的访问控制。 如果你授权某人访问 ACL 中的"List 对象"，他们可以在单个 API 调用中获得 存储桶 中所有对象的列表，并可以读取这些文件中的任何文件。 如果你授予某人访问 ACL 中的"写对象"的权限，这意味着他们可以在存储桶中创建、覆盖和删除对象。 这两点足以成为避免使用 ACL 的理由。

你应该使用存储桶策略而不是 ACL，因为它允许最细粒度的权限管理。 你可以只授予 ACL 中的两个权限中的一个，而不是授予用户列表和读权限。 你甚至可以实施进一步的限制，例如只对存储桶中的少数对象进行读访问。 例如，如果你的网站直接从你的 存储桶 中读取 S3对象，那么它不需要列出 存储桶 中的每个对象的权限，因为它应该已经知道它正在取什么。 在这种情况下，你可以在 存储桶 策略中授予它"s3: GetObject"，而不是在列表中授予它，并在 ACL 中读取它。 与通过 ACL 授予创建或覆盖和删除对象权限不同，你可以授予其中一个权限并施加进一步的限制，如上所述。

S3 存储桶 策略的另一个特性是，它们能够实施特定类型的加密。 这方面的例子是强制所有上传的文件使用 AES256进行加密，或者强制所有上传的文件使用特定的 AWS KMS 密钥进行加密。 这可以用来防止 S3勒索软件，因为理想情况下，攻击者无权修改存储桶的策略。

你可以设置你的存储桶策略，只允许上传使用你的特定 KMS 秘钥加密的对象。 在这种情况下，攻击者将不能使用你在策略中没有指定的另一个 KMS 密钥，这对于勒索该存储桶是必要的。 然后他们会得到一个拒绝访问的错误消息，最终防止了攻击。

下面是一个 S3 存储桶 策略的例子，它强制必须使用一个特定的 KMS 密钥对文件进行加密后才能上传:

{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Principal":"*","Action":"s3:PutObject","Resource":["arn:aws:s3:::my-bucket-name\/*","arn:aws:s3:::my-bucket-name"],"Condition":{"StringNotEquals":{"s3:x-amz-server-side-encryption-aws-kms-key-id":"arn:aws:kms:REGION:ACCOUNT-ID:key\/KEY-ID"}}}]}

关于 S3操作、资源和条件密钥的更多信息可以在这里找到。

方法 # 6: 帐户范围内的 S3 公共访问设置

如果你担心你的开发人员可能会向你的存储桶提供公共可访问性，那么你可以利用帐户范围的选项来阻止公共 ACL 和公共策略生效。 请注意，这适用于你帐户中的每个存储桶，如果你依赖于对帐户中特定存储桶的跨帐户或公共访问，则可能会导致问题。

如果你可以验证针对你的所有存储桶的公共访问的阻止配置是正确的，那么你应该考虑为你的帐户启用帐户范围的 S3公共访问设置。

上面的屏幕截图显示了 AWS Web 控制台中某个示例帐户的公共访问设置。 在本例中，所有现有的公共存储桶 ACL 和所有现有的公共存储桶策略都将被阻止，这意味着由于这个更高层级的公共访问设置，它们实际上不会授予公共访问权限。 此外，新的 ACL 和授予公共访问权限的策略也将被阻止。

方法 # 7: 备份

最后，当然，你需要备份你的数据！ 无论是使用 MFA 版本化的存储桶、跨存储桶或帐户复制数据，还是甚至是本地复制数据，这都是非常重要的事情。 有了充分备份的数据，你就可以忽略攻击者(当然是在事件响应计划付诸实施之后) ，并恢复备份，然后就像从未得到勒索攻击一样。

从一次成功的勒索软件攻击中恢复数据

如果你已经成为 S3勒索软件攻击的目标，你如何应对很可能取决于几个不同的因素。 AWS 安全部门意识到了这种攻击载体的风险，但尚不确定他们在帮助你的过程中能发挥什么作用——如果有帮助的话。 如果你能接受这些额外的时间成本，那么最好的办法就是联系有关部门，尽管这样的拖延对你的公司来说可能成本太高了。 出于这个原因，最好是能够对这种攻击实施强有力的防御，这样你就不会陷入需要权衡你的潜在选择和面临的风险的局面。

事件响应计划

如果你已经成为攻击目标，那么第一步就是制定你的事件响应计划。 这样做可以降低攻击者的“爆炸半径”，让他们远离你的环境，并确定他们已经获得的数据和攻击影响。 这就是为什么在AWS 环境中配置日志记录和监视是必不可少的原因之一。 了解攻击者访问了什么，将有助于你确定下一步需要做什么。

检查存储桶配置的脚本

我们编写了一个脚本，可以检查 AWS 帐户中所有存储桶的重要设置。 这包括检查每个存储桶上的对象版本控制和 MFA 删除。 你可以在我们的 GitHub 上找到这个脚本。 它还有一个选项，可以为任何尚未启用它的存储桶启用对象版本控制。

这个屏幕截图显示了针对一个易受攻击的 AWS 帐户运行脚本的一些示例输出。

当打开输出结果的 CSV 文件时，你将看到类似下面的屏幕截图(S3存储桶名称已被打码) :

在运行这个脚本时需要注意一些参数:

-p 或 --profile: 用于 AWS 身份认证的 AWS CLI 配置文件 (~/.aws/credentials).
-b 或 --buckets: 要检查的以逗号分隔的 S3存储桶列表。这些存储桶应是你拥有或至少可公开访问。如果未提供此参数，则将检查帐户中的所有存储桶。
-e 或 --enable-versioning: 如果传递了该参数，脚本会将尝试启用状态为禁用或挂起（disabled 或 suspended）的存储桶的版本控制。注意，脚本将不会尝试启用 MFA 删除功能，因此该操作需要 AWS root 用户权限能启用。

下面的屏幕截图显示了激活版本控制参数的使用情况(S3 存储桶名称再次被打码)。

CSV 文件的结果会显示任何已成功启用其版本控制的 存储桶。 如果脚本无法启用版本控制(例如因为权限错误之类的原因) ，它将移动到下一个存储桶，并用其原始版本控制的设置选项("Disabled"或"Suspended")对检查失败的存储桶进行标记。

总结

S3勒索软件对于攻击者来说可以相当直接且简单地执行，但是防御者可以设置各种简单和困难的防御机制。 在最低级别上，对于防御者来说，在一个 S3存储桶上启用版本控制和删除 MFA 是很简单的方法，这在大多数情况下可以有效地防止勒索软件。

在 AWS 环境和敏感的 S3存储桶中实现防御机制非常重要。 虽然可能没有必要执行上面讲到的每个方法，但必须确定哪些攻击载体和入口点最容易受到影响，因此需要进行防护。

虽然上面讲到的方法在帮助防止用户被 S3勒索软件攻击方面非常有用，但总是还有更多的防御或检测方法。 我们鼓励任何读者与我们联系，讨论其他的想法，这样我们可以把他们的想法添加到这篇文章中(这归功于你) ，并与其他人分享他们试图保护自己的环境。