智能物联网（IOT）家居平台复杂的安全隐患问题

梦里梦外; 2023-10-11 20:26 49阅读 0赞

浅谈智能物联网家居平台安全隐患  
0x01.简介  
随着物联网云的兴起，越来越多的智能设备接入了云。现在人们可以随时随地拿起手机，打开APP远程控制家里的路由器、摄像机、扫地机等等。但这种前所未有的便利也引入了各种安全隐患。笔者最近在usenix上读到一篇关于智能物联网家居平台安全隐患的论文：“Discovering and Understanding the Security Hazards in the Interactions between IoT Devices, Mobile Apps, and Clouds on Smart Home Platforms”，本文以这篇论文为主线，聊聊智能物联网家居平台的安全隐患。

0x02.智能物联网平台  
<a href=智能物联网（IoT）家居平台复杂的安全隐患问题 物联网 安全隐患 智能设备 第1张" alt=“智能物联网（IoT）家居平台复杂的安全隐患问题 物联网 安全隐患 智能设备 第1张” class=“div\_message\_boxShadow” style=“box-sizing: border-box; vertical-align: middle; border-style: none; max-width: 100%; margin: 1rem 0px; cursor: pointer;”>

如图所示基于云的智能家居平台，涉及三个关键的相互交互的对象：物联网设备、移动应用程序和物联网云。  
物联网云是智能家居平台的大脑，用于设备识别管理、设备控制等。传统嵌入式设备一般通过嵌入式web服务来管理，比如用户通过浏览器访问路由器、摄像机的http服务，输入用户名、密码登录管理。随着移动互联网的发展，很多IoT设备接入了云，同时使用移动应用来管理设备，移动应用程序将输入请求发送到物联网云，物联网云再将请求下发到IoT设备，这类设备自身可能没有直接对外开放的端口服务，但也引入了一些新的攻击面。

0x03.智能设备交互概览  
1.设备发现和WiFi配置：物联网设备需要加入与移动应用程序相同的局域网，用户通过指定的移动应用APP“添加设备”按钮通过广播发送消息或通过设备的接入点与设备连接，设备上报其基本信息，如MAC地址和设备型号给到移动应用程序，同时通过移动应用程序给设备配网，使得IoT设备能够访问物联网云。

2.设备注册：设备注册后，物联网设备被赋予一个唯一的设备 ID。不同类型的平台以不同的方式提供设备 ID。对于 I 类平台，设备将其设备身份信息发送到它所属的物联网云，云然后生成一个设备ID 并将其返回给设备，云端还保留了一个设备 ID 记录以供将来验证。对于 II 型平台，设备的设备 ID 由平台事先硬编码到设备。

3.设备绑定：移动应用账户和设备直接建立绑定关系，只有授权用户可以通过云端访问设备。对于Type I平台，绑定请求直接由移动应用程序发送到物联网云，由物联网云负责维护绑定信息并执行权限检查（即用户帐户是否具有访问设备的权限）。对于 Type II 平台，移动应用程序首先将帐户信息发送到设备，有了设备 ID 和用户帐户，设备向物联网云发出绑定请求。

4.设备登录：设备使用自己的设备ID登录物联网云。然后它与云以保持状态更新并准备好执行远程命令。另外，当设备长时间失去与云端的连接时，它会尝试自动地重新登录。

5.使用中的设备：注册登录成功后， 设备执行设计的功能，通过移动应用程序远程控制设备。

6.设备解绑和重置：当用户不再使用该设备，可以解除绑定或重置它。 当用户请求解绑时，对于 I 类平台， 物联网云直接擦除绑定信息。对于II类平台，因为设备本地也存有绑定信息，解绑请求从云端下发到设备擦除绑定信息。

