前言

近日，美国最大的无线通信公司Verizon遭遇了一次大规模的数据泄露事件，导致超过1.4亿的美国用户个人信息暴露在网上。事后调查才知道Verizon的这些数据存储在一个不受保护的AWS S3云服务器上，任何人都可以访问并且下载这些数据。详情请点击这里。

如果你还不了解对AWS S3的保护有多重要，那小编就告诉你，如果有人控制了你的AWS S3，那你所有的网络资料都将被人盗取。怎么样，就问你怕不怕？

AWS S3的访问控制设置由多个级别组成，每级都有自己独特的错误配置风险。下文，我将详细介绍每个级别的细节，并确定弱ACL可以创建易受影响的配置，从而对使用S3-bucket的个人和组织的网络安全造成影响。另外，我还会在本文介绍如何正确监控这些影响所造成的破坏。

译者注：bucket是S3对数据的管理单元，一个bucket类似于一组数据的根目录。

AWS S3的介绍

S3是 AWS 最早发布的诸多服务之一，用作可信存储。所谓可信，AWS给出的概念是，在指定年度内为对象提供 99.999999999% 的持久性和高达 99.99% 的可用性，换句话说就是任何存储于S3的数据基本不可能丢失，在一个年度内，不超过1小时（3153.6s）的宕机时间。

AWS S3会有一个存储容器接口，存储容器称为“bucket”，bucket内的文件称为“objects”。 S3为每个bucket提供无限存储的空间，用户可以这些bucket来存放文件。可以通过个人（通过签名的URL）或通过适当配置的ACL（访问控制列表）或ACP（访问控制策略）公开存放文件。

另外， Amazon CloudFront还提供了一种全球内容分发网络 (CDN) 服务，可以安全地以低延迟和高传输速度向浏览者分发数据、视频、应用程序和 API。CloudFront可与 AWS 相互集成，不仅可以与直接连接到 AWS 全球基础设施的物理站点集成，也可以与多种 AWS 服务（包括S3）无缝协作软件集成，以便用户快速地从S3储存文件或对象

AWS S3的漏洞

最近有研究人员提到了用于S3存储的bucket配置错误可能会暴露敏感数据，并解释了其中的原因可能是S3访问控制列表（ACL）与AWS中常规用户权限设置有很大不同，这些设置称为识别访问管理(IAM)。

不过，本文决定从另外一个角度来解释这个问题。通过识别一些不同的配置错误，我发现由于bucket和对象ACL的配置很弱，可以控制，监控和破坏高端网站（high end website）。

测试声明

我不建议在未经事先批准的情况下测试下列任何易受攻击的情况，这在识别漏洞的唯一方法是实际覆盖文件和配置的情况下尤其重要。但是，我发现了一种可以用来检测其中一个易受攻击的设置方法，而无需实际修改数据。

测试技术细节

每种配置和其影响取决于以下标准：

1.谁拥有S3bucket

2.使用什么域向bucket上传文件

3.bucket中有什么类型的文件

我将尝试通过以下所描述的不同情况，来具体解释何时可以创建易受攻击的配置错误。

识别bucket

一开始，我需要能够识别拥有或使用的bucket的公司，另外还需要特定bucket的名称才能对bucket进行签名请求。

识别一个存储bucket取决于设置，以及如何访问存储bucket的方式，比如有可以直接转到S3的请求，也有CloudFront或任何其他来自bucket的CDN代理服务文件，还可以利用S3静态网站托管等。

识别S3-bucket的一些方法：

1.看看AmazonS3的服务器头的HTTP响应。

2.看一个不存在的随机URL，看看它是否给你一个S3-404，或者是禁用静态网站的提示，或者是访问被拒绝或NoSuchKey的提示：

3.如果主机直接指向S3，则该域的DNS条目可能会直接显示bucket名称。

4.尝试访问根URL，如果启用了索引列表（Bucket ACL上的public READ），你将可以看到在<Name> -element中定义的bucket名称。

如果你已经找到一个指向一个存储bucket但无法获取存储bucket名称的域名，请尝试使用实际的完全限定域名（FQDN）作为存储bucket名称，这是一个常见的设置。

如果这不行，请尝试以下方法：

1.搜索域名，查看其历史记录是否暴露了bucket名称。

2.查看bucket中的对象的响应头，看看它们是否具有显示存储bucket名称的元数据。

3.看看内容，看看它是否涉及任何一个bucket。利用这些方法，我已经看到过资料被标记为bucket名称和部署日期的实例。

4.使用Brute-Force算法，不要试图在S3上用几千个请求来找到一个bucket。能否找到bucket，具体取决于指向它的域的名称以及存储bucket的实际原因。如果该bucket包含域media.acme.edu上ACME的音频文件，请尝试使用media.acme.edu，acme-edu-media，acme-audio或acme-media。

