任意用户密码重置(三):用户混淆

2018-02-08 414850人围观 ,发现 34 个不明物体 WEB安全

*本文原创作者:yangyangwithgnu,属于FreeBuf原创奖励计划,禁止转载

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

前文:任意用户密码重置一

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


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

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

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

image.png

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

image.png

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

image.png

输入重置验证码:

image.png

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

image.png

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

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

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

image.png

尝试用 liuwei/PenTest1024 登录:

image.png

成功进入系统:

image.png

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


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

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

image.png

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

image.png

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

查看个人信息:

image.png

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

查看视频监控设备列表:

image.png

视频监控设备登录信息:

image.png

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

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

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


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

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

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

image.png

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

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


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

*本文原创作者:yangyangwithgnu,属于FreeBuf原创奖励计划,禁止转载

这些评论亮了

  • yangyangwithgnu (5级) 任何事情都有无穷乐趣 回复
    @ 风在指尖  PHPSESSID 是找回密码时关联的管理员账号,并非登录后关联的管理员账号。前者,只需用管理员账号发起密码找回流程即可;后者,你得需要密码才行。
    )10( 亮了
发表评论

已有 34 条评论

取消
Loading...
css.php