译文声明
本文是翻译文章，原作者 Bipin Jitiya
原文地址：https://medium.com/@win3zz/how-i-made-31500-by-submitting-a-bug-to-facebook-d31bb046e204
译文仅作参考，具体内容表达请见原文

前言

这篇文章讲述了我如何在Facebook资产中找到若干SSRF并为我获得第一份漏洞赏金的故事。

发现过程

在枚举Facebook资产子域名期间，有一个子域https://m-nexus.thefacebook.com/将我重定向到了https://m-nexus.thefacebook.com/servlet/mstrWebAdmin,截图如下：

我迅速使用Google查找关键字mstrWebAdmin，发现这是基于MicroStrtegy工具构建的商业智能门户系统。

我通过一篇blog确认了这一点：

随后，我在MicroStrategy官方手册中，发现有两个可公开访问的数据端点：

• /MicroStrategy/servlet/mstrWeb

• /MicroStrategy/servlet/taskProc

根据其文档描述，默认情况下 /MicroStrategy/servlet/mstrWeb端点启用了基于HTTP Basic 认证，随后我发现/MicroStrategy/servlet/taskProc端点访问时未要求身份认证！
该端点可以基于taskId参数来实现一些自定义数据收集和内容生成的功能，我通过Burp-Intruder模块枚举taskId参数，发现很多参数值虽然达到预期输入但会被要求校验身份凭据，而shortURL该参数值会处理简单的URL而不会要求校验身份凭据。相关截图如下：

我在基于taskId=shortURL的任务前提下fuzz了官方文档中提到的所有参数，但没有发现啥发现，每次它都抛给我一个状态码为500内容为“源URL无效”的错误消息，随后，我转变思路，下载了MicroStrtegy的SDK源码准备审计，大小400MB+，SDK中有若干脚本和一些jar包：

随后，我用jd-gui工具反编译了一些jar包，开始审计，我的主要目标时围绕shortURL参数来找寻相关利用点，如下，我找到了相关的Java Class：

后来我才知道为什么都反馈给我同样的错误消息，原来taskId=shortURL任务下的srcURL参数只允许通过https://tinyurl.com（一个短地址生成工具）来创建,相关代码如下：

开始利用

1. 我使用 Burp Collaborator Client来创建一个dnslog：
   

2. 接下来，把通过Brup Collaborator Client创建的 dnslog 在 https://tinyurl.com上生成短链接
   

3. 将生成的短链接赋值给srcURL参数，具体URL如下：
   https ://m-nexus.thefacebook.com/servlet/taskProc?taskId=shortURL&taskEnv=xml&taskContentType=json&srcURL={ YOUR_TINY_URL_HERE}
   页面响应如下：
   

4. 随后发现在Burp Collaborator拿到回显，得知请求地址是199.201.64.1
   

5. 通过whois查询到该ip属于Facebook
   

6. 如果要通过该SSRF探测内网，可以通过给srcURL参数赋值对应的内网地址来完成，例如探测123.10.123.10：
   

7. 接下来我探测了内网URL（127.0.0.1:8080）,发现响应中要求我进行对应的HTTP BASIC认证：
   

通过此途径，我可以绕过防火墙来探测服务器的内部网络结构。我迅速将此发现报告给了Facebook，但是由于他们不认为这是安全漏洞而被拒绝：

感谢您的来信！ 我们站点的各种功能有意向用户输入的URL发起请求。我们建立了速率限制和其他反滥用机制以阻止个人恶意大规模使用这些功能。如果您的目的是执行端口扫描，则接下来可尝试比端口扫描更有效率和深度的方法。不过，某些系统需要具备与外部地址进行通信的功能。鉴于我们已经采取了适当的保护措施，因此我们不认为此行为会在我们的计划中构成有效的安全风险

深入挖掘

至此，我不得不证明一些其它的危害，我尝试用多个协议（例如 file://, dict://, ftp://, gopher:// 等）来读取内部信息。还尝试获取云实例的元数据，但未成功。
一段时间后，我想出了一些其它有影响力的例子。以下是一些攻击场景：

1. 反射XSS
   

2. 在SSRF的配合下进行网络钓鱼
   2.1 创建并托管一个Facebook的钓鱼登录页面，该页面用于窃取Facebook登录凭据。
   

2.2 通过短地址生成器https://tinyurl.com来将http://ahmedabadexpress.co.in/fb/login/fb.html生成短链接

2.3 构造如下恶意URL：
https ://m-nexus.thefacebook.com/servlet/taskProc?taskId=shortURL&taskEnv=xml&taskContentType=json&srcURL={ YOUR_TINY_URL_HERE}

在此页面上输入并登录的账户密码将会被记录在http://ahmedabadexpress.co.in/fb/login/usernames.txt文件中，之后受害者将被重定向到真实的Facebook登录页面。可以看到页面中主机名是m-nexus.thefacebook.com，这完全合法。
2.4 查看获取到的账户密码：

1. 探测内网服务
   由于我能绕过防火墙进行内不网络扫描，随后我使用Burp Intruder发送了10000多个请求，以寻找内网中开放的服务。
   

随后，我发现了一个运行在10303端口上名为LightRay的应用程序。截图如下：

在我打算深入测试之前，Facebook安全团队已修复了该漏洞。
我因此获得了 $1000 的奖金：

继续深入

