IOT测试

物联网（The Internet of Things，简称IOT）是指通过 各种信息传感器、射频识别技术、全球定位系统、红外感应器、激光扫描器等各种装置与技术，实时采集任何需要监控、 连接、互动的物体或过程，采集其声、光、热、电、力学、化 学、生物、位置等各种需要的信息，通过各类可能的网络接入，实现物与物、物与人的泛在连接，实现对物品和过程的智能化感知、识别和管理。

IOT小白一枚,在网上看了很多资料,最终看到

https://www.freebuf.com/articles/ics-articles/247718.html

觉得非常详细,本篇文章也是我记录我在这个博文的学习记忆

IoT体系结构

web渗透从信息收集开始,对IOT也是,只不过IOT的信息收集也就是他的体系结构

分为

一、传感器（Sensor）——“感知世界的小探头”

作用： 负责“感知”和“采集”周围环境的数据。
你可以把它想成设备的“五官”：

它“看”光线有多亮（光照传感器）；

它“感受”温度、湿度变化（温湿度传感器）；

它“听到”有没人经过（红外/运动传感器）；

它“检测”水流、电量、烟雾等。

一句话理解：
传感器就是负责“收集信息”的角色。

二、执行器（Actuator）——“负责行动的手脚”

作用： 把传感器采集到的信息“转化为行动”。
比如：

温度太高 → 空调自动开启；

检测到有人靠近 → 门锁自动解锁；

早晨定时 → 窗帘自动打开。

一句话理解：
执行器是“动手干活”的部分，能根据命令控制现实世界中的东西。

三、网关（Gateway）——“负责沟通的中间人”

作用： 连接“下层设备”和“上层系统”。

一边从传感器那里收集数据；

一边把命令发送给执行器；

同时把信息上传到“云端”或“控制中心”。

一句话理解：
网关就是“翻译官”+“中转站”，让各种设备能互相交流、协同工作。

 四、云平台（Cloud）——“大脑与数据仓库”

作用：

存储和分析从网关上传的数据；

提供控制界面（Web网页或API），让用户能远程管理设备；

进行智能分析，比如根据历史数据自动优化空调温度。

一句话理解：
云就是IoT系统的大脑和数据库，负责“思考”和“决策”。

五、移动端应用（Mobile App）——“你的遥控器”

作用：

你用手机App远程查看温度、湿度等信息；

控制家里的灯、空调、门锁等设备；

与云端系统交互，实现“随时随地控制”。

一句话理解：
App就是你手里的“遥控器”，帮你随时控制整个IoT系统。

六、整体关系图（简化理解）

传感器 → 网关 → 云平台 ↔ 手机App 
          ↓ 
        执行器 

工作流程举例：
温度传感器检测到屋里太热 → 网关把数据传给云端 → 云端判断需要降温 → 云端发出命令 → 网关通知执行器 → 执行器开启空调 → 你在手机App上看到温度变化。

IoT攻击面及测试思路

在物联网（IoT, Internet of Things）系统中，不同设备之间需要通信与数据交换，因此使用了多种网络协议。
常见协议包括：

HTTP

TLS/SSL

S7Comm-plus

WebSocket

MQTT

这些协议有的偏向人机交互（HTTP、WebSocket），有的偏向设备通信（MQTT、S7Comm-plus），有的则负责安全加密（TLS/SSL）

协议

1.HTTP(应用层)

HTTP（Hypertext Transfer Protocol，超文本传输协议）是最常见的Web 通信协议，用于在客户端（如浏览器）与服务器之间传输数据。

在 IoT 中，HTTP 主要用于：

设备与云端服务器通信（上传数据或接收指令）；

设备自带Web 控制面板（如路由器、摄像头等）供用户访问和管理。

HTTP 在 IoT 中的两种典型场景

场景一：有 Web 应用的 IoT 设备

例如：

路由设备：TP-Link、D-Link 等；

视频监控设备：海康威视、DVR/NVR；

门禁考勤系统：Linear eMerge E3-Series；

智能网关：GPON Home Gateway 等。

特点：

用户通过浏览器访问设备的 Web 界面；

登录后可配置网络、用户、摄像头画面、门禁规则等功能；

设备通过 HTTP 请求与后台交互（如
/login,
/config）。

常见安全问题：
这些 Web 应用的安全问题，往往与普通 Web 系统类似：

