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

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户，每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序把安全装进口袋

^{0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9}

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

clouds 2020-03-22 13:00:29 422801

今天分享的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字符应该是一样的。