今天跟我一起来涨姿势,深入了解一下AWS S3访问控制机制
导语:近日,美国最大的无线通信公司Verizon遭遇了一次大规模的数据泄露事件,导致超过1.4亿的美国用户个人信息暴露在网上,事后调查才知道Verizon的这些数据存储在一个不受保护的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),你将可以看到在<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
发表评论