zoukankan      html  css  js  c++  java
  • 任意用户密码重置(二):重置凭证接收端可篡改

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

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

    前情提要:【传送门


    案例一:接收端可篡改。请求包中包含接收端参数,可将凭证发至指定接收端。

    密码重置页面,输入任意普通账号,选择手机方式找回密码。在身份验证页面点击获取短信验证码:

    image.png

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

    image.png

    直接篡改为攻击者的手机号,成功接收短信验证码,提交验证码后,正常执行 3、4 步即可成功重置该账号的密码。


    案例二:接收端可篡改。请求包中出现接收端间接相关参数,可将凭证发至指定接收端。

    在密码找回页面,用攻击账号 test0141,尝试重置目标账号 2803870097 的密码(对滴,你没看错,这两个长得完全不像的账号的确是同个网站的)。

    在第一个首页中输入 test0141 和图片验证码完成“01 安全认证”:

    image.png

    请求为:

    image.png

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

    image.png

    请求为:

    image.png

    后续的 03、04 步不涉及用户名信息,忽略。

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

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

    image.png

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

    image.png

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

    image.png

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

    image.png

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

    image.png

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

    image.png

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

    image.png

     

    本文原创作者:yangyangwithgnu  转自 www.freebuf.com

  • 相关阅读:
    poj 2676 Suduku (dfs)
    poj 1562 Oil Deposits (dfs)
    poj 2907 Collecting Beepers (dfs)
    poj 1655 Balancing Act (树形dfs)
    poj 3411 Paid Roads (dfs)
    hdu 2896 病毒侵袭 (AC)
    hdu 3065 病毒侵袭持续中 (AC)
    poj 2251 Dungeon Master (bfs)
    java中debug使用
    Swing入门级小项目总结
  • 原文地址:https://www.cnblogs.com/lic1005/p/8690533.html
Copyright © 2011-2022 走看看