如果$ bucket.s3.amazonaws.com上的响应显示NoSuchBucket，则表示该bucket不存在。如果存在bucket，则显示的响应应该是ListBucketResult或AccessDenied。

不过要注意的是，找到的bucket并不一定是对应的公司，你还要尝试直接从公司的官网查找其相关资料进行核对。

权限组或预定义组

首先，我将用不同的方式来探讨可用于访问bucket的请求者和对象。

用户名或电子邮件地址

你可以使用AWS用户ID或其电子邮件地址访问AWS内的单个用户，如果你希望允许单个用户具有对该存储bucket的特定访问权限，那么这招很管用。

AuthenticatedUsers

这可能是AWS S3的ACL中最被误解的一个预定义组。将ACL设置为AuthenticatedUsers基本上意味着只要到计算机验证你的身份合法，你就会有一个有效的AWS凭证，即登录请求的所有AWS帐户都在该组内。请求者根本不需要拥有与bucket或对象的AWS帐户有任何关系。记住，“认证”与“授权”不一样。

全部用户

当设置此授权时，请求者甚至不需要进行认证请求来读取或写入任何数据，任何人都可以根据配置的策略对PUT请求进行修改或GET请求下载对象。

政策许可或访问控制策略

可以在存储bucket或bucket中的对象上设置以下策略权限。

bucket和对象上的ACP控制S3的不同部分，AWS有一个功能表单，显示了每个部分的具体功能。你可以在其中为bucket创建特定的IAM策略，称为bucket策略（bucket-policy）。虽然创建bucket策略也存在一定的漏洞，但是，我只是用它来涵盖在bucket和对象上设置的ACL的标准设置。

读取

此权限允许读取内容，如果这个ACP设置在一个bucket上，请求者可以列出bucket中的文件。如果ACP设置在对象上，则可以由请求者检索内容。

即使在完整的存储bucket中未设置对象访问读取，读取仍然可以在bucket中的特定对象上工作。

在AWS S3中进行以下ACL设置：

我仍然可以看到具体的对象：

这意味着每个对象的读取可以是不同的，与bucket上的设置无关。

READ_ACP

此权限允许读取bucket或对象的访问控制列表，如果启用此功能，你可以在不尝试修改内容或ACP的情况下识别易受攻击的资料。

即使在完整的存储bucket中未设置对象访问READ_ACP，READ_ACP仍然可以在bucket中的特定对象上工作。

这意味着每个对象的READ_ACP可以不同，与bucket上的设置无关。

写入

此权限允许写入内容，如果bucket已为用户或组启用此功能，则就可以上传，修改和创建新文件。

如果整个存储bucket中未设置对象访问写入，写入将无法在bucket中的特定对象上运行：

但是，如果写入设置在存储bucket中，则所有对象都将遵循，并且无法单独决定是否可写入：

这意味着，写入可以通过两种方式在bucket上进行验证，无论是通过上传随机文件，还是修改现有文件。不过修改现有文件是破坏性的，建议不要使用。下面我将介绍一种检查方法，该方法可以不用进行破坏性调用，通过触发访问控制检查和文件的实际修改之间的错误。

WRITE_ACP

此权限允许修改bucket或对象的权限ACL。

如果bucket中有一个用户或一个组启用，那么就可以修改bucket的ACL，其实这是非常糟糕的。在bucket上具有WRITE_ACP将完全暴露出由具有ACP集合的一方控制，这意味着任何对象的任何内容现在都可以由该方控制。虽然攻击者可能无法读取bucket中已有的每个对象，但仍可以完全修改现有对象。此外，S3-bucket的原始所有者在新的AWS S3控制台中的访问会被拒绝，当攻击者在删除bucket上的读取访问权时会同时声称拥有该AWS存储。

首先，不能访问READ_ACP或WRITE：

然后我尝试更改bucket ACL：

bucket的初始所有者现在可以看到，不过作为使用者，他们仍然可以修改bucket的策略，这是一个奇怪的情况：

现在我就可以控制一切了：

一个非常有趣的事情是，即使是在完整的数据bucket中未设置对象访问WRITE_ACP，WRITE_ACP仍然可以在bucket中的特定对象上工作：

此外，与此相反的写入则适用于在bucket上使用WRITE_ACP，但这并不意味着你可以直接在对象上拥有WRITE_ACP：

但是，通过在bucket上的WRITE_ACP执行以下步骤，你仍然可以通过用新内容替换现有对象，获得对所有对象内容的完全访问权限，：

1.改变bucketACL：

2.修改对象，这会将你更改为对象的所有者：

3.再次修改对象的ACP：

由于写入仍然需要在bucket上设置，因此无法在对象上升级WRITE_ACP，以便在同一个对象上获取本身的WRITE：

最终显示如下：

