我挖到Facebook漏洞得到54,800美元赏金

w ^ e've一直在这一疫情三月以来，一旦大流行开始，我就有大量的空闲时间，我需要明智地利用这段时间，所以我决定采取OSWE认证和我完成了考试上的8在那之后的八月，我花了几个星期从OSWE考试中恢复，然后在九月的那一天，我说你知道吗？我没有像每年一样在2020年的Facebook名人堂中注册自己的名字。好吧，让我们开始吧。

我从未在一个Facebook子域中发现漏洞，并且查看了一些文章，并且在一个Facebook子域中看到了一份文章，引起了我的全部关注。这是一个很棒的文章，您可以检查一下[HTML到PDF转换器错误导致Facebook服务器中出现RCE。]

因此，在阅读了这篇文章之后，我对在如此庞大的Web应用程序中可以找到多少个漏洞有了一个很好的了解。

所以我的主要目标是https://legal.tapprd.thefacebook.com，我的目标是RCE或类似的东西。

我运行了一些模糊测试工具，只是为了获取该Web应用程序的完整端点，我小睡了2个小时，看了一部电影，然后又回到看结果，好了，我得到了一些不错的结果。

发现Dirs的响应为403：

/ tapprd / / tapprd / content / / tapprd / services / / tapprd / Content / / tapprd / api / / tapprd / Services / / tapprd / temp / / tapprd / logs / / tapprd / logs / portal / / tapprd / logs / api / / tapprd / certificates / / tapprd / logs / auth / / tapprd / logs / Portal / / tapprd / API / / tapprd / webroot / / tapprd / logs / API / / tapprd / certificates / sso / / tapprd / callback / / tapprd / logs / callback / / tapprd / Webroot / / tapprd / certificates / dkim / / tapprd / SERVICES /

好的，我认为这个结果足以支持我以前关于此应用程序有多大的理论，然后我开始阅读javascript文件，以了解网站的工作方式以及使用..etc的方法。

我注意到一种绕过重定向到登录SSO的方法，即

https://legal.tapprd.thefacebook.com/tapprd/portal/authentication/login

在分析登录页面后，我注意到了该端点

/ tapprd / auth / identity / user / forgotpassword

在用户端点上进行了一些模糊处理之后，我注意到了另一个端点，该端点的/ savepassword并期待POST请求。然后，在读取javascript文件后，我知道页面的工作方式，应该有一个生成的令牌和xsrf令牌。.etc最初想到的主意是，让我们对其进行测试，看看是否可行，我尝试使用burp suite手动进行更改，但出现错误，错误是执行此操作失败。

我说好吧，这可能是因为电子邮件有误或其他原因？让我们得到一个管理员电子邮件，然后我开始将随机电子邮件放入列表中以创建单词列表，然后，我使用入侵者，然后说让我们看看会发生什么。

几个小时后，我回来了，我发现了相同的错误结果以及另一个结果，这是302重定向到登录页面的消息，我说，哇，如果这行得通，我该死的哈哈。

因此，让我们回过头来看看我在这里做了什么，我使用带有CSRF令牌的入侵者发送了随机请求，并使用带有新密码的随机电子邮件发送了此端点。

/ savepassword

结果之一是302重定向。

现在，我进入了登录页面，将登录电子邮件和新密码以及我成功登录的BOOM放入了应用程序，然后可以进入管理面板了：）

我阅读了在使用PDF之前发现RCE的黑客报告，他们只给了他1000美元作为奖励，所以我说好，让我们在这里取得良好的影响力，并进行一次完美的利用。

我编写了一个快速简单的脚本来利用python利用此漏洞，您将电子邮件和新密码放到了一起，脚本将更改密码。

这里的影响之所以如此之大，是因为Facebook员工曾经使用其工作场所帐户登录，这意味着他们正在使用其Facebook帐户访问令牌，并且如果另一个攻击者想要利用此身份，则可能使他能够获得访问某些帐户的权限。Facebook的工人帐户..等

