论文阅读：《FUME: Fuzzing Message Queuing TelemetryTransport Brokers》

夬月十二

已于 2024-04-06 15:30:51 修改

阅读量847

点赞数 17

文章标签：网络论文阅读

于 2024-04-06 15:28:09 首次发布

本文链接：https://blog.csdn.net/cx_312/article/details/129408824

版权

《无线网络与移动计算》课程要求一篇论文阅读汇报，我选择了发表在IEEE INFOCOM 2022 - IEEE Conference on Computer Communications的文章《FUME: Fuzzing Message Queuing TelemetryTransport Brokers》，由于文章很新，网上没有相关的论文导读，因此我把自己的阅读结果和感想进行记录，由于相关的专业知识不足，可能存在许多瑕疵，希望读者多多包涵，最后希望这篇文章能帮助到你。

同样，根据我一贯风格，先说感受，再接着介绍文章，文章较长，好让读者有需要的及时止损。

总体感受

简单来说，这篇论文就是将Fuzzing技术（一种bug检测技术）应用到了MQTT（一种通信协议）上面，并设计了全面的科学实验，迁移效果和实际效果都很不错。

其次，文章中有一些我不理解的点：1.可解释性2.参数设置文章对于采用模型、设计模型和参数的设置都缺乏解释，文章中大都直接给出结果图和数据，没有来源，所以看到这部分会有些疑虑。

OK，下面正式开始。ps:下面的内容中，黑色字体为文章的翻译内容，红色字体是我添加的内容。

摘要

消息队列遥测传输(MQTT)是一种流行的通信协议，用于互连具有相当大的网络限制的设备，例如物联网(IoT)中的设备。MQTT直接影响大量设备，但其服务器（“代理”）实现的软件安全性并未得到很好的研究。在本文中，我们为MQTT设计、实现和评估了一种新颖的模糊测试模型。模糊器结合了变异引导模糊测试和生成引导模糊测试的各个方面，以严格耗尽MQTT协议并识别服务器中的漏洞。我们介绍了用于突变引导模糊测试和生成引导模糊测试的马尔可夫链，它们根据有限伯努利过程对模糊引擎进行建模。我们实施“响应反馈”，这是一种监控网络和控制台活动的新技术，以了解哪些输入触发了代理的新响应。我们总共在9个不同的MQTT实现中发现了7个主要漏洞，包括6个零日漏洞和2个CVE。我们表明，在对这些流行的MQTT目标进行模糊测试时，我们的模糊器与其他最先进的模糊测试框架（如BooFuzz和AFLNet）相比具有优势。

（摘要是一个文章的总体介绍，里面涉及了很多专业名词，这些在正文中都会进行介绍，因此如果在正文中没有介绍过的名词且再次出现的，我进行了学习了解，并进行了记录）

正文

引言

消息队列遥测传输(Message Queuing Telemetry Transport, MQTT)[1]在智能家居、智慧城市、工业物联网等应用中互联资源受限的设备。MQTT被全世界成千上万的设备使用[2]，据估计，62%的IoT解决方案使用MQTT[3]。与CoAP、AMQP、[4]等同类协议相比，由于其低开销和广泛应用，常被认为是物联网(IoT)通信的"事实标准"。自MQTT诞生以来，已经开发了许多MQTT的实现，包括用于各种硬件、操作系统和云平台[5]上的客户机和服务器的软件库。兄弟kers可以在任何给定的时间服务数千个独特的客户。

MQTT安全性——特别是代理/服务器实现的软件安全性——在文献中很少受到关注。大多数研究工作仅关注MQTT中缺乏的网络安全机制，如身份认证、访问控制、加密和完整性检查[5]-[8]。另一方面，经纪人的软件脆弱性并不像文献中所描述的那样。据我们所知，我们只观察了一个示例，该示例从代理[9]的角度对MQTT软件安全性进行了全面评估。基于这一研究空白，我们认为迫切需要对MQTT代理的软件安全性进行研究。

