NEWS.ALL
Ruizhao's News Reader

挖洞经验 | 密码重置Token可预测性导致的账号劫持漏洞

FreeBuf /2020-03-22

今天分享的Writeup是一个有趣的账号劫持漏洞,漏洞原因在于目标服务端重置用户密码时,其Token生成算法有问题,存在可预测和可枚举可能,导致网站注册用户面临账号被劫持风险。

这里我们把目标服务端称为program.com,当我在测试其忘记密码功能时发现一个怪异的现象,每次我对我当前账号发起密码重置请求后,在我收到的下述密码重置Token信息中,其Token串中的前3个字符都是一样的,所以这引起了我的注意。

https://program.com/forgot_password/<TOKEN-HERE>

几分钟后,我惊奇地发现Token信息中的前3个字符,是我在目标网站时绑定注册邮箱前缀中,从第4个字符住前反向排序到第2个字符的3个字符。也就是说,假设我在该网站的注册邮箱为 johndoe@domain.com ,那么我发起密码重置请求后,在我邮箱中收到的重置Token信息其前3个字符就是“nho”(无引号),如下:

有了这个发现,我想那么Token信息中剩余字符应该也存在某种意义吧,于是,经我多次的测试分析,发现其余字符就是当前的时间戳信息(Timestamp)。但是,最后,还余下2个字符我无法找到规律,这两个字符位于前3个字符和后部份时间戳字符之间,它们可能是随机生成的。

我想,如果是随机生成的话,那就来暴力枚举试试看,非常好的是,目标服务端竟然毫无任何速率限制措施。这里,我用两个注册邮箱来进行测试,一个当成受害者邮箱的johndoe@domain.com,另一个当成攻击者邮箱的johndoe@domain2.com,可以看到它们前缀都是相同的。在测试中,我同时向目标服务端对该两个邮箱发起了账户密码重置请求,由于它们的邮箱前缀都是相同的,所以,在服务端发送回来的密码重置Token中,除了那2个随机字符之外,其余的Token字符应该是一样的。

这样,我可以登录作为攻击者的邮箱johndoe@domain2.com,从中获取包含Token信息的密码重置链接,然后,针对该密码重置链接请求,在Burp Instruder中构造字典文件进行暴力枚举。果然,不一会儿,在不多的请求发出之后,我成功地枚举到了一个302跳转的有效密码重置请求。

该漏洞上报后,厂商把该漏洞定级为P1严重级,及时进行了修复。

*参考来源:medium,clouds 编译整理,转载请注明来自 FreeBuf.COM