问题类型	说明
默认密码	厂商出厂时使用统一账号密码（如 admin/admin），用户未修改即被攻击者暴力破解；
弱口令	用户设置简单密码（如 123456、password），容易被暴力破解；
越权漏洞（Authorization Bypass）	攻击者可直接访问未授权的管理接口，修改设备配置；
远程代码执行（RCE）	存在命令注入、文件上传等漏洞，可让攻击者远程控制设备。

---

场景二：无 Web 应用的 IoT 设备

这里说的“没有 Web 应用”的 IoT 设备，指的是那些不以网页界面给用户交互为主、但内部或部分功能仍用 HTTP 与其它组件/云端/控制器通信的设备。常见例子：打印机、智能烤箱、电饭煲、智能咖啡机、智能音箱、智能门禁等。

关键点：即便设备没有完整的 Web 面板，只要存在 HTTP 请求（比如绑定、控制命令、上报数据）就可能产生安全风险。

常见攻击向量（为什么会被攻破）

中间人攻击（MITM）

在局域网或不安全 Wi-Fi 下拦截并篡改 HTTP 请求/响应，伪造命令或返回假数据。

重放攻击（Replay）

抓包记录一次合法的控制请求，再重复发送以重复触发动作（例如重复下单、重复制作咖啡）。

敏感数据嗅探/泄露

HTTP 明文传输，设备上报的卡号、sid、密码等被抓包获取。

接口枚举/遍历（Insecure ID）

sid、device id 可被遍历或猜测，从而解绑或控制其它设备。

本地网内权限绕过

内网中只要能连上局域网，攻击者就可能访问未加固的本地接口。

逻辑/认证缺陷

无签名、无认证或弱认证的控制接口容易被滥用。

---

典型测试方法（实操思路）

（实测顺序可按被动→主动→利用）

被动侦查

用 Wireshark / tcpdump 抓包，观察设备发出的 HTTP 请求（URL、参数、Headers、Cookie、Authentication）。

中间人（主动）

在受控测试环境下用 mitmproxy / Burp 做 MITM：查看并篡改流量，看设备/服务是否接受篡改后的命令。

重放测试

把抓到的控制请求用 curl、Burp Repeater 或自写脚本反复发送，观察是否重复触发动作（是否有 nonce/timestamp 检查）。

枚举/遍历

枚举 sid、id 或 URL 参数，尝试访问或修改其它设备的资源（注意合法授权的测试环境）。

认证与会话测试

检查是否使用 HTTPS、是否无效证书仍被接受、是否存在会话固定/会话劫持问题。

接口安全测试

用模糊测试（fuzz）、参数篡改、注入测试等探测接口逻辑漏洞。

固件/配置分析（进阶）

下载或提取固件查看是否有硬编码凭据、明文密钥或不安全库。

---

风险举例

智能烤箱：二维码绑定 URL 中 sid 可遍历 → 可尝试解绑或控制其它烤箱。

智能音箱：点歌用 HTTP → 在不安全网路下 MITM 可篡改播放内容（影响用户体验、引发投诉）。

智能咖啡机（假想）：控制命令用 HTTP 且无认证 → 抓包重放可无限“刷咖啡”。

门禁系统：刷卡信息通过 HTTP 上传 → 内网嗅探可泄露敏感信息，导致权限滥用。

---

测试与防护的简易检查表

设备是否存在 HTTP 明文请求？（用 Wireshark 检查）

关键控制请求是否使用 HTTPS？证书是否被验证？

是否存在可枚举/可遍历的设备 ID（sid 等）？

绑定流程是否包含一次性验证或物理确认？

是否可以通过重放已捕获请求复现控制动作？

是否有对异常请求的速率限制与告警？

是否对局域网设备做网络隔离（VLAN）和防火墙策略？

固件是否可更新？是否及时有补丁发布？

2.TLS/SSL(表示层)

加密后的流量虽然可以被抓包工具捕获，但是一般都无法获取有效信息，因此针对使用了TLS协议的设备，首先需要将流量解密，关于解密方法，一种是通过该协议本身的漏洞进行解密，但这一块本人没有太多的研究，不进行深入，另一种是通过对设备固件进行分析，获取解密方法，这一块涉及逆向和二进制等方面，也无法进行过多深入。当然流量解密后，测试方法就参考上文所写HTTP协议部分即可。

TLS 的作用

目的：TLS/SSL 的主要目的是对网络通信进行加密与完整性保护，防止中间人窃听或篡改内容。

结果：即便抓到流量（用 Wireshark），流量内容也是加密的、不可读的——这是 TLS 的本意。

---

为什么需要“解密”流量

