📚 课程目录第2章 IoT安全基础

2、IoT安全基础：IoT架构分层（感知层、网络层、应用层）、常见通信协议（MQTT、CoAP、Zigbee、BLE、Wi-Fi、Z-Wave）及攻击面概览

IoT（物联网）设备渗透测试与传统的Web或主机渗透测试最大的差异在于：测试对象不再是一个孤立的软件系统，而是一个由物理硬件、嵌入式固件、多种通信协议、云平台和移动应用共同构成的复杂生态系统。要在这个生态系统中找到突破口，首先必须建立对IoT架构的全局认知。本章将系统梳理IoT的三层架构模型，深入剖析MQTT、CoAP、Zigbee、BLE、Wi-Fi、Z-Wave等主流通信协议的安全特性与攻击面，并给出一个从攻击者视角出发的威胁建模框架，为后续章节的实战操作奠定理论基础。

2.1 IoT三层架构：从物理世界到云端

核心原理：三层架构的职责边界与数据流

IoT系统的架构分层并非学术上的空谈，而是直接决定了安全测试的切入路径。感知层（Perception Layer）是IoT与物理世界交互的末端，包含传感器、执行器、RFID标签、摄像头等物理组件，以及驱动这些组件的MCU（微控制器）、SoC（片上系统）和嵌入式固件。这一层的核心安全问题是硬件信任根缺失——攻击者一旦通过UART、JTAG或SPI接口获得调试权限，即可直接读取固件、提取密钥甚至篡改运行逻辑。网络层（Network Layer）负责将感知层的数据传输到应用层，涵盖Wi-Fi、BLE、Zigbee、Z-Wave等近距离无线协议，以及MQTT、CoAP、HTTP等应用层协议。该层的安全焦点在于通信的机密性、完整性和可用性，典型的攻击包括中间人、重放、嗅探和协议级拒绝服务。应用层（Application Layer）是数据汇聚与业务逻辑实现的场所，包括云平台、IoT Hub、规则引擎、移动App和Web控制台。这一层的安全问题与传统Web安全高度重合，但增加了设备身份管理、影子设备、批量设备固件升级等IoT特有场景。

从数据流角度看，一次典型的IoT交互路径为：传感器采集物理量 → MCU进行初步处理 → 通过无线协议发送至网关 → 网关经MQTT/CoAP上报云端 → 云端规则引擎触发业务逻辑 → 用户通过App查看或控制。安全测试人员需要理解的是，每一跳都是一次信任边界的跨越，而攻击者往往选择最薄弱的环节而非最核心的组件作为突破口。

  渗透测试启示：在实战中，不要将三层架构视为孤立的测试范围。一个典型的攻击链可能是：通过感知层的UART调试口提取固件 → 逆向固件发现硬编码的MQTT Broker凭据 → 使用该凭据连接云端 → 在应用层通过API越权控制其他租户的设备。因此，三层架构的测试应当形成闭环思维，而非各自为战。

判断方法：如何识别目标设备所属架构层级

在接到渗透测试任务时，首先需要明确被测对象的层级归属。判断方法如下：

物理接触判断：如果测试对象是一个可拆卸外壳的硬件设备，且存在PCB板、芯片、传感器接口，则必然涉及感知层测试。此时应优先检查是否有暴露的调试接口（UART/SPI/JTAG）、Flash芯片型号以及丝印上的版本号。
通信行为判断：使用Wireshark或tcpdump抓取设备启动后的网络流量。如果发现设备主动连接某个IP的1883端口（MQTT默认端口）或5683端口（CoAP默认端口），则说明其网络层和应用层协议已明确。若抓取到的是802.15.4帧或BLE广播包，则需使用专用嗅探器（如TI CC2531 USB dongle或nRF52840 dongle）进行链路层分析。
业务逻辑判断：如果测试对象是手机App或Web管理后台，则属于应用层范畴。此时应关注API接口的认证授权机制、云平台的配置错误（如存储桶权限、IAM策略）以及设备固件升级包的签名校验逻辑。

