警钟长鸣：S3存储桶数据泄露情况研究

声明：本文内容仅供合法教学及研究使用，不得将相关知识、技术应用于非法活动！

一、S3存储桶概述

存储桶(Bucket)是对象的载体，可理解为存放对象的“容器”，且该“容器”无容量上限、对象以扁平化结构存放在存储桶中，无文件夹和目录的概念，用户可选择将对象存放到单个或多个存储桶中[1]。由于存储桶具有扩展性高、存储速度快、访问权限可自由配置等优势，如今已纳入各大公有云厂商的关键基础设施中。

Amazon作为全球最大的公有云厂商，其所提供的S3存储桶服务正在被许多租户所使用。公有云租户可根据自身业务需求，定制化地租用S3服务并为S3配置合适的访问权限，供相关人员进行数据存储与共享。但正是这一款广受欢迎的对象存储服务，近年来却屡屡曝出数据泄露事件。那么，究竟是什么原因引发了S3存储桶的数据泄露事件呢？S3存储桶的数据泄露问题如今是否仍然存在呢？本文将对S3存储桶的数据泄露事件进行分析，并通过实验进一步验证说明当下S3存储桶存在的数据泄露问题。

二、S3存储桶数据泄露事件

接下来，让我们坐上时光列车，一起来看一下近几年发生的S3存储桶数据泄露事件。如表1所示。

表1 近五年S3存储桶数据泄露事件示例

在表1所展示的12个数据泄露事件中，可以发现有10个事件涉及到的S3存储桶是公开访问的。这意味着，只要在浏览器中输入了正确的域名，世界上任何人都可以访问这些数据；另外，有一个事件涉及的存储桶被设置为允许任何AWS登录用户访问，这看起来似乎比公开访问更安全些，但事实上，任何人都能够免费注册AWS，因此这样配置的存储桶安全性并不高；最后，一个医疗数据泄露事件的相关存储桶竟然被设置为任何人均可读写，这是不可想象的。

既然大部分的数据泄露事件是由存储桶被配置为公开访问导致的，那我们不妨从S3的访问权限配置机制出发，来看一下S3存储桶的数据泄露事件是何种原因导致的。

首先从图1中可以看到，在S3存储桶创建过程中，系统有明确的权限配置环节，且默认替用户勾选了“阻止全部公共访问权限”选项。

接下来，若要将存储桶设为公开访问，先要在“阻止公共访问权限”标签页中取消对“阻止公共访问权限”的选中状态，然后进入“访问控制列表”标签页设置“公有访问权限”，允许所有人“列出对象”，“读取存储桶权限”。而且每设置一步，都会有风险提示。具体流程如图2所示。

而且，就算存储桶被设置为公开访问，还需要设置存储桶内文件的权限。由此看来，Amazon在安全控制方面做得还是不错的，但是为什么还会不断有数据泄露事件发生呢？

图1 S3存储桶访问权限说明

图2 开启存储桶公共访问流程示意图

有研究者指出[2]，虽然Amazon已经做了不错的安全控制，但问题的核心在于，有时完全弄清楚某个存储桶的公开程度是不容易的——虽然已经限制了存储桶级别的权限，但是桶内文件的访问权限覆盖了存储桶本身的限制。另外，随着时间的推移，用户添加的访问策略可能会越来越复杂，甚至有时出于特殊需要打开了访问限制，却忘记了关闭。

总之，S3存储桶数据泄露风险的主要原因是人为错误配置导致的某些存储桶中的某些敏感信息被公开。

三、S3存储桶访问测试实验

通过上一节的介绍，想必大家对S3存储桶发生的数据泄露事件及其主要原因已经有所了解。那么本节将通过对S3存储桶进行访问测试实验进一步说明S3存储桶的数据泄露问题。

从前文的信息中我们可以知道，通过输入正确的访问域名可以获取到S3存储桶中允许被公开访问的数据，那么构建出正确的访问域名便是进行访问测试的第一步。从Amazon官方给出的信息来看，S3存储桶的一种访问域名形式为https://<bucket-name>.s3.<region>.amazonaws.com/<key-name>[3]。在这种域名形式下，变量主要有三个，分别为存储桶名bucket-name，存储桶所在区域region(可省略)以及文件路径key-name。笔者对几家公有云厂商存储桶进行了访问测试，与S3存储桶类似，Microsoft Azure的Blob以及阿里云的OSS访问路径中的变量也为上述三者。但不同的是，在对AmazonS3存储桶进行访问时，若是一级域名正确，则会返回存储桶内的文件信息，如图3所示。此后，根据返回的存储桶内文件信息，将域名进行拼接，则可获取存储桶内文件，如图4所示。此外，当域名中的region信息错误时，访问后还会返回正确的region信息，如图5所示。

