今天跟我一起来涨姿势，深入了解一下AWS S3访问控制机制
前言
近日，美国最大的无线通信公司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），你将可以看到在
如果你已经找到一个指向一个存储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