逻辑漏洞之密码找回

先上个图，是博客园其他大佬的一个导图，我个人看了十分受益，于是借鉴来使用，此博客也是我的学习总结，个人要从今日起记录自己学习的点滴，每周2-3篇，有关于自己学习渗透测试的经验和遇到的不同事情。

说来惭愧，从掌控学习完以来 陆陆续续的学习，学习效率很低很低，今天在被面试官打击了以后，觉得自己做一个博客，好记性不如烂笔头，自己把自己学的东西记下来，才是知道学了什么，学到了什么，而不是看过忘，忘过看，一问三不知。

先上个图吧

我结合图进行总结和学习，然后会尽量的找找类似的洞或者把其他相关文章进行总结节选，这篇文章主要还是参考 逻辑漏洞之密码找回总结 - mark-zh - 博客园 (cnblogs.com)主要是对自己的学习进行一个记录 先试行一下。

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

看到了beff上的yangyangwithyou的文章，感觉学习很多，我一个菜鸡做一下总结，写一遍整理一下 方便自己以后查阅。https://www.freebuf.com/articles/web/160883.html

案例一(2-1返回验证码) 2-1

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

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

他这个抓的应该是返回包 我找个网站试一下，这个也就是返回包包含验证码。啊 看论坛真的惊喜 随便找了一个站没找到验证码 但是看到id= 试了下 是宝塔 然后搜了一下宝塔 看到了一篇文章 用pycharm 写了一些代码来fuzz注入函数， 然后绕过狗进行了注入得到了数据 非常厉害 而且分享了脚本 https://www.freebuf.com/articles/network/262295.html
接下来分析一下上面这个，这个属于是暴露了返回凭证 也就是 脑图中的2-3返回短信验证码这类 属于返回凭证这一类
发现两者一致，那么，几乎可以确认服务端将密码找回的校验码泄漏至客户端，可导致任意账号密码重置问题。

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

的确是可行的，随便抓了个包 的确修改uname就可以判断存在与否
用字典可以进行爆破
尝试找回管理员账号的密码。从该网站的域名注册信息中找到联系人的邮箱为 fishliu@xxxx.cn，可推测后台用户的邮箱后缀为 @xxxx.cn，所以，用常见后台用户名简单调整可构造出后台用户邮箱字典，枚举出大量后台用户：

这就是常规操作了，whois查所有人然后找到常用的邮箱后缀然后找到管理员账户进行后渗透

案例2（返回token，导致伪造重置链接） 2-1

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

直接再提交邮箱后抓返回包 然后发现location 这个参数
显然是个重定向，isVerify、PassPhrase 这两个参数很可疑，后续交互中应留意，先放包，进入发送重置邮件的页面，输入验证码后提交。登录攻击者邮箱查看重置邮件：
这个带 token 的重置链接似曾相识，对，就是前面抓包获取的 token 信息，比对看下：

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

接下来验证通过服务端泄漏的 token 能否重置普通用户的账号密码。从重置流程可知，要重置密码必须提供用户名及其邮箱（或手机号）。
到这里也就是说 必须获得用户名和用户的邮箱，用之前的方法跑出用户名然后加上@qq 试验qq邮箱，正常完成密码找回逻辑，从交互包中获取服务端下发的重置 token： 可以看到就是a改成了c 对获得的token把他加上url和路径拼接进行访问就可以修改密码，这种是属于2-1 个人感觉 返回了token 然后很简单的拼接进了验证链接中

案例三(账户与手机号无绑定，导致修改手机号接受用户凭证) 7-1

接收端可篡改。请求包中包含接收端参数，可将凭证发至指定接收端
拦截请求，发现接收验证码的手机号为请求包中的参数：
直接篡改为攻击者的手机号，成功接收短信验证码，提交验证码后，正常执行 3、4 步即可成功重置该账号的密码。
怎么说呢 这种案例应该比较少见了 属于用户和验证不匹配，请求包修改就会把验证信息发出导致任意密码修改 属于7-1 账户与手机号码的绑定没有做到

案例4(通过 cookie 混淆不同账号，实现重置任意用户密码) 6-1

密码找回页面 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，前端显示重置成功：
这个案例讲的是格尼cookie里面的参数修改，导致cookie和账户没有进行绑定，从而产生的任意密码修改漏洞，应该是页面产生的这个phpsession的值会和前面开头输入的账号密码产生关联，第二次输入普通账号以后的页面这个phpsession的值没变但是关联的是普通账户，直接进行放直接抓的攻击者的数据包就会成功，还是有点没理解，这个根据我理解应该属于脑图的服务器验证最终提交步骤 也就是 6-1的方法

案例5 通过篡改请求包中的用户名参数，实现重置任意用户密码。 7-1

密码找回页面 http://www.xxxx.cn/getpass.html 用攻击者账号走完密码找回全流程，涉及三步请求，依次为：验证用户名是否存在、获取短信验证码、提交短信验证码和新密码。第三步的请求拦截如下：
各参数作用从其命名可了解。尝试将 accountname 参数值篡改为普通账号 zhangzhiqiang 后放行，应答为：
重定向至登录页面。用普通账号 zhangzhiqiang/PenTest1024 登录成功。
这个明显属于用户标识（用户名、用户 ID、cookie）和凭证（验证码、token）直接没有设立验证导致的

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

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

输入攻击者账号绑定的邮箱后点击“确认”，收到如下带 token 的密码重置链接：
该重置链接有两个地方引起我的注意：一是，NDI1NTg= 为 base64 编码，解码为 42558，正是攻击者账号的用户 ID；二是，这是个 REST 风格的请求。所以，尝试用普通账号的用户 ID 的 base64 编码替换 NDI1NTg= 后，成功重置该普通用户的密码。

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

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