MultiFuzz: A Coverage-Based Multiparty-Protocol Fuzzer for IoT Publish/Subscribe Protocols

Zeng, Yingpei; Lin, Mingmin; Guo, Shanqing; Shen, Yanzhao; Cui, Tingting; Wu, Ting; Zheng, Qiuhua; Wang, Qiuhua

doi:10.3390/s20185194

开放式访问第条

MultiFuzz:IoT发布/订阅协议的基于Coverage的多方协议模糊器

¹

杭州电子大学网络空间学院，中国杭州310000

²

南京大学新软件技术国家重点实验室，南京210000

^三

山东大学网络科学与技术学院，济南250000

⁴

通信安全科学技术实验室，中国成都610041

⁵

北京航空航天大学杭州创新研究院，中国杭州310000

^*

信件应寄给的作者。

传感器 2020,20(18), 5194;https://doi.org/10.3390/s20185194

收到的提交文件：2020年8月13日/修订日期：2020年9月4日/接受日期：2020年9月8日/发布时间：2020年9月11日

（本条属于本节物联网)

下载

浏览地物

版本注释

摘要

:

发布/订阅模型在物联网（IoT）网络中得到了重视，消息队列遥测传输（MQTT）和约束应用协议（CoAP）都支持它。然而，现有的基于覆盖的模糊器在模糊化此类发布/订阅协议时可能会丢失一些路径，因为他们隐式地假设协议中只有两方，而现在情况并非如此，因为有三方，即发布方、订阅者和代理。在本文中，我们提出了一种新的基于覆盖范围的多方协议模糊器MultiFuzz。首先，它将多连接信息嵌入到单个输入中。其次，它使用消息变异算法来刺激协议状态转换，而不需要协议规范。第三，它使用一个新的desockmulti模块将网络消息输入到测试程序中。desockmulti类似于社区广泛使用的工具desock（Preeny），但它是专门为模糊化设计的，速度快10倍。我们基于AFL实现了MultiFuzz，并用它模糊了两个流行的项目Eclipse Mosquito和libCoAP。我们向项目报告发现的问题。此外，我们将MultiFuzz与AFL以及两个最先进的模糊器MOPT和AFLNET进行了比较，发现它发现了更多的路径和崩溃。

关键词：

基于覆盖的模糊;网络协议;发布/订阅;多方协议模糊器;MQTT公司;CoAP公司;物联网;Preeny公司;安全;去石

1.简介

模糊[1,2]是发现程序漏洞的重要方法。模糊化的基本思想是将不同的输入输入到被测程序（PUT）中，并不断监视其状态以防出现任何错误行为。基于覆盖的模糊[三,4,5]被归类为灰盒模糊[2,6]. 与传统黑匣子起毛不同[7,8]基于覆盖的模糊化监控输入的内部执行路径，并在输入执行任何新的有趣路径时将其保存为进一步的变异种子。虽然基于覆盖的模糊化通常不需要复杂的程序分析，也不需要像白盒模糊化那样的程序输入语法[9]，它能够逐步运行程序的不同部分并发现许多漏洞[三]. 现在，安全行业正在使用基于覆盖范围的模糊处理[三,10]并被学术界研究[5,11,12,13,14,15,16].

物联网领域提出了不同的网络协议[17,18,19,20]为了适应物联网的独特需求，几个重要协议支持发布/订阅模型[19]. 例如，消息队列遥测传输（MQTT）协议[21]使用发布/订阅模型作为其核心设计，并使用约束应用程序协议（CoAP）[22]支持使用协议扩展来“观察”资源（类似的发布/订阅模型）[23]. 发布/订阅模型为物联网网络提供了松散耦合和可扩展性[19]：（i）出版商和订阅者不需要知道彼此的存在，也不需要同时在线，（ii）一个出版商可以向多个订阅者发布数据，一个订阅器可以从多个出版商订阅数据，即支持多对多通信模型。在本文中，我们重点讨论了两个发布/订阅协议MQTT和CoAP的模糊化。它们广泛应用于物联网网络，也得到了物联网云提供商（如亚马逊和微软）的支持[24,25].

目前，网络协议模糊化主要有两种方法。第一种方法属于黑箱模糊[19]. 它包括Boofuzz（Sulley）等通用模糊工具[26]和桃子[8]，以及为TLS攻击者等特定协议设计的工具[27]. 这些工具通常需要用户编写脚本或代码来描述网络消息的格式和协议状态的转换。他们需要协议方面的专业知识才能获得良好的模糊结果，并且当协议有新版本时，需要相应地更新脚本和代码。第二种方法属于灰盒模糊化，它是将基于覆盖的模糊化工具应用于网络协议的模糊化。该方法更具前景，因为它通常不需要知道协议规范或编写代码。然而，它需要一种方法将模糊输入输入输入到测试的网络程序中。一种方法是使用desock（Preeny的一个模块）[28]钩住套接字功能，如套接字（）和接受（）（AFL推荐[三]无需修改代码）。挂钩通常由LD_PRELOAD完成，返回到PUT的套接字被劫持，以向（或从）stdout（或stdin）发送（或接收）数据。稍后我们将进一步解释desock的设计第4.4节另一种方法是通过AFLNET等普通插座发送输入[15]. 最后一种方法是修改程序源代码，使程序直接从内存缓冲区读取数据包，而不是从真实的网络接口读取，如Google OSS-Fuzz项目中的模糊openssl[10]. 前两种方法可能会引入性能瓶颈（如后面所示第5.4节). 最后一种方法可能并不简单，因为修改可能需要代码重构。

我们可以看到，基于覆盖的模糊器在模糊化之前需要较少的准备，但是，在使用它们模糊物联网中的发布/订阅协议时，还有一个特殊问题。现有的基于覆盖的模糊器隐式假设网络协议中只有两方（模糊器在模糊另一方时假装是一方），但发布/订阅协议中有三方。考虑MQTT协议的典型过程[21,29]在图1，用户首先订阅传感器/温度主题。当发布者向主题发布值时，订阅者稍后将收到发布的值。现有的基于覆盖的模糊器无法模拟这样的过程，这是因为模糊输入中只包含单个连接的消息，而模糊器只为每个输入启动单个连接[三,10,15]. 因此，即使模糊器成功模拟为订户并在进程中发送第一条SUBSCRIBE消息，它也无法接收第三条PUBLISH消息，因为在模糊化执行期间没有发布者发送第二条PUBLESH消息（对于每个输入，模糊化下的代理服务器也会重新启动）。如果模糊器碰巧订阅了一些内置主题，它可能会收到PUBLISH消息，但它无法使代理服务器运行如所示的整个动态发布/订阅过程图1。如果代理服务器中相应的执行路径中存在漏洞，则模糊器无法发现该漏洞。因此，通常情况下，现有的基于覆盖率的模糊器对于此类多方协议来说是不合适的。

在本文中，我们提出了一种基于覆盖的多方协议模糊器MultiFuzz。我们将MultiFuzz与中现有的模糊器进行了比较表1.MultiFuzz不需要任何协议规范，也不需要用户进行任何编码。它可以启动到PUT的多个连接，这使它能够模糊物联网发布/订阅协议，如MQTT和CoAP（请注意，现有的灰盒模糊器，如AFL[三]和AFLNET[15]仍然可以用于模糊发布/订阅协议，即启动到PUT的单个连接以模拟协议中的一方，尽管如前所述，它们可能会从本质上错过一些路径。像Boofuzz（Sulley）这样的黑匣子模糊者[26]不要在每次模糊输入后重新启动PUT；因此，它们自然支持多方协议，因为它们可以通过使用多个模糊输入模拟到PUT的多个连接）。MultiFuzz有一个新的模块desockmulti，用于将网络消息输入PUT，它的速度是desock（Preeny）的10倍。为了刺激网络协议的状态转换，MultiFuzz首先使用消息变异算法对更高级别的输入进行变异。MultiFuzz是基于覆盖范围的，因此它属于灰盒类别。

