【HackPwn2015】SmartCare破解细节分析

 

1、 目标介绍

SmartCare属于时下热门的互联网安防产品一类，实时监控家庭环境，推送到用户手机上。

 

 

SmartCare通信体系架构

SmartCare要实现用户手机与设备间实时的信息通信，必然要通过云端连连接两端，经过我们分析发现，SmartCare使用了如上图的通信结构，云平台使用MQTT协议分别与用户手机和设备（网关）建立连接，而在设备端网关又使用ZigBee与其他的传感器进行通信。本文将主要围绕，设备与云端来进行攻击，而不会涉及关于ZigBee与无线射频的内容。

        

2、分析部分细节

         对于这类设备主动反连云端的通信模型，要实施较大范围的攻击的主要手段就是从云端和通信协议入手。通过对APP逆向分析，我们能确定APP使用用户名和一个token（由用户名和密码通过http获取，在此不做深入）作为登陆凭证登陆进入MQTT

        分析发现，APP使用了SSL之上的MQTT，并加载了服务器证书和客户端私钥做双向认证，不过这并不能阻止攻击者的脚步，扫描服务器断开发现，服务器出了开启了APP中用到的1884端口以外，还开启了MQTT的默认端口1883，一阵小喜悦涌上心头，一试之下果然不出所料，1883端口是没有SSL的，连证书转换的步凑都省了!!!

        先写个程序连接上去，订阅所有频道，

 

        服务端登陆下发app和固件更新信息，如此便得到了设备固件的关键程序。

 

        简单分析了下固件的登陆流程，基本跟APP差不多，也是MQTT,有SSL,不同之处在于设备使用MAC地址作为MQTT用户名，用配置时APP发送给设备的密钥(由APP向云端请求生成)作为密码进行登陆，同时使用gateway/[mac]/commands等作为topic

        进一步测试之下发现，在登陆上MQTT之后，即使手机APP再次登陆，已经连接的会话也不会被强制下线，也就是说同一时间可能存在多个相同用户名的用户注册在MQTT服务器上，此处云端的消息派发便会面临挑战：云端如何确定消息被派发给了正确的用户呢？事实证明，此服务器并不能做到，此攻击的意义在于，我们能很方便的得到APP与设备间的MQTT消息镜像，对于进一步分析大有脾益。

如图，是APP发出控制指令，并收到回包的过程。

 

        有了这，再结合对APP和对固件的逆向，就不难分析出网关设备上线的流程，APP进入配置阶段后，会在局域网内寻找设备，并建立通信，然后APP会使用发现设备的Mac地址向云端申请Token(dev_token)，并把该token发送给设备，设备登陆MQTT服务器，并发送一个带dev_token确认包，确认上线，服务端就完成设备与APP之间的绑定，一方发出的消息才会被服务端转发给另一方。

 

伪造设备登陆MQTT:

        设备登陆之后发出的确认包非常有趣，没发送确认包的情况下，伪造设备与真实设备完全一样，而且用户并没有感知，我们既能用来监听之间的通信状态，也能主动发出假消息，造成加告警。

        而在发送了这个确认包之后，服务端会把我（攻击者）的手机号与我伪造的设备绑定，并且会让该设备与它原来绑定的设备解绑 ，用户就完全不会收到任何告警，并且除非手动重新登陆APP，用户不会知道自己的设备已经被人解绑劫持了。而攻击者实施这样的攻击只需要一个账号（免费注册）和目标设备mac地址。

 

3、  总结

本文围绕SmartCare与云端通信中存在的安全漏洞，对其脆弱性进行了尝试性攻击，能实现伪造任意设备告警，甚至强制解绑任意用户，达到使其安防功能完全失效的目的。

SmartCare这类设备使用单一控制节点连接互联网，本地再与其他设备建立通信（BLE,ZigBee…）也为攻击者引入了无限遐想，在这方面还有很多可以深入挖掘。