0x04.威胁模型评估  
这里文中假设攻击者有能力收集必要的信息，包括设备身份信息和合法性信息。针对不同的平台，收集这些信息项的难度不同。根据获取特定身份信息项的方式，可以对这些信息项进行分类分为三类：公共信息（P）、可猜测信息（G）和硬编码信息（H）。例如，设备型号和设备芯片id (CID) 是公共信息，可猜测的信息是指能够被暴力猜解的，比如MAC 地址就是一种典型的可猜测的信息。硬编码的信息是指不易预测的、不可变的，并且设备固有的。例如，嵌入在设备硬件中设备 ID 是 Type II 平台的一种典型的硬编码信息。此外，对于某些Type I 平台，硬编码信息（例如，序列号(SN)) 也包含在设备 ID 的生成中。虽然硬编码的信息不容易获得，但它是不变的，一旦这些信息泄露，受害者设备将存在潜在风险。要获取这些信息，攻击者可以通过嗅探设备应用流量或进入设备shell等方式来获取设备的硬编码设备 ID，另外二手平台上售卖的设备或公寓酒店的设备ID信息也可能会被攻击者恶意收集。

实际上论文中提到的类似Alink平台使用MAC地址来标识设备的厂商并不少见，这种做法存在被攻击的风险，物联网云将MAC地址作为与真实设备的映射，而MAC地址是一种典型的可被猜测的信息，MAC地址前3字节表示OUI（Organizationally Unique Identifier），是IEEE的注册管理机构给不同厂家分配的代码，区分不同的厂家。后3字节由厂家自行分配，假如攻击者有一台设备，通过这台设备MAC地址就可以猜解出其他同型号设备的MAC地址，前三字节固定，遍历后三个字节即可。

通过MAC地址前三个字节查询对应生成厂商：

这种直接使用MAC地址作为真实设备标识可能带来哪些危害？想象这么一个攻击场景，，用户使用移动应用与设备通信获取到设备MAC地址，然后向云端发送绑定请求，云端留存用户信息和MAC地址的绑定映射关系，然后用户通过移动应用远程控制该设备。这里关键点是移动应用程序通过这种方式向云端发送的绑定请求这个过程存在被攻击的风险，攻击者通过抓包获取到该请求，将其中的MAC地址参数替换，通过暴力猜解MAC地址的方式持续向物联网云发送绑定请求，最终攻击者可非法绑定大量设备，实际上一些设备同时只允一个用户绑定，但这种攻击也可以针对未出货的设备和已被解绑的设备，当用户买到一个新设备时可能已经被攻击者绑定过了。

一个产品整体的安全性和往往和开发者的安全意识有很大关系，国内很多应用都上了加固和通信强加密，但这也不代表可以和安全划等号。比如一款智能设备的移动应用程序和物联网云通信用了https、证书校验、请求体AES加密、加密后又压缩，应用做了加固、反调试等，实际上这些安全措施只是提高了逆向的门槛，并不能实际消除漏洞。当攻击者一层层扒开这些安全防护后就暴漏了协议设计本身，就如上述所说的非法绑定漏洞，本质是协议设计的漏洞。

0x05.已识别的设计缺陷  
论文中对物联网云、设备、移动应用程序在不同时期的状态做了一个总结，围绕它们三者的状态组合，总结出来一些攻击向量并验证。

在五个平台中共发现了四种缺陷：

F1: Insufficient State Guard。实验发现这些平台对三个实体都没能够正确地处理它们的states。这可能导致严重后果。由于物联网云负责设备识别管理等安全关键服务，因此物联网云受到的影响最大。在物联网云的状态机中（Figure 2a），当云工作时处在状态 4（Running）中，理想情况下它应该只接受已授权用户请求（edge 6）或设备解除绑定请求（edge3）。但实际测试中发现物联网云也接受其他请求。根据物联网云处于状态 4 时正确接受的请求，将缺陷F1分解为三个子缺陷：

