关于云计算:存储桶上传策略和签名-URL的绕过及利用

7次阅读

共计 5580 个字符，预计需要花费 14 分钟才能阅读完成。

本文中带有本人一些高见，读者若存在相干问题或者有其余想法的，欢送在评论区交换探讨。原文：https://labs.detectify.com/20…

存储桶上传策略是一种间接从客户端将数据上传到存储桶的便捷形式。通过上传策略中的规定和与某些文件拜访场景相干的逻辑，咱们如何越权拜访到残缺的存储桶对象列表，同时可能批改或删除存储桶中的现有文件。

（如果你曾经晓得什么是桶策略和签名 URL，你能够间接跳到上面的利用章节）

存储桶策略旨在将内容间接上传到基于云的存储桶存储（如 Google Cloud Storage 或 AWS S3）的平安形式。管理者只须要创立一个定义容许和不容许的策略，而后应用密钥对策略进行签名，并将策略和签名提供给客户端，接着客户端能够间接将文件上传到存储桶，存储桶将验证上传的内容是否合乎策略。如果合乎，则文件将被上传。

在开始之前，咱们须要明确一点，有多种办法能够拜访存储桶中的对象。POST 策略 (AWS）和 POST 对象 (Google Cloud Storage) 办法只容许上传内容，应用 POST 申请到存储桶。

另一种称为预签名 URL (AWS) 或签名 URL (Google Cloud Storage) 的办法不仅容许批改对象。依据预签名逻辑定义的 HTTP 办法，咱们能够 PUT、DELETE 或 GET 对象，这些对象默认为公有。

与 POST 策略版本相比，预签名 URL 在定义内容类型、访问控制以及相似上传文件方面更为宽松。签名 URL 也更常常应用不欠缺的自定义逻辑来实现，如下所示：

还有更多容许某人拜访上传内容的办法，一种是相似于 POST 策略的 AWS STS AssumeRoleWithWebIdentity，不同之处在于您能够获取由预约义的 IAM 角色创立的长期平安凭证 (ASIA *)。

这是应用 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 文件的，那么咱们能够在存储桶中内联地提供它。如果在策略中基本没有定义它，则文件是内联的。

starts-with $key 为空
```
["starts-with", "$key", ""]
```
这样配置不是很平安。咱们当初可能上传到存储桶中的任何地位，并且可能笼罩任何对象。您能够将 key-property 设置为任何内容，并且该策略将被承受。

留神：
在某些状况下，这一点的可利用性依然很艰难，例如，存储桶仅用于上传名为 UUID（通用惟一标识符）的对象，这些对象从未公开或进一步应用。在这种状况下，咱们不晓得要笼罩哪些文件，也无奈晓得存储桶中其余对象的名称。

starts-with $key 不蕴含门路分隔符或对所有用户应用雷同的门路。
```
["starts-with", "$key", "acc_1322342m3423"]
```
如果 $key 策略的 -part 蕴含定义的局部，但没有门路分隔符，咱们能够将内容间接放在存储桶的根目录中。如果 Access=Yes 并且 Inline=Yes 取决于 content-type，咱们能够通过装置 AppCache-manifest 来窃取其余用户上传的 URL 来滥用它。

如果对象上传到的门路对所有用户都雷同，则同样的问题也实用。

starts-with $Content-Type 为空
```
["starts-with", "$Content-Type", ""]
```

如果 Access=Yes 和 Inline=Yes 时，咱们能够上传 text/html。如 #2 所示，咱们能够应用它来运行 javascript 或在此门路上装置 AppCache-manifest，这意味着在此门路下拜访的所有文件都将泄露给攻击者。

内容类型定义应用 starts-with $Content-Type.
```
["starts-with", "$Content-Type", "image/jpeg"]
```
这实际上与 #3 雷同，咱们能够减少一些内容使得 content-type 成为一个未知的 mime-type，而后加上 text/html，文件将被以 text/html 的模式存储，如下所示：
```
Content-type: image/jpegz;text/html
```
此外，如果 S3 存储桶托管在公司的子域上，通过滥用上述策略，咱们还能够通过上传的 HTML 文件在域上运行歹意的 javascript 代码。

最乏味的局部是利用在沙盒域上上传内容的网站。

签名的 URL 是在服务器端签名并提供给客户端，以容许他们上传、批改或拜访内容。最容易呈现问题的状况是当网站建设自定义逻辑来检索它们。

要首先理解如何滥用签名 URL，重要的是要晓得默认状况下，可能通过一个签名的 GET-URL 到桶的根部，便可显示桶的文件列表。这就像应用一个公开的可列表的桶被曝光一样，不同的是，这个桶必定蕴含其余用户的私人数据。

请记住，当咱们晓得存储桶中的其余文件时，咱们也能够为它们申请以获取到签名的 URL，此时将容许咱们拜访相干公有文件。

所以，咱们的指标始终是尝试进入根目录或其余咱们晓得存在的文件。

上面是一些示例：收回签名的 GET-URL 在不经意间裸露了存储桶的根门路。

应用 get-image- 终端节点对残缺的桶进行齐全的读取拜访。
如下申请：
```
https://freehand.example.com/api/get-image?key=abc&document=xyz
```
提供以下签名 URL：
```
https://prodapp.s3.amazonaws.com/documents/648475/images/abc?X-Amz-Algorithm=AWS4-HMAC-SHA256...
```
然而，终端节点在签订前对 URL 进行了规范化解决，故咱们可通过应用目录穿梭，探测桶的根目录。
```
https://freehand.example.com/api/get-image?key=../../../&document=xyz
```
和第一个链接进行比照，能够揣测出与之对应的签名 URL 如下：
```
https://prodapp.s3.amazonaws.com/?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIA...
```
成果：这个 URL 给出了存储桶中每个文件的列表。
对签名 URL 申请进行正则表达式解析，实现全读拜访

这是另一个示例，向网站上的终端节点收回以下申请，以获取对应的签名 URL：

POST /api/file_service/file_upload_policies/s3_url_signature.json HTTP/1.1
Host: sectest.example.com

{"url":"https://example-bucket.s3.amazonaws.com/dir/file.png"}

上述申请将会解析 URL 并将它的一部分提取到签名的 URL 中，响应包如下：

{“signedUrl”：“https://s3.amazonaws.com/example-bucket/dir/file.png?X-Amz-Algorithm=AWS4-HMAC...”}

能够应用 s3.amazonaws.com 上的子域和门路拜访 S3 存储桶，在这种状况下，能够揣测出服务器端的逻辑是：将 URL 更改为基于门路的存储桶 URL 的形式。

根据上述对 URL 的提取地位的剖析，能够对其进行结构，如下所示：

{"url":"https://.x./example-bucket"}

此时返回带签名的 URL 如下，该 URL 将显示存储桶的残缺文件列表：

{"signedURL" : "https://s3.amazonaws.com//example-beta?X-Amz-Algorithm=AWS4-HMAC..."}

浅浅解析一下：依据提取法则：会提取申请包 URL 中的 http:// 后的一位，此时咱们结构的 URL 中为空，进行拼接后，便会呈现 //example-beta?X-Amz-Algorithm=AWS4-HMAC… 的状况啦~

滥用长期签名 URL 链接

这个例子来自两年前，我发现的第一个与签名 URL 相干的问题。

在网站上，当上传文件时，你首先在 secure.example.com 上创立一个随机密钥。

POST /api/s3_file/ HTTP/1.1
Host: secure.example.com

{"id":null,"random_key":"abc-123-def-456-ghi-789","s3_key":"/file.jpg","uploader_id":71957,"employee_id":null}

响应包如下：

HTTP/1.1 201 CREATED

{"employee_id":null, "s3_key": "/file.jpg", "uploader_id": 71957, "random_key":"abc-123-def-456-ghi-789", "id": null}

对应生成的 URL 为：

https://secure.example.com/files/abc-123-def-456-ghi-789

将会跳转到如下链接：

Location: https://example.s3.amazonaws.com/file.jpg?Signature=i0YZ...

测试时，能够尝试在原申请包上批改 s3_key，如下所示：

“random_key”：“xx1234”，“s3_key”：“/”

此时对应生成的 URL 为：

https://secure.example.com/files/xx1234

同理，将重定向到如下链接：

Location: https://example.s3.amazonaws.com/?Signature=i0YZ...

我当初有了他们存储桶的文件列表。该网站应用一个存储桶存储所有数据，其中蕴含他们领有的每个文档和文件。当我尝试提取文件列表以显示公司时，存储桶十分宏大，数以百万计的文件。我间接将谬误发送给了公司，他们很快进行了响应：

应该为每个文件上传申请或至多为每个用户专门生成一个上传策略。

$key 应该齐全定义，具备惟一的、随机生成的名称并在随机生成的门路内。
content-disposition 最好定义 attachment 为。
acl 最好是 private 或基本不定义。
content-type 应该明确设置（不应用 starts-with）或基本不设置。

而且，创立签名 URL 永远不应该基于用户的参数，正如您在下面看到的那样，这很大概率存在破绽。

我见过的最蹩脚的状况是：

https://secure.example.com/api/file_upload_policies/multipart_signature?to_sign=GET%0A%0A%0A%0Ax-amz-date%3AFri%2C%2009%20Mar%202018%2000%3A11%3A28%20GMT%0A%2Fbucket-name%2F&datetime=Fri,%2009%20Mar%202018%2000:11:28%20GMT

当依照要求发送申请时，响应包返回的签名是能够用于申请所有资源的签名。

0zfAa9zIBlXH76rTitXXXuhEyJI=

此时便能够随心所欲，用如下形式去获取你想要申请的所有资源

curl -H "Authorization: AWS AKIAJAXXPZR2XXX7ZXXX:0zfAa9zIBlXH76rTitXXXuhEyJI=" -H "x-amz-date: Fri, 09 Mar 2018 00:11:28 GMT" https://s3.amazonaws.com/bucket-name/

本文首发于前线 Zone：https://zone.huoxian.cn/d/126…

作者：樱宁

正文完