背景介绍：

今天的故事来自一位名叫Tushar Sharma的白帽子，他利用自己创建的Google Dorkers发现了一个几天前才启动的项目。

Google Dorks：

https://github.com/tushar-arch/Bug-Bounty-Dorks/blob/main/Bug-Bounty-Dorks.txt

于是他开始尝试使用子域枚举，并在手动渗透时开启了nuclei监听，接下来先看看下面这个漏洞，即:Token令牌不会在邮件更改后失效，根据BugcrowdVRT的规则，该漏洞被定级为P5级：

于是这位白帽小哥快速注册了这个应用程序，并浏览了它的每一项功能，在了解了应用程序的大致流程之后，他准备测试该应用，首先启动Burp，测试的第一个就是注册功能。

白帽小哥开始尝试重复注册，但毫无结果，然后他想起曾出现过的一个案例：

https://twitter.com/Virdoex_hunter

于是小哥用[email protected]注册，然后再次尝试用[email protected]（注意.的位置）注册。

理论上应用程序不应该允许这么做，试想如果你的电子邮件是[email protected]，你就拥有所有.分割的邮件地址，诸如[email protected]，其他人就无法再使用任何此类账号在Gmail上注册，所以应用程序不应该允许这么做，但不幸的是，该程序可以这么做。

因此，在注册这2个帐户后，白帽小哥尝试请求[email protected]的密码令牌时，应用程序会进入[email protected]的收件箱，而当他试图更改密码时，由于某种后端逻辑，这两个帐户的密码都被更改了。

白帽小哥本可以如实报告该漏洞，但漏洞影响相当低，而且没有任何攻击场景来说明该漏洞对安全团队的影响，于是他尝试寻找和思考一种攻击场景。

过了一会儿，邮件地址的更改功能引起了他的注意…

白帽小哥注册了一个临时电子邮件，并要求重置密码，然后他更改了邮件地址，而在临时邮件中发送的密码重置令牌仍然可以用来更改密码。

根据BugcrowdVRT的规则，目前该漏洞可以被评为P5级，但是现在事情却变得开始有趣了！

于是白帽小哥一步一步地建立了下面的攻击场景：

1、用任何电子邮件注册

2、请求一个密码重置令牌

3、登录并将电子邮件更改为受害者的电子邮件，例如:[email protected][假设受害者有一个[email protected]的帐户]，因为应用程序允许我们创建带.的帐户

4、现在进入前一封邮件的邮箱，尝试修改密码

5、修改密码后，成功登录了[[email protected]]帐户

白帽小哥很快将POC及视频演示作为漏洞报告提交，几天后，漏洞被确认并修复，白帽小哥也因此获得了$$$$奖励。

漏洞时间线：

2021年11月1日 – 漏洞报告

2021年11月9日 – 漏洞确认

2021年11月11日 – 漏洞修复并奖励$1000

====正文结束====

感谢阅读，读者可通过下方“阅读原文”跳转至原文网站查看。

原文始发于微信公众号（骨哥说事）：【白帽故事】从P5到P1，一次有趣的账户接管