2024年最全浅谈智能物联网家居平台安全隐患_智能家居行业网络安全，【面试必备

本人从事网路安全工作12年，曾在2个大厂工作过，安全服务、售后服务、售前、攻防比赛、安全讲师、销售经理等职位都做过，对这个行业了解比较全面。

最近遍览了各种网络安全类的文章，内容参差不齐，其中不伐有大佬倾力教学，也有各种不良机构浑水摸鱼，在收到几条私信，发现大家对一套完整的系统的网络安全从学习路线到学习资料，甚至是工具有着不小的需求。

最后，我将这部分内容融会贯通成了一套282G的网络安全资料包，所有类目条理清晰，知识点层层递进，需要的小伙伴可以点击下方小卡片领取哦！下面就开始进入正题，如何从一个萌新一步一步进入网络安全行业。

学习路线图

其中最为瞩目也是最为基础的就是网络安全学习路线图，这里我给大家分享一份打磨了3个月，已经更新到4.0版本的网络安全学习路线图。

相比起繁琐的文字，还是生动的视频教程更加适合零基础的同学们学习，这里也是整理了一份与上述学习路线一一对应的网络安全视频教程。

网络安全工具箱

当然，当你入门之后，仅仅是视频教程已经不能满足你的需求了，你肯定需要学习各种工具的使用以及大量的实战项目，这里也分享一份我自己整理的网络安全入门工具以及使用教程和实战。

项目实战

最后就是项目实战，这里带来的是SRC资料&HW资料，毕竟实战是检验真理的唯一标准嘛~

面试题

归根结底，我们的最终目的都是为了就业，所以这份结合了多位朋友的亲身经验打磨的面试题合集你绝对不能错过！

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

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

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

平台的一种典型的硬编码信息。此外，对于某些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分解为三个子缺陷：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(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.参考

给大家的福利

零基础入门

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

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

因篇幅有限，仅展示部分资料

网络安全面试题

绿盟护网行动

还有大家最喜欢的黑客技术

网络安全源码合集+工具包

所有资料共282G，朋友们如果有需要全套《网络安全入门+黑客进阶学习资源包》，可以扫描下方二维码领取（如遇扫码问题，可以在评论区留言领取哦）~

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

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

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