夜雨聆风论文：IoTBec: An Accurate and Efficient Recurring Vulnerability Detection Framework for Black Box IoT devices作者：Haoran Yang, Jiaming Guo, Shuangning Yang, Guoli Zhao, Qingqi Liu, Chi Zhang, Zhenlu Tan, Lixiao Shan, Qihang Zhou, Mengting Zhou, Jianwei Tai, Xiaoqi Jia单位：Institute of Information Engineering, Chinese Academy of Sciences；School of Cyber Security, University of Chinese Academy of Sciences；School of Internet, Anhui University来源：NDSS 2026原文：https://www.ndss-symposium.org/wp-content/uploads/2026-f634-paper.pdf项目：https://github.com/IoTBec
IoTBec 这篇论文在 Tenda、TOTOLINK、D-Link、TP-Link、Linksys 五类设备实验中，它检测出 183 个漏洞，其中 169 个已分配 CVE ID；和 boofuzz、Snipuzz 相比，发现数量超过 7 倍，gpt-4 配置下 recall 达到 93.37%，alert precision 是 100%。
但这篇论文真正有意思的地方，不只是“LLM fuzzing 又发现了很多洞”。它解决的是一个更贴近实战的约束：如果拿不到 firmware，也没有 source code，甚至不能做物理调试，只能登录设备 Web 管理界面、抓请求包、读公开 CVE 报告，能不能做自动化的复现漏洞检测？
作者的答案是：可以，但不要把 LLM 当作万能漏洞扫描器。IoTBec 把黑盒可见的信息组织成签名，LLM 只在签名抽取和 payload 生成这两个环节发力。
真实黑盒场景里，固件依赖是硬门槛
IoT 漏洞检测常见路线是静态分析和动态分析。静态分析需要 firmware 或 source code；动态分析往往需要高保真仿真、rehosting，或者至少能拿到固件镜像。现实里这两者都不容易：固件可能不公开，可能加密，企业级设备的外设和运行环境也不好复现。
黑盒 fuzzing 当然可以做，但信息太少。Snipuzz 用设备响应来指导消息片段变异，已经比fuzzing 更聪明；LABRADOR 用 response-guided control flow inference 提升效率，但仍然需要 firmware 静态分析。IoTBec 想处理的是更严格的场景：firmware/source-code independent。
论文观察到两个外部信息源其实很有价值。
第一是公开 CVE 和漏洞报告。IoT 设备有大量历史漏洞，报告里经常写着受影响产品、漏洞类型、POST endpoint、关键参数甚至 PoC。
第二是设备 Web UI 和请求包。很多路由器、摄像头、扩展器都有导航栏、层级页面和管理接口。相似产品的功能模块和 POST 接口经常复用，某个接口上的漏洞很容易在同系列设备里复现。
这就把问题从“没有固件怎么分析程序”换成了“能不能用外部可见接口和公开漏洞信息，构造一个足够准确的复现漏洞签名”。
IoTBec 的三个签名
IoTBec 的流程如下。
IoTBec workflow
它用了三类签名。
第一类是 VS，Vulnerability Signature。IoTBec 从 CVE 描述和公开漏洞报告里抽取结构化字段，例如 CVE ID、vendor、affected product、vulnerability type、POST interface、critical parameter、payload 信息。这里会用 vulnerability analyzer LLM。
Vulnerability Signature extraction
第二类是 IS，Interface Signature。IoTBec 登录设备 Web UI，深度优先遍历页面，抓取 POST interface、网络请求包和 UI context。UI context 不是无关信息：导航栏和按钮文本能帮助判断这个接口属于哪个功能模块。
Interface Signature extraction
第三类是 VIS，Vulnerability Interface Signature。它把同一设备上的 VS 和 IS 通过 POST interface 等关键字段对齐，形成一个既包含漏洞语义、又包含设备接口结构的签名。之后测试新设备时，只抽它的 IS，再和 ground-truth VIS 做匹配。
这个设计的好处是，它没有把漏洞判断直接交给 LLM。LLM 负责把非结构化报告变成结构化 VS，或者根据匹配到的 VIS 生成 fuzzing payload；匹配、执行、监控这些部分仍然是程序化流程。
检测流程：先匹配，再定向 fuzz
IoTBec 的检测可以拆成四步。
第一步，用一部分设备构建 VIS ground truth。论文选了 5 个主流厂商：Tenda、TOTOLINK、D-Link、TP-Link、Linksys。每个厂商挑有较多公开漏洞的产品，收集 CVE 和报告，抽 VS；同时遍历设备 UI 抽 IS；最后合成 VIS。
第二步，对待测设备抽 IS。待测设备只需要能访问 Web 管理界面，不需要 firmware。
第三步，做相似匹配。如果待测设备某个 IS 和 ground truth 里的 VIS 匹配，就说明这个接口可能存在同源或相似的 recurring vulnerability。
第四步，调用 fuzzing LLM 生成 payload。论文里每个 match 生成 7 个不同 payload，再自动发送并由监控模块判断是否触发漏洞。root-cause vulnerability 用 (POST interface, parameter) 去重。
这套流程和普通黑盒 fuzzing 的差别很大。boofuzz/Snipuzz 往往要在大量接口上盲测；IoTBec 先用 VIS 缩小搜索范围，然后围绕“已知漏洞对应的接口和参数”做定向变异。
实验设置：虽然用了仿真，但检测过程是黑盒
论文用 27 台来自五个厂商的真实设备做实验：6 台用于 ground-truth VIS 构建，21 台作为 test set。为了可控和可复现，作者把固件放进 QEMU 全系统仿真环境里跑，并用 binwalk 提取文件系统。
这里容易有误解，IoTBec 的检测输入仍然只来自 Web UI、请求包、CVE 描述和公开报告；论文使用固件和 QEMU 是为了统一实验环境、方便确认漏洞触发，并不是说 IoTBec 分析时读取了 firmware。
构建 ground truth 时，作者从 6 个产品收集了过去 5 年的 261 个 CVE ID。vulnerability analyzer LLM 从 CVE 描述和报告中成功抽取 VS 的比例是 90.8%。平均每个 CVE 抽 VS 约 5 秒，prompt/output token 通常不超过 1,200/200。相比之下，抽一个设备的所有 IS 平均约 1,200 秒，这个过程不需要 LLM。
主结果：183 个漏洞，100% alert precision
主结果在 Table II。
IoTBec vulnerability detection results
21 台测试设备上，IS 抽取成功率是 86.42%。IoTBec 总共发现 183 个 root-cause vulnerabilities，其中 169 个已分配 CVE ID。论文摘要里还给出一个更强的统计：其中 53 个是新发现漏洞，平均 CVSS 3.x 分数 8.61，覆盖 buffer overflow、command injection、CSRF 等类型。
从厂商分布看，Tenda 是大头：接口 336 个，成功抽取 IS 262 个，匹配 148 个，产生 452 次告警，最后确认 136 个 root-cause vulnerabilities，其中 122 个分配 CVE。Linksys 也很突出：32 个接口/IS，12 个 match，42 次告警，36 个 root-cause vulnerabilities，36 个都分配 CVE。
论文报告 IoTBec 的 alert precision 是 100%。这个数字来自它的监控规则比较保守：例如 buffer overflow 通过服务崩溃、连接异常或特定 HTTP 500 响应判断；command injection 使用 out-of-band 检测。换句话说，它宁可依赖更明确的触发信号，而不是只凭页面返回内容猜测。
效率上，IoTBec 平均用 101 秒、11 个 test payloads 发现一个 root-cause vulnerability。对黑盒 IoT 测试来说，这个数字比“跑一整晚 fuzzing 看日志”更接近可操作。
和 boofuzz、Snipuzz 比，差距来自搜索范围
对比实验用了 boofuzz 和 Snipuzz。
Comparison with Snipuzz and boofuzz
总结果是：Snipuzz 找到 13 个漏洞，boofuzz 找到 26 个，IoTBec1，也就是 gpt-4 配置，找到 183 个。按三者合并发现的 root-cause 漏洞集合计算 recall，Snipuzz 是 6.63%，boofuzz 是 13.27%，IoTBec1 是 93.37%。换成 gpt-3.5-turbo 的 IoTBec2 recall 是 74.49%，chatgpt-4o-latest 的 IoTBec3 是 93.88%。
作者给了一个具体例子。Tenda FH1201 的 /goform/RouteStatic 接口上，boofuzz 通过穷举 fuzzing 找到 page 参数溢出；IoTBec 因为把这个 IS 匹配到了 Tenda FH1202 的 CVE-2023-37714 VIS，第一个 payload 就发现了 page 参数的复现溢出。更进一步，LLM 围绕同一接口生成的第 5 个 payload 还发现了 mitInterface 参数上的新溢出，后来分配为 CVE-2024-41464，CVSS 3.1 分数 9.8。
这说明 IoTBec 的优势不是简单“LLM 生成的字符串更花”。更准确地说，VIS 把 fuzzing 的搜索空间压缩到了高风险接口和高风险参数附近，LLM 再做局部泛化。
LLM 的作用：抽取和泛化，不是端到端判断
IoTBec 里有两个 LLM。
vulnerability analyzer LLM 负责从 CVE/报告里抽 VS。这类任务适合 LLM，因为输入往往是自然语言报告、PoC 片段、页面描述，输出则是结构化字段。
fuzzing LLM 负责在匹配到 VIS 后生成 payload。它会拿到待测设备的请求包 seed、匹配到的漏洞信息和公开报告，然后生成针对关键参数的 payload。
需要注意的是，IoTBec 没有把“这个设备有没有漏洞”的判断直接交给 LLM。它的判断链条是：签名匹配给出候选，payload 执行产生行为，监控模块发出 alert，最后按接口和参数归并 root cause。这样的分工比较稳，也更容易复核。
鲁棒性和消融：字段不能随便删
论文还做了两个补充实验。
第一个是加密数据包场景。测试中有两台 Tenda 设备抓到的数据包是 AES 加密的，无法获得完整明文。其他黑盒 fuzzing 工具在这种情况下基本失效，但 IoTBec 仍能用不完整 IS 做匹配，发现 16 个 root-cause vulnerabilities。这说明 VIS 并不完全依赖 form-data 明文，UI context 和 endpoint 仍然能提供信号。
第二个是 IS 字段消融。作者分别去掉 POST interface、form-data、navigation-button。结果很有意思：删字段后 match 数量会增加，但 root-cause vulnerabilities 没有增加，LLM payloads 和时间成本反而上升。以 Tenda AC7 为例，baseline 是 31 个 match、217 个 payload、16 个 RC；去掉 navigation-button 后变成 37 个 match、252 个 payload，RC 还是 16。
这说明这些字段不是为了“把签名做复杂”。POST interface、请求参数和 UI context 共同约束了匹配范围，少一个字段就更容易过度泛化，把不相关漏洞也匹配进来。
局限：它强在复现和变体，不是全量漏洞发现
IoTBec 的边界也很清楚。
第一，它依赖公开 CVE/报告和设备 UI。如果某个厂商历史 CVE 很少，或者设备没有可遍历的 Web UI，VIS 的基础就会弱很多。
第二，它发现不了 UI 没链接到的隐藏接口和 debug path。没有 firmware/source code，本来就缺少内部路径信息；IoTBec 选择了外部可见信息，因此检测范围也被外部可见面约束。
第三，当前设计主要做 intra-vendor recurring vulnerability detection。不同厂商之间 UI 结构、POST endpoint、参数命名差异更大，跨厂商匹配在当前设计下不可靠。
第四，它仍然需要人工做前期设备准备、选择 ground-truth 设备。LLM 能抽字段和生成 payload，但不能替代实验资产准备。
最后，性能依赖模型能力。gpt-3.5-turbo 配置下 recall 从 gpt-4 的 93.37% 降到 74.49%，说明这类系统在工程落地时要认真评估模型替换成本。
我的理解
IoTBec 给黑盒 IoT 测试提供了一个很实用的思路：当内部不可见时，不要假装自己能做白盒分析；把外部可见信息做到足够结构化，反而更稳。
它尤其适合两类任务。第一类是同系列设备的漏洞复现：某个 Tenda/TOTOLINK/D-Link 型号上有公开 CVE，另一个同系列产品是否也有类似接口和参数？第二类是变体挖掘：已知漏洞的关键参数附近，是否还有语义相近但未报告的参数也会触发？
它不适合被包装成“黑盒 IoT 全自动扫全漏洞”。论文的实验数字很强，但核心前提是 recurring vulnerability：用历史漏洞和外部接口的一致性来换效率。这个边界越说清楚，它的工程价值反而越高。
从开发者和安全团队角度看：Web UI 的接口命名、参数结构和功能模块复用，本身就是供应链式漏洞复现的线索。如果产品线里反复复制同一套管理接口，那么公开 CVE 不只是某一个型号的问题，它很可能已经变成了一整组设备的测试入口。
