实现一个业务功能,也有着很多不同的实现方式,当业务逻辑考虑不严谨的时候,同一个业务功能模块存在着很多漏洞场景,如密码重置漏洞、商城支付漏洞等。
本文分享一个有意思的案例,通过漏洞组合实现任意密码重置,同时,也是验证码验证一次有效的利用场景。
1、在这个密码重置模块里面,只需输入手机号和手机验证码即可进入修改密码界面,看到这个界面,很多人会尝试暴力破解,但会发现验证码仅能使用一次,爆破成功,但输入的时候已经失效了,怎么办?
2、 我们填写用户的手机号码,获取验证码,随意输入几个验证码,抓包:
我们注意到返回的是失败,如果返回成功,是什么样子呢?通过测试,如果验证码输入正确,返回{"data":"success"}。
3、修改返回包为{"data":"success"},即可绕过验证码验证,进入修改密码界面。
4、在这里,输入两次新密码,提示密码修改失败。查看HTTP交互过程,Token值不变。猜想:如何把Token变成有效的,这样才能修改成功。
{"Token":"eyJhbGciOiJIUzI1NiJ9.eyJpczMiOiJmYW5ydWFuIiwiaWF0IjoxNTYyOTI0MzUxLCJzdWIiOiIxaDA0MDI5OSIsIgp0aSI6Imp3dCJ9.Mo0KuEZwOuT6pPsJCydgKD-qVjIieaVAWDX7tchk4NY","newPassword":" IGFiY2RlMTIz"}
5、这里,我们利用系统的另一个缺陷,因对手机验证次数没有限制,遍历000000-999999区间,暴力破解手机验证码,成功后返回success
6、此时,输入用户新密码,保存后修改成功。
简单来说,这个漏洞场景是这样:
A、前端验证绕过可以直接进入密码修改界面,但Token无效,无法成功修改密码。
B、手机验证码可以暴力猜解,但验证码一次失效,爆破出来再输入验证码无效。
这个时候,通过A+B的漏洞组合,利用前端验证绕过进入修改密码界面,暴破验证码使Token生效,就可以实现任意密码重置漏洞 。
漏洞往往就隐藏在一些细节里面,在渗透测试中,去分析请求中的每个参数,并注意检查页面返回的源代码。比如,当参数拼接到SQL中执行,就存在SQL注入,当参数直接输出到前端,就存在XSS跨站脚本。
似乎很难再找到人去分享,发现一种新的漏洞利用场景的喜悦。
----致那些曾经一起玩渗透的朋友。