但是，你仍然可以删除对象上的所有ACP，使对象完全隐藏，这将阻止它被发送，同时给出一个403 Forbidden提示。

译者注：403 Forbidden 是HTTP协议中的一个状态码(Status Code)，可以简单的理解为没有权限访问此站。

不过，WRITE_ACP只能通过在bucket或对象上写入新的ACP来进行验证。修改现有的当然是破坏性的，但目前为止，我还没有发现一种非破坏性的测试方法。

FULL_CONTROL

这是结合所有其他方法的一种政策。但是，即使在对象上设置了此权限，除非存储bucket已设置，否则写入仍然无法正常工作。

易受攻击的情况

以下是公司受到AWS S3攻击的情况：

一、在公司所有的域名上使用的bucket

如果你发现一个由公司的子域或域服务的bucket，你应该进行以下测试：

1.1BUCKET READ

在bucket中列出文件，敏感信息可能会暴露出来。

1.2 BUCKET READ-ACP

来看看ACP，看看是否可以在无需测试的情况下，识别出容易受到攻击的垃圾bucket。如果能看到AllUsers或AuthenticatedUsers设置了WRITE_ACP，就知道是否可以完全控制bucket。

1.3BUCKET WRITE（模拟使用无效的MD5被黑的情况）

如果我可以将新文件上传到存储bucket，就代表我可以覆盖bucket中的任何对象。但是，如果想避免上传任何东西，可以尝试以下被黑的几种情况：

当对bucket进行签名的PUT请求时，我可以选择添加一个Content-MD5来告知AWS正在上传内容的校验和。事实证明，这个检查正在以下流程中进行：

1.3.1检查用户是否存取写入文件的权限。

1.3.2检查MD5校验和是否与内容匹配。

1.3.3上传文件。

由于校验和控制发生在访问该文件之后，所以我不需要写入文件。

以下是用bash代码模拟此场景的情况：

我可以上传到一个bucket的情况，这将导致：

我不可以上传到一个bucket的情况，这将导致：

通过对比以上两种情况，可以知道，我永远不能修改内容，只能对内容进行确认。不过这种情况仅在对象的WRITE上有效，而不是在WRITE_ACP上。

BUCKET WRITE-ACP

这是最危险的一个漏洞，黑客会完全升级到bucket的完全访问权限。所以要对其进行了解的唯一方法是首先弄清楚bucket的工作原理，不过前提是不会破坏任何当前的ACP。不过要注意的是，即使你无法访问READ_ACP，你仍然可以访问WRITE_ACP。

对象读取

我可以尝试读取由BUCKET READ发现的我感兴趣的文件的内容。

对象写入

不需要测试这个，因为BUCKET WRITE可以完全自我决定。如果BUCKET WRITE给出的是错误的结果，则对象不可写入，而且如果BUCKET WRITE成功，则该对象将始终可写入。

但是，如果使用存储bucket的公司有用户可以上传文件的应用程序，可以查看如何实现将实际文件上传到S3。如果公司正在使用POST策略上传，请特别查看$key和Content-type条件匹配中的策略。根据是否使用启动，你可以将内容类型修改为HTML / XML / SVG或类似内容，或更改正在上传的文件的位置。

OBJECT WRITE-ACP

我可以尝试修改特定对象的ACP，这样就不会修改内容，而只能修改文件的访问控制，使我能够停止文件的公开。

可能的漏洞

1.Reflected XSS(反射跨站脚本攻击)，如果我可以实现BUCKET读取，就可以找出其中的资料，并可能会发现易受攻击的对象，例如在公司域名上提供的脆弱的SWF。

2.Stored XSS(存储式XSS漏洞)或资料控制漏洞，如果我可以运行BUCKET写入或BUCKET WRITE-ACP，我可以修改现有内容或创建新内容，从而进一步修改javascript/css文件或上传新的HTML文件。

3.窃听拒绝服务(Denial of Server)漏洞，如果我可以使用OBJECT WRITE-ACP修改对象的ACP，我可以防止对象被公开加载。

4.信息披露（Information Disclosure）漏洞，如果我可以列出对象，很可能会找到敏感信息。

5.RCE漏洞，如果存储bucket包含可修改的可执行文件，这可能会导致远程执行代码（RCE）漏洞，具体取决于可执行文件的使用位置，以及是否被下载。

二、公司使用的bucket资料

有些项目试图自动化，如Second Order。但是，Second Order仅检查HTTP响应中引用的资料，动态加载的文件将不在被检查的范围之内。以下是使用Headless Chrome检查动态加载资料的快速示例。

首先，在端口9222上启动headless模式下的Chrome：

然后我可以使用一个小脚本（context.js是从HAR-capturer项目借来的）。

根据页面上的所有资料，我可以使用它们来确定是否在利用S3提供服务：

你应该进行的测试如下：

BUCKET READ-ACP

BUCKET WRITE

