由于疫情原因，让我有了充足的时间来做职业规划。8月份我参与了OSWE的考试，之后闲了一个星期，到了9月份，我才想起来今年还没参与过Facebook的漏洞众测呢，于是乎说干就干。
此前，我从未发现过Facebook子域名网站的漏洞，看了许多相关writeup后，其中一篇文章让我有了启发-《HTML to PDF converter bug leads to RCE in Facebook server》。有了如此的珠玉在前，让我思路大为开阔。我决定围绕Facebook子域名网站https://legal.tapprd.thefacebook.com进行深入测试，看看能否发现RCE等高危漏洞。我先是拿出了fuzz工具对其路径进行了扫描，发现了以下响应为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/
乍一看，确实能想像出该网站有些庞大，于是，我尝试着从网站请求调用的js脚本文件中窥探其应用系统具体的运行机制。之后，我注意到了一种绕过单点登录SSO的路径https://legal.tapprd.thefacebook.com/tapprd/portal/authentication/login，深入分析该路径后，我又注意到了以下这两个路径：
/tapprd/auth/identity/user/forgotpassword（忘记密码）
/tapprd/auth/identity/user/savepassword（保存密码）
通过阅读其中相关的js脚本文件，我发现/tapprd/auth/identity/user/savepassword的调用方法应该是一个POST请求，请求参数是绑定邮箱和新设置的密码，请求机制应该是保存密码（savepassword），且在此过程中会生成一个token和xsrf token，不管了，我还是先测试看看吧。但当我用burp测试的时候却遇到了错误，错误提示我操作失败。难道是我在POST请求中提供的邮箱有错？于是我从我前期收集的Facebook管理员邮箱字典库中构造了一个邮箱字典，尝试用burp的Intruder模块去发现该网站匹配的管理员邮箱。
用邮箱字典、随意设置的新密码和一个CSRF token值，配合上述路径/savepassword的POST请求，我前后差不多捣鼓了两个多小时，请求测试大部份是报错，但其中出现了一个跳转到登录路径的302响应，这让我看到了希望，说明它是https://legal.tapprd.thefacebook.com/的管理员邮箱，且服务端可以保存它的密码重置请求！然后，我用其中测试得出的匹配邮箱和其密码值执行了针对路径/tapprd/auth/identity/user/savepassword的POST请求，这一次，服务端返回了路径https://legal.tapprd.thefacebook.com/tapprd/portal/authentication/login的302响应。
我立马用其中的匹配邮箱和设置密码在登录界面https://legal.tapprd.thefacebook.com/tapprd/portal/authentication/login进行了登录，竟然成功登录了！可以进入到其管理界面：
针对/savepassword路径和以上漏洞，我马上编写了一个自动化的利用脚本，只要提供正确的邮箱地址和新设置的密码，最终的漏洞利用即可成功更改与该邮箱绑定的账号密码，实现账户劫持。
漏洞上报后，Facebook很快给出了响应，最终我收获了7500$的奖励：
在该网站我还发现了其它漏洞，请关注我的博客https://alaa.blog/，且听下回分解。
参考来源：medium，编译整理：clouds，转自Freebuf