一次物联网设备app的渗透测试经历
起因
因租房遇到门禁卡绑定，需要下载app才能实现开门禁，本着想试试遇到了不能放过的精神开展了测试，测试目的是为了实现越权开其他单元门 首先通过已知账户（已绑定单元门为某小区3栋2单元）
过程
前期准备
首先配置夜神模拟器和bp代理抓包
打开app开始登录抓包
离线开锁
发现登录过程分为三步
第一步与服务端进行账号密码校验，返回200成功密码通过校验
第二步，发送账号和密码（明文）获取当前用户user_id
Ps:如果是等保的话这应该密码明文传输应该也算个洞吧
第三步客户端通过第二步的返回的user_id
作为请求参数,获取用户可绑定的门禁信息（已知账户绑定的是某小区3栋2单元)
修改user_id由341412
改为341411
测试下发现请求可以更改绑定
点击后来到主页面（过程中无发包）
本以为绑定之后直接点击钥匙开锁就可以了,但是看到了回显是用户无权限开门
首先修改将用户id由341412
改成341411
测试，判断是不是用户id不对导致的无法开锁，事实证明不行
然后想起之前在使用app的时候，发现app存在当网络不好可以通过离线密码开锁
，进行抓包不放让app进入离线密码生成逻辑，出现开锁密码
由于修改的用户id碰巧在一个小区，且离线密码有效时间很长（没统计，不过近缘时间够），遂下楼前往所在单元
最终采用离线密码的方式完成越权开锁，至此通过离线开锁密码方式完成越权
。
在线开锁
还是比较纠结第一种为什么无法开门，接下来测试下第一种在线开锁的方式，先用正确的绑定信息登录并绑定到3栋2单元门禁，抓包在线开锁。
正常在线开锁的请求包的响应包响应体返回为空，提示正常开门成功，也去我所在的单元看到确实开锁成功，接下来判断后端校验开门逻辑。
首先对请求包中的挨个进行修改
（room_id，device_type，door_guid，device_guid，type，token，user_id，door_id）
经过修改发现当对
（device_type，door_guid，type，token）
修改均无影响开锁 而当修改
（room_id,device_guid,user_id,door_id）
会产生不同的影响,当修改room_id
会显示
当修改device_guid
会显示
因为根据之前的请求包发现device_guid是登录抓包过程中，app生成出的数值，修改后也可登陆成功，判断是与user_id作为绑定的但是值可编辑，故对开锁无影响只要值对就可以
当修改user_id
会显示
当修改door_id
会显示
综上得出以下结论:
-
1. 将正确的用户id修改成没有和当前门禁绑定的id时显示无权限，所以权限方面应该首先满足
-
2. Room_id和device_guid和door_id，这三个参数后台会首先进行校验判断是否对应，之后才会判定用户权限
故开始寻找其他功能点获取更多信息开始测试其他功能模块，自助授权感觉可以先试试
点开之后抓包发现当点击时app会向服务器发送一个请求获取用户信息
包括了用户的住址，token值，手机号，以及room_id等信息），主要请求参数时mobile_no也就是手机号，因为现在虽然可以更改user_id但是暂时获取不到对应的手机号。
点开之后发现该功能是给租户提供自助绑定门禁的功能，并且查看看到用户申请记录，抓包改user_id
修改了几个id后发现存在越权并在user_id=341413
时存在申请记录信息并且可以看到租户的手机号，姓名，以及详细到门的地址，还有绑定有效期，因为当前目的是为了开锁，所以因越权导致的租户信息泄露的影响面随后评估。
现在通过修改user_id获取到了该user_id对应的租户手机号
，所以开始重放步骤一的请求包
但现在为止可以掌握的是开锁的两个要素user_id
和room_id
还差door_id
和device_guid
对抓包记录分析，发现当用户绑定登录后就存在一个请求包，获取信息的参数需要知道room_id
和user_id
，这两个参数已经在上一步获取的用户信息中拿到的所以构造出请求包，拿到door_id
构造开锁请求包
将对应的信息填入发现返回值也为空，判断开锁成功（因为近缘成本较高没去成） 实现开锁后开始评估门禁影响范围 通过自助授权功能获取门禁数量
通过dep_id小区id获取小区单元表
通过遍历爆破，获取受影响的单元数7607个
测试结果
经过分析数据该漏洞可影响小区共188个，影响单元门7607个 在对自助绑定申请记录数据泄露影响范围评估，通过对用户信息进行遍历步长为1000进行判断初步判断数据泄露信息在38w左右