F1.1：这个缺陷是特定于 I 型平台的。拥有所有设备识别信息的攻击者可以使用虚拟设备向云端发送注册请求。（Figure 3F1.1）。  
F1.2：此缺陷特定于 Type II 平台。 攻击者可以使用虚拟设备发送绑定请求将设备（由设备 ID 标识）与攻击者的帐户相关联（Figure 3F1.2）。在 II 型平台中的设备，绑定请求是从设备发出，云无条件接受绑定请求。结果，虚拟设备可以将攻击者的帐户绑定到受害者设备。  
F1.3：物联网云接受设备登录请求，并将相应的设备ID返回给攻击者，即使它处于状态 4。

F2： Illegal State Combination。实验发现这三个实体有时会处于意想不到的非法状态组合中。当一个非法的状态组合被利用时，安全可能会被破坏。例如，理想情况下，当用户重置并取消绑定设备，三个实体都应回到它们的初始状态（即状态组合（S1，S1，S1））。但是，对于 I 型平台，如果用户在没有重新设置设备的情况下解绑设备，设备仍然保留与云的连接，并且状态组合实际上切换到（S1，S4，S1），由于该设备处于这种非法状态组合，如果攻击者远程发出注册该设备的请求，请求被允许，云转移到状态 2。如果攻击者继续发送请求绑定设备，云接受请求并转移到状态4（状态3被跳过，因为连接仍然与受害者设备一起维护）。此时，如果攻击者向设备发送控制命令，云端将错误地将命令转发到被解绑的设备。这个本质上会导致设备劫持攻击。

F3: Unauthorized Device Login。设备登录后，设备与物联网云之间保持连接。理想情况下，云应该只允许绑定的设备的帐户发出的登录请求。但是，实验发现物联网云在设备登录期间没有进行任何基于账户的授权检查。

F4: Unauthorized Device Unbinding。理想情况下，只有拥有当前绑定到设备的用户有解除绑定设备的权限。如果解除绑定，一般在移动应用程序上进行，解除绑定请求中包含用户凭据。但对于Type I平台，发现也可以在设备端实现设备解绑。根据分析，设备端取消绑定命令不包含任何用户凭据。作为结果，攻击者可以构建一个虚拟设备使用设备端 API 伪造解绑请求，然后在用户不知情的情况下设备被解绑（Figure 3F4）。

0x06.漏洞利用  
论文中利用各种组合缺陷，验证了一系列攻击，包括远程设备替换、远程设备 DoS、非法设备占用。

文中实验使用 Alink 设备（Philips smart plug with model SPS9011A）和一个 TP-LINK 设备（WiFi Bulb with model LB110) 分别代表 I 型和 II 型设备，然后设法获得它们的身份和合法信息，Alink 设备使用型号、MAC 和 CID 作为其身份信息。型号和 CID，对于特定的设备类型是固定的，相应移动应用程序维护的日志中可以提取它们。对于 MAC 地址，上文已经提到过可以使用暴力破解。对于 TP-LINK 设备，由于其身份信息（即设备 ID）和合法性信息（即 hwid 和MAC 地址）是硬编码的，必须物理提取它们。具体来说，实验收集了设备 ID、hwid 和MAC 地址通过发起 MITM 攻击来拦截设备-应用程序通信。有了所有可用的所需信息，可以使用Python构建虚拟设备，即用Python程序模拟设备行为。

6.1 远程设备替换  
这里展示了攻击者如何使用虚拟设备远程替换受害者的设备。下文使用 Alice 来表示受害者/合法用户，Trudy 表示攻击者。