图3 通过一级域名获取文件信息示意图

图4 拼接文件名获取可访问文件示意图

图5 填写错误Region后返回正确Region信息示意图

综上，Amazon S3存储桶的访问域名变量可缩减到一个——存储桶名(bucket-name)。

既然S3存储桶的访问域名变量可缩减到一个，那么访问域名的生成问题则可以转化为存储桶名的构建问题。根据AWS的官方规定，S3存储桶的bucket-name是由小写字母、数字、句号(.)以及连字符(-)组成的3-63位的字符串[4]。全部遍历需要约39^63次，显然无法实现。那么便需要对存储桶的命名规律进行分析，以构建合适的bucket-name。

根据创建存储桶时的命名习惯，可以做出如下推论：

1. 对于某组织或企业的存储桶，一般会以组织或企业名、简称或包含上述信息的字符作为bucket-name；
2. 对于某组织或企业下的某产品或某项目，一般会以产品名、项目名、产品或项目名与组织名的拼接或包含上述信息的字符作为bucket-name；
3. 对于某个人用户，一般会以个人姓名、昵称或包含上述信息的字符作为bucket-name。

基于上述推论，笔者对Yago数据集[5]进行了分析处理，提取出与上述推论相关联的信息，最终筛选整合出7131个字符作为bucket-name进行域名访问测试。笔者利用了开源项目S3scanner[6]作为测试扫描器，测试过程如图6所示。

图6 通过数据分析批量获取存储桶域名

经过访问测试，最终从7131个bucket-name命中到3482个存活存储桶。在这3482个存活存储桶中，有268个是可以公开访问的，其中还有13个的公开访问权限被设置为FullControl，可公开访问的存储桶数量约占访问测试总次数的3.7%。此次测试只使用了Yago数据集中的一部分字符，其他符合推论条件的字符约有28万，从比例预估能够获得10000个可以公开访问的存储桶。

四、S3存储桶敏感信息发现

正常情况下，存储桶所有者在给某一文件配置为可以公开获取的前提是所有者期望其他人去访问这些信息且其中不包含敏感信息。但实际情况是这样么？

笔者对已经发现的268个可以公开访问的存储桶中的数据进行了统计分析，具体信息如表2所示。

表2 可公开访问存储桶数据类型统计表

进一步地，各个类型的数据分布如图7所示。

图7 可公开访问存储桶数据类型分布图

另外，从目前发现的97569个存储桶数据中，仍有37389个数据文件是不可访问的，另外60180个数据文件可以公开访问。

从表2和图8的信息中可以看出，大部分用户使用S3来存储图像，而这些图像大多是Web界面的图像组件和企业的宣传海报以及Logo。可见S3是一个相对便利的可进行宣传和信息共享的平台。此外，Web界面、视频以及音频类型的文件也大多是令用户浏览以及企业宣传使用。因此，笔者将重点关注对象放在了文档文件中，以验证其中是否存在敏感信息泄露的情况。

值得注意的是，已经获取的可以公开访问的文档文件中包含一些非公开信息。其中，有一个包含某企业某部门员工姓名、所在地以及个人邮箱的csv文档，整个文档中共有将近500条该企业员工的个人信息，如图8所示。此外，我们还发现了一个某企业私有的项目需求文档，如图9所示。

图8 某企业某部门员工信息

图9 某企业私有项目文档

五、总结

总的来说，S3存储桶数据泄露事件主要是人为错误配置导致的。而从最后我们发现的两项敏感信息来看，访问权限的错误配置导致的数据泄露问题如今仍在时刻发生着。那么针对S3存储桶数据泄露的防护策略可从两个方向入手，一方面需要加强存储桶运维人员的安全意识，从源头上避免访问权限错误配置的情况发生，另一方面则需要有效的数据安全评估工具，当存储桶有数据泄露的情况发生时，可以及时地进行发现并锁定敏感信息。

参考文献

[1]https://github.com/tencentyun/qcloud-documents/blob/master/product

[2]https://www.helpnetsecurity.com/2019/09/23/s3-bucket-security/

[3]https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/userguide/VirtualHosting.html#virtual-hosted-style-access

[4]https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html

[5]https://yago-knowledge.org/

[6]https://github.com/sa7mon/S3Scanner