今天跟我一起来涨姿势,深入了解一下AWS S3访问控制机制 - 嘶吼 RoarTalk – 网络安全行业综合服务平台,4hou.com

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

luochicun 技术 2017-07-17 08:55:01
400911
收藏

导语:近日,美国最大的无线通信公司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

  • 分享至
取消

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

扫码支持

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

发表评论

 
本站4hou.com,所使用的字体和图片文字等素材部分来源于原作者或互联网共享平台。如使用任何字体和图片文字有侵犯其版权所有方的,嘶吼将配合联系原作者核实,并做出删除处理。
©2024 北京嘶吼文化传媒有限公司 京ICP备16063439号-1 本站由 提供云计算服务