经验提醒：很多智能家居设备同时具备三层属性。例如一个智能灯泡，其内部MCU属于感知层，通过BLE或Wi-Fi通信属于网络层，而用户通过App控制则涉及应用层。测试时建议从最易获取的入口开始——通常是网络层流量分析，因为被动嗅探的风险最低且信息量丰富。

案例拆解：某智能插座的三层攻击面分析

以一个典型的Wi-Fi智能插座为例，其硬件采用ESP8266模块（感知层），通过MQTT协议与云端通信（网络层），用户通过手机App远程控制（应用层）。在一次授权测试中，我们首先对设备进行拆解，发现PCB上留有4针UART调试接口（GND、VCC、TX、RX）。使用逻辑分析仪以115200波特率连接，成功进入设备Shell，获取了root权限。随后在文件系统中发现/etc/mosquitto.conf配置文件，其中包含MQTT Broker地址mqtt.iotcloud.example.com和明文密码Admin@2024。使用该凭据连接Broker后，发现设备订阅了/devices/+/status主题，且Broker允许通配符订阅。通过订阅/devices/#，我们能够实时监控所有在线设备的开关状态和电量数据，甚至可以向/devices/<device_id>/control主题发布{"power":"off"}指令，实现对任意设备的远程断电控制。

该案例的完整攻击链为：硬件调试接口 → 固件文件系统 → 硬编码凭据 → MQTT Broker → 设备控制。整个过程中，感知层的物理访问是起点，网络层的协议缺陷（未启用TLS、无ACL控制）是放大器，应用层的业务逻辑缺失（未校验设备所有权）是最终危害的根源。

风险提示：在真实环境中，对MQTT Broker进行通配符订阅测试属于主动攻击行为，可能违反授权范围。务必在测试前获得书面授权，并明确测试边界。建议在隔离的测试环境中复现该场景，而非直接针对生产系统。

常见误区与总结复盘

误区一：认为硬件安全测试门槛过高。实际上，UART调试接口在消费级IoT设备中非常普遍，且默认开启。使用USB转TTL模块和PuTTY即可完成连接，无需昂贵的专业设备。
误区二：只关注网络层而忽略物理层。很多测试人员习惯从Wi-Fi抓包开始，但往往忽略了设备外壳上的调试接口。物理访问是最高权限的起点，一旦获得Shell，所有网络层加密都形同虚设。
误区三：将应用层测试等同于Web渗透。IoT应用层还涉及设备影子、固件升级、OTA签名验证等特有功能。例如，固件升级包若未做签名校验，攻击者可通过DNS劫持或中间人替换固件，植入后门。

总结复盘：三层架构的划分是为了帮助测试人员建立系统化思维。在实际项目中，建议绘制一张数据流图，标注每一跳的协议、端口、信任边界和潜在攻击点。这张图将成为后续章节中固件逆向、协议分析、云平台测试的路线图。

2.2 常见通信协议安全剖析

核心原理：各协议的设计初衷与安全权衡

IoT通信协议的设计往往在资源受限（低功耗、低内存、低带宽）与安全需求之间做出权衡。理解这种权衡是评估协议攻击面的前提。

MQTT（Message Queuing Telemetry Transport）是基于TCP的发布/订阅协议，采用Broker作为消息中枢。其安全性完全依赖于TLS的启用情况和Broker的访问控制配置。默认情况下，MQTT Broker（如Mosquitto）允许匿名连接，且不加密通信内容。即使启用了用户名/密码认证，如果未使用TLS，凭据也是明文传输的。此外，MQTT的Topic设计天然存在越权风险——如果Broker未配置ACL（访问控制列表），任何客户端都可以订阅#通配符获取所有消息。

CoAP（Constrained Application Protocol）是面向UDP的RESTful协议，常用于资源受限的节点。CoAP本身不提供加密，其安全依赖于DTLS（Datagram TLS）。然而，DTLS在CoAP中的实现存在两个典型问题：一是握手开销较大，对于内存仅几十KB的节点可能造成DoS；二是PSK（预共享密钥）的管理不善，很多设备出厂使用相同的默认PSK，攻击者可从固件中提取后冒充任意设备。