模糊测试(fuzz testing，简称[10])是软件漏洞挖掘的重要方法之一。模糊测试软件(fuzzer)会生成伪随机或无效的测试用例，然后将其发送给目标应用程序。然后，模糊器观察应用程序的行为。流行的网络应用模糊测试框架包括BooFuzz[11]、Spike[12]和AFLNet[13]。在物联网安全的背景下，IoTFuzzer是一个黑盒模糊测试模型，它对移动应用程序进行动态分析，以了解如何与远程物联网设备[14]通信。该模型可以在不需要了解协议本身的情况下实现协议引导的模糊测试。然而，IoTFuzzer仅针对网络客户端的软件漏洞。

为此，提出一种针对MQTT代理的模糊测试模型FUME。该模糊测试器基于马尔可夫模型实现了变异引导和生成引导两种模糊测试技术。马尔可夫模型独立于以往的模糊测试迭代来描述每次迭代的状态。每个马尔可夫模型都可以被描述为一个有限的伯努利过程，因为每个直接转移都可以被认为是一个伯努利试验，具有转移到下一个状态的概率，与其他状态转移独立dent。我们还实现了“响应反馈”(response feedback)技术，让模糊器可以监听来自代理的网络活动和控制台输出(即stdout、stderr或日志文件)。触发来自代理的唯一响应的输入将被保存并稍后进行测试。FUME不需要源代码，也不需要运行在与目标代理相同的系统上。我们总共在9个不同的broker实现中发现了7个主要漏洞，包括6个0天漏洞。在这些漏洞中，有2个cve出现在由Eclipse Foundation开发的非常流行的MQTT平台Mosquitto[15]中。

本文的主要贡献：

我们从马尔可夫建模的角度讨论了模糊测试的原理。也就是说，我们设计了2条马尔可夫链和一个伯努利过程来建模突变和生成引导的模糊器。

我们提出了一种新的针对MQTT代理的模糊分析器FUME。fuzzer实现了前面提到的马尔可夫模型，并利用响应反馈动态地选择更智能的突变输入。

我们根据9种不同的MQTT代理实现来评估FUME。我们发现了7个主要漏洞，包括6个零日漏洞和2个CVE。我们证明了与其他最先进的Fuzzer框架相比，Fuzzer可以很好地检测到这些错误。

（零日漏洞：也可以称为零时差漏洞，通常是指还没有补丁的安全漏洞。零日漏洞中的“零日”得名于漏洞被公开后，补丁未出现的天数。漏洞被公开当天，一般来讲都不会及时推出补丁，所以称为零日漏洞；如果N日后仍然没有补丁，则称为N日漏洞。换个角度讲，“零日”也可以理解为针对此漏洞的攻击出现在哪天，漏洞公开当天即利用此漏洞的攻击称为零日攻击，以此类推。实际上，“零日”现在已经不再局限于漏洞被公开的时间长短。所谓“零日”不一定是真的刚刚发现，黑客完全有可能在很久之前发现了漏洞，但就是没有公开。那么对于外界来说，漏洞公开的那一刻才能称为零日漏洞。所以，“零日”往往可以理解为“软件供应商和公众未知”，但是“黑客或暗网上的交易者已知”。）

（CVE：CVE（Common Vulnerabilities and Exposures）的全称是公共漏洞和暴露，是公开披露的网络安全漏洞列表。IT人员、安全研究人员查阅CVE获取漏洞的详细信息，进而根据漏洞评分确定漏洞解决的优先级。在CVE中，每个漏洞按CVE-1999-0067、CVE-2014-10001、CVE-2014-100001这样的形式编号。CVE编号是识别漏洞的唯一标识符。CVE编号由CVE编号机构（CVE Numbering Authority，CNA）分配，CVE编号机构主要由IT供应商、安全厂商和安全研究组织承担。）

背景

MQTT