然后，我报告了该漏洞，并对报告进行了分类。

在10月2日，我收到了7500美元的赏金

我非常喜欢利用此漏洞，所以我还说这还不够，这是一个很弱的脚本！让我们越来越多地挖掘。

而且我在同一应用程序上发现了另外两个漏洞，但是在第二部分中我们将讨论其他漏洞:)

在第一部分中，我发现一个不安全的API接管了帐户，这使我可以在没有用户交互的情况下更改任何管理员帐户的密码，并且我得到了Facebook安全团队的7500美元奖励，在第二部分中，我发现了使用Cookie进行的帐户接管操作并将其与内部SSRF链接起来，我得到了$ xxxxx的赏金。是的5位数字..让我们开始吧。

该文章在发布之前曾被多方修订，并且我还必须获得发布的书面许可，以便可以根据Facebook及其合作伙伴的要求更改某些名称和信息。

因此，当我在一天的报告中发现第一个漏洞时，Facebook缓解了它。然后我不得不回头阅读打p套件的历史记录，并查看其工作原理。

正如您在屏幕快照中看到的那样，数字1为蓝色，其cookie为ASPXAUTH，绝对是！

你明白我的意思了吗？— ASPXAUTH表示它有80％的漏洞，但首先，您需要做一些事情：

• validationKey （字符串）：十六进制编码的密钥，用于签名验证。

• decryptionMethod （字符串）：（默认为“ AES”）。

• decryptionIV （字符串）：十六进制编码的初始化向量（默认为零向量）。

• decryptionKey （字符串）：用于解密的十六进制编码密钥。

好吧，我没有这4样东西，那么我怎么认为它很脆弱呢？- 好的。实际上，我没有，但是大多数使用ASPXAUTH的应用程序只使用电子邮件或带有加密密钥以及有效期的加密cookie中的用户。我在其他赏金计划网站上多次使用相同方法对其进行了利用，并且有效。

因此，在这里我必须找到一种解决此问题的方法，并且我相信尝试之后没有什么可以失去的，之后，我进入google并搜索了使用相同应用程序的其他网站-我在这里假设我会很幸运，并且找到一个使用相同应用程序和相同加密密钥的网站，而我只需要使用正确的管理员用户名即可。

我这样做了，发现另一个网站使用相同的应用程序，并且注册处于活动状态，并且我使用了Facebook管理员使用的用户名进行注册，我拦截了该请求，并接受ASPXAUTH并将其替换为Facebook过期的ASPXAUTH，然后猜测什么？

我有一段时间错过了这个小组:) ..但是，是的！我再次回到它的角度，现在让我们谈谈ASP.net错误，即大多数开发人员在构建应用程序以根据以下几点加以保护时必须小心：

• 该ASPXAUTH必须存储在数据库和应用程序必须检查它是否有效。

• 有时，ASPXAUTH必须包含比用户名更多的名称，以进行进一步的验证。

• 站点之间的加密和解密密钥必须不同（必须更改默认密钥）。

结论1：我知道用户名即可使用任何管理员帐户登录，这个漏洞的复杂性我认为很低而且影响很大，如果仅报告此漏洞，我将获得$ 7500作为第一部分，但是我想要更多。

因此，我刚刚注意到面板中的某些内容是制作表格的选项，还有另一个选项是API触发器。因此，我怀疑有些东西，这里大部分都没有SSRF，因为我向Facebook安全团队写了一条消息，向他们解释我怀疑应用程序中几乎存在某些关键的SSRF，如果我能够获得许可，测试一下，他们回答了我：

此时，我仍在第一部分的报告（帐户接收）中与他们联系，因为这些漏洞是在第一部分的一周后报告的。如您所见，Facebook安全团队仍然认为我声称自己还有另一个身份验证绕过和SSRF，即使在我用证据向他们解释了漏洞之后也是如此。据此，这意味着他们给了我绿灯以测试SSRF。

