论文题目：Discovering and Understanding the Security Hazards in the Interactions between IoT Devices， Mobile Apps， and Clouds on Smart Home Platforms
论文作者： Wei Zhou， Yan Jia， Yao Yao， Lipeng Zhu， Le Guan， Yuhang Mao， Peng Liu and Yuqing Zhang
作者单位：中国科学院大学国家入侵防范中心，西安电子科技大学，美国佐治亚大学，美国宾夕法尼亚州立大学
论文地址：https://www.usenix.org/system/files/sec19-zhou.pdf
一、物联网云平台架构
现阶段随着物联网技术的发展，智能家居也得到了广泛应用。为了方便集中管理众多的智能家居设备，国内外许多知名的IT厂商如三星、阿里巴巴、京东和小米等均推出了自己的智能家居云平台。虽然各家厂商在实现上有细节上的差别，但整体架构基本相似。如图1所示，云平台主要包括三大交互实体(云服务，移动端APP，物联网设备)。云服务作为整个智能家居云平台的核心主要负责设备管理，远程指令转发以及设备联动服务等；物联网设备常见有两种连接云的方式，对于有具备互联网功能的设备大多可以直接和云服务建立连接，而对于只能通过zigbee或者蓝牙的连接的小型设备需要通过一个中间路由(Gateway/Hub)来和云进行交互；最后，移动APP端为用户提供操作设备的接口如连接、断开和注销设备等。
另一方面为了方便对大量的物联网设备进行部署，这些智能家居平台往往会开发设备端交互SDKs包括一些常用的交互指令和协议实现，这样物联网设备应用开发的时候只需要将这些SDK和特定的设备功能进行结合即可，大大缩短了设备开发周期。
图1 云平台整体架构
二、常见物联网云平台交互过程
通过进一步对云平台三方交互过程的进一步分析，论文总结常见设备使用周期(从设备首次连接到设备注销)过程中涉及的基本交互步骤。注：由于在设备注册和绑定步骤实现上的差别本文将云平台分为了两类，但其原理相似，本文只介绍其中的Type1，另一种详见论文。
1.设备发现：APP 一般通过广播的方式和设备进行识别和连接。
2.提供WIFI证书：为了使设备可以通过互联网和云服务进行交互，APP需要向设备提供Wi-Fi证书，其主要方法包括自建热点、Wi-Fi直连和 SmartConfig。
3.设备注册：设备通过向云发送其独一无二的物理信息如MAC地址来完成设备注册，并从云端获取设备标识码device ID。云端也会记录此ID作为此设备的标识用于后续交互。
4.设备绑定：为了保证只有设备所有者有控制对应设备的权限，用户需要通过APP申请设备绑定。从而云将此用户信息和设备device ID进行一一绑定。后续云平台只允许此用户才可以控制对应ID的设备，拒绝其他用户对用户对此ID设备的控制命令。
5.设备登录：完成设备绑定后，设备申请和云建立并维持一个长连接，同时，如果发现长时间和云没有交互会自动重新进行连接。
6.设备使用：完成1-5步骤后，设备处于正常工作状态可以接受并执行云和用户的远程操作指令。
7.设备注销：当用户不想再使用此设备如转让给他人，其可以用APP向云发送申请解绑设备的操作从而云平台解除其与设备的绑定关系，并重置设备使三方实体均回到初始状态。
通过分析每个步骤中智能家居平台三方实体的交互过程，从而得到三方实体各自交互过程中导致的正常工作状态的转换模型如图2所示，注意：三方实体的工作状态并不是相互独立而是通过交互存在一定的对应关系。
图2 转换模型
注:红色代表Type1智能家居平台特有的交互请求和状态，蓝色代表Type2智能家居平台特有的交互请求和状态，黑色代表共有的交互请求和状态。
三、云平台安全分析方法
首先为了分析三方交互的细节，论文采用逆向、中间人和其他证书绕过等方法解密了三方通信。然后为了检查云平台三方交互过程中是否存在异常请求和工作状态，需要发送非正常的设备请求。为了实现此目的，论文通过利用和修改原有通信SDK，构建一个模拟真实设备交互的“幽灵”设备，从而实现无论云和APP处于任何状态，都可以发送任意设备请求。
四、漏洞总结与分析
通过对云平台认证、授权和状态管理的实验，论文在五大知名智能家居平台发现了如下四种常见的安全漏洞，如图3所示。
图3 四种常见的安全漏洞
F1不充分的状态防护：通过实验发现，云平台在接受设备请求的时候，并不检查此时设备以及自身的工作状态。例如当云处于绑定后的正常工作的状态，其仍然可以接受相同设备的申请注册的请求(F1.1)，并返回相同的device ID。相似的云也可以接受F1.2设备绑定(Only in Type 2 platform)和F1.3设备登录请求。
F2异常工作状态组合：在背景中介绍的，在正常工作状态时，三方实体的工作状态并不是相互独立的而是存在一定的对应关系。例如待设备完成绑定登录后，三方实体均应维持在其Running状态。但通过实验测试，论文发现在某些条件下，三方的工作状态并总是这样的规律。如果在用户在APP段发送解绑设备请求到云以后，但未重置设备。此时，某些云平台虽然解除了用户和设备的绑定关系，但仍然和设备处于连接关系，也就是此时设备仍然处于running状态，仍然可以接受远程指令，但云和APP已经回到了初始工作状态。
F3未授权用户登录：通过实验发现，某些云平台只对于敏感操作对设备请求进行授权验证，而对于其他的设备操作并不会对其进行授权验证。
F4未授权用户解绑：论文还发现某些平台不仅支持从APP端发送解绑设备的请求，同时设备端也可以发送解绑请求，而对于设备端的解绑请求往往也并不会验证用户信息。
五、漏洞组合利用
论文通过巧妙的组合利用这些漏洞可以实现一系列的远程攻击如表1所示，本文这里选取其中Type1平台上最具代表性和严重的设备劫持和设备“替换攻击”进行介绍。对于其他攻击，感兴趣的读者可以查看原文。
表1 远程攻击
1. 设备身份“替换”攻击
如图4所示从左到右依次代表的实体为攻击目标的真实设备，使用此设备的用户Alice、云服务、攻击者Trudy， 受攻击者控制可以发送任意设备请求的“幽灵设备”。
攻击步骤：T.1：首先在用户完成A.1 到A.3正常用户的初始化操作后，此时攻击者利用幽灵设备发送相同的设备注册请求到云，由于漏洞F1.1，云会接受此请求并返回和真实一样的device ID到幽灵设备。
T.2：幽灵设备利用此设备ID频繁的去和云建立和维持链接(F3和F1.3)，由于幽灵设备和真实设备的ID一样，而相同的device ID云只维持一条链接，从而攻击者利用幽灵设备“挤掉”了原来的真实设备。此时，用户在APP端虽然看见设备仍然保持在线，但此时和云建立连接的已经从真实设备被替换为被攻击者控制的幽灵设备。
攻击影响：1)由于此时用户实际控制的设备变成了幽灵设备，攻击者可以利用此漏洞去收集用户发送给设备的任何请求，从而窃取和分析用户的一些生活习惯。比如用户每次大概在什么时间去打开和关闭家中的智能插销，从而判断用户的在家时间。
2)攻击进一步可以利用伪造的幽灵设备来上传虚假设备信息从而产生更为严重的危害。现在许多云平台均支持一些设备联动的自动化控制，比如当烟雾器报警后自动打开屋内的门窗。而攻击者通过幽灵设备替换真的烟雾报警器并和云建立连接后，上传一个超过报警阈值的浓度，云会根据用户设定的联动规则自动打开门窗。
图4 实体为攻击目标的真实设备
2. 设备劫持攻击
如果此云平台还存在F4和F2的漏洞，攻击者可以在上一个设备身份替换攻击的基础上进一步实施设备劫持攻击。
攻击步骤：T3：当幽灵设备和云建立连接后，其可以向云发送解绑请求。由于F4，云会无条件接受此请求， 从而解绑了原始用户但仍然保持着和幽灵设备的连接(F2)。
T4：由于此时云回到了初始状态处于未有用户绑定的状态，攻击者可以发送设备绑定请求，云会将此设备ID的所有权转为攻击者所有。然后攻击者只需要断开幽灵设备，真实设备会自动重新连接云。此时，攻击者就可以远程控制用户的真实设备，完成设备劫持。
攻击危害：攻击者可以通过远程劫持用户的敏感设备如摄像头等从而直接窃取用户隐私。同时，虽然用户可以发觉自身设备的异常操作，但在APP端并没有任何攻击痕迹，所以用户一般认为是设备或者云故障，很难察觉设备已经被攻击者控制。
六、缓解方案
论文最后简单提及一些有效的缓解方案，如在设备注册和登录阶段增加随机数以及证书来加强认证。同时，设备状态的同步和管理往往被智能家居平台所忽略，因此论文建议在三方交互过程中也应传递各自的此时工作状态的信息，然后云作为中心对三方的工作状态进行实时的监控和管理，从而防止攻击利用非正常的工作状态来实施非法操作。
作者简介：周威，中科院大学国家网络入侵防范中心在读博士生。研究领域包括物联网安全、嵌入式系统安全、可信计算等，在Usenix、ESORICS等国际学术会议和期刊发表论文近10篇。
相关阅读：
【InForSec通讯】证书透明化CT机制的Monitor可靠性研究 | CCS 2019
点击，查看论文原文！
