AoT - Attack on Things:A security analysis of IoT firmware updates论文梳理分析
IoT 固件更新安全分析报告:《AoT - Attack on Things》论文梳理与综合解读
一、研究背景与核心目标
1. 背景:IoT 设备的固件更新风险
- IoT 设备普及现状:据 Avast 数据,2025 年 IoT 设备数量将达 750 亿,广泛应用于家庭、企业、短租公寓(如 Airbnb)等场景,但固件更新机制(DFU,Device Firmware Update)的安全性未被系统验证。
- DFU 的核心作用:通过配套 App(Companion App)触发固件更新,修复漏洞、新增功能,但若实现不当,可能导致设备被篡改、降级或变砖。
- 现有研究局限:此前研究仅针对单个厂商设备,需物理访问硬件,缺乏对 IoT 生态 DFU 漏洞的规模化、系统性分析。
2. 核心研究目标
- 定义 IoT 固件更新的威胁模型,分类潜在安全漏洞;
- 分析 23 款流行 IoT 设备及配套 App,识别漏洞 SDK(实现 DFU 功能的软件开发工具包);
- 生成漏洞 SDK 指纹,对 Google Play Store 的 IoT 配套 App 进行大规模检测,评估风险覆盖范围。
二、研究方法论
论文采用 “手动 Reconnaissance(侦察)+ 自动化 App-Rumbling(大规模分析)” 两阶段框架,核心组件包括 AoT-Scout、Attack-Tester 和 App-Rumbling Pipeline,具体流程如下:
1. 第一阶段:IoT DFU 安全侦察(Reconnaissance)
(1)数据来源:构建 DeviceDataset
- 亚马逊畅销 IoT 设备:2022 年 4 月抓取 16 个 IoT 相关品类(如智能插头、LED 灯、追踪器)的 Top 6 产品,经筛选(排除非裸机、非安卓配套、单价>50 美元设备),最终保留 19 款设备及 19 个配套 App;
- IoTSpotter 数据集:从 37,783 个 IoT 配套 App 中,筛选使用 Top 11 SDK 的 App,最终补充 1 款设备及 App,合计 23 款设备(见表 1)。
(2)AoT-Scout:手动分析 DFU 机制
通过 5 步流程逆向 DFU 逻辑,生成 SDK 指纹:
- 定位 DFU 代码:反编译 App(用 Jadx)、搜索关键词(“firmware”“DFU”)、动态监控通信(FridaHook、Wireshark 抓蓝牙 / Wi-Fi 包);
- 触发 DFU 流程:篡改设备固件版本号(静态修改 Apk 或动态注入代码),迫使 App 发起更新;
- 获取固件二进制:从 App 内置资源或后端服务器(拦截网络请求)提取固件,含历史版本;
- 识别 SDK:区分处理 DFU 的第三方 SDK 与主 App 代码;
- 生成 SDK 指纹:基于未混淆的硬编码字符串(如厂商 UUID、通信协议标识)构建正则表达式,规避 ProGuard 混淆影响。
(3)Attack-Tester:漏洞测试与分类
通过篡改固件二进制,测试设备对三类攻击的脆弱性,判断标准如下:
攻击类型 | 定义 | 判定依据 |
固件篡改攻击(ModAttack) | 注入恶意固件并执行 | 设备接受并运行修改后的固件 |
固件降级攻击(DownAttack) | 回滚至旧版本(含已知漏洞) | 设备接受历史版本固件 |
设备变砖攻击(BrickAttack) | 使设备永久不可用 | 设备无响应或无法恢复 |
- 关键关联:ModAttack 可衍生另外两类攻击(篡改固件可植入旧版本或无效代码)。
2. 第二阶段:大规模 App 分析(App-Rumbling)
基于第一阶段生成的漏洞 SDK 指纹,自动化检测 Google Play Store 的 IoT 配套 App:
- 数据输入:IoTSpotter 数据集的 37,783 个 IoT 配套 App;
- 检测流程:下载 Apk→用 Apktool 反编译为 Smali 代码→匹配 SDK 指纹→标记漏洞类别;
- 漏洞验证:对每个漏洞 SDK 随机抽样 1 款 App 及设备,重复 Attack-Tester 测试,确认漏洞真实性。
三、核心研究发现
1. 漏洞 SDK 与设备风险
- 6 个高危 SDK:通过 23 款设备分析,识别出 6 个存在 DFU 漏洞的 SDK,覆盖不同攻击类型(见表 2);
- 大规模影响范围:1,356 个 Google Play App、61 款亚马逊畅销 IoT 设备依赖这些漏洞 SDK,涉及智能插头、LED 灯、GPS 追踪器、摄像头等品类。
表 2:6 个漏洞 SDK 详情汇总
SDK 名称 | 漏洞类型 | 受影响 App 数量(估算) | 典型设备案例 | SDK 性质 |
Nordic-SDK | ModAttack(衍生 Down/Brick) | 1,128 | ilumi 智能灯泡 | 开源(SoC 厂商) |
Tuya-SDK | ModAttack(衍生 Down/Brick) | 933(含多 SDK 复用) | Aoycocr 智能插头、GoSund 插线板 | 开源(IoT 厂商) |
JcPrinter-SDK | ModAttack(衍生 Down/Brick) | 少量( proprietary) | NIIMBOT 标签打印机 | 闭源(专用) |
Telink-SDK | DownAttack(仅降级) | 102 | SYLVANIA 智能灯泡 | 开源(SoC 厂商) |
Wemo-SDK | BrickAttack(仅变砖) | 31 | Wemo 智能插头 | 开源(已停用) |
NordicSecure-SDK | BrickAttack(仅变砖) | 936 | SwitchBot 智能开关、NUT 寻物器 | 开源(需配置) |
2. 漏洞关键特征
- 开源 SDK 风险更高:Nordic、Tuya、Telink 等开源 SDK 因普及性高,影响范围最广(占受影响 App 的 80%+),且默认缺乏加密验证;
- 闭源 SDK 并非更安全:JcPrinter-SDK(闭源)虽仅用于标签打印机,但存在严重的 ModAttack 漏洞;
- 配置错误加剧风险:NordicSecure-SDK 本应支持固件签名验证,但厂商未启用 “双 bank 更新”(备用固件分区),导致设备接收无效固件后变砖;
- 厂商响应不足:仅 SwitchBot、Nordic Semiconductor 确认漏洞并配合修复;Wemo(Belkin)停止对漏洞设备更新,但该设备 2023 年仍在亚马逊销售。
3. 攻击场景实例
论文验证了两类高可行性攻击场景:
- 短租公寓场景:攻击者进入 Airbnb 房间后,通过蓝牙拦截配套 App 与智能灯泡的通信,注入恶意固件(ModAttack),窃取家庭网络权限;
- 恶意 App 场景:攻击者在用户手机植入恶意 App,篡改配套 App 的 DFU 请求(如替换固件 URL),使智能摄像头降级至有漏洞版本(DownAttack),进而监控用户。
四、关键案例研究(典型 SDK 漏洞深度解析)
1. Nordic-SDK 与 NordicSecure-SDK:配置决定风险
- Nordic-SDK:无固件签名验证,默认支持 ModAttack。如 ilumi 智能灯泡接受任意修改的固件,攻击者可通过蓝牙直接注入恶意代码;
- NordicSecure-SDK:需正确配置才安全,但多数厂商存在疏漏:
- SwitchBot 智能开关:未验证固件 CRC(循环冗余校验),攻击者修改固件后重新计算 CRC 即可通过验证;
- NUT 寻物器:未启用 “双 bank 更新”,接收无效签名固件后进入 “等待状态”,无法恢复(BrickAttack),仅能通过 Nordic 官方工具修复。
2. Tuya-SDK:MQTT 协议漏洞导致批量攻击
Tuya-SDK 依赖 MQTT broker 实现 Wi-Fi 设备的 DFU,攻击者可通过工具(如tuya-convert)伪装成 MQTT broker,在设备注册时触发 DFU 并发送恶意固件。论文验证:GoSund 智能插线板接受篡改固件后,可被远程控制断电 / 通电。
3. Telink-SDK:仅防篡改,不防降级
Telink-SDK 对固件进行加密签名(防 ModAttack),但未实现 “防回滚机制”。攻击者可从后端服务器获取旧版本固件(修改 URL 中的版本号),将 SYLVANIA 智能灯泡降级至存在蓝牙漏洞的版本,进而拦截设备通信。
五、研究局限与未来方向
1. 局限
- 设备范围受限:排除非安卓配套设备(如仅支持 iOS 的设备)、非裸机设备(如智能手表)、单价>50 美元的高端设备,可能低估高端设备的安全性;
- 通信协议覆盖不全:仅分析蓝牙 / Wi-Fi 设备,未包含 ZigBee、Z-Wave 等主流 IoT 协议;
- 逆向工程限制:部分 App 依赖原生代码(Native Code),无法完全逆向 DFU 逻辑,可能存在漏检漏洞。
2. 未来工作
- 自动化分析工具:开发自动化提取固件 URL、识别 DFU 代码的工具,减少手动逆向成本;
- 扩展协议与设备类型:覆盖 ZigBee、Z-Wave 设备,分析不同价格、不同目标用户(消费级 / 工业级)的 IoT 设备安全差异;
- 防御方案验证:设计 “固件签名 + 防回滚 + 双 bank 更新” 的标准化 DFU 方案,并在实际设备中验证有效性。
六、实践建议(面向厂商与用户)
1. 厂商:修复 DFU 漏洞的核心措施
- 强制固件验证:实现固件的加密签名(如 RSA)、完整性校验(如 SHA-256),拒绝未验证的固件;
- 防回滚机制:记录设备当前固件版本,拒绝低于当前版本的更新请求;
- 双 bank 更新:预留备用固件分区,更新失败时自动回滚至旧版本,避免变砖;
- SDK 安全审计:定期检查第三方 SDK 的配置(如 NordicSecure-SDK 需启用签名验证),及时修复 SDK 本身的漏洞。
2. 用户:降低 IoT 设备风险的实用指南
- 优先选择安全认证设备:避免购买无品牌、无更新记录的 IoT 设备,优先选择支持 “固件自动加密更新” 的产品;
- 及时更新配套 App 与固件:关闭 App 的 “自动更新” 时,定期手动检查更新(漏洞 SDK 常通过 App 更新修复);
- 限制设备通信范围:蓝牙 IoT 设备(如智能灯泡)仅在更新时开启蓝牙,避免长期暴露在攻击范围内;
- 警惕陌生设备接入:短租场景中,避免连接未知 IoT 设备的 Wi-Fi / 蓝牙,防止被植入恶意固件。
七、研究价值与行业影响
该研究是首个针对 IoT DFU 机制的规模化安全分析,填补了 “App 介导的 DFU 漏洞” 研究空白:
- 技术价值:提出的 AoT-Scout、Attack-Tester 方法论可复用于其他 IoT 安全研究,SDK 指纹技术为大规模漏洞检测提供可行方案;
- 行业影响:披露的 6 个漏洞 SDK 影响超 1300 个 App,推动 Nordic、SwitchBot 等厂商修复漏洞,提升 IoT 设备整体安全性;
- 警示意义:揭示 “开源 SDK 普及性” 与 “安全性” 的矛盾,提醒厂商不可依赖第三方 SDK 的默认配置,需针对性加固。