记一次有趣的密码重置 - FreeBuf网络安全行业门户

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

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}

^{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
90
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}

记一次有趣的密码重置

Strjziny 2019-03-02 08:00:00 476924

*本文中涉及到的相关漏洞已报送厂商并得到修复，本文仅限技术研究与讨论，严禁用于非法用途，否则产生的一切后果自行承担。

最近被客户日的头晕晕，不但要搞定客户，还要搞定他们的开发，在熬掉14根头发后发现了这个漏洞，觉得比较有意思。

前景提要

之前有测过客户的App，发现在忘记密码的地方存在手机号验证绕过导致任意用户密码重置,登陆后的修改密码也是存在手机号验证绕过问题。这次测试的是Web端，发现之前的几个接口都是和app一样的，所以拿到手就先开始对密码这部分下手。

正片

开局直奔忘记密码的重置，但是开发已经学乖了，已经把这个在app端发现的问题修复了，寻之无果，又转战到个人中心修改密码处。

看起来是挺吓人的，又是手机验证码，又是旧密码的。走一波流程，发现是先验证手机验证码，从下图的参数中可以看到是分步验证的，首先尝试绕过手机验证。

修改code=0绕过第一次手机号验证。下图为第二次验证提交参数，发现还有一个验证码的参数，以为会进行二次效验，但是万万没想到，直接放行就修改成功了。。。。。。

看来都是纸老虎，再看参数中好像并没有其他做验证的参数，丢到repeater里尝试看看修改手机号为另一个手机号能否成功。

？？？黑人问号脸，看来还是做了身份验证，也就是上图中的ut值，绑定当前用户的手机号，也就是说要修改别人手机号得拿到别人的ut值。原本打算到这里结束了，但是心有不甘，回想了一下上一次挖到的任意用户密码重置过程，在上一次的挖掘中重置用户密码是没有用户身份验证的，因为是从忘记密码进去的，所以没有经过用户登录，然而登录以后则验证了ut和手机号。那么问题就在于如何让他变成没有用户登录的情况，由于ut值是整个系统判断用户登录信息的唯一参数，所以我尝试删除cookie中的ut值，达到用户未登录状态。