MQTT是消息队列遥测传输协议，在智能家居、智慧城市和工业物联网等应用中，它连接着资源受限的设备。MQTT被全球数十万设备使用，估计有62%的物联网解决方案使用MQTT。与类似的协议CoAP和AMQP相比，MQTT因其低开销和广泛流行常被视为物联网通信的“事实标准”。自MQTT诞生以来，已经开发了许多实现，包括针对各种硬件、操作系统和云平台的客户端和服务器软件库。代理可以在任何给定时间为数千个唯一客户提供服务。

MQTT安全——尤其是代理/服务器实现的软件安全——在论文中少有关注。大多数工作只关注 MQTT 中缺乏网络安全机制，例如身份验证、访问控制、加密和完整性检查。另一方面，在文献中几乎没有代理程序的软件漏洞得到详尽的介绍。仅有一个例子从代理角度对 MQTT 软件安全进行全面评估。

MQTT 是一种轻量级通信协议，其遵循发布于开放 OASIS 标准 ISO/IEC 20922 下。它旨在满足资源受限设备（如嵌入式系统和物联网设备）的网络需求。MQTT 通常运行在 TCP 上，但并非必须如此。在 MQTT 中，客户端连接到中央代理，并可以发布消息或订阅主题。当客户端发布消息时，它会指定一个主题过滤器，代理必须将这些消息转发给任何已订阅相同主题过滤器的客户端。代理协调所有客户端之间的通信，解决会话需求，并验证客户端。MQTT 只支持基于密码的身份验证，其他安全要求必须由应用程序实现。

MQTT支持15种不同的数据包类型，称为控制数据包。这些包括：CONNECT（连接）；CONNACK（连接确认）；PUBLISH（发布）；PUBACK（发布确认）；PUBREC（发布接收）；PUBREL（发布释放）；PUBCOMP（发布完成）；SUBSCRIBE（订阅）；SUBACK（订阅确认）；UNSUBSCRIBE（取消订阅）；UNSUBACK（取消订阅确认）；PINGREQ（PING请求）；PINGRESP（PING响应）；DISCONNECT（断开连接）和AUTH（认证）。所有MQTT数据包都包含相同的结构，如图1所示。即，每个数据包都以fixed header（固定头）开始，该头标识控制数据包的类型并指定数据包的长度；variable header（变量头）列出包的一些特性；payload（载荷）包含消息的有效载荷。根据控制数据包类型，变量头和有效载荷可能是可选或必需的，而固定头始终是必需的。MQTT的第5版还支持一个properties sub-header（属性子头），其中包含可选属性列表。变量头结束时会出现属性字幕区域。CONNECT数据包还可以指定遗嘱主题和遗嘱载荷。如果客户端出现意外断开连接，例如没有发送DISCONNECT数据包就关闭了连接，那么这个载荷将发布给遗嘱主题的所有订阅者。在MQTT 5版本中，遗嘱信息包含CONNECT载荷中的遗嘱属性字段。表I显示了每个控制数据包的名称、标识符和目的。

图1： MQTT数据包结构。

表1： MQTT数据包类型

模糊测试

软件漏洞发现中最突出的方法之一是模糊测试（fuzz testing，简称fuzzing）。模糊测试软件（“fuzzer”）会生成伪随机或无效的测试用例，然后将其发送到目标应用程序。然后fuzzer观察应用程序的行为。如果应用程序表现出奇怪的行为或崩溃，则很可能发现了新的漏洞；研究人员可以进一步深入调查该漏洞。模糊测试工具可以根据三个因素分类：模糊测试方法、目标应用程序的了解程度和漏洞检测方式。