在做安全测试或调试时，如果设备使用 TLS 而你又想分析它在说什么（例如确认接口逻辑、检测是否有敏感信息被传输），就需要把加密的流量还原成明文来查看。

---

常见的流量解密途径

注意：下面列举的是测试/研究中常见的方法，涉及到设备、固件或网络的修改，必须在合法授权和受控环境下进行。

1. 配置代理 + 安装自签 CA（对可控设备最常用）

在测试网络中用 mitmproxy / Burp 等做中间人代理，生成自签 CA。

若设备/客户端接受该 CA（没有做证书校验或证书固定），即可解密 TLS 流量。

优点：简单、快速；缺点：很多安全设计良好的设备会校验证书或做 cert-pinning，从而无法奏效。

2. 利用设备接受“自签证书”或不严格校验（配置/实现缺陷）

有些 IoT 设备并不校验证书链或接受任意证书，这种实现缺陷使 MITM 容易成功。

3. 从固件或存储中提取密钥 / 私钥 / 会话种子（逆向/固件分析）

通过下载或提取固件、分析二进制，找到硬编码的私钥、对称密钥或调试日志中的密钥。

拿到私钥可用于在离线环境中解密捕获的流量（如果没有使用 PFS）或模拟服务器。

难度高：需要逆向、二进制分析技能并触及固件安全。

4. 开启客户端/服务端的“密钥日志”或调试模式

在可控制的测试设备上，有时能开启 TLS 库（如 OpenSSL、BoringSSL、NSS）的密钥导出或调试日志，生成
SSLKEYLOGFILE，用 Wireshark 读取解密。

适用场景：你能修改设备配置或控制应用启动参数。

5. 利用协议/实现漏洞

某些历史漏洞（如 Heartbleed、某些实现的心跳/记忆泄露，或握手降级漏洞）能泄露密钥或明文，但这些属于特定实现漏洞，需具体漏洞与环境匹配。

注意：这类方法具有很强的情境依赖性与法律/安全风险。

6. 证书钓鱼 / 被信任的 CA 被滥用

如果测试能使设备信任一个由你控制的证书（例如用户在手机手动安装 CA），也可实现解密。

---

解密后可做的测试（与 HTTP 相同的后续步骤）

一旦能把 TLS 流量还原成明文，就可以做与 HTTP 相同的那些测试：

查找敏感信息（明文密码、token、卡号等）；

检查接口认证与授权逻辑；

做重放、篡改、访问控制测试；

查找潜在的 RCE、参数注入、信息泄露等漏洞。

3.S7Comm-plus

https://www.freebuf.com/articles/ics-articles/220239.html

4.Websocket

WebSocket 是一种在浏览器与服务器之间建立的双向、持久化连接，建立时通过 HTTP 协议的
Upgrade 握手，建立后在 TCP 之上做全双工通信，适合即时/实时数据传输（例如聊天、实时监控面板、设备状态推送等）。

在工业互联网（IIoT）常用场景：
实时监控仪表数据、报警推送、远程控制面板的即时反馈、可视化仪表盘的实时刷新等。

一般通过抓包可以看到

为什么 WebSocket 在 IoT/工控里危险点高？

连接长期存在 → 一旦接入就能长期收发消息（攻击面扩大）。

实时数据多为敏感信息（状态、告警、控制指令）。

有些设备/服务对内网信任过度，忽视鉴权或做粗暴鉴权。

建立连接后服务器往往默认信任客户端发来的消息，易发生越权或注入。

---

常见安全问题

缺失或弱鉴权（No/Weak Auth）：连接或发送消息前不校验身份，任意客户端可连可发。

越权执行：未做权限校验就执行控制命令（例如控制其他设备、改变配置）。

敏感信息泄露：服务器通过 WebSocket 推送大量明文数据（如设备ID、卡号、用户信息等）。

会话固定/会话劫持：长期会话令牌泄露后可长期滥用。

消息篡改 / 注入：服务器对消息内容校验不足，可能被注入恶意指令或导致逻辑异常。

拒绝服务（资源耗尽）：大量持久连接或恶意消息耗尽服务器资源。

---

可执行的测试方法（步骤化，便于实操）

0. 准备工具（常用）

抓包：Wireshark（查看握手/帧）、tcpdump

WebSocket 客户端：
wscat,
websocat, 浏览器控制台、Postman（支持 WS）

中间人/代理：Burp（支持 WebSocket 抓包与篡改）、mitmproxy（支持 websocket）

