信息来源：互联网   发布时间：2023-12-22

每日 · 简讯 0x01.简介随着物联网云的兴起，越来越多的智能设备接入了云。现在人们可以随时随地拿起手机，

 

每日 · 简讯

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

0x02.智能物联网平台

如图所示基于云的智能家居平台，涉及三个关键的相互交互的对象：物联网设备、移动应用程序和物联网云物联网云是智能家居平台的大脑，用于设备识别管理、设备控制等传统嵌入式设备一般通过嵌入式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信息也可能会被攻击者恶意收集。

通过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可以将虚拟设备设置频繁登录，结果就是虚拟设备总能“挤掉”真实设备。

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.参考论文原文链接：https://www.usenix.org/system/files/sec19-zhou.pdf转载声明●本平台所收集的部分公开资料来源于互联网，转载的目的在于传递更多信息及用于网络分享，并不代表本平台赞同其观点和对其真实性负责，也不构成任何其他建议。

如果您发现平台上有侵犯您的知识产权的作品，请与我们取得联系，我们会及时修改或删除

扫二维码｜关注我们微信号｜AFFWPT官方网站｜secjx.com

免责声明：本站所有信息均搜集自互联网，并不代表本站观点，本站不对其真实合法性负责。如有信息侵犯了您的权益，请告知，本站将立刻处理。联系QQ：1640731186