具体而言，我们的论文做出了以下贡献：

我们提出了一个多方协议模糊器MultiFuzz，以充分支持发布/订阅协议的模糊化。模糊器可以启动到PUT的多个连接，并具有新的种子格式，用于在单个种子输入中存储连接的所有消息。
我们提出了一种消息变异算法来变异种子输入中的消息序列，以有效地刺激协议的状态转换。变异算法还考虑了种子中存储的多个连接。
我们设计并实现了desockmulti，用于将网络消息发送到PUT。以前，社区通常使用Preeny的desock模块和AFL来模糊网络服务，但desock只支持一个连接。我们使用一种新的设计来支持多个连接，并进一步优化desockmulti，使其比广泛使用的desock工具快10倍(第5.4节)（我们计划在本文发表后开源desockmulti）。
我们基于AFL实现MultiFuzz，并使用MultiFuz模糊两个流行项目，Eclipse Mosquito（MQTT代理）[29]和libCoAP（CoAP库）[30]. 我们报告了发现的项目漏洞，并得到了认可(第5.5节). 我们还表明，MultiFuzz优于AFL和最先进的模糊器MOPT[14]和AFLNET[15]在查找程序路径和崩溃时（例如，在模糊Eclipse Mosquito时，查找的程序路径比AFLNET多44.6%，比AFL多126.6%，比MOPT多125.4%）。

论文的其余部分组织如下。在第2节我们审查了相关工作。然后在第3节我们简要介绍了MQTT和CoAP。在第4节我们详细描述了MultiFuzz。我们在中给出了实验结果第5节，并在中总结论文第6节.

2.相关工作

模糊[1,2,6,31]now是一种广泛使用的技术，用于发现程序中的漏洞。模糊化的基本思想是将不同甚至异常的输入输入到PUT中，并持续监视其状态以检查程序是否崩溃或行为异常[1]. 模糊器可以分为三类：黑匣子、灰匣子和白匣子[2,6]. 黑匣子模糊器[7,8]只能监视PUT的输入/输出，其中一些人（如Peach）可能知道输入的结构[8]. 大多数传统模糊器都属于这一类[2]. 白盒模糊器[9,32]使用更多PUT的内部信息，例如通过符号执行。灰盒模糊器采取中间方法，从PUT中收集一些内部信息。例如，基于覆盖的模糊器收集输入的覆盖信息[2,6]. 灰盒模糊器通常比白盒模糊器运行得更快，并且比黑盒模糊器利用更多信息[6]如果我们想要更高的覆盖率并发现“隐藏”的错误，和是很好的选择[6]. AFL等现代模糊器[三]，libFuzzer[4]属于此类别。灰盒模糊化（主要基于覆盖）已经在安全行业中广泛使用[三,10]. 这也是一个热门的研究课题；许多模糊器，如AFLFast[5]，科拉夫[11]，安哥拉[12]、QSYM[13]、MOPT[14]和IJON[16]建议。

众所周知，模糊网络协议（即网络服务/程序）很难实现[15]. 这是因为输入是一个消息序列，但不像传统模糊化那样是单个文件，它需要一种将输入输入到PUT中的方法。现有网络协议模糊化方法可分为两类：

黑匣子网络协议模糊化[19]. 它包括通用协议模糊化工具，如SPIKE[33]，PROTOS公司[34]、SNOOZE[35]、LZFuzz[36]、布夫兹（苏利）[26]和桃子[8]以及专门为某些协议设计的工具，如TLS-Attacker[27]传输层安全（TLS）协议和MTF[37]用于Modbus协议。这些工具大多需要用户告诉网络消息的格式，其中一些还支持用户提供协议状态的转换规则[8]. 对于通用协议模糊化工具，用户需要通过脚本提供此类信息[26,33,34]或xml文件[8,35]. 对于专门为某些协议设计的工具，这些信息由工具开发人员提供。这些工具中的大多数假装为客户端，将输入输入到网络程序中，还有一些工具，如LZFuzz[36]充当中间人（MITM）代理来修改客户端和服务器之间的消息。黑盒模糊处理通常需要按照协议规范编写脚本、xml文件或代码，并且需要在协议有新版本时相应地更新它们。此外，与灰盒和白盒模糊相比，黑盒模糊可能更适合于发现“浅层”错误[6].
灰盒网络协议模糊化[三,10,15]. 通用的基于覆盖的模糊工具，如AFL[三]和libFuzzer[4]也用于模糊网络协议。通常用户不需要知道协议规范或编写任何脚本/代码，而是准备（例如通过录制）一些消息作为种子输入。然而，由于AFL等工具[三]用于使用files/stdin/memory buffer作为输入源对程序进行模糊处理，它们需要某种方式将模糊输入输入到网络程序中。现在有三种已知的方法。AFL建议使用Preeny（desock）[28]，一个基于钩子的工具，只需将stdin重定向到该工具劫持的套接字[三]、AFLNET[15]通过普通套接字向网络程序发送输入，用户还可以修改程序源代码，使程序直接从内存缓冲区读取数据包，而不是真正的网络接口，就像Google OSS-Fuzz项目对openssl所做的那样[10]. 前两种方法可能会限制模糊化的执行速度（与本文提出的desockmulti工具相比）。如果程序的原始开发人员不期望这样的修改，那么第三种方法可能会很困难，而且对于封闭源代码程序来说也是不可能的。AFLNET的最新作品[15]提出将基于覆盖的模糊化与自动状态模型推理相结合。当模糊化生成新的消息序列以覆盖新状态时，推断的状态模型指导如何进行模糊化。AFLNET表现优于Boofuzz[26]和AFL[三]在代码覆盖和漏洞发现方面[15]. 然而，它要求用户编写代码来从消息中提取部分信息，如响应代码。

最近也有一些关于物联网领域模糊化的研究。IoTFUZZER公司[38]是一种新的黑匣子模糊器，它利用控制物联网设备的移动应用程序在没有协议规范的情况下进行协议模糊。它通过在数据源（例如，字符串常量和来自系统API的输入）上进行变异来间接地改变协议字段。IoTFUZZER需要移动应用程序来模糊网络协议，也仅限于与移动应用程序相关的功能的模糊化。FIRM-AFL公司[39]使用AFL模糊物联网固件，并使用增强过程仿真以更高的速度模糊程序。它主要关注物联网固件中普通程序的模糊化，而不是网络协议。在[40]，作者提出了一种基于模板的模糊化方法来模糊MQTT协议。模糊器位于客户端和代理之间的中间位置，它选择性地改变与指定类型（例如，PUBLISH消息）匹配的数据包。它为用户提供了模板，以决定修改哪些字段，从而减轻像Boofuzz那样编写代码的负担[26]. 然而，用户仍然需要知道协议的规范（例如，数据包类型）。mqtt_fuzz[41]是一个开源工具，用于模糊MQTT代理服务器。它可以生成用于模糊化的大部分MQTT数据包。然而，它已经五年没有更新了，不支持2019年发布的MQTT 5.0版[21]更不用说本文研究的CoAP协议了。

3.MQTT和CoAP简介

MQTT公司[21]和CoAP[22]是物联网中提出的两个重要应用层网络协议[17,18,19,20]. MQTT是一个发布/订阅模型协议，CoAP支持请求/应答和发布/订阅模式[19,42,43]. 发布/订阅模型提供了对物联网至关重要的好处，如松散耦合和巨大的可扩展性[19]. 这两种协议（尤其是MQTT）现在被广泛用于物联网网络[44,45]，也得到了物联网云提供商（如亚马逊、微软和谷歌）的支持[24,25].

