我连同PoC一起发送给了Facebook,收到的回复却是说涉及到的这些内部主机系统都是用来发送外部请求的,而且不能复现SSRF漏洞。我KAO。竟然漏洞无效。
后来,过了几天,我发现Facebook已经悄悄修复了其中的blind SSRF漏洞,而且之前的wikiScrapper任务方法调用已经无法利用了。我觉得这似乎不太公平,于是乎向Facebook安全团队发函质询:
Facebook在给我的回复中声称,这不是它们的刻意修复,估计是其它不相关漏洞的连带修复,或组件更新导致的。
太不幸了,是吧。
SSRF重现($30000)
继续经过几天的研究后,我终于发现了另外一个Blind SSRF漏洞。从MicroStrategy web SDK中,我确认这是一个SSRF漏洞,在“com.microstrategy.web.app.utils.usher”类的源代码中,我发现处理“serverURL”参数的方法“validateServerURL” 会向用户输入的URL链接发送一个GET请求。
我用Burp Collaborator URL替换了请求链接中 “serverURL”后,得到的服务端响应如下:
很快,Burp Collaborator服务端就收到了来自Facebook请求的响应,响应中包含请求发起端的Facebook内部IP地址信息。SSRF无疑了。
终于让Facebook安全团队如愿了,综合利用该漏洞同样可导致内部敏感信息泄露,他们也回复称漏洞可以复现,此处收获的赏金为$30000,WOW:
另一个SSRF($500)
接着,我想测试MicroStrategy演示门户网站中是否存在SSRF漏洞,又发现基于SSRF方式,请求MicroStrategy的AWS元数据API,可以从MicroStrategy服务端读取一些敏感信息,如以下SSRF请求链接后得到的响应信息:
之后,我立马上报给了MicroStrategy安全团队,再次收获了$500的赏金。
总结
原谅我写这么一篇writeup长文,目的在于让大家真正理解我的发现过程和思路。我综合利用代码审计、特定值枚举和脚本技巧最终发现了高危漏洞。当时我想构造发现Facebook的RCE漏洞,但他们的安全措施很到位。不管怎样,这三个漏洞让我收获了$31500 ($1,000 + $30,000 + $500) 的奖励,相当值得。