Hello World ❤️，
Facebook是世界上最大的社交网站，也是使用最广泛的社交网站之一。我一直对测试Facebook的安全性很感兴趣。在子域枚举时，我得到了一个子域，它是，它会重定向到，观察以下截图：
mstrWebAdmin
我通过一篇博客确认了这一点：
从MicroStrategy的官方配置文档中，我发现有两个可公开访问的端点：
在MicroStrategy的官方配置文档中，我发现在默认情况下，在门户网站(https://m-nexus.thefacebook.com/servlet/mstrWeb)上启用了HTTP基本身份验证，然后我发现这个页面https://m-nexus.thefacebook.com/servlet/taskProc不需要身份验证。
它从“taskId”参数中获取值来执行一些自定义数据收集和内容生成。通过枚举预先构建的任务(使用Intruder)，我发现每个预先构建的任务都会检查有效的身份验证session参数，但是“shortURL”任务只处理短URL，不检查有效的身份验证session，攻击者无需任何身份验证即可访问此服务。
使用Burp插件Intruder进行预构建任务枚举
我开始fuzzing官方文件中提到的所有参数，但我没有找到任何东西。每次都给我一个错误消息“状态代码500，源URL无效”。然后，我下载了web应用源码并开始源代码审查。我下载了一个超过400 MB的应用程序包，包中有几个脚本和jar文件。
简单地说，我使用jd-gui工具反编译了jar文件，并开始检查代码。我的主要目标是shortURL任务，该任务处理短URL，并且不检查有效的身份验证session。最后，我从一个jar文件中找到了那个Java类。
然后我才知道为什么每次它都给出相同的错误消息，“shortURL”任务的“srcURL”参数只接受由“https://tinyurl.com/”创建的URL来导入数据或读取数据。请注意以下代码片段：
现在怎么办呢？——让我们利用！
复现步骤(我发给Facebook的):
1. 打开Burp工具，进入Burp菜单，选择“Burp Collaborator client”。生成一个Collaborator payload并将其复制到剪贴板。
2. 从web浏览器打开“https://tinyurl.com/”，输入Collaborator payload并创建短URL，复制创建的短URL。
3.在以下URL的“srcURL”参数中插入复制的“短URL”，并在浏览器中打开:
4. 观察到Burp Collaborator立即命中，它显示从IP地址“199.201.64.1”收到请求。
这表明存在外部SSRF漏洞
5. 经whois记录确认，IP - 199.201.64.1属于Facebook。
6. 测试内部SSRF：创建无效内部IP地址的短URL(例如123.10.123.10)，将其插入“srcURL”参数中，并观察到服务器未响应。
7. 再次创建有效的内部IP地址(127.0.0.1:8080)的短URL，将其插入“srcURL”参数中，观察到它要求进行HTTP basic基本身份验证。
通过这个现象，我们可以枚举防火墙环境背后的内部基础设施。我很快把我的发现报告给了Facebook，但是他们拒绝了，因为他们不认为这是一个安全漏洞。以下是Facebook响应内容：
那接下来呢?——深入挖掘⛏️
我必须拿出证据。我尝试使用URL模式来读取内部信息，比如file://、dict://、ftp://、gopher://等。也尝试获取云实例的元数据，但没有成功。
过了一段时间，我终于想出了一些有影响力的例子。以下是我发给Facebook的一些实时攻击场景以及复现步骤:
1. 反射型跨站脚本攻击(XSS)：
2. SSRF帮助下的钓鱼攻击：
步骤1. 创建并托管一个看起来像合法的Facebook登录网站的钓鱼页面，用于窃取受害者的Facebook登录凭证。
我把它托管在一个私有服务器上，即http://ahmedabadexpress.co.in/
步骤2. 从web浏览器打开“https://tinyurl.com/”，创建一个钓鱼页面的短URL，即“http://ahmedabadexpress.co.in/fb/login/fb.html”，复制创建的短URL。
步骤3. 在以下URL的“srcURL”参数中插入复制的“短URL”，并发送给受害者:
一旦受害者在此页面上输入他/她的用户名和密码，它将被保存到“ http://ahmedabadexpress.co.in/fb/login/usernames.txt”文件。受害者被重定向到真实的Facebook登录页面。你可以看到主机名是字符串“ m-nexus.thefacebook.com”，因此它看起来是合法的。
攻击者还可能利用此漏洞将用户重定向到用于提供恶意软件和类似攻击的其他恶意网页。
3.指纹内部（非Internet公开）网络感知服务：
我能够扫描防火墙后面的内部网络。为了在服务器或该端口上运行的任何应用程序中找到一个开放端口，我使用burp插件Intruder发送了10000多个请求。
扫描后，我终于找到了一个在端口10303上运行的名为“ LightRay”的应用程序。
在我对此进行进一步调查之前，Facebook安全团队已解决了该漏洞。
最后：
… 这就是结局？ —不，这个故事才刚刚开始
现在，我知道MicroStrategy Web SDK托管在Facebook的生产服务器上。 MicroStrategy Web SDK用Java编写，我喜欢在Java代码中发现错误。因此，我使用JD Decompiler工具反编译了SDK的每个jar文件，并开始查看代码。我还在服务器上托管了SDK，因此，如果我在代码中发现任何可疑的地方，就可以在其中进行检查。
经过26天的努力和磨砺，我终于得到了一个有趣的发现。
在“ com.microstrategy.web.app.task.WikiScrapperTask”类中，我观察到字符串“ str1”是由我们作为参数发送的用户提供的输入初始化的。它将检查提供的字符串是否以http：//（或https：//）开头，如果是，则将调用函数“ webScrapper”。
“ webScrapper”功能将使用JSOUP在内部将GET请求发送到提供的URL。它曾经用于获取和解析HTML页面。
BOOM！！再次是SSRF..
不幸的是，这次是一个盲SSRF，因此我无法证明它允许内部GET请求的提交。但是，从MicroStrategy Web SDK（部署在m-nexus.thefacebook.com域上）的源代码中，我确认它是内部SSRF。
从这种观察中，我们无法枚举防火墙环境背后的内部基础架构，或者无法泄漏任何敏感信息。我知道如果我向Facebook报告此问题，他们将拒绝它，因为此漏洞没有影响。
那接下来呢？ —我现在还是一片空白！
我放弃了，开始在主要的Facebook域（facebook.com）中寻找新的漏洞。
几个月后..⌛我在Facebook上发现了另一个漏洞，其中URL缩短器可能泄漏有关服务器的敏感信息。
URL缩短是万维网上的一种技术，在这种技术中，统一资源定位符可以做得很短，而且仍然指向所需的页面。 -维基百科
Facebook在https://fb.me/上拥有自己的URL缩短服务。内部（Facebook员工）和公共用户都使用此URL缩短服务。我注意到，短网址将使用HTTP Location标头将用户重定向到长网址。我发现网站“ fb.me”没有设置速率限制。我正在寻找现有的（和/或隐藏的）Web目录和文件。我针对该Web服务器发起了基于字典的蛮力攻击（大约2000个单词），并分析了响应。在burp suite intruder的帮助下，我捕获了几个短链接，这些短链接将用户重定向到内部系统，但是内部系统会将用户重定向到Facebook主域（即facebook.com）。
这是一个场景：
https://fb.me/xyz ==> 301永久移动
https://www.facebook.com/intern/{some-internal-data} ==>找不到404
请注意，Facebook的内部人员会生成一些将用户重定向到内部系统的短链接。它可能包含敏感的内部信息。例如“ https://our.intern.facebook.com/intern/webmanager?domain=xyz.com&user=admin&token=YXV0aGVudGljYXRpb24gdG9rZW4g”
在burp工具中观察https://fb.me/err URL的HTTP响应，该工具显示了日志文件夹的内部完整路径。
我已经能够通过单词列表和Intruder获得更多类似的信息。我创建了一个简单的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请求。
我用Burp Collaborator URL替换了“ serverURL”参数的值，并发送GET请求
它观察到Burp Collaborator立即命中，它将显示从其接收请求的IP地址“ 199.201.64.1”。这表明存在SSRF漏洞
我要求他们允许我执行上一封电子邮件中所述的操作。他们回答说，他们能够复现该漏洞，并且正在开发补丁程序。他们会尽快通知我有关奖励的决定。终于，几天后我得到了回应：
Facebook奖励
哇！
接下来，我想测试MicroStrategy demo网站上是否存在SSRF漏洞，我发现这里也有这个漏洞。我可以使用AWS元数据API从他们的服务器中获取一些有用的信息。
我已将其报告给MicroStrategy的安全团队，收到了以下回复：
MicroStrategy认可和奖励
结论
现在，此问题已得到解决。这是一篇稍长的文章，但是我的目的是让您很好地了解如何结合所有技能，例如安全代码审查，枚举和脚本编写知识，以找到严重的漏洞。
当我在Facebook服务器上首次发现此错误时，我尝试将其转换为RCE，但不幸的是，他们实施了良好的安全措施。但是，从此漏洞中我总共赚了31500美元（1,000美元+ 30,000美元+ 500美元）。
希望您喜欢这篇文章。原谅我的错误。
谢谢阅读。保持学习。
保持安全健康healthy