MQTT公司[21]是发布/订阅消息传递协议。它重量轻，设计简单。它需要较小的代码占用空间和有限的网络带宽。默认情况下，协议通过TCP运行。它的客户端可以是发布其他客户端可能感兴趣的应用程序消息的发布者，也可以是请求他们感兴趣的申请消息的订阅者。它的服务器充当发布应用程序消息客户端和进行订阅的客户端之间的中介（代理）（请参阅图1其架构）。MQTT提供的信息基于主题，主题使用主题级分隔符（即“/”）将结构引入主题名称。当订阅者发送订阅时，他们使用主题过滤器，其中可能包含通配符（即多级通配符“#”或单层通配符”+“），以便他们可以订阅多个主题。然而，当发布者发送发布消息时，他们只能使用主题名（不包括通配符）。

在MQTT的发布消息中，它可以指示三个QoS级别中的一个：0表示最多一次传递（尽最大努力传递消息，可能会发生消息丢失），1表示至少一次传递。MQTT控制包最多由三部分组成[21]：在所有MQTT控制数据包中出现的固定标头，在某些MQTT控件数据包中存在的可变标头和有效负载。在MQTT v5.0中，共有15种类型的MQTT控制包（AUTH类型是v5.0中新增的）。我们把它们列在表2。我们可以看到，这些数据包中的大多数是成对的（即CONTROL命令及其ACK），但对于QoS 2，有3个ACK用于确保只传送一次。

CoAP公司[22]是用于受限环境的专用web传输协议。它遵循Web的REST（Representational State Transfer）架构，但针对机器对机器（M2M）应用进行了优化。默认情况下，它绑定到UDP，但也可以绑定到TCP[46]. 它在逻辑上可以被视为两层协议，一个用于处理UDP和异步交互的CoAP消息传递层，以及一个用于REST类型方法和响应代码的请求/响应层。在消息传递层，CoAP定义了四种类型的消息：可确认、不可确认、确认和重置。例如，将消息标记为可确认（CON）可以为上层提供可靠性。在请求/响应层中，CoAP定义并使用诸如HTTP的GET、PUT、POST和DELETE方法，并使用令牌字段将响应与独立于底层消息传递层的请求进行匹配（出于类似目的使用消息ID字段）。CoAP还定义了一个URI方案，如HTTP，前缀为“CoAP://”（或其他变体，如tcp传输层的“CoAP+tcp://”）。

CoAP协议还支持选项，它使用Observe选项使CoAP客户端可以“观察”发布/订阅模型中的资源[23]. 过程如下。客户端向服务器发送一个扩展的GET请求（Observe选项设置为0），以注册其对资源的兴趣。每当资源的状态发生变化（例如，通过其他人的PUT请求），服务器都会通过响应通知每个观察客户端。在响应中，令牌与原始GET请求中的令牌相同，并且Observe选项被设置为用于重新排序检测的序列号。

MQTT和CoAP协议的安全性非常重要，因为它们可能部署在敌对环境中。这两种协议都可以通过TLS或DTLS（数据报传输层安全性）进行保护，具体取决于传输层协议是使用TCP还是UDP[21,22]. 还可以添加客户端和服务器之间的相互身份验证[21]. 研究人员还正式验证了协议[47]，研究了可能的袭击[48]，并建议对其进行入侵检测[49].

4.多引信

在本节中，我们首先概述MultiFuzz，并在后面的小节中详细描述其技术。

4.1. 概述

MultiFuzz的基本思想是使模糊器在模糊单个种子时支持多个连接。因此，它可以模拟物联网发布/订阅协议（以及其他多方协议）的过程，因为在模糊化期间，每个连接都可以代表协议中的任何一方。我们从种子输入到PUT的执行进行了必要的更改。

我们在中展示了MultiFuzz的架构图2它类似于其他基于覆盖的模糊器，如AFL[三]（MultiFuzz是基于AFL实现的），也可以分为四个模块。不同的部分用黄色网格高亮显示。首先，种子池存储所有初始种子输入和新发现的有趣输入。MultiFuzz包含一种新的种子格式，用于在一个种子中存储多个连接的信息。其次，调度模块从种子池中选择种子并发送给变异模块。调度模块稍后还会与执行和监视模块一起检查任何具有有趣路径的新输入，并将这些新输入保存到种子池中以供将来使用。MultiFuzz中的调度模块没有改变。第三，变异模块对种子输入进行变异，并发送给执行和监控模块。AFL中的突变模块可进一步分为三个阶段[三]：确定性阶段（使用一些预定义的操作，如“比特翻转”和“算术inc/dec”）、破坏阶段（使用以前的操作进行堆叠更改）和拼接阶段（将种子与另一个随机选择的种子拼接）。确定性阶段需要很长时间，可以使用“-d”选项跳过。MultiFuzz在破坏阶段之前添加了一个新的消息突变阶段，以使消息感知突变处于更高的级别。执行和监视模块执行PUT并将输入输入到其中，并像任何崩溃或其他错误行为一样监视结果。模块以前可能使用desock（Preeny）[28]钩住套接字函数以便将输入输入到PUT中，但MultiFuzz使用了一个更快的、面向多连接的工具desockmulti。

4.2. 用多连接信息扩充种子

我们需要一种新的种子格式来存储多个连接的信息。现有模糊器[三,10,15]假设在使用种子进行模糊处理时，只与PUT建立了一个连接，因此，它们可以直接将所有原始消息存储在一个种子中，而无需任何额外信息。在模糊处理期间，模糊器启动连接（[15]，通过挂钩[三,28]，或实际上[10])，并通过连接将所有消息发送到PUT。然而，在MultiFuzz中，我们需要为一个种子输入启动多个连接，因此必须确定属于每个连接的消息。我们还希望确定是确定的，而不是随机的，因为我们希望模糊器是稳定的（即，使用相同的种子多次运行PUT，以执行相同的路径）。我们曾经考虑在种子的文件名中嵌入元信息（如连接数和消息长度），并将实际消息存储在种子文件中。然而，我们不使用该方法，因为：（i）文件名在某些文件系统中的长度有限（例如，ext4中的255字节），这限制了种子中的消息数量，（ii）文件名可能已经有了含义，例如AFL[三]在种子文件名中嵌入id、parent和mutation操作，（iii）有时我们可能想模糊元信息，比如消息的长度，然后我们需要设计额外的模糊操作。最后，我们决定将元信息也嵌入到种子内容中，实验结果证实其效果良好(第5节).

我们设计了一种新的种子格式来嵌入多连接信息，并将其显示在图3。我们希望保持种子紧凑，因此使用二进制格式。现在，每个种子都包含一个HEADER和一个或多个MESSAGE。HEADER占用两个字节，每个字节表示一个无符号值（[0–255]）。第一个字节是连接到PUT的接受（即侦听）套接字的套接字数。第二个字节是PUT连接到其他方的套接字数（由于我们模糊化的服务器不启动与其他方的连接，所以还没有使用连接数）。在每个MESSAGE中，有一个1字节无符号值（[0–255]）表示消息所属套接字的索引（即，消息通过哪个套接字发送），一个2字节无符号的值（[0-65535]，小端）表示消息的长度

我 e（电子） {n个}_{我}

，以及

我 e（电子） {n个}_{我}

表示消息内容的字节。在一个种子中，不同的MESSAGE可以具有相同的套接字索引，并且所有这些消息都将通过套接字发送。我们在中显示了一个种子示例图4。它的接受号是2，因此模糊器将启动两个连接到PUT的接受套接字的套接字。模糊器将通过第一个套接字（套接字索引=0）发送4字节消息“00 11 22 33”，并通过第二个套接符（套接符索引=1）发送两字节消息“FF EE”。

4.3. 新消息突变阶段