模糊测试方法：主要有两种模糊测试方法，即生成式引导和变异式引导。在生成式引导模糊测试中，数据随意生成或按用户定义的模型生成；例如，在协议引导模糊测试中，数据是根据协议结构生成的。当用户对目标协议的语法和语义有完全的理解时，这种模糊测试方法是合适的。在变异式引导模糊测试中，载荷样本从有效数据输入语料库中抽样并进行模糊化处理。当目标协议不被很好地了解或实现与规范不一致时，这是合适的。另一种方法是遗传模糊测试，可使用任一模糊测试方法，并基于目标所呈现的行为应用遗传算法。

目标应用程序的了解程度：根据目标的认知程度不同，模糊测试器可分为黑盒模糊测试器、白盒模糊测试器和灰盒模糊测试器。黑盒模糊测试器无法获得目标规范的知识，只能观察到直接可见的内容。白盒模糊测试器完全了解目标的结构，可能可以访问其源代码和规范。灰盒模糊测试器对规范具有一定的了解，并可使用仪表或动态污点分析来跟踪目标的控制流。

漏洞检测：为了在目标中发现漏洞，模糊测试器可以使用多种技术。例如，目标可能发送一个意外或格式错误的响应，这可能表明存在逻辑错误。目标也可能挂起，即连接保持打开状态但目标从未发送响应。最后，目标可能崩溃并关闭连接；所有模糊测试器几乎都会观察到这种行为。程序崩溃可能表明存在严重漏洞，如内存损坏。

原理方法

使用马尔可夫建模的模糊测试

1.1 变异引导模糊测试

变异引导模糊测试引擎依赖于语义上有效的测试用例输入语料库的存在。该引擎可分为两个不同的阶段：构建阶段和模糊测试阶段。在构建阶段中，从输入语料库中追加新的数据包到有效载荷中。在模糊测试阶段中，模糊测试引擎可以使用注入、删除和变异的字节粒度方法来操作有效负载。这些方法的效果如下：注入将新字节插入有效负载中；删除从有效负载中删除字节；突变更改有效负载中一些字节的值。图2用一个带有值9003b80f07的MQTT SUBACK控制数据包说明了每种方法的原理。

图2：不同的载荷变异方法

变异引导模糊测试程序可以被马尔可夫链所建模，如图3左侧所示。该模型描述了模糊测试引擎的单次迭代过程。节点表示模糊测试引擎中的状态，弧表示转移概率；转移概率标签位于其对应的转换旁边。状态 $\text{[math]}$ 表示模糊测试引擎的初始状态。状态 $\text{[math]}$ 表示构建阶段。状态 $\text{[math]}$ 表示模糊测试阶段。最后，状态 $\text{[math]}$ 是最终状态，标志着当前模糊测试引擎迭代的结束。

图3：变异引导模糊测试和生成引导模糊测试的马尔可夫链

在初始状态 $\text{[math]}$ 中，模糊引擎可能转移到构建阶段，或者它可以从响应日志中选择有效载荷。响应日志在第3.2节中有进一步的解释；广义上讲，它描述了已添加到输入语料库中的测试用例集，即那些不属于原始输入语料库的测试用例。从响应日志中选择的概率为 b。

在构建阶段，模糊引擎从输入语料库中随机选择控制数据包。选择 CONNECT 的概率为 $\text{[math]}$ ，CONNACK 的概率为 $\text{[math]}$ ，以此类推。这些概率的总和为 1，即： $\text{[math]}$

当模糊引擎处于状态 $\text{[math]}$ 时，它有 $\text{[math]}$ 概率直接转换到状态 $\text{[math]}$ ，即模糊阶段，有 $\text{[math]}$ 概率选择一个新的数据包添加到有效载荷中。在该模型中，添加新数据包的状态表示为Add CONNECT，Add CONNACK等等。基于数据包选择概率 $\text{[math]}$ 和追加新数据包的概率 $\text{[math]}$ ，添加特定数据包的整体概率是 $\text{[math]}$ 。