BUCKET WRITE-ACP

OBJECT WRITE-ACP

可能的漏洞：

1.Stored XSS(存储式XSS漏洞)或资料控制漏洞，如果我可以运行BUCKET写入或BUCKET WRITE-ACP，则可以修改现有的内容或创建新的内容，从而修改javascript / css文件或类似的内容。这取决于使用资料的位置，例如登录页面或主页面。

2.窃听拒绝服务(Denial of Server)漏洞，如果我可以使用OBJECT WRITE-ACP修改对象的ACP，则可以防止对象被公开加载。

3.RCE漏洞。如果资料是可修改的可执行文件，则可能会导致远程执行代码（RCE），具体取决于可执行文件的使用位置，以及是否被下载。

三、如果bucket被随机发现，则代表是公司在使用

这个解释起来有点复杂，你需要有明确的证据证明该bucket确实属于公司所有。尝试从公司找到指向此bucket的各种引用，例如其网站上的引用，CI日志或开源代码。

你应该进行的测试如下：

BUCKET READ

BUCKET READ-ACP

BUCKET WRITE 

BUCKET WRITE-ACP

OBJECT WRITE-ACP

可能的漏洞：

1.Stored XSS(存储式XSS漏洞)或资料控制漏洞，如果我可以运行BUCKET写入或BUCKET WRITE-ACP，就可以修改现有的内容或创建新的内容，从而修改javascript / css文件。不过此时，我并不知道文件在哪里被使用，也就不知道对公司的影响有多大。

2.窃听拒绝服务(Denial of Server)漏洞，如果我可以使用OBJECT WRITE-ACP修改对象的ACP，就可以防止对象被公开加载。

3信息披露（Information Disclosure）漏洞，如果我可以列出对象，就可能会找到敏感信息。只有当你确认bucket确实连接到你已获得的公司时，才能执行此操作。

4. RCE漏洞，如果存储bucket包含可修改的可执行文件，这可能会导致远程执行代码（RCE），具体取决于可执行文件的使用位置，以及是否/被下载。

测试结果

在本文的测试研究中，我可以确认的是我能够控制高知名度的网站（high profile website）上的资料。

我发现以下类别的网站都受到了AWS S3攻击的影响：

1.密码管理员

2.DNS/CDN提供商

3.文件存储

4.赌博

5.音视频流提供商

6.健康跟踪

我确定了一些公司登录页面上确实存在一些易受攻击的资料。

在某些情况下，虽然使用Google代码管理器（gtm.js）加载了易受攻击的资料，但是他们没有正确地进行沙箱分析，而是直接在域名上运行第三方资料（不使用www.googletagmanager.com沙箱）。

为此，我直接与一些第三方提供商联系，但也得到受影响公司的帮助，以便他们可以迅速识别此问题并解决。

如何防止AWS S3的攻击

1.对第三方资料进行沙盒验证，一旦你需要第三方资料，就可以通过gtm.js，尝试使用由Google跟踪代码管理器提供的iframe或将其放置在单独的域上来隔离脚本。同时，你的提供商还要知道如何处理其文件的访问控制，以及如果使用S3进行文件服务。

2.如果你有自己的bucket，请查看bucketACL以验证WRITE和WRITE_ACP是否仅在特定用户上设置，而从不在诸如AllUsers或AuthenticatedUsers之类的组中。

3.防止任何bucket中的任何对象拥有WRITE_ACP，通过使用受限的AWS用户对你的bucket中的对象执行适当的设置，来测试自己的aws s3api put-object-acl，你可能需要更新每个对象上的ACL以完全缓解这一问题。

4.看看如何将对象上传到S3bucket，并确保在两个bucket和对象上设置适当的ACL。

5.不要使用秘密bucket名作为安全性的一种形式，因为处理Bucket_name就像已经是公开了。

总结

通过阅读本文，你大概了解了AWS S3访问控制机制中所存在的普遍问题，它们难以识别和彻底解决，特别是如果公司使用了不同系统创建的大量存储bucket。 WRITE_ACP是最为危险的，因为在bucket和对象上都大量存在WRITE_ACP。

使用Cyberduck手动将文件上传到S3，以便更改文件上的访问控制：

译者注：cyberduck是一个开放源代码的ftp及sftp客户端，只需要在IP或IT上安装openssh协议就可以将mac系统的电脑和移动设备联接起来。

应该进行哪类检测扫描

检测Web应用程序可以对以下S3错误配置漏洞进行测试，严重性范围在CVSS级别的4.4-9之间：

Amazon S3 bucket允许完全匿名访问

Amazon S3 bucket允许任意文件列表

Amazon S3 bucket允许任意文件上传和曝光

Amazon S3 bucket允许盲目上传

Amazon S3 bucket允许任意读取或写入对象

Amazon S3存储bucket显示为ACP / ACL