欢迎来到 无奈人生 安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

任意用户密码重置(二):重置凭证接收端可篡改

来源: 作者: 时间:2019-02-24 21:00 点击: 我要投稿
广告位API接口通信错误,查看德得广告获取帮助

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

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

案例一:接收端可篡改。请求包中包含接收端参数,可将凭证发至指定接收端。
密码重置页面,输入任意普通账号,选择手机方式找回密码。在身份验证页面点击获取短信验证码:

拦截请求,发现接收验证码的手机号为请求包中的参数:

直接篡改为攻击者的手机号,成功接收短信验证码,提交验证码后,正常执行 3、4 步即可成功重置该账号的密码。
案例二:接收端可篡改。请求包中出现接收端间接相关参数,可将凭证发至指定接收端。
在密码找回页面,用攻击账号 test0141,尝试重置目标账号 2803870097 的密码(对滴,你没看错,这两个长得完全不像的账号的确是同个网站的)。
在第一个首页中输入 test0141 和图片验证码完成“01 安全认证”:

请求为:

输入图片验证码获取短信验证码完成“02 身份验证”:

请求为:

后续的 03、04 步不涉及用户名信息,忽略。
全流程下来,客户端并未直接提交接收短信验证码的手机号,多次尝试可知,02 中出现的 user_name 用于查询下发短信的手机号,用它可以间接指定接收端,那么,它是否仅此作用而不用于指定重置密码的账号?如下思路验证,先将 userName 置为 2803870097 完成 01 以告诉服务端重置的账号,再将 user_name 置为 test0141 完成 02 以欺骗服务端将短信验证码发至攻击者手机,顺序完成 03、04 或许能实现重置 2803870097 的密码。具体如下。
第一步,用普通账号 2803870097 进行安全认证:

第二步,对普通账号 2803870097 进行身份验证:

拦截发送短信验证码的请求:

将 user_name 从 2803870097 篡改为 test0141,控制服务端将验证码发至 test0141 绑定的手机号:

test0141 的手机号成功接收到验证码 872502,将该验证码填入重置 2803870097 的身份校验页面后提交:

第三步,输入新密码 PenTest1024 后提交,系统提示重置成功:

第四步,用 2803870097/PenTest1024 登录,验证成功:

防御措施方面,一定要将重置用户与接收重置凭证的手机号/邮箱作一致性比较,通常直接从服务端直接生成手机号/邮箱,不从客户端获取。
 

在逻辑漏洞中,任意用户密码重置最为常见,可能出现在新用户注册页面,也可能是用户登录后重置密码的页面,或者用户忘记密码时的密码找回页面,其中,密码找回功能是重灾区。我把日常渗透过程中遇到的案例作了漏洞成因分析,这次,关注因重置凭证接收端可篡改导致的任意用户密码重置问题。 内容来自无奈安全网

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

copyright 无奈人生

案例一:接收端可篡改。请求包中包含接收端参数,可将凭证发至指定接收端。
密码重置页面,输入任意普通账号,选择手机方式找回密码。在身份验证页面点击获取短信验证码:

拦截请求,发现接收验证码的手机号为请求包中的参数:

直接篡改为攻击者的手机号,成功接收短信验证码,提交验证码后,正常执行 3、4 步即可成功重置该账号的密码。
案例二:接收端可篡改。请求包中出现接收端间接相关参数,可将凭证发至指定接收端。
在密码找回页面,用攻击账号 test0141,尝试重置目标账号 2803870097 的密码(对滴,你没看错,这两个长得完全不像的账号的确是同个网站的)。
在第一个首页中输入 test0141 和图片验证码完成“01 安全认证”:
无奈人生安全网
请求为:

输入图片验证码获取短信验证码完成“02 身份验证”:

请求为:

后续的 03、04 步不涉及用户名信息,忽略。
全流程下来,客户端并未直接提交接收短信验证码的手机号,多次尝试可知,02 中出现的 user_name 用于查询下发短信的手机号,用它可以间接指定接收端,那么,它是否仅此作用而不用于指定重置密码的账号?如下思路验证,先将 userName 置为 2803870097 完成 01 以告诉服务端重置的账号,再将 user_name 置为 test0141 完成 02 以欺骗服务端将短信验证码发至攻击者手机,顺序完成 03、04 或许能实现重置 2803870097 的密码。具体如下。

www.wnhack.com

第一步,用普通账号 2803870097 进行安全认证:

第二步,对普通账号 2803870097 进行身份验证:

拦截发送短信验证码的请求:

将 user_name 从 2803870097 篡改为 test0141,控制服务端将验证码发至 test0141 绑定的手机号:

test0141 的手机号成功接收到验证码 872502,将该验证码填入重置 2803870097 的身份校验页面后提交:

无奈人生安全网



第三步,输入新密码 PenTest1024 后提交,系统提示重置成功:

第四步,用 2803870097/PenTest1024 登录,验证成功:

防御措施方面,一定要将重置用户与接收重置凭证的手机号/邮箱作一致性比较,通常直接从服务端直接生成手机号/邮箱,不从客户端获取。
 
内容来自无奈安全网

。 (责任编辑:admin)
【声明】:无奈人生安全网(http://www.wnhack.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱472701013@qq.com,我们会在最短的时间内进行处理。