在模糊测试阶段，模糊引擎可以转换到注入状态、删除状态或变异状态，也可以转换到发送状态，该状态将模糊的有效负载发送给代理服务器。注入状态可以转换为 BOF 状态或非 BOF 状态。在前者中，大量字节被注入到有效载荷中，以触发缓冲区溢出攻击。在后者中，模糊引擎仅注入少量字节 ——在实现中，注入的字节数永远不会超过原始有效负载的长度。模糊状态注入、删除和变异具有概率 $\text{[math]}$ 、 $\text{[math]}$ 和 $\text{[math]}$ ，使得 $\text{[math]}$ 。状态 BOF 的概率为 $\text{[math]}$ 。

直接转移到“发送”状态的概率为 $\text{[math]}$ 。基于模糊状态的概率和转移到“发送”状态的概率，选择特定模糊状态的整体概率为 $\text{[math]}$ 。

最终，在“发送”状态下，模糊引擎将有 $\text{[math]}$ 的概率转移到 $\text{[math]}$ 并结束当前的模糊迭代。否则，有

$\text{[math]}$ 的概率返回到 $\text{[math]}$ ，并恢复从构建阶段获取的有效载荷。

1.2生成引导模糊测试

生成引导模糊测试取决于对协议的深入了解，以生成语义有效的测试用例。图3（右）说明了生成引导模糊测试的马尔可夫模型。模糊器首先生成一个CONNECT包，然后随机生成其他数据包。步骤 $\text{[math]}$ 和 $\text{[math]}$ 包括负载生成器组件。步骤 $\text{[math]}$ 执行实际的模糊操作。为简单起见，我们将注入、删除和变异状态压缩为单个I/D/M状态。状态转移 $\text{[math]}$ → 发送、 $\text{[math]}$ → I/D/M、发送 → $\text{[math]}$ 和发送 → $\text{[math]}$ 的概率在两个模型之间保持一致。事实上，一旦达到状态 $\text{[math]}$ ，两个模型就完全相同，因为载荷的实际模糊与如何获取该载荷无关。

1.3马尔可夫模型与伯努利过程

由于每个状态转移仅取决于其状态转移概率，且每个概率被假定为随机的，则我们同样可以将每个马尔科夫模型表示为有限的伯努利过程。换句话说，我们可以将每个马尔科夫链描述为序列

$\text{[math]}$ ，其中 S 是马尔科夫模型中的状态集合， $\text{[math]}$ 描述了从状态 $\text{[math]}$ 直接转移到状态 $\text{[math]}$ 。每个状态转移 $\text{[math]}$ 都是一个伯努利试验，其伯努利变量为 $\text{[math]}$ 。模糊引擎从状态 $\text{[math]}$ 转移到状态 $\text{[math]}$ 的概率为 $\text{[math]}$ 。该值仅为图3中相应转移的概率值。

FUME：MQTT协议的模糊器

FUME的体系结构共由五个组件构成，分别是：核心组件(可以称其为“FUME”)、用户定义的参数、有效载荷生成器、用户文件系统与代理，其示意图如图4所示。

图4：FUME体系结构

模糊模型的每种组件实现不同的功能，总结如下：

核心组件（“FUME”）。这个部分包含两个模糊引擎，同时它还能够处理来自目标代理的通信和响应监视。

用户定义的参数。这个组件使得用户能够配置模糊器的各项参数，例如概率值 $\text{[math]}$ 、 $\text{[math]}$ 和 $\text{[math]}$ 。

有效载荷生成器。这个组件能够从头生成结构上有效的控制包序列。

用户文件系统。它用于存储输入语料库，而且当代理观察到新的响应时，会记录更多的测试用例。

代理。即目标代理，可能是本地的，也可能是远程的。

下文将详细介绍各个组件任务和工作原理。

2.1核心组件