在Figure5 的顶部（最高的红色虚线上方），展示了正常的工作流程，Alice 在 Type I 平台上使用她的 IoT 设备。在 Alice 为设备提供 WiFi 凭据后，设备将其合法性凭证和设备身份信息发送到云端以进行注册（步骤 A.1）。基于设备身份信息，云端用设备 ID A 注册设备并将其绑定到 Alice 的帐户（步骤A2）。设备登录后（步骤 A.3），Alice 可以控制她帐户下的设备。然后，攻击者 Trudy 进入，如图中间部分所示（在两条红色虚线之间），他先让虚拟设备发送相同的设备注册请求，由于缺陷 F1.1，云接受此请求并注册具有相同的设备 ID A的虚拟设备，但设备 ID A 仍保持与Alice的绑定，那么Trudy可以利用缺陷 F1.3 和 F3 在没有 Alice 账户信息的情况下登录虚拟设备。由于虚拟设备与真实设备具有相同的设备ID，云与真实设备断开了连接并与虚拟设备建立连接。但是，当真实设备在一段时间内没有收到心跳包，它会再次自动登录到上云并使虚拟设备脱机。相当于真实设备和虚拟设备在竞争与云的连接，攻击者Trudy可以将虚拟设备设置频繁登录，结果就是虚拟设备总能“挤掉”真实设备。

<a href=智能物联网（IoT）家居平台复杂的安全隐患问题 物联网 安全隐患 智能设备 第9张" alt=“智能物联网（IoT）家居平台复杂的安全隐患问题 物联网 安全隐患 智能设备 第9张” class=“div\_message\_boxShadow” style=“box-sizing: border-box; vertical-align: middle; border-style: none; max-width: 100%; margin: 1rem 0px; cursor: pointer;”>同样，Figure6 的顶部（最高红色虚线上方）显示正常情况下Alice 如何在 Type II 平台上使用她的设备的工作流程。移动应用程序将她的帐户信息发送到设备（步骤A.1），设备发送绑定请求将设备 ID 和合法性信息以及帐户信息发送到云端（步骤 A.2）。云将设备 ID A绑定 到 Alice 的帐户。设备登录到云（步骤 A.3），Alice 可以使用移动应用程序控制/监控设备。图中中间（两条红色虚线之间行)，Trudy 发起远程设备替换攻击。由于缺陷 F1.3 和 F3 ，他让虚拟设备使用相同的设备ID成功登录云端。此时，设备 ID A 仍然绑定到 Alice 的帐户。与 Type I 平台一样，虚拟设备通过定期登录来保持与云的连接。通过这种方式，攻击者使用虚拟设备秘密地替代了 Alice 的真实设备。  
攻击后果：隐私泄露，在正常操作中，当 Alice 使用她的移动应用程序向云端发送远程控制命令时，云端会转发该命令到设备。然而，在远程替换中，真实设备已被虚拟设备取代，由攻击者控制。结果，来自 Alice 的所有控制命令都暴露给了虚拟设备。例如以智能插头为例，Trudy可以知道 Alice 什么时候打开/关闭智能插头。该信息可用于推断爱丽丝是否在家。  
攻击后果：伪造数据，在正常操作中，真实设备将其传感器读数更新到云端，结果反映在 Alice 的移动应用程序中。然而，在远程替换攻击中，传感器读数从虚拟设备发送。这给了 Trudy 一个操纵发送给 Alice 的传感器读数的机会，从而欺骗或误导Alice。例如，实验测试了一个小米烟雾报警器（model: Fire Alarm Detector）和一个Alink智能锁（model: KAADAS KDSLOCK001)。如果烟雾报警器检测到房间内浓烟，智能锁将自动解锁以打开窗门。实验使用远程设备替换攻击来操纵烟雾报警器的传感器读数并成功解锁了智能锁，这会导致严重的后果，因为Trudy可以随意进入Alice的房间。

6.2远程设备 DoS  
作为一项基本的安全措施，物联网云应该只允许授权用户控制设备。如果攻击者可以解除绑定合法用户的目标设备，导致合法用户无法再操作设备，本质上导致设备拒绝服务 (DoS) 攻击。为了发动这种攻击，攻击者不需要利用很多缺陷，特别是对于 I 型平台，在攻击者发送设备端解除绑定命令后（step T.3），如图Figure 5，直接请求云撤销受害用户与用户之间的设备绑定关系。对于Type II平台，如图Figure 6所示，攻击者利用F1.2漏洞将攻击者账户绑定到受害者设备。

