任意用户密码重置（三）：用户混淆

在逻辑漏洞中，任意用户密码重置最为常见，可能出现在新用户注册页面，也可能是用户登录后重置密码的页面，或者用户忘记密码时的密码找回页面，其中，密码找回功能是重灾区。我把日常渗透过程中遇到的案例作了漏洞成因分析，这次，关注因用户混淆导致的任意用户密码重置问题。

密码找回逻辑含有用户标识（用户名、用户 ID、cookie）、接收端（手机、邮箱）、凭证（验证码、token）、当前步骤等四个要素，若这几个要素没有完整关联，则可能导致任意密码重置漏洞。

案例一：通过 cookie 混淆不同账号，实现重置任意用户密码。

密码找回页面 https://my.xxxx.com/pwd，用攻击者账号 yangyangwithgnu 走完密码找回全流程。

输入用户名和图片验证码后提交：

验证为有效用户名后，系统提供手机、邮箱两种密码找回方式，选用邮箱方式：

登录邮箱查收重置验证码：

输入重置验证码：

进入新密码页面，输入后提交，拦截请求如下：

其中，

PHPSESSID=dcusc1ahkn4ioqeeav9c6e0bdq、USER_ACCOUNT=yangyangwithgnu、 USER_APPID=1092 这三个参数引起我的注意。这个请求，用于重置账号 yangyangwithgnu 密码，那么服务端如何知道该重置 yangyangwithgnu 而不是 yangyangwithgnu2、yangyangwithgnu3 呢？刚才说的那三个参数中肯定有一个用于该目的。逐一尝试发现，PHPSESSID 就是它。

这让我闻到浓郁的 cookie 混淆的味道。大致攻击思路：首先，用攻击者账号 yangyangwithgnu 进入密码找回流程，查收重置验证码、通过校验；然后，输入新密码后提交，拦截中断该请求，暂不发至服务端，这时，PHPSESSID 关联的是 yangyangwithgnu 账号；接着，关闭浏览器的 burp 代理，新开重置流程的首页，在页面中输入普通账号 liuwei 后提交，这时，PHPSESSID 已关联成 liuwei 了；最后，恢复发送之前中断的请求，放至服务端，理论上，可以成功重置 liuwei 的密码。

用上述思路尝试将 liuwei 密码重置为 PenTest1024，前端显示重置成功：

尝试用 liuwei/PenTest1024 登录：

成功进入系统：

同理可重置管理员账号 administrator，为避免影响业务，不再实际操作。

案例二：通过篡改请求包中的用户名参数，实现重置任意用户密码。

密码找回页面

http://www.xxxx.cn/getpass.html，用攻击者账号走完密码找回全流程，涉及三步请求，依次为：验证用户名是否存在、获取短信验证码、提交短信验证码和新密码。第三步的请求拦截如下：

各参数作用从其命名可了解。尝试将 accountname 参数值篡改为普通账号 zhangzhiqiang 后放行，应答为：

重定向至登录页面。用普通账号 zhangzhiqiang/PenTest1024 登录成功。

查看个人信息：

泄漏用户手机号、邮箱等敏感信息。

查看视频监控设备列表：

视频监控设备登录信息：

登录后可查看实时视频监控，隐私考量，不截图了。

另外，密码找回流程第三步的请求中的 vcode 参数为短信验证码，单次有效，不可复用，如何实现自动批量密码重置？经测试，将该参数置空，或者完整删除该参数，服务端不再校验短信验证码。

综上，几个问题结合，可导致任意用户密码重置。

案例三：通过篡改带 token 的重置链接中的用户名，实现重置任意用户密码。

http://xx.xxxx.com/echannel/forgetPassword/ 为重置密码页面。攻击者用户 ID 为 42558。

输入攻击者账号绑定的邮箱后点击“确认”，收到如下带 token 的密码重置链接：

该重置链接有两个地方引起我的注意：一是，NDI1NTg= 为 base64 编码，解码为 42558，正是攻击者账号的用户 ID；二是，这是个 REST 风格的请求。所以，尝试用普通账号的用户 ID 的 base64 编码替换 NDI1NTg= 后，成功重置该普通用户的密码。

特别注意，参数部份出现 / 应想到这是 rest 风格的参数和参数值。

防御措施方面，一定要将重置用户与接收重置凭证作一致性比较，通常直接从服务端直接生成，不从客户端获取。另外，密码找回逻辑中含有用户标识（用户名、用户 ID、cookie）、接收端（手机、邮箱）、凭证（验证码、token）、当前步骤等四个要素，这四个要素必须完整关联，否则可能导致任意密码重置漏洞。另外，HTTP 参数污染、参数未提交等问题，服务端也要严格判断。