核心组件“FUME”的任务包含三项，每一项都会由一个子组件进行处理。第一个任务是交替（也可能是随机）运行基于变异的Fuzzing算法和基于生成的Fuzzing算法。这些算法实现了第三节中描述的马尔可夫模型。在基于变异的Fuzzing算法运行过程中，引擎将访问文件系统组件，以便将新的控制包附加到载荷或从响应日志中选择输入。在基于生成的Fuzzing算法运行过程中，引擎将访问有效载荷生成器组件以执行实际的控制包生成。第二个任务是建立与目标代理的连接，并将模糊输入发送到目标。模型中的Send状态将处理连接需求的责任交给这个子组件。第三个任务是监听网络响应和控制台响应，并在必要时将它们记录到文件系统。进行日志操作就通过访问文件系统组件。

1）响应回馈。FUME会监听来自目标代理的两种主要活动：网络响应和控制台响应。网络响应由从代理发送到客户端的MQTT包组成。控制台响应引用代理的标准输出和标准错误文件描述符。当模糊器观察到一个唯一的响应时，触发该响应的有效载荷将被记录到文件系统中。这些有效载荷之后可以通过基于变异的模糊引擎进行模糊。从初始状态 $\text{[math]}$ 到状态Select from response log的转换过程中，这种行为由变异引导的马尔可夫链建模。注意，如果代理远程运行，那么在本地文件系统上就不能访问控制台输出。然而，一些云平台记录来自运行软件的控制台活动——例如，AWS CloudWatch——在这种情况下可以利用。模糊器可以随时观察网络响应。

响应回馈的一个弊端是这个回应可能是冗余的。例如，来自代理的CONNACK包可以包含分配的客户端标识符，该标识符可能是随机生成的；那么每个CONNACK包都不包含真正的新信息，尽管技术上是唯一的。为了解决这个缺点，我们设计了一个数据包解析器，它可以准确地从代理中派生有效载荷中的每个字段。FUME监视只包含少量可能值的字段(我们称这些字段为“interesting”)，它忽略了上面描述的那些冗余字段。当代理发送一个包含一组新的感兴趣字段的响应时，该响应被认为是唯一的，并被记录到文件系统中。

但是，数据包解析器只能从网络响应中派生字段，而不能从控制台响应中派生字段。为了限制控制台响应中的冗余，作者引入了一个相似度阈值，忽略与过去响应过于相似的响应。阈值是用户定义的百分比值。例如，75%的阈值意味着如果控制台响应与以前记录的任何响应至少有75%相似，则不会记录。我们在4.4节中评估了相似阈值对模糊器的影响。

2.2 用户定义的参数

用户能够定义部分能够影响模糊器的行为的参数，将其上传至模糊器运行。模糊强度，可以表示为fi，这是一个百分比值，表示数据包中应该模糊的字节的百分比。例如，模糊强度为50%意味着应该模糊最多50%的有效载荷。模糊强度还决定了在模糊引擎的一次迭代中，载荷应该被模糊的频率，即模型应该在状态 $\text{[math]}$ 中等待多长时间。构造强度ci是一个非负整数，表示负载序列中所需的数据包数。例如，构造强度为7则意味着，平均而言，有效载荷应由7个不同的MQTT包构成(由于模型的随机属性，这只是一个平均值)。这个序列总是以一个CONNECT包开始。

1) 将用户参数映射到马尔可夫变量。对于想要使用FUME而不操心马尔可夫模型细节的用户，相比于马尔可夫模型，模糊强度和构造强度参数的概念可能更直观。为了解决这个问题，作者提供了一个简单的方法来将模糊强度fi和构造强度ci映射到概率值 $\text{[math]}$ 、 $\text{[math]}$ 和 $\text{[math]}$ 。作者假设选择/生成数据包的状态为离散均匀分布，所以 $\text{[math]}$ 、 $\text{[math]}$ 。同时作者假设模糊状态也为离散均匀分布，所以 $\text{[math]}$ 、 $\text{[math]}$ 。需要注意的是，在作者的FUME系统中，所有参数和变量都可以由用户配置，包括 $\text{[math]}$ 、 $\text{[math]}$ 和 $\text{[math]}$ 。作者的映射定义如下:

● 令 $\text{[math]}$

2.3 有效载荷生成器

为了满足基于生成的模糊算法的要求，有效载荷生成器组件可以为15个MQTT控制包中的每一个生成有效载荷。算法1演示了有效载荷生成器如何构造一个CONNECT包，即马尔可夫模型中的状态Generate Connect。该算法构造固定报头、变量报头和载荷，如图1所示。变量头包含一个flags字段，表示存在用户名/密码对、协议名称和版本、遗嘱信息和会话信息。根据协议版本的不同，变量头可能包含一个属性字段。有效载荷包含客户端标识符，可能还有用户名、密码和遗嘱消息（遗嘱消息是MQTT为那些可能出现意外断线的设备提供的将遗嘱优雅地发送给第三方的能力）。


Algorithm 1: Payload generator pseudocode for a CONNECT packet.

input: protocol_version
fixed_header.ID = 0x10;
variable_header.name = "MQTT";
variable_header.version = protocol_version;
variable_header.flags.username = random(0..1);
variable_header.flags.password = random(0..1);
variable_header.flags.will_retain = random(0..1);
variable_header.flags.will_qos = random(0..2);
variable_header.flags.will_flag = random(0..1);
variable_header.flags.clean_start = random(0..1);
variable_header.keepalive = random(0, 0xffff);
if protocol_version == 5 then
    variable_header.properties = random_properties();
payload.clientid = random_string();
if variable_header.flag.will_flag == 1 then
    if protocol_version == 5 then
        payload.will_properties = random_string();
    payload.will_topic = random_string();
    payload.will_payload = random_string();
if variable_header.flags.username == 1 then
    payload.username = random_string();
if variable_header.flags.password == 1 then
    payload.password = random_string();
packet_length = len(variable_header) + len(payload);
fixed_header.remaining_length = packet_length;
packet = concat(fixed_header, variable_header, payload);
return packet;

2.4 文件系统

用户的文件系统存储输入语料库和崩溃日志。根据相似度阈值，触发来自代理的唯一网络或控制台响应的有效载荷也被记录到文件系统中。在将来的迭代中，这些输入由基于变异的模糊引擎访问，这样它们就可以被模糊化。

评估

实验设置

软硬件：python3，Kali Linux 2021.1虚拟机。

用户定义参数：在所有实验中，模糊强度和生成强度分别设为0.1和3，因此X1设置为0.33,X2设置为0.9,X3设置为0.917。

输入语料库：通过将客户端连接到Mosquitto、HiveMQ和VerneMQ代理，并使用Wireshark收集MQTT流量，系统地收集预定义的输入语料库。输入存储在文件系统中。我们总共收集了50个不同的MQTT数据包作为初始语料库。

目标代理：文章总共测试了9种不同的MQTT代理，使用突变引导和生成引导技术的组合，对每个代理进行了大约12个小时的模糊处理。上表显示了每个代理的版本号以及该代理使用的编程语言。

漏洞发现

针对以上9种MQTT代理，Fuzzer总共发现了7个漏洞，包括6个零日漏洞和1个n日漏洞。

Malformed CONNACK in MQTT V5:客户端发送格式错误的CONNACK包

UBLISH topic length = 0：客户端发送主题字长为0的PUBLISH包

Broken pipe error：在一些Linux系统上，如果代理试图将有效载荷发送到一个关闭的TCP连接，服务器将抛出一个SIGPIPE信号。

Malformed DISCONNECT：如果客户端使用格式错误的DISCONNECT数据包关闭连接，则会出现漏洞。该序列将导致缓冲区溢出并导致服务器崩溃。

Malformed PUBLISH：当客户端发送一个有效的CONNECT包后，再发送一个格式错误的PUBLISH包时，就会发生解析错误。

UNSUBSCRIBE topic length = 0：客户端发送主题长度为0的UNSUBSCRIBE报文时。

Malformed CONNECT：客户端发送一个格式错误的CONNECT报文时。

