- 【参考文献】Song C, Yu B, Zhou X, et al. SPFuzz: a hierarchical scheduling framework for stateful network protocol fuzzing[J]. IEEE Access, 2019, 7: 18490-18499.
- 【注】本文仅为作者个人学习笔记，如有冒犯，请联系作者删除。
目录
4、Description Language Definiton and Translation
4.1、Protocol Specification Description
4.2、Protocol State Transition Description
4.3、Protocol Dependency Representation
4.4、Translation of description file
5、Hierarchical Fuzz Mutation Strategy Scheduling
5.3、Sequence mutation strategy
6、SPFuzz Scheduling Framework Implementation
7.2、Evaluation three-granularity coverage
8.1、MESSAGE SPECIFICATIONS CANNOT COVER ALL SITUATIONS
8.2、APPLICATION IN COMPLEX PROTOCOLS
8.3、ENCRYPTION ISSUES IN THE PROTOCOL
摘要
- 近年，由于目标程序覆盖范围的提高和使用的方便性，模糊技术被广泛应用于软件漏洞的检测。但是，由于维护消息的状态和依赖性等困难，模糊有状态协议的效率较低。
- 为了解决这些挑战，我们提出了SPFuzz，一个用于构建灵活的、覆盖引导的有状态协议模糊测试框架。我们在SPFuzz中定义了一种语言来描述协议规范、协议状态转换和依赖关系，用于生成有价值的测试用例，在会话状态中维护正确的消息，并通过及时更新消息数据来处理协议依赖关系。
- SPFuzz采用三级突变策略，即头部、内容和序列突变策略，驱动模糊测试过程覆盖更多的路径，并结合随机为消息和策略分配权重的方法。我们使用以下指标来评估SPFuzz和其他框架在三个协议实现（即Proftpd、Oftpd和OpenSSL）上的性能，这些指标具体是函数级覆盖率、基本块级覆盖率和边级覆盖率。
- 在实验中，SPFuzz框架在三个粒度覆盖测试中平均比现有的有状态协议模糊工具Boofuzz高出69.12%。这表明SPFuzz有能力探索目标程序更深入更深入的路径。我们使用SPFuzz进一步在OpenSSL 1.0.2中触发了CVE-2015-0291，这证明了我们的框架的有效性和实用性。
1、Introduction
- Munea等人，通过2015年的研究总结了5个协议模糊分类标准如下：
-
Intelligence level（智能水平）
-
Method of producing test cases（生成测试用例的方法）
-
Method of detecting vulnerabilities in a server（检测服务器漏洞的方法）
-
Ability of storing the previous states of sessions（储存之前对话的能力）
-
Method of sending inputs to a server（向服务器发送输入的方法）
-
- 基于上述5个标准，现存的fuzzers有以下问题：
- 这些方法在协议规范的自学习上花费很少。
- 测试用例通常倾向于通过变异真实消息来生成，而不是基于协议标准生成输入，以提高模糊效率。
- 由于不可避免的开销，这些方法中的大多数都忽略了诸如动态内存分析之类的技术，并手动分析漏洞。
- 存储以前会话状态的能力对于模糊有状态协议是必要的。
- 至于最后一个标准，一种方法是在发送输入时保持消息序列的正确顺序，然后修改消息数据。另一种是同时改变顺序和数据。
1.1、Main Challenge
- 有状态协议的状态很难维持
- 有状态协议模糊测试比无状态模糊测试要复杂得多。例如，超文本传输协议 (HTTP)的输入是独立的，而不管状态保留；而模糊测试FTP这样的有状态协议需要维护包含状态如何转换的状态机。然后，fuzzer建立所有以前的状态，并保持基于状态机的连接，以测试一个目标状态。
- 依赖关系很难处理
- 对于大多数有状态的网络协议，存在消息内部和消息之间的依赖关系。例如，长度字段或校验和字段由内容决定，这是一种消息内部依赖关系。前序消息 (Pre-order)携带后续消息所需的认证或加密信息，这在它们之间产生了依赖关系，这是一种消息之间的依赖关系。这些依赖关系影响我们在模糊测试时是否能够生成有效的测试用例。
- 路径覆盖范围很难提升
- 许多框架通过根据协议的规范制定一些模板来生成测试用例。这种采用人工参与的方法导致许多路径不被覆盖，而其中可能存在隐藏的漏洞。
1.2、SPFuzz Framework
- 在本文中，我们提出了SPFuzz，一个可以在模糊测试的同时维护会话状态和网络连接的框架。同时，它还解决了处理消息依赖关系的问题。此外，采用头部、内容和序列的三级突变策略，提高了模糊化的覆盖范围。
- SPFuzz框架定义了一种描述语言来描述规范、状态转换和协议的依赖关系。解释器将描述文件转换为框架可以识别的消息实体和消息序列。
- 三级变异策略结合了协议规范中的知识驱动和AFL的随机全策略变异。此外，SPFuzz利用了AFL的变异能力来随机生成测试用例，这避免了用太多的细节来描述协议规范。
- 消息内部或消息间的依赖通过更新消息的相关字段来处理。根据不同消息的特征，对被模糊测试消息的选择和突变策略都给予不同的权重，产生不同的选择概率，使模糊测试过程穿越更多的路径，容易发现漏洞。
- 该框架参与了整个模糊测试的过程。同时，它还与AFL引擎和目标服务器进行通信。此外，它还监视服务器的响应消息并收集跟踪，所有这些跟踪都被反馈给测试用例生成。
1.3、Contribution
- 我们定义了一种描述语言来描述消息规范，状态转换和依赖。
- 我们设计了一种三级变异策略（头部，内容和序列）。
- 我们实现了SPFuzz，通过AFL的特征和权重选择来提高覆盖率。
- 我们进行了实验，结果表明SPFuzz比Boofuzz和AFL的覆盖率更高。此外，SPFuzz框架触发一个已知的漏洞。
2、Background
2.1、Fuzzing Technology
- 根据模糊工具是否了解目标程序的特点，可以分为“dumb mode”和“intelligent mode”。
- 一些程序会存储接收到的消息，并用于影响当前消息的处理。这称为有状态协议。有状态协议模糊测试与文件模糊测试不同。首先，我们需要考虑协议规范生成有价值的输入。第二，消息的传输是有状态的，并且输入有依赖关系。第三，发送到目标的测试用例顺序可能导致不同的结果。例如，在FTP协议中（图1所示），根据正确的顺序，序列的第一个消息是“USER”，后面是对应的“PASS”消息。在连接建立后，可以通过“STOR”或“RETR”消息传输数据。如果不保持之前的状态，那么后续的模糊测试就毫无意义了。
- 对有状态协议进行模糊测试存在一些问题。
- 首先，目标的状态应该由一个监视器来记录。如果发生崩溃或模糊工具失去与目标的连接，监视器将记录崩溃，并将过程的轨迹反馈给模糊工具；
- 第二，解决消息中的依赖是一个挑战。例如，TLS协议的“Heartbeat”消息，其长度字段由内容字段的长度决定。
2.2、Introduction of AFL
- American Fuzzy Lop (AFL) 是一种流行的现成模糊测试工具。它依赖于变异策略来实现高覆盖率。AFL 维护一个队列，该队列存储输入文件作为每个循环变异的种子。
- 此外，AFL 使用五种策略生成大量测试用例，并通过位图对目标程序进行插桩以计算覆盖率。提出的 SPFuzz 框架利用 AFL 的变异特性来对消息的内容字段进行变异。
3、Framwork overview
- 为了解决模糊有状态协议方面的挑战，我们设计了一个名为SPFuzz的强大框架，它不仅包含协议规范的描述语言，还包含一个三级模糊策略。我们实现了一个带有功能组件的框架来调度模糊测试过程。
3.1、Main Componets
- SPFuzz的概述如图2所示，由下面几个部分组成：
- Description File
- 它涵盖了协议规范描述，包括消息名称、消息中每个字段的规范及其依赖关系，以及协议状态转换描述。我们定义了一种描述语言，该语言基于 Boofuzz 的格式化功能设计，并进行了一些扩展以适应我们的框架。
- Interpreter
- 解释器的作用是翻译描述语言，特别是将协议规范描述文件转换为消息实体以生成测试用例，并将状态转换描述文件转换为消息序列。
- Core Scheduler
- 核心调度器使用三级策略，即头部、内容和序列，调度分层模糊测试过程。同时，它还负责处理依赖关系和通信。
- Mutation Engine
- 我们使用AFL作为内容变异引擎，它基于原始种子生成测试用例，并将测试用例反馈给核心调度器。
- Target Server
- 目标服务器接收测试用例并返回对应的响应。这些响应消息连同目标进程的跟踪记录一起返回给核心调度器，以便进行后续分析。
3.2、Work Flow
- SPFuzz的工作流程如下：
- 用户定义协议规范文件和协议状态转换文件。
- 解释器将描述文件转换为消息实体和消息序列。
- SPFuzz开始一轮模糊测试。
- SPFuzz根据消息权重在当前轮次中随机选择一条消息进行测试。
- SPFuzz获取当前消息的整个消息序列，用于构建先前的状态。然后，它根据消息特征更新策略权重，例如，对于那些具有多个头部字段的消息，会选择头部策略。
- SPFuzz根据策略权重从三种类型（头部、内容和序列）中随机选择一种策略。
- SPFuzz对消息执行对应的变异策略，如果采用内容变异策略，则从AFL接收测试用例。
- SPFuzz格式化测试用例。
- SPFuzz根据消息序列构建当前消息之前的状态。
- SPFuzz将测试用例发送到目标服务器。
- 目标服务器发送响应消息和跟踪记录，然后框架进行分析并将信息反馈到下一轮模糊测试。
- SPFuzz为下一轮模糊测试重置。
4、Description Language Definiton and Translation
-
SPFuzz必须了解正在进行模糊测试的网络协议的规范，包括协议中的消息格式和构建会话的消息序列。此知识可以从RFC ( Request For Comments)获得。
-
因此，我们定义了一种从Boofuzz的描述语言扩展而来的描述语言。该描述语言包括协议规范描述和协议状态转换描述。在规范描述文件中，不仅描述了协议的格式，还描述了协议内消息内部和消息之间的依赖关系。与其他工具的描述语言相比，SPFuzz框架进行了粗粒度的描述，并且 没有定义消息的每个字段，这减少了人工干预。
4.1、Protocol Specification Description
-
图3显示了两个消息的格式：FTP协议的“USER”和“PORT”。
-
- 完整的消息描述分为3个层次。
- 第一层为“request”：声明了协议中的名称和消息的权重。这里的消息权重表示该消息在协议中的重要性。它会影响当前消息在协议的所有消息中被混淆的概率。
- 第二层为“block”：它将“request”分为头部字段和内容字段，以选择不同的变异策略。头部块在描述文件中表示为“s_block_start(‘‘HEAD’’)”，内容块表示为“s_block_start(‘‘CONTENT’’)”。
- 第三层为“primitive”：负责划分头部块中的每个字段。值得进行模糊测试的字段用“s_string”表示，而诸如分隔符和填充等无意义的字段则用“s_delim”和“s_static”表示。
4.2、Protocol State Transition Description
- 图 4 是协议状态转换描述的一部分，描绘了如何逐步从初始状态移动到当前状态的过程，其中“s_connect”是转移动作。整个消息序列是根据链接顺序构建的。
4.3、Protocol Dependency Representation
- 协议中有两种依赖关系。一种是内部依赖，即一条消息内字段之间的依赖关系，例如长度字段由内容字段决定。另一种是相互依赖，即消息之间的依赖关系，例如在某些测试用例中，其数据由前置消息控制。有时，这些依赖关系会影响有效测试用例的生成。
- 因此，SPFuzz在协议规范描述中定义了两种依赖关系。
- Dependency representation between messages
- 消息间的依赖关系指的是前置消息与后续消息之间，以及发送的消息与响应消息之间的依赖关系。其表示形式如下：
- outDep(type,msg1,field1,msg2,field2)
- resDep(type,msg1,field1,res_type,res)
- 其中“type”表示依赖的类型，“msg1”和“field1”表示前置消息的消息名称和字段名称，“msg2”和“field2”表示后续消息的相同信息。
- 消息间的依赖关系指的是前置消息与后续消息之间，以及发送的消息与响应消息之间的依赖关系。其表示形式如下：
- dependency representation within a message
- 消息内的依赖关系表示形式如下：
- inDep(type,msg1,field1,field2)
- 其中“type”表示依赖的类型，“msg1”表示消息名称，“field1”和“field2”代表两个相互依赖的字段。
- 消息内的依赖关系表示形式如下：
- Dependency representation between messages
4.4、Translation of description file
- 如图 5 所示，这两个描述文件由解释器转换为 SPFuzz 框架其他部分可访问的格式。解释器从协议规范文件中提取所有消息的规范，并生成消息实体。在状态转换过程中，它还从状态描述文件中提取信息，并收集当前模糊测试消息的前置消息。这些前置消息被统一放置在消息序列中以进行状态构建。
5、Hierarchical Fuzz Mutation Strategy Scheduling
- 考虑到信息的内部结构及其之间的联系，对彻底融合的突变策略进行了分层次设计，涵盖了头部、内容和序列三个层次。
5.1、Head mutation strategy
- 头部部分根据表 1 中所示的消息头部字段的语义和规范采用定制的策略。在手动分析 RFC 文档后，我们发现头部字段可以分为以下几类：“长度”、“标记”、“版本”和“命令”。因此，变异策略可以选择在正常值范围内的头部，或者具有特殊值或非法值，如空值、零、一个大数字以及长度超出界限的字符串。
- 例如，在正常范围变化的策略下，“USER xxx”的头部可能会发生变异，而通过特殊值选择它可能会变异为“eRD2 xxx”，或者通过非法值选择变异为“0 xxx”。
5.2、Content mutation strategy
- 消息内容字段中的数据通常是随机且杂乱的。即便如此，在AFL的帮助下，SPFuzz能够为内容字段随机生成测试用例，用于执行全策略变异。
- AFL 使用包括位翻转、算术、兴趣、字典和破坏等策略，其引擎倾向于选择能发现新路径的策略。由于其出色的性能，我们可以利用 AFL 在目标程序上实现高覆盖率。
- 我们专门在conten变异模式下对 SPFuzz 框架进行了测试，该模式使用的是 AFL 的全策略变异。结果将在第7节中进行解释。此外，某些头部字段和内容字段之间存在依赖关系，例如长度和类型字段。在更新内容数据后，头部字段应相应地进行更新。
5.3、Sequence mutation strategy
- 为了保持消息的结构完整性，我们打乱消息序列的顺序，这也能够提高覆盖率。序列变异策略的实现是将当前选择的消息插入到正确消息序列的随机位置，以改变状态转换的方向。
6、SPFuzz Scheduling Framework Implementation
- 图6显示了SPFuzz框架的组件及其工作流程。最重要的组件是负责全局调度的核心调度器。核心调度程序与AFL引擎和目标服务器进行通信，并从解释部分接收描述文件。该关系如图2所示。
6.1、Mutation scheduler
- 根据三级突变策略，Mutation scheduler由三个突变调度器组成。基本上，头部突变调度程序将由头部突变策略产生的值（表1）保存到字典中。内容突变调度程序生成从AFL引擎获得的测试用例，而序列突变调度程序扭曲正确的消息序列。
- 变异调度器将随机选择一种变异策略和一条要进行模糊测试的消息，这些随机选择是根据消息权重和策略权重进行的。消息权重在第四节中定义，策略权重表示哪种策略更容易被选择。之后，它启动相应的调度器进行模糊测试。
6.2、Format handler
- Format handler用于在变异后重新排列测试用例或头部的格式。有必要将头部字段与内容字段拼接起来，使其成为一个完整的测试用例，因为变异调度器是分别对内容或头部进行变异的。
6.3、Dependency handler
- Dependency handler在接收到完整的测试用例时处理依赖关系。该处理程序会用正确的数据替换违反依赖关系的头部字段。消息内的依赖关系通过分析字段的相关性是否被打破来处理，例如内容的长度是否随着内容数据长度的变化而更新。当当前测试用例依赖于之前的消息时，处理两个消息之间的依赖关系。处理程序从一个缓存中读取数据，该缓存临时存储之前的消息以获取相关数据。
6.4、Communication scheduler
- Communication scheduler由一个套接字和一个流量状态监视器组成。它是向目标服务器发送和接收消息的桥梁。
- 调度器持续为 AFL 分叉一个子进程，该子进程提供测试用例，并以管道的方式传输回变异调度器。经过变异和格式化后，这些消息被调度并发送到目标服务器。然后，目标服务器返回响应消息和进程跟踪，这些将反馈给变异调度器以生成更有意义的测试用例。流量监视器始终监听来自目标的响应消息。如果响应消息未及时返回，当前的模糊测试轮次将被中断并跳过进入下一轮。这将为更有价值的模糊测试节省更多时间。
7、Evaluation
- 有两个指标来评估模糊测试工具的性能。
- 一个是触发的软件崩溃，无论是已知的还是新的漏洞导致的。
- 另一个是目标程序的路径覆盖率。路径覆盖率表示目标程序中覆盖了多少条路径。
- 在网络协议模糊测试中，之前的工作都没有使用基于覆盖率的方法，在本文中我们同时采用基于覆盖率的测量和触发崩溃。我们在三个粒度上评估了 FTP 协议和 TLS 协议的两种实现的覆盖率，即函数覆盖率、基本块覆盖率和边覆盖率。此外，我们重现了 OpenSSL 的 CVE-2015-0291漏洞，以证明 SPFuzz 的有效性和实用性。
7.1、Experiment setup
- 实验是在 Proftpd 1.3.5、Oftpd 0.3.7和 OpenSSL 1.0.2上进行的。这三个目标服务器部署在一个轻量级的 Debian-i386 2.6.32-5-686 虚拟机上。
- 环境配置步骤如下：
- 在 Debian 虚拟机上部署协议服务器并进行配置。
- 构建消息规范和状态转换描述文件以生成测试用例。
- 启动服务器以接受响应并记录跟踪。
- 运行框架对目标进行模糊测试。
7.2、Evaluation three-granularity coverage
- 我们测量了三个粒度的覆盖：函数覆盖、基本块覆盖和边缘覆盖。结果图表2所示。
- 其中，SPFuzz/C表示内容模式下的SPFuzz，它仅使用基于AFL引擎的内容突变策略，而SPFuzz/F表示具有所有突变策略的全模式下的SPFuzz。
- 由于细粒度的边缘覆盖混合了上下文信息，我们进一步比较和分析了三种服务器实现随时间的变化，如图7、图8和图9所示。
7.3、Triggering CVE-2015-0291
- 传输层安全（TLS）保护网络会话的安全性和完整性。通过交换密钥和证书、加密数据并在应用层传输来建立握手过程被认为是安全的。OpenSSL 是 TLS 的一种实现，在其 1.0.2 版本中检测到 CVE-2015-0291 。该漏洞通过在重新协商期间在“ClientHello”消息中替换无效的签名算法扩展导致拒绝服务。
- 我们利用 SPFuzz 框架，在内容和序列变异策略的帮助下，通过监测 TLS 中的握手协议来重现 CVE-2015-0291 。我们描述了握手消息的规范，并选择了可模糊的字段，如“client_random”、“premaster_string”和“signature_algorithms”。
- 在握手过程中，客户端和服务器生成随机值，用于生成后续消息的内容。握手过程中的所有消息都需要计算其哈希值。相应字段的长度字段必须不断更新，处理复杂的消息内和消息间依赖关系是困难的。我们通过用我们的语言描述这些依赖关系、在握手期间缓存消息以及利用 TLS 中现有的加密库来克服这些挑战。最终，触发了 CVE-2015-0291 ，证明了 SPFuzz 框架的有效性和实用性。然而，与 SPFuzz 相比，BooFuzz 未能触发 CVE-2015-0291 ，因为它没有处理协议中依赖关系的能力。
8、Limitation and Future Work
- 尽管与现有工具相比，SPFuzz提高了项目覆盖率，但也有一些限制和未来的改进。
8.1、MESSAGE SPECIFICATIONS CANNOT COVER ALL SITUATIONS
- 目前，协议规范描述文件、协议状态描述文件、协议状态转换描述文件和状态构建都必须手工处理。这是劳动密集型的，并且是不可扩展的。使这一步骤自动和智能，例如直接从RFC中提取协议规范，同时确保该步骤的正确性。
8.2、APPLICATION IN COMPLEX PROTOCOLS
- 如果没有协议规范和源代码，就很难模糊专有协议和其他复杂的协议。关注这些协议和设计一个通用的方法是进一步努力的方向。
8.3、ENCRYPTION ISSUES IN THE PROTOCOL
- 尽管SPFuzz框架触发了一个已知的OpenSSL漏洞，但除非我们对协议中使用的复杂加密算法有深入的了解，否则加密问题仍然是对有状态协议模糊的挑战。
9、Conclusion
- 总之，本文试图攻克有状态协议模糊测试的挑战，这些挑战包括维护状态、处理依赖关系以及提高模糊测试覆盖率。为了实现这一目标，定义了一种描述语言，不仅用于描述协议的规范、协议的状态转换和依赖关系，以生成模糊测试用例并维护会话状态，还用于处理消息内和消息间的依赖关系。此外，三级策略（头部、内容和序列）以及随机为消息和策略分配权重，极大地提高了协议模糊测试的覆盖率。这有助于探索更深入的路径。
- 基于上述内容，设计了 SPFuzz 框架。它调度三级变异策略，并与 AFL 结合生成高覆盖率的测试用例。该框架还可以与 AFL 和目标服务器进行通信，传输测试用例，收集目标进程生成的跟踪并将其反馈给 AFL。在实验中，SPFuzz 框架在对 FTP 的两种实现（即 Proftpd、Oftpd 和 OpenSSL）的三个粒度的覆盖率测试中，平均比现有的有状态协议模糊测试工具 Boofuzz 高出 69.12%。它还进一步触发了 CVE-2015-0291 ，展示了其有效性和实用性。
610
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