现有的变异阶段不具有消息感知能力，并且在刺激协议的状态转换方面效率低下。我们想设计一种变异算法，它不需要用户做额外的工作，但仍能提供良好的结果。我们的基本思想是对消息序列进行完全变异，并依赖基于覆盖的模糊化中现有的进化机制来逼近新的协议状态。例如，假设当前有三条消息A、B和C作为分离的种子，则有把手A,把手B，以及把手C函数分别处理这些类型的消息（一种常见的设计模式），然后PUT进入

秒 t吨 一 t吨 {e（电子）}_{A类}

,

秒 t吨 一 t吨 {e（电子）}_{B类}

，以及

秒 t吨 一 t吨 {e（电子）}_{C}

分别处理消息A、B和C后，仅处理转换

秒 t吨 一 t吨 {e（电子）}_{A类}

->

秒 t吨 一 t吨 {e（电子）}_{B类}

，以及

秒 t吨 一 t吨 {e（电子）}_{B类}

->

秒 t吨 一 t吨 {e（电子）}_{C}

是允许的。然后，如果有一个错误只发生在

秒 t吨 一 t吨 {e（电子）}_{C}

（即在处理A、B和C后），几乎不可能产生具有现有突变阶段的种子A‖B‖C（“‖”表示串联）。然而，根据我们在本小节接下来提出的消息变异算法，它将基于现有种子A和种子B快速生成输入A‖B（由于它有新的路径，因此将被保存为新的种子），也将快速生成所需的A‖B‖C输入（基于新种子A‖B，或直接基于A、B和C）。我们还需要考虑多连接场景的特殊突变要求。

我们设计了一种新的消息变异算法，它可以像AFL中现有的破坏阶段一样进行堆叠更改[三]，并在算法1中显示。我们在种子的每个破坏阶段之前添加消息突变阶段。我们在这里添加它是因为确定性阶段是可选的，并且对一个种子只调用一次，而拼接阶段还重用破坏阶段来在每次拼接后改变输入。在该算法中，我们首先用常数MF_STACK_POW2决定堆叠变化的数量（现在常数设置为3，因此堆叠变化的最大数量为16）。然后每次我们从五个可能的操作中随机选择一个。第一个操作是在种子头中加减数字（即接受num或连接num）。第二个操作是添加或删除整个连接。请注意，在操作（和下一个操作）中，我们可能需要填充消息，而这些消息是从随机选择的种子中获得的。我们不局限于初始种子，因为在模糊处理期间可能会发现新类型的消息。第三个操作是顺序更改，即在连接结束时添加或删除消息。第四个操作与第三个操作类似，但是在连接中的任意位置添加或删除消息。第五个操作是从种子中选择一个随机连接，并切换连接中两条随机消息的位置。

算法1消息变异算法

输入：seed（其连接信息已被解析）
输出：输出缓冲器

1:: use_stacking=1 $< <$ （1+UR（MF_STACK_POW2））//UR是随机函数
2:: 虽然使用堆栈>0做
三：: 从以下5项操作中随机选择1项：
4:: 1. 从4个操作中随机选择1个：添加/减去接受数/连接数
5:: 2. 选择删除或添加连接（如果要添加，请进一步选择添加单个消息连接或从随机种子复制完整连接）
6:: 3. 向种子中的随机连接末尾添加或删除随机消息
7:: 4. 与操作3类似，但在连接中更改位置是随机的
8:: 5. 切换种子中连接的两条随机选择的消息
9:: use_stacking=使用堆栈-1

4.4. desockmulti，一种快速、多连接的脱扣工具

由于MultiFuzz的种子输入具有不同的格式，并且是面向多连接的，因此我们需要一个新工具将输入输入输入到PUT中。社区通常使用Preeny的desock模块[28]与AFL合作[三]（AFL推荐[三]无需修改代码）。desock使用LD_PRELOAD挂接套接字（）,绑定（）,listen（），以及接受（）功能。它使用两个线程同步插座对到stdin和stdout。然而，它的设计使它无法接受服务器的多个连接（因为所有新套接字都将从插座对通过dup（）调用）。此外，Preeny的最初目的是与二进制文件进行本地交互；因此，它没有针对模糊进行优化。例如，desock使用poll（）继续从stdin读取。然后，首先它需要一个额外的线程来继续调用poll（）第二，这是不必要的，因为在模糊化中，一次提供整个输入，并且没有poll（）需要通话。我们发现desock在模糊方面的性能确实有限(第5.4节).

我们设计并实现了一个新工具desockmulti。它具有以下优点：

desockmulti支持新的种子格式。
desockmulti可以启动到PUT的多个连接（即一个或多个），它可以替代只能启动一个连接的desock。
desockmulti针对模糊进行了优化，比desock快10倍。

我们详细描述了desockmulti的设计。它还使用LD_PRELOAD挂接主要套接字函数套接字（）,绑定（）,listen（），以及接受（），并使用UNIX套接字模拟原始INET/INET6套接字。然而，desock和desockmulti中套接字的关系不同，如所示图5。在desock中，只有一个套接字对由套接字对（）使用系统调用。这对套接字中的一个返回到PUT（尽管套接字可能通过以下方式复制到其他文件描述符dup（）在钩状物中接受（）函数），另一个套接字的读流和写流分别由两个线程同步到stdout和来自stdin。在desockmulti中，为多个连接创建多个套接字对，并且每对套接字中的一个返回到PUT。但是，这些套接字对不是由套接字对（）普通系统调用连接（）和接受（）电话。这是因为多重接受（）调用是使PUT进程像往常一样多个新连接的唯一有效方法。此外，其他挂钩套接字函数也以更“真实”的方式工作。例如，在挂钩中绑定（），我们将套接字绑定到一个地址。

