本文中,作者在分析某社交应用的注册机制时,发现复制其中的Confirm链接至微软Edge浏览器中,即能绕过原有的身份确认操作,属于用户注册邮箱自动化确认漏洞,漏洞上报后获得微软官方奖励的$10,000。
漏洞发现过程
在疫情隔离期间,我在Facebook上看到了以下这条帖图:
这条贴图激起了我深入学习WEB安全的动力,经过在HackerOne的项目筛选,我选择了Lark Technologies公司的系统作为测试目标。一开始,我花了将近五六个小时的时间,但一无所获。在漏洞测试中,我本来用Firefox比较顺手,但那天我决定用其它浏览器试试,于是,我就打开了微软的Edge浏览器对Lark的用户注册机制进行了测试。
使用邮箱进行用户注册后,我在邮箱中收到了以下Lark发来的确认邮件:
在点击确认(Confirm)按钮之前,我复制了该按钮的URL链接,尝试在浏览器中进行打开测试,看看有什么反应。当在Edge浏览器打开后,我发现该条URL链接会直接跳转到确认(Confirm)操作之后的界面,等等,这里我都还没点击确认(Confirm)按钮的啊,怎么回事?
我觉得这应该是一个漏洞,为了深入确认,我又用另外一个我的邮箱分别在Firefox和Chrome浏览器进行了测试。注册->接收确认邮件->复制其中的确认(Confirm)按钮URL链接->浏览器中打开链接,但是,什么也没发生。之后,我又把该链接复制到了Edge浏览器的地址搜索栏中,在没执行访问操作的情况下,我竟然又看到了该邮箱已被Lark身份验证通过。迷惑了。接下来,我用此种方式在Facebook、Spotify等社交应用的注册机制中尝试了一遍,但都没有出现Lark的这种情况。
我认为Lark的此种情况属于自动化的注册邮箱确认漏洞,但内心还是充满好奇。为了消除疑虑,我用BurpSuite中的burp collaborator作为代理服务,拷贝了上述确认邮件中的Confirm按钮链接到Edge浏览器中,不一会儿,我就观察到产生了向IP地址125.20.208.158发起的DNS请求,经反向查询,该IP地址归属于微软网络架构。
此时,综合上述情况,也就是说,当我把Lark注册邮件中的Confirm按钮URL链接复制在Edge浏览器的地址搜索栏中,此时,Edge浏览器会向IP地址125.20.208.158发起一个DNS请求,当Lark应用后端探测到该DNS请求后,它即认为其中包含的Confirm按钮已被用户点击并且已形成了HTTP请求,因此,Lark应用后端“理所当然”地就把该用户邮箱设置为经过身份确认的。但遗憾的是,当我把该漏洞通过HackerOne上报后,厂商Lark认为这不是一个有效漏洞,且把漏洞分类为了N/A,有点扯。
有点不甘心,之后,我想该漏洞涉及到了微软,可以把它向微软进行了上报。这里要说明的是,虽然Microsoft Edge是基于chromium内核的,但是在Google chrome浏览器该漏洞是不行的,所以,最终我也只剩下对微软的期待了。我都差不多把这事忘记了,在2021年1月6日的凌晨4点,我收到了来自微软的邮件,其中表示,我的漏洞已被微软接收,并给予了$10,000的奖励。当时,我太激动了。还是大厂实在啊。
漏洞上报和处理进程
2020.12.2 漏洞一并向Lark和微软进行了上报
2020.12.2 漏洞被Lark拒绝
2020.12.3 微软审核我的漏洞
2020.12.23 微软确认了漏洞
2021.1.6 微软奖励了我$10,000
2021.1.14 微软修复了该漏洞
参考来源:medium