现在我知道MicroStrategy Web SDK运行在Facebook生产服务器上，该SDK基于Java，我使用 JD Decompiler工具反编译了每一个jar包，我开始审计每一处代码，我还在我的服务器上搭建了此SDK，这样的话就能随时调试以及验证我发现的问题。
经过26天的努力，我有了一个发现，在com.microstrategy.web.app.task.WikiScrapperTask类中，我观察到字符串str1是用户可控的。它会检查所提供的字符串是否以http：//（或https：//）开头，如果是，则它将调用webScrapper函数.

该函数将使用JSOUP在内部以GET方式来请求用户所提供的URL字符串。而JSOUP被用于获取和解析HTML页面。
基于上述，我又发现了一处SSRF，如下

只可惜这是一个无回显的SSRF，这样的话我无法枚举内部网络结构，无法获取任何敏感信息。

几个月后，我在Facebook上发现了另一个关于在线短地址生成器的漏洞，过程如下：
https://fb.me/ 是facebook的短地址生成器。Facebook内部员工和公共用户都可使用此工具。我注意到，所生成的短网址将使用HTTP Location响应头将用户重定向到长网址。https://fb.me/并没有设置速率限制。于是我对它发起了基于字典的目录攻击（大约2000个目录），并分析了响应包。在burp intruder的帮助下，我得到了几个短链接，这些短链接将用户重定向到内部系统，但是内部系统会将用户重定向到Facebook域（即facebook.com）。如下是一个跳转例子：
https://fb.me/xyz ==> 301 Moved Permanently
===> https://our.intern.facebook.com/intern/{some-internal-data} ==> 302 Found
===> https://www.facebook.com/intern/{some-internal-data} ==> 404 Not Found
在一些场景下，Facebook内部人员会生成一些将用户重定向到内部系统的短链接。它可能会包含一些敏感的内部信息，如下：
https://our.intern.facebook.com/intern/webmanager?domain=xyz.com&user=admin&token=YXV0aGVudGljYXRpb24gdG9rZW4g

接下来我编写了一个py脚本来搜集类似的敏感信息：

如下是我获取的部分敏感信息截图：

我只放了两个截图，因为根据Facebook的政策，我无法透露所有信息。

漏洞链

现在，我有两个漏洞

• 无回显SSRF :模拟服务器向内部或外部地址提交请求
• 服务器敏感信息泄露: 日志存储路径、其它文件路径、内部IP、内部HTTP请求信息、接口信息等
  接下来我在报告中构造了一个场景，该场景展示了在敏感信息泄漏前提下，配合目录遍历或者SSRF如何造成更大的危害。此外如果攻击者能够获取到内部IP地址，对他们来说这样更容易针对内网系统发起攻击。
  我将这两处漏洞都提交给Facebook，随后我得到了如下回复：
  

感谢您补充更多的信息。我们应用程序的各种功能有意向外部用户提供的URL发出请求。 我们知道您正在描述的场景，并且可以确认此功能仅允许外部请求。在无有效POC详细显示内部SSRF的前提下，我们将无法认同此为有效报告。感谢您抽出宝贵的时间报告此问题，并祝您今后一切顺利

随后我发现，基于Scrapper的无回显SSRF已被修复。
我做了如下回复：

试想一下攻击者通过枚举https://fb.me找到所有可用内部URL的情况，正如我在本报告中前面所描述的那样，然后攻击者使用所有URL来利用SSRF漏洞。通过结合两个漏洞，攻击者 可以恶意更新防火墙环境背后的内部基础架构。它会对业务产生不同的影响。这会导致业务数据和重要文件的丢失。 如果您仍然认为这不是漏洞. 可以删除补丁. 让我验证上述方案。
注意：采取上述措施如果发生任何风险或造成内部基础设施损坏，我将不承担任何责任。请给我相应授权。

收到回复如下:

谢谢你补充的信息，如果我理解无误，该问题不可复现。 请注意，Facebook服务的许多组件可能会随时间而变化--这种变化可能是最近添加的新功能、补丁修复或基础架构/配置更改所引发的环境变动。针对您报告中所提到的利用点我们并没有做任何更改。如果您认为仍然可以利用此问题，请告诉我们，我们将尽力复现内部SSRF。

经过几天的研究，我又发现了一个无回显SSRF！！
它位于MicroStrategy Web SDK中的com.microstrategy.web.app.utils.usher类中，我发现validateServerURL对于serverURL参数的不当处理,因为该方法直接基于serverURL参数来发起GET请求。

对应利用过程如下：

我询问他们是否允许我复现在上一封邮件中提到的操作，Facebook官方回复说，他们能够复现该漏洞，并会尽快告诉我有关奖励的决定，终于，几天之后我得到了包含赏金金额的如下回应：

接下来，我想测试MicroStrategy演示门户上是否存在相似SSRF漏洞，我发现其存在，我可以在AWS元数据接口(/latest/user-data)中读取到一些敏感信息：

我将此漏洞报告给MicroStrategy的安全团队，收到如下回复,其中包含他们决定给予我的奖励：

结论

现在，这些漏洞都已得到修复。希望这篇文章能让你更好地了解如何结合自身技能(如代码审计、目录枚举和脚本编写等)来挖掘更严重的漏洞，当我在Facebook服务器上首次发现此漏洞时，我尝试将其转换为RCE，但失败了。但是，从此漏洞中我总共赚了$31500（$1000 + $30000 + $500）