我们主要通过以下优化改进了desockmulti的性能：（i）我们一次读取种子的所有内容，而不使用poll（），因为在模糊化期间不需要交互，（ii）我们删除了对dup2（）这似乎很慢，（iii）我们使用抽象套接字地址(https://www.man7.org/linux/man-pages/man7/unix.7.html)在Linux系统中删除套接字与普通文件系统的关系，（iv）并且我们删除了新设计中不必要的线程的使用，即使我们正在使用连接（）和接受（）创建套接字对。我们通过剖析（例如，strace和详细日志记录）发现了一些优化（例如，（ii）和（iv））。与desock相比，desockmulti有更多的优化，如（i）、（ii）和（iv），这使得它的模糊化速度提高了10倍(第5.4节).

4.5. 其他实施细节

我们在此分享一些其他实现细节。我们基于AFL实现了MultiFuzz[三]我们添加了一个选项“–l”以启用MultiFuzz。由于种子是随机变异的，并且一些数字（如套接字索引）可能超出了它们的界限（即接受num+连接num），因此我们使用的数字等于它们的界限，而不是将种子视为无效。我们添加了一个方法multifuzz_generate（）对于MultiFuzz的消息变异，并在每次堆叠破坏变异之前调用它。我们通过环境变量USE_RAW_format使desockmulti支持原始种子格式。当设置变量时，desockmMulti的行为就像更快的desock一样。与其他基于覆盖的模糊器一样，MultiFuzz使用消息作为种子输入。我们使用Wireshark(https://www.wireshark.org/)捕获消息，并开发Python脚本来转储捕获的pcap文件中的消息。

5.评估

5.1. 实验设置

为了评估MultiFuzz，我们选择了两个著名的MQTT和CoAP协议实现，Eclipse Mosquitto[29]和libCoAP[30]. Eclipse莫斯基托[29]是实现MQTT协议版本5.0的消息代理[21]第3.1.1节和第3.1节。它还提供moswitto_pub和moswito_sub命令行MQTT客户机。我们使用了它的最新版本1.6.10进行模糊处理。我们通过不启用TLS来构建Mosquito(make WITH_TLS=否)因为我们不想模糊TLS代码。在收集模糊种子时，我们使用mosquito_sub和mosquitop_pub客户端连接到本地代理服务器，并分别发送订阅请求和发布请求。然后，我们使用Wireshark捕获数据包，并使用自定义Python脚本转储消息，如前所述。我们为莫斯基托准备了10粒种子。libCoAP数据库[30]是CoAP的C实现，为开发资源高效的CoAP服务器和客户端提供核心功能。它支持资源观测等扩展[23]，TCP[46]、块线传输、FETCH/PATCH和无响应。它提供了CoAP-client和CoAP-server，我们使用CoAP-serve作为PUT。我们使用其最新版本4.2.1进行模糊处理。我们也在构建时禁用了TLS。由于我们的desockmulti还不支持UDP（desock也不支持它），所以我们使用TCP作为CoAP-client和CoAP-server的传输层协议。为了收集种子，我们使用两个CoAP-client实例分别观察和放置资源（实现资源观察）。按照同样的方法，我们获得了31个libCoAP种子。我们还建造了两个没有Address Sanitizer（ASan）的项目[50]支持更快的模糊处理速度，我们后来使用ASan构建了它们，ASan支持分析崩溃和程序路径（本文中我们没有考虑检测数据争用或争用条件，因此我们没有使用ThreadSanitizer之类的消毒剂，也没有专门设计任何机制来提高并发性）。

与AFL类似[三]（使用desock），可以在控制台中使用以下命令运行MultiFuzz：LD_PRELOAD=/path/to/desockmulti/desockmulti.so/afl-fuzz-l 0-d-i testcase_dir-o findings_dir-/path/to/program[…params…]，其中“-l”用于启用前面提到的MultiFuzz，“0”用于普通初始化情况（“1”用于新格式初始化情况，即中所示的格式图3).

我们选择了AFL[三]和两个最先进的模糊器MOPT[14]和AFLNET[15]与MultiFuzz进行比较。AFL公司[三]是最著名的基于覆盖的模糊器之一，我们使用它的最新版本2.52b。MOPT是最近提出的一种模糊器，它使用粒子群优化（PSO）算法来寻找变异算子的最佳概率分布[14]. AFLNET是最近提出的一种基于AFL的模糊器，但使用自动状态模型推理来处理基于覆盖的模糊[15]. AFLNET需要用户编写代码来从消息中提取响应代码，我们根据需要实现它们。基本上，我们分别使用MQTT消息第一个字节的高4位和CoAP消息的第二个字节作为响应代码[21,22]. 我们使用其默认设置运行AFLNET（即。，-D 10000-q 3-s 3-K-R). 我们跳过了所有模糊器（包括MOPT模糊器，它会在一段时间后自动跳过确定性阶段）在变异期间的确定性阶段（这是AFLNET的默认配置）[14]). 我们使用了Preeny的解吸模块[28]与AFL和MOPT合作。我们还为所有模糊器使用了相同的种子集。

所有实验都是在配置了2个Intel（R）Xeon（R）CPU E5-2640 v4@2.40 GHz处理器、64 GB RAM和64位Ubuntu 20.04 LTS的服务器上进行的。所有的fuzzer都用一个fuzzer实例运行了2天，因为建议运行24小时以上[31].

5.2. 路径和崩溃发现

发现的程序路径数是模糊器能力的最重要指标之一，我们在中显示了实验结果图6（我们显示了一次运行的结果，不同运行的结果相似）。我们可以看到，所有的模糊者都有一个类似的趋势：开始时快速找到更多的路径，然后到达一个平台。一个例外是模糊Mosquitto的AFLNET，它在中间突然生长（因为当时产生了大种子，我们将在本小节稍后进一步分析）。在这两个项目中，我们可以看到MultiFuzz在开始时发现路径的速度比其他模糊器快得多。当后来大多数路径都已经找到时，MultiFuzz的发现速度放慢了，AFLNET可以迎头赶上。然而，AFL和MOPT似乎很难找到相同的路径，甚至在很长一段时间内进行模糊处理。MultiFuzz最终在模糊Mosquito时发现了2166条路径，比AFLNET（1498）多44.6%，比AFL（956）多126.6%，比MOPT（961）多125.4%。就libCoAP而言，结果类似。MultiFuzz发现了1763条路径，与AFLNET（1769）相似，但比AFL（1304）多35.2%，比MOPT（1327）多32.9%。我们还检查了找到的路径（即种子/队列条目），并确认MultiFuzz确实找到了不在原始种子集中的新消息类型，例如PUBCOMP[21]消息。结果证实了模糊网络协议的难度，因为尽管MOPT可以优化变异算子的选择，但它不能发现比AFL更多的路径。AFLNET模糊器确实可以发现比AFL更多的路径，这证明它很好地利用了我们在代码中返回的消息响应代码。最后，作为一个不需要用户提供额外信息或代码的模糊器，MultiFuzz发现了比类似的模糊器AFL和MOPT多得多的路径。

我们比较了在图7由于所有的模糊者都没有在莫斯基托发现任何崩溃，我们只显示了libCoAP的结果。MultiFuzz也比其他fuzzer更快地发现崩溃。MultiFuzz最终发现198起独特的车祸，比AFL（116起）多70.7%，比MOPT（127起）高55.9%，比AFLNET（53起）高273.6%。结果表明，MultiFuzz比未针对网络协议模糊化进行优化的模糊器更快地搜索错误。AFLNET在这里表现不佳，这可能是因为它更多地关注更高级别的消息突变，而不是详细的程序逻辑。

我们使用位图密度检查模糊器的代码覆盖率，并在中显示结果图8基于Coverage的模糊器通常使用固定大小（例如，AFL中的65536字节[三])位图来存储所有输入的覆盖范围。PUT的每个控制流图（CFG）边缘都映射到位图中的一个位置（在高密度情况下不考虑碰撞[11]). 因此，位图包含所有输入的累积边缘覆盖。位图密度表示位图中具有值（即移动的边）的位置的比率。我们可以看到，MultiFuzz的位图密度略高于AFL和MOPT，这是考虑到我们的消息变异算法所期望的。

然而，AFLNET具有比其他模糊器更高的位图密度，这表明它可以移动更多的边。首先，这可能是因为它能够故意行使很少行使的协议状态。特别是对于libCoAP，我们主要生成与发布/订阅相关的消息种子，这可能给模糊者留下了更多的探索空间。其次，我们进一步检查了AFLNET的队列条目（即种子），发现它们的大小比其他模糊器大得多（对于Mosquito，大小仅在模糊过程的中间增长了很多，但对于libCoAP，大小甚至在开始时也增长得很快）。AFLNET的许多种子大小都是几百KB（有些甚至超过1MB），单个种子中有数千条消息。相比之下，MultiFuzz和其他模糊器的种子大小通常小于1KB，最多为几十KB，一个种子中只有几条或几十条消息。较大的种子可能会使执行速度变慢(第5.4节). 它们还使执行变得不稳定（即，同一种子具有不同的路径）。我们发现AFLNet在Mosquito中的稳定性比率（即1-位图中可变字节的比率）下降到约50%，在libCoAP中下降到约20%（其他模糊器均超过90%）。然而，另一方面，大尺寸种子也可能引入了动态消息处理行为（例如，不同的读/写顺序），这似乎是一种增加代码覆盖率的可行方法。

5.3. 多连接设计和消息变异算法的影响

我们知道，多连接设计和消息变异算法使多方协议的模糊化更合理、更高效，然而，它们在多大程度上提高了MultiFuzz的能力尚不清楚。我们在这里制作了MultiFuzz的两种变体：MultiFuzz（SingleConn.，NoMsgMuta.）和MultiFuzz（NoMsgMuta.）。在第一种变体中，我们将种子视为原始种子格式，即种子仅包含单个连接的消息（即，在使用desockmulti时设置USE_RAW_format环境变量），并禁用消息变异算法。在第二种变体中，我们正常使用了新的种子格式和去锁多个，但禁用了消息变异算法。

