回归最本质的信息安全

今天跟我一起来涨姿势,深入了解一下AWS S3访问控制机制

2017年7月17日发布

25,075
0
9

导语:近日,美国最大的无线通信公司Verizon遭遇了一次大规模的数据泄露事件,导致超过1.4亿的美国用户个人信息暴露在网上,事后调查才知道Verizon的这些数据存储在一个不受保护的AWS S3云服务器上。

69283011ly1fd9i7wzv50j20dn07ljsj.jpg

前言

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

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

9-161001160325.jpg

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的提示:

1.jpg

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设置:

2.jpg

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

3.jpg

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

READ_ACP

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

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

加图.jpg

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

写入

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

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

45.jpg

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

67.jpg

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

WRITE_ACP

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

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

首先,不能访问READ_ACP或WRITE:

8.jpg

然后我尝试更改bucket ACL:

9.jpg

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

9.2.png

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

10.jpg

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

1112.jpg

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

1314.jpg

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

1.改变bucketACL:

15.jpg

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

16.jpg

3.再次修改对象的ACP:

17.jpg

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

1819.jpg

最终显示如下:

20.jpg

但是,你仍然可以删除对象上的所有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代码模拟此场景的情况:

21.jpg

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

22.jpg

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

23.jpg

通过对比以上两种情况,可以知道,我永远不能修改内容,只能对内容进行确认。不过这种情况仅在对象的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:

24.jpg

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

25.1.jpg

25.2.jpg

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

26.jpg

你应该进行的测试如下:

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.健康跟踪

27.png

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

在某些情况下,虽然使用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,以便更改文件上的访问控制:

28.png

译者注: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

本文翻译自:https://labs.detectify.com/2017/07/13/a-deep-dive-into-aws-s3-access-controls-taking-full-control-over-your-assets/ ,如若转载,请注明来源于嘶吼: http://www.4hou.com/technology/6649.html

点赞 9
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

luochicun

luochicun

这个人很懒,什么也没留下

发私信

发表评论