不乱于心,不困于情。
不畏将来,不念过往。如此,安好。

业务安全之任意用户密码重置总结(一)

一、重置凭证泄漏

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

案例一

用邮件找回密码时,作为重置凭证的验证码在 HTTP 应答中下发客户端,抓包后可轻易获取。先用攻击者账号走一次密码找回流程,测试账号 yangyangwithgnu@yeah.net 选用邮箱找回密码:

点击获取校验码后抓取如下应答:

其中,VFCode 从字面理解很可能是校验码。登录邮箱查看网站发过来的密码找回邮件:

发现两者一致,那么,几乎可以确认服务端将密码找回的校验码泄漏至客户端,可导致任意账号密码重置问题。

尝试找回普通账号的密码。密码找回首页输入邮箱后,系统将立即校验该邮箱是否注册:

将 UName 参数定义为枚举变量,以常见 qq 邮箱作为字典,可枚举出多个有效邮箱:

以 chenwei@qq.com 为例,在应答包中找到校验码,成功将其密码重置为 PenTest1024,验证可登录:

尝试找回管理员账号的密码。从该网站的域名注册信息中找到联系人的邮箱为 fishliu@xxxx.cn,可推测后台用户的邮箱后缀为 @xxxx.cn,所以,用常见后台用户名简单调整可构造出后台用户邮箱字典,枚举出大量后台用户:

同理可重置这些后台用户的账号密码,为避免影响业务,不再实际操作。

案例二

用邮件找回密码时,带凭证的重置链接泄漏至客户端,抓捕可获取。用攻击者账号走一次密码找回流程。在找回密码页面输入攻击者账号及其邮箱(yangyangwithgnu、yangyangwithgnu@yeah.net)后提交:

拦截如下应答:

显然是个重定向,isVerify、PassPhrase 这两个参数很可疑,后续交互中应留意,先放包,进入发送重置邮件的页面,输入验证码后提交。登录攻击者邮箱查看重置邮件:

这个带 token 的重置链接似曾相识,对,就是前面抓包获取的 token 信息,比对看下:

forgotPwdEa.php?isVerify=eWFuZ3lhbmd3aXRoZ251fHlhbmd5YW5nd2l0aGdudUB5ZWFoLm5ldHw2MzQyNDkw&PassPhrase=01e4f6d4ede81b2604dc320bc4e3a6e8
forgotPwdEc.php?isVerify=eWFuZ3lhbmd3aXRoZ251fHlhbmd5YW5nd2l0aGdudUB5ZWFoLm5ldHw2MzQyNDkw&PassPhrase=01e4f6d4ede81b2604dc320bc4e3a6e8

唯一区别 forgotPwdEa 和 forgotPwdEc 两个文件名。

接下来验证通过服务端泄漏的 token 能否重置普通用户的账号密码。从重置流程可知,要重置密码必须提供用户名及其邮箱(或手机号)。

获取有效用户名。注册页面中,输入用户名后立即校验该用户名是否被占用:

对应请求、应答如下:

用户名已存在返回 failed,不存在返回 ok。以此特征,用常见国人姓名字典,可枚举出大量有效用户名(如 chenchuan、chenanqi、chenanxiu、zhangfeng 等等),存为 username.txt。

获取有效用户名对应邮箱。密码找回首页提交的请求中,user_name 与 email 参数匹配情况下,HTTP 应答代码为 302,交互包如下:

可以此特征枚举有效用户名及其邮箱。现在考虑如何制作邮箱字典?很多用户喜欢用用户名注册 qq 邮箱,换言之,用户名 yangyangwithgnu 可能对应邮箱 yangyangwithgnu@qq.com。所以,用前面已经获取有效用户名字典 username.txt 快速制作了邮箱字典 qq-email.txt,其中,username.txt 与 qq-email.txt 逐行对应。

例如,前者第一行为 yangyangwithgnu、后者第一行为 yangyangwithgnu@qq.com。将上面的数据包放入 burp 的 intrduer 中,攻击类型选 pitchfork、user_name 的参数值定义为枚举变量 1 并加载字典 username.txt、email 的参数值定义为枚举变量 2 并加载字典 qq-email.txt,可枚举出大量有效用户名/邮箱信息,如,zhangfeng/zhangfeng@qq.com、chenchuan/chenchuan@qq.com 等等。

用普通账号 chenchuan/chenchuan@qq.com 演示密码重置漏洞。输入用户名、密码提交,正常完成密码找回逻辑,从交互包中获取服务端下发的重置 token:

isVerify=Y2hlbmNodWFufGNoZW5jaHVhbkBxcS5jb218MTE2MDIzNw==&PassPhrase=cbf0160662358808f3586868f041cbaa 

拼装为重置链接 http://www.xxxx.com/user/forgotPwdEc.php?isVerify=Y2hlbmNodWFufGNoZW5jaHVhbkBxcS5jb218MTE2MDIzNw==&PassPhrase=cbf0160662358808f3586868f041cbaa ,访问之,即可进入密码重置页面:

输入新密码 PenTest1024 后系统提示修改成功。用 chenchuan/PenTest1024 成功登录:

防御措施上,密码找回的凭证切勿下发客户端,另外,校验邮箱是否有效应添加图片验证码,以防止关键参数被枚举。

二、重置凭证接收端可篡改

密码找回逻辑含有用户标识(用户名、用户 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 登录,验证成功:


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

三、用户混淆

这次,关注因用户混淆导致的任意用户密码重置问题。

案例一:通过 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 参数污染、参数未提交等问题,服务端也要严格判断。

四、重置凭证未校验

这次,关注因重置凭证未校验导致的任意用户密码重置问题。

在日常对密码找回功能的攻击中,我的大部份精力聚焦在是否可以暴破验证码、是否可以劫持接收验证码的手机号或邮箱、是否可以混淆重置其他账号、是否可以绕过验证步骤、甚至是猜测重置 token 的生成规律等攻击方式上,反而忽略了最容易、最低技术含量的一种方式——服务端未校验重置凭证。换言之,不论你输入的重置验证码或密保答案是否正确,只要请求格式无误,均可成功重置任意账号密码。我举两个真实案例(漏洞均已修复,就不打码了),你感受下。

案例一:因服务端未校验 token 导致可重置任意账号密码

密码找回页面 http://www.omegatravel.net/users/retrievePassword/ 用攻击者账号 yangyangwithgnu@yeah.net 进入密码找回全流程,输入图片验证码后提交:

随后收到带 token 的密码重置链接的邮件:

其中,key:FqvICT 和 userEmail:yangyangwithgnu@yeah.net 引起了我的注意。正常来说,提交该 URL 后,服务端会校验 key 与 userEmail 是否匹配,若匹配则进入提交新密码页面,若不匹配则报错。现在,我尝试将 key 从 FqvICT 改为 xxxxxx 后再访问,本来心理预期将看到报错页面,没想到进入了新密码提交页面,难倒所谓的重置 token 仅仅是个摆设?

赶紧找个账号试试,就拿信息收集时找到的 travel24@omegatravel.net 为例(更多后台账号见后文)。参照前面收到的重置链接格式,简单拼装为 http://www.omegatravel.net/users/retrievePasswordReset/key:xxxxxx/userEmail:travel24@omegatravel.net,是滴,key 的值我随便写的,访问看看,哇,居然真的进入了新密码提交页面:

输入新密码 PenTest1024 后提交,网站提示“修改密码成功”。尝试用 travel24@omegatravel.net/PenTest1024 登录,成功进入系统:

如何获取其他账号?从注册页面可知,该网站只能用邮箱注册,邮箱即账号。我关心普通用户和内部员工用户两类账号(即邮箱)。普通用户的邮箱字典方面,把国人常见姓名拼音 top500 结合常见邮箱后缀(@qq.com、@163.com 等等)快速生成个简单邮箱字典;内部员工的邮箱方面,我从该网站域名注册信息查询到联系人为 omegait@omegauk.net,说明该公司使用 @omegauk.net 的邮箱后缀,同上,把国人常见姓名拼音 top500、常见后台账号,结合 @omegauk.net 邮箱后缀,快速生邮箱字典;另外,从“联系我们”、“诚聘英才”、“公司简介”等页面找到大量内部员工邮箱和合作伙伴邮箱,如 info@jadetravel.co.uk、info@ukchinese.com 等等:

将以上几类邮箱字典存为 mail.txt 也就是用户名。

这样,我不仅可以重置普通账号的密码,还能劫持大量内部员工、合作伙伴的账号,为避免影响业务,不再实际操作。

案例二:可枚举无密保的用户名,导致任意密保答案均可重置密码

在密码找回页面 http://www.hzpzs.net/u_findPassword.asp 输入有效用户名 yangyangwithgnu 后拦截请求包:

猜测该数据包用于用户名有效性校验,放至 repeater 中分析。

由于没用图片验证码,导致可枚举有效用户名,发现三类情况。一是,用户名存在且设置过密保问题,应答类似:

二是,用户名存在但未设置密保问题,应答类似:

三是,无效用户名,则应答类似:

用常见用户名和中国人姓名拼音作为字典进行枚举,在所有结果中过滤显示含有关键字 <td width=”65%”></td> 的应答,得到的所有 UserName 参数值即为未设置密保问题的用户名。如:aaron、admin、adolph、alisa、chenchen、esther、jones 等等。

按正常流程,对 chenxin 进行密码重置,输入任意密保答案均可重置密码:

加固措施

密码重置凭证一定要严格校验,空密保问题时禁止通过密保找回密码;服务端应限制枚举等恶意请求。

赞(0)
未经允许不得转载:seo优化_前端开发_渗透技术 » 业务安全之任意用户密码重置总结(一)