LLMIF 论文整理

论文LLMIF（LLMIF: Augmented Large Language Model for Fuzzing IoT Devices ）

论文作者：Jincheng Wang（The Hong Kong Polytechnic University）
论文链接：2024 IEEE Symposium on Security and Privacy (SP)
工作源码：https://github.com/anonymousAnalyst22/LLMIF

1. 解决问题

Obfuscated Message Formats（复杂的消息格式）: IoT消息格式比较复杂。缺失消息格式会导致以下两个问题：
1. 种子生成受到消息格式的限制
2. 难以生成有效的变异输入（格式问题）
Unresolved Message Dependencies （未解析消息依赖）: IoT协议不同消息对应了设备的不同状态，也就是某些漏洞需要特定的消息序列使设备处于特征状态才能触发。
Lack of Testing Case Evaluations（缺乏案例评估）: 黑盒测试，缺乏对模糊测试定义合理反馈（代码覆盖率？），导致可能难以提升模糊测试效果。

2. 核心思路

协议规范提供了丰富且准确的消息格式描述，而复杂繁多的协议描述信息可以由LLM自动化完成

协议规范中对消息header与payload部分的描述有助于帮助生成正确格式的消息结构，从而有助于提取消息覆盖率、制定有效的变异策略
协议规范会描述与设备交互的具体信息，有助于提取消息之间的依赖关系。
eg：
- Zigbee Identify message <->“This then starts the device’s identification procedure”
- AddGroupIfIdentifying message <-> “The message allows the device to add a group on the condition that it is identifying itself”
协议规范展示了消息处理的工作流，可以用于评估测试输入是否达到目标效果

3. 技术实现

基于LLM实现，LLM辅助分为两个部分：Protocol Information Extraction（协议信息提取）， Device Response Reasoning （设备响应归因）

协议信息提取：LLM提取有效的协议信息：消息格式，field value，header structure，消息依赖关系。
设备响应推理：LLM基于协议规范，对给定的test case和设备response判断test case是否导致了设备状态转换。

3.1 大模型增强

具备相关领域知识的LLM被称为增强语言模型（ALM）

专业知识嵌入到上下文+CoT

3.1.1 为什么需要大模型增强

该工作向我们展示了LLM在IoT Protocol领域相关知识的缺乏，表明了使用ALM的必要性

Message identification：LLM需要给出正确的消息名
Format inference：LLM需要输出正确的field name以及field data types

96个消息类型中，大模型平均只成功构建了15个消息格式，召回率（15.6%）（和表格不一致？和实验评估里chatAFL的结果一致）。

3.1.2 大模型增强方法

使用知识提取器提取任务相关知识，然后将其作为上下文传递给大模型，有利于后续的任务解决。

该工作提取协议规范作为相关知识。

由于一般协议规范都有良好的格式，可以通过根据不同标题、大纲来制作索引；

使用了background-augmented prompting技术，感觉就是把专业知识和问题凑到一起…

3.2 基于LLM指导的模糊测试

整体流程：

使用LLM提取有效信息并根据这些信息生成种子；
发送到设备进行测试，获取设备响应；
使用LLM根据响应判断种子有效性。对于造成设备状态改变的，LLMIF会保留该输入并基于消息依赖关系构建新的种子。

3.2.1 协议信息提取

消息格式

针对消息描述可能过长的问题，该工作先划定范围，通过LLM总结协议规范指定范围的每一页，然后再合成每一页的总结描述来构成{message_descriptions}

message
{
  "payload": "leet";
  "code": 0xdeadbeef;
}

Interesting Field Value

感兴趣的目标值，有两种：dangerous value（不合法的值），functioning value（定义功能的值）

如下图：Effect Identifier = 0x00; Effect Variant = 0x00时对应了”Fade to off in 0.8 seconds”的功能。

消息头结构

提取消息头结构，和前面类似，也是提取相关bit的功能和类型

消息依赖

该工作对消息依赖的定义：A->B，传入A消息后更新部分设备属性，在传入B消息时会进行检查这些对应属性。

使用了CoT方法引导LLM进行推理，构建了21609个提示词，结果成功构建了968个消息依赖关系

3.2.2 种子生成

为每一个消息格式定义了MID， MID = (clusterID, cmdID)

生成种子时，从消息模版中挑选一类消息，然后根据其MID从上述阶段中提取的Interesting Value进行赋值，如果没有则随机赋值，组合成为种子，用于后续种子变异以及模糊测试输入。

3.2.3 种子变异

变异器分为两类：基于数据类型和基于消息头

基于数据类型的变异器

对于定长数据：一般为数值型，设置为极限值0,0xffff
对于变长数据：一般为字符串，第一字节为长度，1）增加字符串长度和对应变量长度位；2）仅修改变量长度位，可能会有不一致问题。
还会随机去除消息中的field来构造不合法输入

基于消息头的变异器

随机指定command identifier field
位翻转：翻转特定比特，可能会出现解析问题

3.2.4 响应推理

根据响应判断设备在接收输入后的状态，并据此选择是否保留输入。

判断是否应该保留输入的标准：

输入成功执行并使得设备状态改变
输入造成的响应非预期。eg：不合法输入并没有导致设备返回Invalid value，而是被成功执行。

3.2.5 测试集扩充

根据上一步消息响应结果来生成新的种子。

具体来讲：目前已有一个测试集输入s = [m₁, …, m_n]，该测试集输入后可以让设备处于特定状态，此时，如果存在m_n+1满足上述提取的消息依赖关系，那么就可以将m_n+1作为新的输入加进该测试集。

注：此处论文中标明依赖关系是仅根据前一个消息来提取的，是不是可以有更好的方法，考虑m₁到m_n整个序列对设备造成的影响，比如应该有个设备属性集合，作消息与设备属性的映射。

3.2.6 模糊测试工具实现

该工作设计了两个部分：Fuzzing controller和stack controller。

Fuzzing controller：LLMIF本体
stack controller：与Zigbee设备进行交互，与Fuzzing controller用UART串口连接

4. 实验结果

相较于baseline（BOOFUZZ，Z-FUZZER，BEEHIVE，chatAFL），消息覆盖率提升55.2%，代码覆盖率提升53.9%，其中消息覆盖率达到100%。
挖掘了11个Zigbee设备漏洞，8个0-day，7个无法被其他fuzzer检测到。

作者自己构造了模拟工具对提供源码的ZStack品牌设备进行编译插桩，进行代码覆盖率分析，由于消息覆盖率达到100%，代码覆盖率也得以有很大提升。

5. 优势

能够成功提取Zigbee的各类消息格式（100%）
显著提升了代码覆盖率（提升了53.9%）
更定制化地利用了LLM工具（相较于chatAFL，基于提示词工程）

LLMIF源码阅读