原文:
https://alaa0x2.medium.com/how-i-hacked-facebook-part-two-ffab96d57b19
有删减
这是昨天文章的后续,part2.在这一部分，我找到了一个cookie操作来进行任意账户登陆和一个SSRF。然后我获得了5位数字的赏金。
在part1里，我报告的漏洞，在Facebook确认之后1天就修复了。然后我就又回过头看了看burpsuite的history，我仔细研究这个应用程序是如何工作的。
如截图所示，红色框框里的，这个cookie绝对是ASPXAUTH。
你明白我意思嘛？80%的ASPXAUTH都是有漏洞的。但是你首先要明白一些事情。
⚪validationKey (string)：十六进制编码的密钥，用于签名验证。
⚪decryptionMethod (string)：默认AES。
⚪decryptionIV (string) ：十六进制编码的初始化向量（默认为零向量）。
⚪decryptionKey (string)：用于解密的十六进制编码密钥。
这里有更多MachineKey Class的资料：
https://docs.microsoft.com/en-us/dotnet/api/system.web.security.machinekey?view=netframework-4.8
但是到目前为止，这4个信息，我啥也没有，我是如何确定他有漏洞的呢？事实上，我也不确定，但是大多数使用ASPXAUTH的应用程序只使用电子邮件或带有加密密钥以及有效期的加密cookie中的用户。我在其他赏金网站项目里利用了很多次，都有效。
然后我就开始尝试寻找一种解决方法。我假设我足够幸运，能够找到使用相同的key的程序，这样的话，我就只需要一个管理员用户名就可以了。
然后我就努力的寻找使用相同技术的网站，我找到了一个，并且是可以注册的。然后我就注册了Facebook的管理员账号，然后我把注册的ASPXAUTH的值覆盖了这个ASPXAUTH,猜猜发生了什么？
我已经有一段时间没有见到这个面板了。让我们再重新回顾一下，思考一下ASP.NET的问题，开发人员开发应用程序的时候需要考虑一下这些点：
⚪ASPXAUTH必须存储在数据库和应用程序必须检查它是否有效。
⚪ASPXAUTH要包含更多认证信息，不能仅仅包含用户名。
⚪不同站点之间密钥一定要不同（一定要更改默认密钥）。
然后我又仔细检查了这个面板，我发现有一些制作表单的还有一些api触发器。给Facebook安全团队发了邮件，申请测SSRF，然后，他们回复我可以测。并给了一个内部链接来测试，
然后我就上传了我的脚本到他们的编辑器里，这个脚本允许我发任意方法的请求到任意URL。
我想尝试再次升级这个漏洞，升级为RCE或者LFI，但是Facebook拒绝了我。他们确信我无法升级。所以我只能请求这个内部SSRF节点。
叮咚。搞到了这个Canary token。完美SSRF。
让我们再次回顾一下整体的利用:
1.我可以使用任意的Facebook账号登录到这个面板里。
2.我不需要解释攻击者登录后可以找到的多汁信息。
3.可以使用SSRF来访问Facebook内部网络。
4.我相信我可以去扫描内部网络来提升这个漏洞，。
后面就是作者和Facebook讨论赏金的事了。。。不翻译了=。=
最后part1+part2，作者总共拿到了54800美元赏金。
译者按:
作者真是奇思妙想啊。像这种没有办法猜测的key，去找一个相同的网站，注册一个管理员名的账号。因为Facebook使用相同的key，而且加密的信息又比较简单，所以注册了一个选管理员相同的账号，ASPXAUTH的值是相同的。后边的SSRF其实没啥讲。前边的操作还是挺秀的。
本文迁移自知识星球“火线Zone”
