赏金猎人|兜兜转转拿下平台充值漏洞

0x01 前言

        业务平台为网络虚拟商品，此次做被动信息收集，本着也是平台老用户的心态，做好事不留名，看看有无逻辑漏洞及手工测试漏洞，各位师傅们测白盒审代码撸洞永远是我追随的目标

此处说明关于公众号发布的应急响应平台公告如下

平台运营及开发正在紧急更新新功能平台将正式公测：具体时间待定发出、很快注册方式还是注册码+邮箱、注册码将批量发放、基本人人可得此外、欢迎投稿应急响应相关的镜像及writeup(目前只收录应急响应)优先关注公众号的同学优先获取注册码

* 本文中涉及漏洞已报送厂商修复、本文仅限技术讨论和研究、严禁非法用途、否则产生后果自负

0x02 思路历程

                       测试用例撞库验证码漏洞支付漏洞反向充值

在逛平台的时候，适当的点点刷刷的状态已经成为习惯，查看一些功能及包的顺序去猜测是否存在某些漏洞

映入眼帘的是余额转账，起初我认为的是将本账号内余额转入到其他账号，因为有验证码，首先测试一下验证码漏洞是否存在

经过一番测试使用两个手机号加逗号分隔，放包、拿到验证码漏洞

好好好，GOOD，按照前面思路，就想看看是否能越权，但是在身份标识处尝试失败了、平台根据用户账号生成session及时间戳进行验证

那么就换个角度去想，目前已知存在验证码漏洞，平台是否有校验用户是否存在功能，尝试在忘记密码处测试

第二个思路尝试成功，并且平台使用的验证码平台经过验证后，所获取的ID在3-5分钟内不失效，可以利用此BUG进行多线程撞库，查看是否存在某用户

经过撞库后成功获取到存在的手机号、再根据之前的思路，验证码漏洞去改密码，但是此时验证码漏洞利用失败

后面试了很多方法，猜测是平台在校验时后端直接进行select语句查询了此字段，然后直接返回结果

此时思路陷入了僵局、先去研究一下支付是否存在漏洞，在抓包后，逐个查看包的内容，顺序、猜测包的功能并改动

平台首先会生成一个包，对于金额及个人信息等，生成一个ID、MD5

然后前端携带ID到后端对接的ZFB的API生成并跳转到支付页面

最后JS监听支付状态是否成功

最后通过修改信息、替换订单号的方法测试失败、API会对包内金额进行校验、无法替换

在最后支付成功替换订单号的时候、接口会二次校验、充值失败告终

辗转反侧又跑到余额转账处摸索、看到明显字眼、平台只能在另一个业务平台进行余额互转，试一下说的啥意思

好好好、忙活半天互转是这个意思、但是也没见过另一个旁站地址，信息收集一下

经过打点信息、找到了业务旁站并且找到了一个后台管理系统，没见过这个CMS，根据icon查一下，看到还不少

算了，跑题了，这个站后续再说、先注册好旁站账号，试一下转账到底啥情况

转出成功了，看一下、纳尼，为什么我的旁站余额还是0，然后我的账户倒欠平台-7

这就没意思了吧、这也说明平台在没有校验余额的情况下进行了扣除，先不说余额是否转出的问题，估计是那边人工去校验的，在转出，不自动同步数据，假设我利用负负得正的原理进行转账呢

最后可以使用负负得正的方法进行反向充值余额到本账户

中国功夫、点到为止、打完收工

0x03 结语

目前此漏洞官方已修复、对当前账户余额进行校验、其次对特殊符号进行过滤

在进行逻辑漏洞挖掘时、在个人不多经验来看就是对平台已有功能对注意、分析包内数据、多思考会有很大很多的发现

思路仅供分享、请勿滥用违法传播。后果自负哦！

原文始发于微信公众号（州弟学安全）：赏金猎人|兜兜转转拿下平台充值漏洞