一段时间后，我编写了一个小脚本并将其上传到他们的编辑器，该脚本使我可以将任何包含任何数据（GET，POST，PUT，PATCH，HEAD，OPTIONS）的请求发送到任何URL（内部或/和外在的。

从脚本后端，我可以更改请求方法和发送的数据，等等。

在这一点上，如果我走得更远的话，我可以将此漏洞升级为RCE，LFI（我对这一点不是很100％的肯定，我后来要求Facebook授予我对应用程序进行反向工程的权限，但他们没有接受，他们相信我将无法升级它）。

我试图打Facebook的金丝雀脚本:)，再次猜猜是什么？

我得到了幸运的Canary令牌，接下来该怎么办？-我必须做一个包含所有详细信息的新报告，包括之前提到的脚本和PoC。

结论2：通过编写脚本来发送定制请求，我能够获得内部SSRF并访问Facebook内部网络。在这里，我认为它的复杂性很低，影响至关重要。

该SSRF的全部影响：

成功的SSRF攻击通常会导致易受攻击的应用程序本身或该应用程序可以与之通信的其他后端系统上的未经授权的操作或访问Facebook内部网络中的数据。在某些情况下，SSRF漏洞可能使攻击者可以执行任意命令。

导致与外部第三方系统建立连接的SSRF利用可能导致恶意的继续攻击，这些攻击似乎源于托管存在漏洞的应用程序的组织，从而导致潜在的法律责任和声誉损失。

最终结论：通过使用帐户接管进入应用程序内部的上载脚本，我将这两个漏洞联系在一起，从而可以访问Facebook内部网络（SSRF），从而可以根据需要发送自定义请求。

• 让我们谈谈我利用到目前为止发现的漏洞链可以实现的目标：

• 我可以在法律部门面板中访问任何Facebook员工帐户。

• 我不需要解释攻击者在登录后可以找到的多汁信息。

• 我能够使用SSRF来访问Facebook内部网络（intern.our.facebook.com）。

• 我相信，只要稍加努力，我就可以升级此漏洞并将其用于扫描内部网络/服务器。

我们都知道SSRF的重要性，特别是它不受速率限制，我可以轻松地编辑内容类型和请求方法，而且正如Facebook的支出准则所述，如果我能够，应以40,000美元的奖金和5000美元的奖金来奖励此漏洞。编辑请求内容类型和请求方法。

经过长时间的等待，我刚从Facebook收到此消息：

被Facebook奖励了40,000美元，外加2,000美元的奖金（应该是7,000美元，哈哈）

所以我问他们为什么我没有得到全部控制奖金（$ 5000），答案是：

出现第一个漏洞的总金额为$ 54,800

我在漏洞的第一天报告了此漏洞。

报告时间表：

• 2020年9月9日，星期三-报告了漏洞。

• 2020年10月26日，星期一-Facebook要求我打开一份新报告。〜已应用缓解措施。

• 2020年10月26日，星期一-报告已分类。

• 2021年2月25日，星期四-固定并获得奖励。〜6个月我知道大声笑。

• 2021年3月5日，星期五-奖励$ 5300。

我想给漏洞猎手一个金色的提示，总是在您看到ASPXAUTH时，尝试从另一个使用相同应用程序并测试与我相同方法的网站获取cookie：

• 从另一个网站创建新的ASPXAUTH cookie。

• 测试Cookie是否可以在您的目标网站上运行。

我很喜欢，但由于非理性的原因等待了6个月并关闭报告，我非常感激，但是辛苦了一切，这并不是我发现的唯一SSRF，实际上，我找到了更多有趣的报告，但是Facebook关闭了它们作为信息，因为Facebook与供应商签署了一份协议，该协议是在“报告分类”之后几周签署的，这实际上不是我的问题，因此无论如何我都不会将其称为最佳体验。

作者：阿拉·阿布杜里达（Alaa Abdulridha）

作者主页：https://alaa0x2.medium.com/

本文始发于微信公众号（Ots安全）：我挖到Facebook漏洞得到54,800美元赏金