Bucket上传策略和URL签名的绕过与利用


本文翻译自: https://labs.detectify.com/2018/08/02/bypassing-exploiting-bucket-upload-policies-signed-urls/


导读

Bucket(存储空间)上传策略是直接从客户端将数据上传到Bucket。通过上传策略中的这些规则以及与访问某些文件的相关逻辑,我们将展示如何爆出所有Bucket对象列表,同时还能够修改或删除Bucket中的文件。

什么是Bucket策略

(如果您已经知道了什么是Bucket策略和URL签名,则可以直接跳到下面利用部分的内容)

Bucket策略是一种将内容直接上传到基于云端的大型存储区(如Google云端存储或AWS S3)的安全方式。我们的想法是创建一个定义有检验是否允许文件上传的策略,随后用密钥对策略进行签名,再将策略和签名发送给客户端。

然后,客户端可以直接将文件上传到Bucket,Bucke存储会验证上传的内容和策略是否匹配,如果匹配,则上传文件。

上传策略 vs URL预签名

在开始之前,我们需要明确指出有多种方法可以访问Bucket中的对象。使用POST请求访问Bucket时,POST策略(AWS)和POST对象 (谷歌云存储)方式只允许上传内容。

另一种称为URL预签名(AWS)或URL签名(Google云端存储)的方式就不仅仅是可以修改对象。我们是否可以PUT,DELETE或GET 默认的私有对象,取决于预签名逻辑定义的HTTP方式。

在定义内容类型(Content-Type),访问控制和文件上传时,URL预签名比POST策略相比会更加宽松。使用错误的自定义逻辑也会更频繁地执行URL签名,如下所示。

有更多允许某人访问上传内容的方法,其中一个是AssumeRoleWithWebIdentity ,类似于POST策略,区别在于您可以获得由预定义的IAM Role(身份和访问管理角色)创建的临时安全凭证(ASIA *)。

如何发现上传策略或URL签名

这是使用POST方法的上传请求,如下所示:

该策略用的是base64编码的JSON,如下所示:

{
 "expiration": "2018-07-31T13:55:50Z",
 "conditions": [
  {"bucket": "bucket-name"},
  ["starts-with", "$key", "acc123"],
  {"acl": "public-read"},
  {"success_action_redirect": "https://dashboard.example.com/"},
  ["starts-with", "$Content-Type", ""],
  ["content-length-range", 0, 524288]
 ]
}

在AWS S3上的类似于下面的URL签名:

https://bucket-name.s3.amazonaws.com/?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIA...

就像谷歌云存储一样:

HTTPS ://storage.googleapis.com/uploads/images/test.png?Expires=1515198382&GoogleAccessId=example%40example.iam.gserviceaccount.com&Signature=dlMA---

上传策略的利用

现在到了有意思的部分!

如果我们想要发现策略中的错误,并充分利用,我们需要定义一些不同的属性:

  • Access = Yes - 在上传后我们是否可以以某种方式访问​​该文件。在策略中ACL是否 被定义为public-read或者能够接收上传文件的URL预签名。在策略中上传但未定义ACL的对象默认为私有。
  • Inline=Yes - 如果您能够修改 content-disposition文件,那么我们可以在内联中提供内容。如果策略中根本没有定义,则文件以内联方式提供。

1. starts-with $key是空的

例:

["starts-with", "$key", ""]

这并不好,我们可以上传文件到Bucket中的任何位置,覆盖任何对象。您可以将key属性设置为任何内容,并且接受该策略。

注意: 在某些情况下,它的可利用性还是很困难,例如,只有一个Bucket用于上传从未公开的或以后会使用的名为UUID(通用唯一标识符)的对象,在这种情况下,我们不知道要覆盖哪些文件,并且无法知道Bucket中其他对象的名称。

点击收藏 | 1 关注 | 1
  • 动动手指,沙发就是你的了!
登录 后跟帖