Fuzzing相关论文阅读笔记（一）

前言

​ 之前从网上一个博主的博客里面看到有关论文阅读记录的博文，博主在看完每一篇论文后都会进行相关总结和思考记录。个人觉得这是个不错的习惯，遂学习了下，刚好对最近看的几篇论文进行简单的记录。

论文总结

1、V-Shuttle

论文地址：V-Shuttle:Scalable and Semantics-Aware Hypervisor Virtual Device Fuzzing

1.1 基本介绍：

​ 这篇文章是潘神在2021年CCS上发表的一篇fuzzing相关论文，论文拿了CCS2021年的best paper（国内唯一）。fuzzing对象是虚拟化技术的核心组件hypervisor（虚拟机管理程序）中的虚拟设备（virtual device），应该属于云计算安全、虚拟化技术、fuzzing、二进制漏洞挖掘与应用等相关领域。

1.2 大致内容：

​ 传统使用随机输入、覆盖引导、结构感知的方法对hypervisor中大部分虚拟设备进行fuzzing，会存在效率低下、覆盖率低、可扩展性差等问题。本文研究了造成这些问题的核心在于：通过DMA传输的数据结构具有高度嵌套特性。后续作者通过对qemu的hypervisor中与DMA操作相关的api进行hook，将对虚拟机用户内存数据的读取重定向到了fuzzer的testcase中，以此来解决传统fuzzing突变指针字段会导致无效内存访问的问题。在前面基础上，作者再通过数据流分析方法（活变量）对每种类型DMA对象的数据结构进行标记、分组构建种子池（seedpool），实现了语义感知的功能，来引导fuzzing过程中testcase的构建。

1.3 结论：

​ 作者提出的对hypervisor中虚拟设备可扩展和语义感知的fuzzing框架，相较于之前的研究来说：

• 有了更好的自动化能力：无需先验知识、整个过程无需人工驱动
• 更强的可扩展性：对不同平台、多个虚拟设备的fuzz都有很好的覆盖率（virtual box上的虚拟设备似乎没有展示，有代考究）
• 更优秀的漏洞挖掘能力：挖出了之前没有的35个bug、17个被授权为CVE，甚至包含了black hat上公布的一个虚拟机逃逸。（先膜拜一波）

1.4 思考：

​ 文章中提到该框架的相关问题主要有：要求目标设备代码开源，因为需要进行相关hook操作（这个应该不是问题，只要得到官方授权应该可以弄到源码）、不能自动恢复POC，因为fuzzing引擎是集成在hypervisor主机进程中（有点没弄懂，是需要手动构建漏洞利用脚本的意思？）、对hypervisor内部状态的细粒度感知不够（v-shuttle的工作过程中，目标系统内部状态一直存在，但相同输入在不同的内部状态下可能执行不同的代码路径）。

​ 个人觉得这篇文章的亮点主要在于：

• 对虚拟化技术底层的研究比较深入（包括DMA、MIMO等机制）
• 论文的产出确实丰厚：35个之前没有发现的bug，17个CVE，1个虚拟机逃逸（这个成绩属实很好了）
• 云计算安全的背景加分：现在云计算相关应用太火了，这方面的安全问题确实影响太大。

2、ICS3Fuzzer

论文地址：ICS3Fuzzer: A Framework for Discovering Protocol Implementation Bugs in ICS Supervisory Software by Fuzzing

2.1 基本介绍

​ 这篇论文是中科院信工所孙利民老师指导的一篇fuzzing论文。fuzzing对象是ICS（工业控制系统）中的监控软件（也就是常见的上位机软件这些），应该属于工控安全领域。

2.2 大致内容

​ 监控软件广泛用于ICS中，可被滥用来恶意控制或操纵物理设备（PLC等），危机生产过程甚至人类生命。本论文提出了一个可移植化、模块化的模糊框架来自动发现监控软件和现场设备之间通信协议中的bug。针对协议逆向需要大量人工工作的问题，该方法通过GUI操作和网络通信的同步控制，实现了整个监控软件的运行和模糊测试，避免了对协议实现模块的分析和提取。基于监控软件的执行轨迹和相应输入，构造一个状态记录本，同时提出一种状态选择算法来找出更容易出现bug的协议状态，进而为fuzzer分配更多这些状态的输入。

2.3 存在的挑战性

• 引导监控软件进入特定的输入状态是有挑战性的，因为监控软件中每个会话涉及多个输入状态。
  • 例如TCP三次交互都是由客户端角色（监控软件）发起的，所以fuzzer智能被动等待，指导接收到监控软件的会话请求。
  • 其次每次模糊测试一个输入状态，多要一次又一次触发监控软件进入正确交互状态。
  • 最后由于输入状态之间复杂的依赖关系，很多情况下监控软件不先输入其他状态就不能直接输入一个输入状态。
  • 最糟糕的是——基于流量识别一组完整的会话状态本身就很难（因为缺乏私有协议知识）
• 几乎所有监控软件使用的都是私有协议来和PLC通信，所以具有未知的状态空间（输入状态）和格式——不可能探索深层路径和协议状态。
• 在进入特定的输入状态之前，监控软件发送的每个请求都必须正确响应（状态机要满足，然而缺乏该方面的知识）

2.4 相关解决方法

• 对于C1，本文设计了一种新的控制机制，通过对GUI操作和网络通信的精确同步控制，实现进入任何识别的输入状态。
• 对于C2，采用现有的工作（Discover、Dispatcher、Netzob等）来自动化逆向工程协议的包帧格式，同时通过差分分析来识别字段、识别出会话ID、序列号等字段值约束。此外为了识别有价值的状态、过滤重复状态，作者避免了对详细的程序状态进行逆向工程，而是基于执行跟踪和相应的输入构建状态簿，同时在此基础上提出一种动态切换状态的模糊策略。
• 对于C3，根据实际捕获的流量构造了一组通信模板，模拟PLC设备的响应。对于管理软件的每个请求，首先在匹配的模板中识别相应的响应，然后自动调整对应的值约束（会话ID、序列号等），如果太复杂则直接使用真实PLC设备提供？

2.5 结论

​ 本文提出一个针对ICS监控软件的可定制、模块化的fuzzing框架，以支持不同监控软件协议实现方面的漏洞检测。给定监控软件的功能，作者可以构建一个通信模板来基于捕获的消息模拟会话，在网络和GUI行为自动同步的帮助下，ICS3 Fuzzer可以达到任何输入状态，并定向提供突变的输入，通过在4个不同的商业监控软件上实验，发现了13个漏洞。

2.6 思考

​ 这篇文章的fuzzing对象是ICS系统的监控软件，通俗点理解应该就是PLC上位机软件。感觉一定程度上还是从流量的角度来对软件进行fuzzing，进而挖掘上位机软件的协议漏洞。整体的框架中，Fuzzer似乎就模拟成了一个虚拟PLC，作为为上位机提供响应的角色。感觉关键思想在于：通过捕获的流量包来制作字典，能匹配请求的响应就送出去，无法匹配（过于复杂）的复杂请求，就交给真实的PLC处理。这个思想和虚拟化工控蜜罐的思想好像差不多欸？然后在此基础上，动态选择感兴趣的状态（输入）来模糊测试软件？