Proof_hi论文阅读

题目：A Large-Scale Analysis of the Crowd-Reported Vulnerabilities in Embedded Devices

期刊/会议：TOSEM 2025

作者：Zheng, YaoWen（南洋理工大学）

论文简介

主题：通过建立漏洞POC库寻找重复漏洞，最终发现了16个新的漏洞

Motivation：

如下图，两个cve的漏洞url和注入点一样，但是时间上却差了5年，也就是说cve-2022-25060本应在2017年就应该被发现并修复。

作者定义的POC库不包括文字描述类，因为此类难以复现，说明模糊不清

难点：

POC定位困难：POC的参考链接种类繁杂，可能是博客、github仓库或者其他网站；
PoC难以提取：表现形式复杂，例如可能为截图
PoC分析复杂：需要专家知识

解决方法：人工~~~

第一步提取了2012到2023年的共3350个CVE；第二步找出有参考链接的CVE共1319个；然后人工筛选出非描述性的PoC共1066个；最后分析PoC获取有价值的内容

贡献：

作者在此文章中提出的几个研究问题：

PoC Characteristics：PoC的分布和种类特点是什么，PoCcrowd-reported的特点存在的问题；
Vulnerability Characteristics：漏洞的常见类型以及它们的漏洞位置；
Vulnerability Relationships：漏洞之间是否存在关系

回答中，针对第三个问题，作者发现了相关漏洞存在两种关系：1）不同设备可能PoC相同；2）同一个URI可能存在多个漏洞

此外，作者提供了相关工具和数据集：

技术路线

整体框架如下图，分为四步：

Vulnerability Dataset Collection：获取CVE数据
PoC Collection：人工筛选出有价值的PoC链接
Vulnerability Characteristic Extraction：自动化方法提取相关漏洞的关键特征，有助于了漏洞之间的关系分析；
Vulnerability Relationship Analysis：基于关键特征分析漏洞关系

Vulnerability Dataset Collection

从网站上爬取cve内容（部分人工收集）

CPE（Common Platform Enumeration）：标识了漏洞的相关平台

近几年有PoC的占比较大，原因可能是：

研究人员倾向于获取编号后就将PoC删去
参考链接错误

PoC Collection

PoC格式多种多样（纯人工收集）：

基于演讲展示的：PDF、图片、视频、PPT
基于实现的：文字描述、脚本、数据包

收集过程中发现的一些问题：

PoC文档化格式不够：一些人申请一系列CVE编号只在其中一个附上了PoC，其他就没有；
参考链接放错了
PoC不全：payload不全；代码不全
语法错误
关键变量未定义
关键变量设置错误：其实也不算错误，而是比如溢出ntpServer=a*num，num是用户要自己修改的值
缺少导入包

Vulnerability Characteristic Extraction

PoC的关键特征：存在漏洞的URI，存在漏洞的参数

提取方法：

格式统一：对于脚本类型的PoC，使用动态执行抓包的方式来获取数据包内容。如果无法动态抓包，则使用动静态分析结合的方式，作者对网络请求函数进行插桩来获取PoC数据包内容，具体做法是生成PoC的抽象语法树并识别发包的函数，然后在其中加上一个print函数打印数据包内容。
特征提取：URI使用正则表达式提取即可。Param需要进行decode以及根据漏洞类型自动化提取

Relationship between Vulnerabilities

关系定义：是否PoC相同（URI和Param都相同，且漏洞类型相同）；是否属于同一簇（URI相同，受影响设备有重合）

总结：应该只能算一篇漏洞数据分析统计的文章，然后就是其总结的方法我觉得创新性并不是很好，但很有用，人工的部分太多（感觉用LLM辅助一下可以减轻很多工作量）

该工作对于漏洞特征的定义是值得借鉴的，**(URI, Param, TYPE)**三元组的范式。而且还提供了web服务和数据集。

该工作对于漏洞CVE数据集的统计信息是有价值的，尤其是其中命令注入和栈溢出占大多数；相同PoC情况逐年上升。

该工作利用已有PoC挖掘其他设备中隐藏漏洞是有意义的。