6.3非法占用设备  
虽然一个设备可以与多个用户共享，但只有一个用户账号可以绑定一个智能家居设备。如果攻击者可以预测未出售的设备 ID设备并使用脚本将它们与有攻击者账户绑定，这些设备售出后无法再次绑定，我们称这种攻击为非法设备占用。本质上，这种攻击使合法消费者无法使用新设备。此攻击仅适用于 Type I 平台，因为攻击者可以预测设备身份信息。在 Type II 平台中，硬编码在设备中的ID是长且不易预测的，这类设备flash中一般会预留一个分区来存储硬编码的设备ID或证书密钥，比如类似于下图这个flash分区，设备出厂前在factory分区烧录了硬编码信息，设备ID或证书密钥，且每台设备都不一样，很难做到批量预测其他设备硬编码信息。

6.4 水平越权  
论文中并没单独来说水平越权的漏洞，实际上存在不少物联网云API权限校验不严格导致的水平越权风险。以某智能摄像机举例，移动应用APP配置摄像机连接WIFI，绑定摄像机，摄像机上线后可以通过APP远程控制摄像机，执行摄像机转向、升级、开关、定时等操作。通过中间人攻击抓取这些控制指令，分析发现物联网云对API做权限校验是通过检查请求中包含的用户cookie和请求体中的sn(设备序列号)参数，权限校验通过后将指令下发到设备，但安全测试中发现某些API漏掉了权限校验，导致通过篡改请求中的sn参数实现对未绑定设备的远程控制，一般来说，同一型号设备的sn码都是厂商按一定规律生成的，可被暴力遍历。

0x07.缓解措施  
7.1 严格的设备认证  
为确保每一个与物联网云通信的设备是真正的设备，建议制造商嵌入唯一的客户端证书。此外，物联网云应该始终在接受任何设备请求之前检查客户端证书。因为物联网云使用设备 ID 来识别设备，建议平台提供商改造设备 ID 分发机制使攻击者无法轻易获得有效的设备ID。硬编码设备ID 是一种不好的做法，因为一旦设备 ID 泄露，相应的设备将永远易受攻击。

7.2 综合授权检查  
与移动端请求指令相比，实验发现大多数物联网云对设备端指令不强制执行严格的授权检查。对于 I 型平台，当设备与物联网云连接，用户账户信息不存在设备，因此，物联网云直接接受未经授权的登录 (F3) 或取消绑定 (F4) 命令。对于 II 型平台，由于设备负责检查绑定关系，云端跳过进一步授权检查。建议设备和物联网云存储并保持绑定关系以及执行授权检查。此外，在云端，每个设备端请求都应做基于账户的身份验证，尤其是对于关键操作，例如设备登录，设备必须明确包含每次登录的用户凭据要求。这种额外的凭据检查可防止目标设备重新连接到云。

7.3 强制状态转换的有效性  
论文实验中所有测试的平台都未能强制执行所涉及的状态转换的有效性。为了为防止攻击者利用意外的状态转换，智能家居平台应识别并制定每个合法的交互请求，以 3 元组形式呈现（sender entity & its state, the request message, receiver entity & its state）。除了检查每个请求之外，发送方实体还应验证其当前状态是否允许请求发出；接收方实体应核实是否允许其当前状态接收请求。例如，图 Figure2 所示的物联网云应该只接受当它停留在状态1时的设备注册请求。同时，平台的物联网云应该同步三个实体，使它们保持在一个合法的状态组合。最后，如果出现不可恢复的系统错误时，三个实体应该立即回滚到它们的初始状态。

0x08.总结  
这篇论文从物联网设备、移动应用程序和物联网云三者交互角度评估了物联网智能家居平台的安全隐患，给我们展现了一些有意思的攻击面，最后讲述了攻击手段和漏洞缓解措施。想了解更详细的信息建议阅读论文原文。

0x09.参考  
论文原文链接：http://www.wodianping.com/article/2022-12-29/26.html