一场"半途中止"物联网系统应用安全检测.

检测背景:学校直饮机 引入物联网设备,用户体验下降,用水费用反而升高几倍...虽然很不满..但是懒人又不愿意烧水喝,还是只能喝直饮机的水. 在使用的同时也对,此系统的架构产生一点点兴趣.....所以....

声明:非专业安全人士,,,仅仅一时xing起...

1.未采用https协议,利用charles简单抓包.

抓包过程

  1.笔记本开启自带wifi,手机连上,开上charles.
  2.打开手机端控制app...进行一系列操作,同时关注charles  .
  3.focus 饮水机控制app 发出的http链接
  4.分析一系列http 头部报文

图一

分析结果

  1.app内置多个host地址...估摸是防止其中某个服务挂掉 影响用户使用吧...
  2.如图一所示  采用类似于jwt 协议认证 （不是jwt，下面会说）
(看到这里的时候 我就知道 基本上随便刷水的可能性不大了..因为估摸所有的接口都            要走验证拦截器.....除非进一步深究...)
  3.通过不断登录获取新的token,发现token 构造有点小规律...前十位不变...估摸是什么跟用户相关的东西,,,虽然目前一点卵用都没有....

2.根据抓包host,访问管理端寻找入口

---

似乎通过抓包看不到什么....于是 想着去看看管理端的漏洞...
于是直接访问....host地址 跳转到 管理端接口....
分析前端代码 得出 也是一套前后端分离的模式

...然后下面就是对于前端代码的各种分析了..

图二

看到这里不免吐槽一下....原来这个平台还有这么多品牌的直饮机在用..所以外面的饮水机 套个牌子...租用一下别人的平台...水价 就翻翻翻翻上涨...?????

图三

根据图三 看到必要js路径资源...剩下的就是慢慢翻了..看看有没有什么可以利用的

图四

看到这里 就知道 原来 token的组成部分 果然如上面的猜测

图五

....终于看到了精华...文件上传接口...包括参数构造形式...于是....

3.postman测试文件上传接口.仅过滤用户权限,未过滤文件类型.

图六

虽然此处折腾了很久...但是还是顺利 成功构造成功...header中.auth中uid必须和form-data中uid 相同... 也并未测试上传文件能否正常解析...但是估摸静态资源文件

如题了....到了此步 为了避免fz.建立空文件.更改后缀上传 成功返回路径.....全程未获取任何目标计算机控制权.....