浅谈智能物联网家居平台安全隐患_智能家居行业网络安全(1)

0x05.已识别的设计缺陷

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

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

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-45uKvea0-1679990011756)(https://image.3001.net/images/20221227/1672111938_63aa6742b64083b4ebb00.png!small)]

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

同样，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.参考

论文原文链接：https://www.usenix.org/system/files/sec19-zhou.pdf

资料分享

最后，给大家分享一波网络安全学习资料：

我们作为一个小白想转行网络安全岗位，或者是有一定基础想进一步深化学习，却发现不知从何下手。其实如何选择网络安全学习方向，如何进行实战与理论的结合并不难，找准正确方式很重要。

接下来我将从成长路线开始一步步带大家揭开网安的神秘面纱。

1.成长路线图

共可以分为：

还有兄弟不知道网络安全面试可以提前刷题吗？费时一周整理的160+网络安全面试题，金九银十，做网络安全面试里的显眼包！

王岚嵚工程师面试题（附答案），只能帮兄弟们到这儿了！如果你能答对70%，找一个安全工作，问题不大。

对于有1-3年工作经验，想要跳槽的朋友来说，也是很好的温习资料！

【完整版领取方式在文末！！】

93道网络安全面试题

内容实在太多，不一一截图了

黑客学习资源推荐

最后给大家分享一份全套的网络安全学习资料，给那些想学习 网络安全的小伙伴们一点帮助！

对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。

1️⃣零基础入门

① 学习路线

对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。

② 路线对应学习视频

同时每个成长路线对应的板块都有配套的视频提供：

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以点击这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！