1. 被动侦查（先观察）

抓包观察握手（HTTP Upgrade）与后续帧：看是否走了
wss://（加密）或
ws://（明文）。

记录 URL、Header（例如 Authorization）、Cookies、Query 参数、消息格式（JSON/XML/二进制）。

2. 鉴权测试（最重要）

未鉴权连接测试：不带任何认证信息直接建立连接，看是否被接受并能接收/发送消息。

伪造/空 Token 测试：带无效或空的 token 建立连接，查看是否被允许。

越权测试：使用普通用户凭据访问管理/控制接口，尝试执行高权限操作。

3. 功能与消息逻辑测试

重放/重复消息：抓包后重放关键控制消息，观察是否被重复执行（无防重放机制）。

篡改消息字段：修改消息中的 device_id、command、参数等，测试是否有服务端参数校验。

模糊/边界测试：发送超长/异常字段、特殊字符，观察崩溃或异常行为（注入/DoS）。

4. 敏感信息测试

检查服务器是否推送敏感字段（密码、卡号、位置信息、完整设备配置等），是否加密或脱敏。

5. 并发与资源测试

大量并发连接或发送大量消息，观察服务是否出现资源耗尽或拒绝服务状况（注意合法授权的压力测试范围）。

MQTT

MQTT（Message Queuing Telemetry Transport）是为低带宽、低功耗设备设计的轻量级发布/订阅（Pub/Sub）消息协议，广泛用于 IoT 场景。默认基于 TCP 端口 1883（明文），加密版常用 8883（MQTTS，TLS）。

MQTT 的基本工作模式

Broker（代理/服务器）：集中转发消息的中间人（例如 Mosquitto、EMQX、HiveMQ）。

Client（客户端）：设备或应用，既可以发布（Publish）消息，也可以订阅（Subscribe）主题（Topic）。

Topic（主题）：消息的“地址”，类似路径（如
home/kitchen/temperature）。

Publish / Subscribe：发布者发消息到某个 Topic，订阅者收到这个 Topic 的消息。

QoS（服务质量）：消息可靠性等级（0/1/2），影响重发与确认机制。

Retained Message / Will：保留消息（新订阅者可见）与遗嘱消息（客户端异常断开时由 Broker 发布）。

常见攻击面

MITM（中间人）

明文 MQTT（1883）容易被抓包、篡改、重放。

如果使用 TLS（8883）且证书校验不到位，也可能被中间人拦截。

口令问题（认证问题）

匿名连接 / 空口令：很多 Broker 开启匿名访问，攻击者可直接连接并发布/订阅。

弱口令 / 明文凭证：用户名/密码弱或传输明文，易被暴力破解或嗅探。

暴力破解防护不足：很多 Broker 未启速率限制或登陆失败锁定。

权限问题（Topic 权限/ACL）

Broker 如果没做细粒度 ACL，任意用户可能订阅或发布任意 Topic。

使用通配符（
+、
#）可轻易监听大量 Topic（例如
CMD/#）。

特权 Topic （如
$SYS/#）若未受限也会泄露系统信息。

重放 / 伪造 / 注入

抓包后重放 Publish 有可能重复触发动作（若无防重放/签名）。

伪造客户端 ID 或消息可欺骗 Broker 或下游系统。

资源滥用 / 拒绝服务（DoS）

大量连接或发布高频消息耗尽 Broker 资源。

发送超大负载或保留大量 Retained 消息也会占用存储。

遗嘱/保留消息滥用

恶意设置 Will 导致断线触发不良动作；滥用 Retained 导致新订阅者收到历史敏感信息。

常用测试方法

基础连接测试：用
mosquitto_pub /
mosquitto_sub、
mqtt-explorer、
mqtt.fx、
paho 客户端尝试连接 Broker（带/不带认证）。

抓包分析：Wireshark 查看 1883 明文流量或 8883 TLS 握手（若能 MITM 则解密）。

匿名/空口令测试：不带凭证尝试连接并订阅/发布。

弱口令/暴力测试：使用字典或现成脚本（如你提到的 joffrey）尝试爆破用户名密码。

ACL 越权测试：订阅
#、
CMD/# 等通配符，看能否获取到未授权 Topic。

重放测试：抓包后重放 Publish 消息，观察是否被重复处理（检查 QoS、唯一 ID、timestamp）。

会话/遗嘱测试：断开客户端连接前后观察 Will 消息触发情况。

并发/压力测试：大量连接或高频消息测试 Broker 稳定性（需在授权环境）。