我们展示了MultiFuzz发现的路径及其在图9我们可以看到，MultiFuzz不断超越其两个变体，MultiFuzz（NoMsgMuta.）不断超越MultiFuz（SingleConn.，NoMsgMuta.。）。对于Mosquito，MultiFuzz最终发现的路径数比MultiFuz（NoMsgMuta.）多9.9%，比MultiFozz（SingleConn.，NoMsgMuta.。）多29.2%。对于libCoAP，MultiFuzz发现的路径比MultiFuz（NoMsgMuta.）多9.6%，比MultiFozz（SingleConn.，NoMsgMuta.。）多18.6%。我们可以清楚地看到，多连接设计和消息变异算法都提高了MultiFuzz的路径发现能力，尽管它们在运行时增加了一些开销。

我们还显示了以下三种类型的MultiFuzz在libCoAP中发现的独特崩溃数图10MultiFuzz仅略胜于它的两个变体，它最终发现比MultiFuz（SingleConn.，NoMsgMuta.）多7次崩溃，比MultiFuzz（NoMsg Muta.。）多12次崩溃。看来，多连接设计和消息变异算法并没有太多地提高碰撞查找能力。

5.4. 执行速度的比较

我们非常关注MultiFuzz的性能（包括消息变异算法和desockmulti模块），并显示了不同模糊器的执行速度（每秒执行数），以及MultiFuzz与其他模糊器的速度比较图11.我们使用了tmpfs(https://www.kernel.org/doc/html/latest/filesystems/tmpfs.html)为了存储模糊输出以更快地执行，我们构建了二进制文件来进行模糊处理，而没有像前面提到的那样启用ASan。对于Mosquito和libCoAP，MultiFuzz的平均执行速度分别为1333.9和1412.4 execs/s。相比之下，AFL的平均执行速度分别为128.8 execs/s和94.6 execs/s，这意味着MultiFuzz比AFL快10.4倍和14.9倍。MOPT比AFL稍快，但MultiFuzz仍比AFL快10.3倍和11.6倍。因为AFL和MOPT使用了Preeny的desock模块[28]，MultiFuzz的速度提高主要归功于新设计的desockmulti工具。MultiFuzz（SingleConn.，NoMsgMuta.）的执行速度可以作为使用带desockmulti的AFL的快速参考，因为在变体中只添加了一点额外的初始化工作。MultiFuzz（SingleConn.，NoMsgMuta.）的平均执行速度是Mosquito的1389.9 execs/s和libCoAP的983.8 execs/s，分别比带desock的AFL快10.8倍和10.4倍。AFLNET的执行速度比其他模糊器慢。Mosquitto的执行速度仅为9.0，libCoAP的执行速度仅为22.6。我们认为这主要是因为AFLNET使用真正的INET网络套接字连接到PUT。众所周知，INET网络套接字比UNIX套接字慢得多。此外，正如我们所提到的，我们发现AFLNET生成的种子比其他模糊器（<1KB）大得多（数百KB），这也会降低执行速度。

5.5. 脆弱性分析

我们手动调查了一些找到的路径和崩溃，并在下面分享了这些发现。

Eclipse Mosquitto中的内存泄漏。我们在Mosquito中发现了两个内存泄漏，这可能由错误的请求反复触发，并可能导致代理服务器中的拒绝服务（DoS）。两次泄漏都是由于自由（）错误处理期间调用。第一次泄漏发生在handle__subscripte（）方法，第122行src/handle_subscribe。c（c）。当代理处理格式错误的MQTT v5.0订阅请求时，它调用返回MOSQ_ERR_PROTOCOL直接，不打电话mosquito_free（子）；mosquito_free（有效载荷）；与其他错误处理情况一样。第二次泄漏发生在处理__publish（）方法，第112行src/handle_publish。c（c）。当它处理格式错误的MQTT v5.0发布请求时，它调用返回rc直接，不打电话mosquito_free（主题）。我们向Eclipse Mosquito项目报告了漏洞，开发人员立即修复了漏洞(https://github.com/eclipse/mosquito/commit/94d04136f8beedbd34ca16158b5be3111a9cb7b4). 下一版本1.6.11中应提供修复程序。

资产（）libCoAP中的故障和内存泄漏。我们发现，大多数撞车事故都是由于资产（）呼叫，例如断言（pdu->max_size>0）在中coap_write_block_opt（）函数，第77行src/块。c（c）。此类故障通常在技术上不会对生产构建产生影响，因为它们应该使用NDEBUG公司定义的预处理器宏，以及装配（）该方法当时什么也没做。然而，它们可以提醒开发人员发生意想不到的事情。例如，我们接下来描述的内存泄漏也有一个断言失败。内存泄漏发生在处理请求（）方法，第2208行src/net。c（c）。当CoAP服务器在中处理格式错误的请求时句柄请求（）函数，调用coap_add_token（）方法失败。然而，只有coap_log（log_WARNING，“无法生成响应\r\n”）在案件中被传唤，没有coap_delete_pdu（响应）致电以及时释放PDU。内存泄漏也可能由格式错误的请求反复触发，因此也可能导致DoS。我们向libCoAP项目报告了泄漏情况，也得到了承认(https://github.com/obgm/libcoap/issues/535).

6.结论

本文提出了一种基于覆盖率的模糊器MultiFuzz，它可以启动与被测程序的多个连接，以可靠地支持诸如物联网中的发布/订阅协议等多方协议的模糊化。MultiFuzz包含一种新的种子格式、一种消息变异算法和一个新的去锁模块desockmulti。我们使用MultiFuzz模糊Eclipse Mosquito项目和libCoAP项目，并向开发人员报告我们发现的漏洞（所有漏洞都得到了确认和修复）。我们还发现，与AFL和两个最先进的模糊器MOPT和AFLNET相比，MultiFuzz发现了更多的路径和崩溃。我们认为MultiFuzz不仅限于物联网发布/订阅协议的模糊化，还可以用于合理模糊其他多方协议。此外，我们相信MultiFuzz的desockmulti模块可以在开源后造福社区，因为它类似于广泛使用的工具desock（Preeny），但速度快10倍。

作者贡献

概念化、Y.Z.和T.W。；方法，Y.Z.和M.L。；软件，Y.Z。；验证、Y.Z.、M.L.和S.G。；形式分析，Y.S。；调查，Y.Z。；资源、Y.Z.、T.W.、Q.Z.和Q.W。；数据管理，Y.Z。；书面原稿编制，Y.Z.和M.L。；书面审查和编辑，Y.Z.、S.G.、Y.S.和T.C。；可视化，Y.Z。；监理、Y.Z.和T.W。；项目管理、Y.Z.和T.W。；资金收购，Y.Z.，T.W.和Q.Z。所有作者都已阅读并同意手稿的出版版本。

基金

本研究部分得到了61902098、61902100、61902148和91546203号国家自然科学基金的支持，部分得到了2020C01078、2019C01012和2017C01062号浙江省重点研究项目的支持，部分由山东省重大科技创新项目、中国No.2017CXGC0704、No.2018CXGC0708、No.2019JZZY010132和山东大学齐鲁青年学者计划资助，部分由通信安全实验室科学技术基金（6142103190105）资助，部分由浙江省自然科学基金资助，批准号Q20F020063。

利益冲突

作者声明没有利益冲突。

工具书类

米勒，B.P。；弗雷德里克森，L。；因此，B.UNIX实用程序可靠性的实证研究。Commun公司。ACM。 1990,33, 32–44. [谷歌学者] [交叉参考]
马内斯，V.J.M。；韩，H.S。；Han，C。；Cha，S.K。；埃格尔，M。；E.J.施瓦茨。；吴，M.《模糊数学的艺术、科学和工程：一项调查》。IEEE T.软件。工程师。 2019, 1–21. [谷歌学者] [交叉参考] [绿色版本]
Zalewski，M.AFL-American Fuzzy Lop。在线可用：http://lcamtuf.coredump.cx/afl/（2020年7月29日查阅）。
libFuzzer。在线可用：http://llvm.org/docs/LibFuzzer.html（2020年7月29日查阅）。
伯赫梅，M。；Pham，V.T。；Roychoudhury，A.基于覆盖的灰盒模糊马尔可夫链。2016年10月24日至28日在奥地利维也纳举行的ACM SIGSAC计算机和通信安全会议记录；第1032-1043页。[谷歌学者] [交叉参考]
Liang，H。；裴，X。；贾，X。；沈伟（Shen，W.）。；Zhang，J.Fuzzing：艺术状态。IEEE T.可靠性。 2018,67, 1199–1218. [谷歌学者] [交叉参考]
佐夫。在线可用：网址：http://caca.zoy.org/wiki/zzuf（2020年7月29日查阅）。
桃子科技。桃子浓雾。在线可用：https://www.peah.tech（2020年7月29日查阅）。
Godefroid，P。；基辅，A。；Levin，M.Y.基于语法的白盒模糊处理。2008年6月7日至13日在美国亚利桑那州图森市举行的ACM SIGPLAN编程语言设计与实现（PLDI）会议记录；第206-215页。[谷歌学者] [交叉参考]
谷歌安全团队。OSS-Fuzz的新篇章。在线可用：https://security.googleblog.com/2018/11/a-new-chapter-for-oss-fuzz.html（2020年7月29日查阅）。
甘，S。；张，C。；秦，X。；涂，X。；李凯。；裴，Z。；Chen，Z.CollAFL：路径敏感模糊。2018年5月21日至23日，美国加利福尼亚州旧金山，IEEE安全与隐私研讨会（S&P）会议记录；第679-696页。[谷歌学者] [交叉参考]
陈，P。；Chen，H.Angora：通过原则搜索实现高效模糊。2018年5月21日至23日，美国加利福尼亚州旧金山，IEEE安全与隐私研讨会（S&P）会议记录；第711-725页。[谷歌学者] [交叉参考] [绿色版本]
我·云。；Lee，S。；徐，M。；Jang，Y。；Kim，T.QSYM：为混合模糊定制的实用协和执行引擎。第27届USENIX安全研讨会（安全）会议记录，美国马里兰州巴尔的摩，2018年8月15日至17日；第745-761页。[谷歌学者]
Lyu，C。；季S。；张，C。；李，Y。；Lee，W.H。；Song，Y。；Beyah，R.MOPT：优化模糊器的变异调度。第28届USENIX安全研讨会（安全）会议记录，2019年8月14日至16日，美国加利福尼亚州圣克拉拉；第1949–1966页。[谷歌学者]
Pham，V.t。；博姆，M。；Roychoudhury，A.AFLNet:网络协议的灰盒模糊器。第13届IEEE软件测试、验证和确认国际会议论文集：测试工具跟踪，葡萄牙波尔图，2020年10月24-28日；第460-465页。[谷歌学者] [交叉参考]
Aschermann，C。；舒米洛，S。；阿巴斯。；Holz，T.IJON：通过Fuzzing探索深状态空间。2020年5月17日至21日，美国加利福尼亚州旧金山，IEEE安全与隐私研讨会（S&P）论文集；第1-16页。[谷歌学者]
Al-Fuqaha，A。；Guizani，M。；穆罕默德（M.Mohammadi）。；Aledhari，M。；Ayyash，M.物联网：关于实现技术、协议和应用的调查。电气与电子工程师协会。Commun公司。调查。导师。 2015,17, 2347–2376. [谷歌学者] [交叉参考]
亚森，医学学士。；M.Q.沙特纳维。；Al-Zoubi，D.物联网应用层协议：一项调查。2016年9月22日至24日，摩洛哥阿加迪尔，《2016年国际工程与管理信息系统会议记录》。[谷歌学者] [交叉参考]
Dizdarević，J。；卡皮奥，F。；Jukan，A。；Masip Bruin，X.物联网通信协议调查以及雾和云计算集成的相关挑战。ACM公司。计算。Surv公司。 2019,51, 1–30. [谷歌学者] [交叉参考]
佩雷拉，C。；Aguiar，A.走向高效移动M2M通信：调查和开放挑战。传感器 2014,14, 19582–19608. [谷歌学者] [交叉参考] [公共医学] [绿色版本]
Banks，A。；布里格斯，E。；Borgendale，K。；Gupta，R.（编辑）MQTT版本5.0; OASIS标准：美国马萨诸塞州伯灵顿，2019年。[谷歌学者]
谢尔比，Z。；Hartke，K。；C.鲍曼。约束应用程序协议（CoAP）。RFC 7252 2014; 互联网工程特别工作组（IETF）：美国加利福尼亚州弗里蒙特，2014年。[谷歌学者]
英国哈特克。观察受限应用程序协议（CoAP）中的资源。RFC 7641 2015; 互联网工程任务组（IETF）：美国加利福尼亚州弗里蒙特，2015年。[谷歌学者]
团队，T.H.IoT云平台对MQTT支持的比较。在线可用：https://www.hivemq.com/blog/hivemz-cloud-vs-aws-iot/（于2020年7月29日访问）。
普托内。物联网核心CoAP代理演示。在线可用：https://cloud.google.com/community/tutorials/cloud-iot-coap-proxy网站（2020年7月29日查阅）。
Boofuzz：人类网络协议模糊。在线可用：https://github.com/jtpereyda/boofuzz（2020年7月29日查阅）。
Somorovsky，J.TLS库的系统模糊和测试。2016年10月24日至28日在奥地利维也纳举行的ACM SIGSAC计算机和通信安全会议记录；第1492-1504页。[谷歌学者] [交叉参考]
普伦尼。在线可用：https://github.com/zardus/prepeny（https://github.com/zardus/preeny）（2020年7月29日查阅）。
Eclipse Mosquito公司。在线可用：https://mosquitto.org网站/（2020年7月29日查阅）。
利伯阿普。在线可用：https://libcoap.net网站/（2020年7月29日查阅）。
克莱斯，G。；Ruef，A。；库珀，B。；Wei，S。；Hicks，M.评估模糊测试。2018年10月15日至19日，加拿大安大略省多伦多市，ACM SIGSAC计算机和通信安全会议（CCS）会议记录；第2123-2138页。[谷歌学者] [交叉参考] [绿色版本]
Godefroid，P。；莱文，M.Y。；Molnar，D.自动化白盒模糊测试。2008年2月10日至13日在美国加利福尼亚州圣地亚哥举行的网络和分布式系统安全研讨会（NDSS）会议记录；第416–426页。[谷歌学者]
艾特尔，D。基于块的协议分析在安全测试中的优势; 技术报告；Immunity Inc.：美国纽约州纽约市，2002年。[谷歌学者]
Roning，J。；Laakso，M。；Takanen，A.PROTOS演讲。在线可用：https://www.ee.oulu.fi/research/ouspg/（于2020年7月29日访问）。
Banks，G。；Cova，M。；Felmetsger，V。；阿尔梅罗斯，K.C。；R.A.凯默勒。；Vigna，G.SNOOZE：走向一个有状态的网络。2006年8月30日至9月2日在希腊萨摩斯岛举行的第九届国际会议信息安全会议记录；第343–358页。[谷歌学者] [交叉参考]
布拉特斯，S。；Hansen，A。；A.舒比纳。LZfuzz：一种用于文档化较差的协议的快速压缩模糊器; 技术报告；达特茅斯学院计算机科学系：汉诺威，新罕布什尔州，美国。[谷歌学者]
Voyiatzis，A.G.公司。；Katsigiannis，K。；Koubias，S.A Modbus/TCP Fuzzer，用于测试互联工业系统。2015年9月8日至11日，卢森堡，IEEE新兴技术和工厂自动化国际会议（ETFA）会议记录；第1-6页。[谷歌学者] [交叉参考]
陈，J。；迪奥·W。；赵（Q.Zhao）。；左，C。；林，Z。；王，X。；刘，W.C。；孙，M。；Yang，R。；Zhang，K.IoTFuzzer：通过基于应用程序的模糊处理发现物联网中的内存损坏。2018年2月18日至21日在美国加利福尼亚州圣地亚哥举行的第25届网络和分布式系统安全研讨会（NDSS）会议记录；第1-22页。[谷歌学者]
郑毅。；Davanian，A。；尹，H。；宋，C。；朱，H。；Sun，L.FIRM-AFL：通过增强过程仿真对物联网固件进行高通量灰盒模糊化。第28届USENIX安全研讨会（安全）会议记录，2019年8月14日至16日，美国加利福尼亚州圣克拉拉；第1099-1114页。[谷歌学者]
埃尔南德斯·拉莫斯，S。；马萨诸塞州维拉尔巴。；Lacuesta，R.MQTT安全：一种新的模糊方法。Wirel公司。Commun公司。暴徒。通用域名格式。 2018,2018. [谷歌学者] [交叉参考] [绿色版本]
mqtt_fuzz工具。在线可用：https://github.com/F-Secure/mqtt_fuzz（2020年7月29日查阅）。
罗德里格斯-多明格斯，C。；班加西，K。；Noguera，M。；加里多，J.L。；罗德里格斯，M.L。；Ruiz-López，T.将请求-响应和发布-订阅范例集成到无所不在系统中的通信模型。传感器 2012,12, 7648–7668. [谷歌学者] [交叉参考] [公共医学] [绿色版本]
Davis，E.G。；Calveras，A。；Demirkol，I.提高无线传感器网络中发布/订阅协议的数据包传递性能。传感器 2013,13, 648–680. [谷歌学者] [交叉参考] [公共医学] [绿色版本]
阿卡西亚迪斯，C。；Pitsilis，V。；Spyropoulos，C.D.基于开源框架的多协议物联网平台。传感器 2019,19, 4217. [谷歌学者] [交叉参考] [公共医学] [绿色版本]
Larmo，A。；Ratilainen，A。；Saarinen，J.CoAP和MQTT对NB-IoT系统性能的影响。传感器 2019,19, 7. [谷歌学者] [交叉参考] [公共医学] [绿色版本]
Bormann，C。；莱梅，S。；Tschofenig，H。；Hartke，K。；Silverajan，B。；雷莫尔，B。基于TCP、TLS和WebSockets的CoAP（受限应用程序协议）。RFC 8323 2018; 互联网工程任务组（IETF）：美国加利福尼亚州弗里蒙特，2018年。[谷歌学者]
Houimli，M。；Kahloul，L。；Benaoun，S.物联网中MQTT协议的正式规范、验证和评估。2017年12月4日至5日在阿尔及利亚阿德拉尔举行的2017年国际数学与信息技术会议（ICMIT）会议记录；第214-221页。[谷歌学者] [交叉参考]
Vaccari，I。；M.Aiello。；Cambiaso，E.SlowITe，一种影响MQTT的新型拒绝服务攻击。传感器 2020,20, 2932. [谷歌学者] [交叉参考] [公共医学]
Granjal，J。；席尔瓦，J.M。；Lourenço，N.使用异常检测在CoAP无线传感器网络中进行入侵检测和预防。传感器 2018,18, 2445. [谷歌学者] [交叉参考] [公共医学] [绿色版本]
Serebryany，K。；布鲁宁，D。；Potapenko，A。；Vyukov，D.AddressSanitizer：一个快速的地址完整性检查程序。2012年6月13日至15日在美国马萨诸塞州波士顿举行的USENIX年度技术会议（ATC）会议记录；第309-318页。[谷歌学者]

图1。消息队列遥测传输（MQTT）协议的典型发布/订阅过程（为了简单起见，省略了一些CONNECT和ACK消息）。

图2。MultiFuzz的体系结构。它与其他基于覆盖的模糊器（如AFL）具有相同的架构[三]，更改以黄色网格突出显示。

图3。新的种子格式。

图4。新格式的示例种子（十六进制编码）。

图5。去锁和去锁多功能的设计。

图6。不同模糊器发现的路径。

图7。libcoap中发现的崩溃。

图8。位图密度比较。

图9。禁用多连接设计和消息变异算法（MultiFuzz（SingleConn.，NoMsgMuta.））以及仅禁用消息变异算法时发现的路径。

图10。MultiFuzz及其变体在libCoAP中发现的崩溃。

图11。不同模糊器的执行速度，以及MultiFuzz与其他模糊器的比较。

表1。模糊比较。“部分”是指需要一些知识或工作。

表1。模糊比较。“部分”意味着需要一些知识或工作。

模糊器	需要规格。	需要编码	支持多方	消息-软件	分类学
Boofuzz（苏利）[26]	是的	是的	是的	是的	黑匣子
AFL公司[三]	不	不	不	不	灰箱
MOPT公司[14]	不	不	不	不	灰箱
AFLNET公司[15]	部分	部分	不	是的	灰箱
MultiFuzz（本文）	不	不	是的	是的	灰箱

表2。MQTT控制数据包类型[21].

姓名	流动方向	描述
连接	客户端到服务器	连接请求
康纳克	服务器到客户端	连接确认
出版	客户端到服务器或服务器到客户端	发布消息
发布	客户端到服务器或服务器到客户端	发布确认（QoS 1）
公共广播公司	客户端到服务器或服务器到客户端	已接收发布（QoS 2交付部分1）
公共	客户端到服务器或服务器到客户端	发布版本（QoS 2交付第2部分）
PUBCOMP公司	客户端到服务器或服务器到客户端	发布完成（QoS 2交付第3部分）
订阅	客户端到服务器	订阅请求
SUBACK（重新确认）	服务器到客户端	订阅确认
退订	客户端到服务器	取消订阅请求
取消订阅	服务器到客户端	取消订阅确认
平格鲁	客户端到服务器	PING请求
平格瑞普	服务器到客户端	PING响应
断开	客户端到服务器或服务器到客户端	断开连接通知
授权	客户端到服务器或服务器到客户端	身份验证交换

分享和引用

MDPI和ACS样式

曾勇。；林，M。；郭，S。；沈毅。；崔，T。；Wu，T。；郑琦。；王，Q。MultiFuzz:IoT发布/订阅协议的基于Coverage的多方协议模糊器。传感器 2020,20, 5194.https://doi.org/10.3390/s20185194

AMA风格

曾毅，林M，郭S，沈毅，崔T，吴T，郑Q，王Q。MultiFuzz:IoT发布/订阅协议的基于Coverage的多方协议模糊器。传感器. 2020; 20(18):5194.https://doi.org/10.3390/s20185194

芝加哥/图拉宾风格

曾英培、林明敏、郭善卿、沈燕赵、崔婷婷、吴婷、郑秋华和王秋华。2020年，“MultiFuzz:物联网发布/订阅协议的基于Coverage的多方协议模糊器”传感器20，18号：5194。https://doi.org/10.3390/s20185194

请注意，从2016年第一期开始，该杂志使用文章编号而不是页码。请参阅更多详细信息在这里.

文章菜单