Zigbee基于IEEE 802.15.4标准，使用AES-128加密。其安全模型分为集中式（Trust Center）和分布式两种。集中式网络中，Trust Center负责密钥分发和管理，但若攻击者物理获取一个已入网的设备并提取其网络密钥，即可解密通信。Zigbee 3.0引入了Install Code机制改善密钥分发，但旧版本设备仍广泛存在。

BLE（Bluetooth Low Energy）的安全核心在于配对（Pairing）和绑定（Bonding）机制。传统BLE 4.0的Just Works配对方式不提供中间人保护，攻击者可被动嗅探或主动注入。BLE 5.0的LE Secure Connections引入了椭圆曲线Diffie-Hellman（ECDH）密钥交换，但前提是设备正确实现了OOB（带外）或Passkey Entry配对。实际测试中，很多IoT设备为了用户体验，默认使用Just Works，导致通信可被解密。

Wi-Fi的安全取决于WPA2/WPA3的配置。WPA2的KRACK攻击（Key Reinstallation Attack）可导致重放、解密和密钥伪造，虽然WPA3已修复该漏洞，但大量存量设备仍停留在WPA2。此外，IoT设备常使用WPS（Wi-Fi Protected Setup）简化配网，而WPS的PIN码暴力破解是经典攻击路径。

Z-Wave运行在Sub-GHz频段（如868MHz/908MHz），使用AES-128加密。其安全模型在S0版本中存在密钥分发漏洞（攻击者可注入临时密钥），S2版本引入了基于椭圆曲线的密钥协商，显著提升了安全性。但Z-Wave的协议栈实现多为闭源，安全研究难度较大。

判断方法：协议安全评估的实操步骤

在渗透测试中，对通信协议的安全评估应遵循以下流程：

流量捕获：使用Wireshark配合相应的抓包工具（如nRF Sniffer for BLE、Ubiquiti XStream for Zigbee、HackRF for Sub-GHz）捕获设备通信流量。重点关注握手过程、密钥交换和明文数据。
协议识别：通过端口号（MQTT 1883/8883、CoAP 5683/5684）或特征字段（MQTT的CONNECT报文、CoAP的选项）确认协议类型。
加密检测：检查是否使用TLS/DTLS。对于MQTT，可尝试使用mosquitto_sub连接Broker，若无需证书即可连接，则说明未启用TLS。对于BLE，使用Wireshark的btle过滤器查看LL Data的加密标志位。
认证测试：尝试使用默认凭据（如admin/admin、root/root）连接Broker或设备。对于Zigbee，尝试使用已知的默认网络密钥（如ZigbeeAlliance09）解密流量。
重放测试：捕获合法的控制指令（如开锁、断电），使用tcpreplay或自定义脚本重放，观察设备是否执行。若执行，则说明协议缺少时间戳或序列号防护。

工具推荐：对于MQTT测试，推荐使用mqtt-pwn（自动化漏洞扫描）和MqttHack（暴力破解）。对于BLE，推荐使用gattack（GATT攻击框架）和bleah（BLE枚举工具）。对于Zigbee，推荐使用Killerbee（攻击框架）和ZigDiggity（渗透测试工具集）。

案例拆解：MQTT Broker未授权访问导致全屋设备沦陷

某智能家居厂商部署了一台Mosquitto Broker用于管理用户家中的智能门锁、摄像头和灯光系统。Broker部署在云服务器上，仅开放1883端口（未启用TLS）。在测试中，我们使用Shodan搜索该厂商的Broker IP，发现其响应了MQTT CONNACK报文。使用mosquitto_sub -h <broker_ip> -p 1883 -t '#' -v命令，成功订阅了所有主题。通过分析消息内容，发现主题结构为/home/<user_id>/lock/status和/home/<user_id>/lock/control。我们构造了一条{"cmd":"unlock"}消息发布到目标用户的/home/<user_id>/lock/control主题，门锁随即打开。

该案例的关键参数：Broker版本为Mosquitto 1.6.9（存在CVE-2017-7650内存泄漏漏洞），未配置ACL，未启用TLS，