2.1漏洞发现速度

文章将FUME与三种模糊引擎进行了比较：BooFuzz、mqtt-fuzz和AFLNet。BooFuzz是一个用Python编写的模糊化框架，它根据给定的输入语料库生成固定数量的测试用例。mqtt-fuzz是mqtt的一个基于突变的模糊器。AFLNet是AFL的扩展，增加了对网络应用程序的支持。因为只有FUME实现了生成引导的模糊方法，而其他模糊器使用了突变引导的方法，为了统一比较，我们在本次评估中只使用了FUME的突变引导模糊引擎，各引擎使用了相同的原始输入语料库。

评估结果如表所示。一般来说，FUME发现所有漏洞的速度比任何其他引擎都快。唯一的例外是，BooFuzz在23秒内发现了第一个Mosquitto漏洞，而FUME花了2分29秒才发现相同的漏洞。一些代理在模糊处理12小时后找不到漏洞（表中“N/a”处）。特别地，mqtt-fuzz只能发现aedes漏洞。

2.2响应反馈分析

FUME监视来自目标代理的两种主要类型的活动：网络响应和控制台响应。网络响应由从代理发送到客户机的MQTT包组成。控制台响应引用代理的标准输出和标准错误文件描述符，每当模糊器观察到一个唯一的响应时，触发该响应的有效载荷被记录到文件系统，这就称为记录1次控制台响应。

【“感兴趣”的解释：响应可能是冗余的，如代理向客户端发送的CONNACK包（确认连接）可以包含分配的客户端标识符，该标识符可能是随机生成的，那么同时发送出的CONNACK包可能都不包含新信息。因此除了监控所有的响应，另外还要识别监控那些不冗余的、真正独立的响应。文章实现了一个文本解析器，可以解析负载中的每个字段设定只关注部分特定的字段，当代理发送一个包含一组新的感兴趣字段的响应时，该响应被认为是“唯一”的，这些关注的字段就称为“感兴趣”的。

相似度阈值的解释：用以忽略与过去响应过于相似的响应。阈值是用户定义的百分比值，例如，75%的阈值意味着如果控制台响应与以前记录的任何响应至少有75%相似，则不会记录。】

本部分针对3种代理（mosquito, HiveMQ和EMQX），分别使用生成引导和突变引导模糊方法，观测在10000次运行中收集到的唯一响应的数量。其中，垂直轴是按指数级上升的，G和M分别代表生成（Generation）和突变（Mutation），I和A分别代表感兴趣的（Interesting）和所有的（All）。

总体上看，网络响应的结果显示：

1.如果只考虑感兴趣的响应数量，突变引导和生成引导的模糊器表现大致相同；

2.如果只考虑响应的总体数量，生成引导高于突变引导产生的响应数量；

控制台响应的结果显示：

1.应将相似度阈值设置在0.5左右时，控制台响应数量与网络响应的结果大致符合；

2.突变和生成引导的模糊方法，响应数量的表现没有明显差异。

结论

本文针对MQTT系统中的服务器，设计了一种基于马尔可夫模型的模糊器。MQTT影响成千上万的设备，特别是资源受限的设备，例如物联网中的设备。我们的模糊器结合了突变引导模糊和生成引导模糊技术，对MQTT协议进行了严格的压力测试。监视来自目标代理的响应反馈以跟踪唯一活动，这为输入语料库提供了新的测试用例。我们讨论了三种强调对有效载荷进行细粒度操作的模糊测试方法。我们已经证明，最先进的MQTT实现(如mosquito)包含严重的漏洞，这些漏洞可以直接导致拒绝服务攻击，并威胁整个网络的可靠性。我们总共发现了7个漏洞，包括6个零日漏洞。最后，将提出的模糊测试器与3个流行的模糊测试框架进行了比较，实验结果表明，在几乎所有情况下，提出的模型都能更有效、更快速地发现MQTT漏洞。