经典开机登录框通过目录爆破,挖掘到一处Swagger文档泄露收获一枚未授权,且文档存在众多接口,此接口重点测试GET请求及接口名称为list相关,运气好会有信息泄露或者账号密码信息,虽然存在插件但是我还是习惯用swagger-hack-main工具提取出接口后,再用BP拼接接口访问单独处理,这样hae插件可以很快定位是否存在敏感参数

swagger-hack可以将文档中的接口提取,但注意提取的位置必须是泄露.json 如果是.html将无法提取,一般只要出现了首页的swagger同样也会指明json格式文档的路径,拼接.json路径得到新的泄露体

使用工具扫描,生成swagger.csv文件

python swagger-hack2.0.py -u  http://xxxxxx/swagger/v1/swagger.json

单独将里面的接口提出来,抓取一个首页包使用BP爆破

/api/driver/msl/module/type/api/driver/msl/module/list/api/driver/msl/channel/list/api/driver/msl/config/list/api/driver/msl/config/read/api/driver/simulation/list/api/driver/simulation/gw/list ..........

接口爆破未两种一种GET直接拼接再就是POST携带空JSON,都需要尝试

GET  /api/driver/msl/module/type---------------------------------POST Content-Type: application/json;{} 

并且swagger泄露页面一些接口本来也会带出请求体参数,可以直接在泄露页面发包测试或者是带入数据包测试

经过长达2分半时间的爆破,最终有多个接口出现内部的控制配置信息,以及多个账户密码泄露,

配置信息无法利用,故整理当前泄露的全部账号密码信息,尝试是否可以进入相关后台

"brokerIP":"xx.xxx161.59","brokerPort":1883,"clientID":"iot-driver-001","driverName":"MSL","clientName":"IoT Driver","userName":"msl_mqtt_user","password":"3HlcSiVhvalAq9JU",

"brokerIP":"xxx.xxxx.32.65","brokerPort":1883,"clientID":"iot-driver-003","driverName":"KNXMqtt Driver","userName":"msl_mqtt_user","password":"3HlcSiVhvalAq9JU",

"clientId":"msl_iot_226CC04AF6026B84","userName":"iot-driver-user001","password":"[email protected]%h>4*k18","name":"Client_Test_001",

目前得到了两个IP地址已及账号密码,密码应该是那种在第一次注册时浏览器所生成的强密码,但是却保存到了配置文件中,那么依次对IP进行查询,看看是否有相关登录口尝试一发入魂！

"brokerIP":"xx.xxx161.59","brokerIP":"xxx.xxxx.32.65",全部账号密码整理"userName":"msl_mqtt_user","password":"3HlcSiVhvalAq9JU","userName":"iot-driver-user001","password":"[email protected]%h>4*k18"

首先收集161.59 通过观察定位到此icon和上方接口泄露出的的mqtt服务有些相似,那么就从这里入手 存在两个登录口,

当我用泄露的密码直接登录以为能美美进入时,两个登录口却全部失败,第一个无任意有效反馈直接无法连接服务器另一个则是账号错误

我继续尝试把得到的2组账号密码来回变换,不同组合方式在两个登录口重新尝试进入,均一无所获,故先放弃转而进攻32.65资产,显示多个资产,一一尝试,只有2处是有效的

出现两个有效登录框,相关特征跟上面的第一个一致,再次进行密码碰撞尝试登录,同样一无所获,目前4个网站没有一点反馈,一度怀疑前面的信息中肯定是漏掉了什么,故回去再看swagger接口泄露寻找信息,企业都能把密码配置文件放到公网了未删除了,那么安全意识肯定非常薄弱,我坚信这一点才一直会想去尝试

重新整理好接口泄露所有出现name相关字段的值,再次尝试对这4个登录框碰撞仍旧无法正确登录后台

"clientName":"IoT Driver","driverName":"KNXMqtt Driver","name":"Client_Test_001",

思考一下从企业人员视角出发,大多密码账号会和单位简写有关,企业简称参数正是MSL 并且接口泄露出的一个name值也出现了MSL

重新测试来到登录口,逐一测试,来到第一个登录口无任何响应

来到第二个地方测试,通过两次账号不同所返回的响应,有经验的大佬已经发现了,典型的用户名枚举情况啊,但这里给出我的提示却是证明我的猜想是正确的,MSL企业简称正是系统的登录有效用户名

这里我已经非常开心了,已经幻想自己进入后台,但是当我将前面所获得的密码再次进行用户名不变密码改变的情况爆破时,仍然无法进入.....而后继续按照此方式对其他的登录框进行操作,但是其他登录框并无用户枚举情况,但我还是将MSL 作为用户名配合上方得到的密码进行爆破, 仍就一无所获,哈基W,....还是办不到吗

经历上述操作仍无法出货,真的很想关掉BP直接换站,但测试肯定是需要将所有思路全部穷尽,后开始上字典对第二个登录框爆破,寄希望与管理员未设置强密码,只针对用户名做了企业简写的操作

很难想象,第一个就出了....那我之前的信息收集 多个站来回碰撞算什么.....算我有耐心吗,我好像一拳打在了棉花上,我原以为弱口令真正意义上并不算一个漏洞,现在发现我对这个漏洞一无所知

![图片](https://mmbiz.qpic.cn/mmbiz_png/WAyrRuvrubEfP4slJ