关于github:MQTT-服务器安全性测试

1次阅读

共计 4238 个字符,预计需要花费 11 分钟才能阅读完成。

物联网市场正在以爆炸式的增长势头飞速发展。随着设施规模的一直增长和业务逻辑的日渐简单,物联网平台基础设施的安全性也愈发重要。物联网平台对协定的具体实现是否残缺、对特定音讯的解析过程是否平安就成了重中之重。

这须要八面玲珑地针对协定中的繁冗规范和指定的行为规范进行较为残缺的测试。同时,思考到理论应用中可能存在的各种烦扰和攻打,测试过程也须要笼罩各种非标准异样报文,以剖析指标平台对异常情况的容错和解决能力。

含糊测试是一个十分无效的测试伎俩。本文将以 EMQ X 为例,介绍如何应用含糊测试工具来发现 MQTT 服务器 /MQTT 客户端对协定实现上可能存在的缺点和破绽。

什么是含糊测试

含糊测试(fuzz testing, fuzzing)是一种软件测试技术。其核心思想是将主动或半自动生成的随机数据输出到一个程序中,并监督程序异样,如解体、断言(assertion)失败,以发现可能的程序谬误,比方内存透露。含糊测试经常用于检测软件或电脑系统的安全漏洞。

含糊测试能够被用作白盒、灰盒或黑盒测试。通常用于黑盒测试,回报率较高。

起源:https://zh.wikipedia.org/wiki/ 含糊测试

筹备工作

测试工具及对象抉择

本文咱们抉择 Defensics 作为含糊测试的工具。Defensics 是 Synopsys 新思公司开发的黑盒含糊测试工具,提供了对大量文件格式、网络协议、接口的含糊测试套件。它针对 MQTT v3.1 协定规范,应用大量主动生成的 MQTT 数据包对 Broker/Client 进行测试,帮忙开发者和测试人员进步软件的安全性。

针对 MQTT v5 的测试套件目前尚未公布

咱们将以开源 MQTT 音讯服务器 – EMQ X 为例,对其协定实现状况进行安全性测试。EMQ X 是由 EMQ 映云科技开源的大规模可弹性伸缩的云原生分布式物联网 MQTT 音讯服务器,可高效牢靠连贯海量物联网设施,高性能实时处理音讯与事件流数据,助力构建要害业务的物联网平台与利用。

测试环境筹备

本次测试在 Arch Linux 环境下进行,滚动更新至最新版本,应用 EMQX 5.0-beta.2-8be2aaf7 进行测试。

此外,在进入下一步之前,须要从 Synopsys 处下载 Defensics 的安装包、后缀名为 .install 的测试套件安装文件、以及 DEFENSIC 可执行文件以提供给 FlexNet 许可服务器验证 license 状态应用。

部署许可服务器(FlexNet)

Synopsys Defensics 应用 FlexNet 治理许可证书,须要在执行 Defensics 含糊测试器的的网络环境中部署 FlexNet Server,以治理从 Synopsys 处获得的许可证书(即 license.lic 文件)。

能够抉择应用 Systemd User Unit 在本地部署启动 FlexNet Daemon,配置如下。其中 license.lic 证书文件及 DEFENSIC (Vendor Daemon) 可执行文件将位于同一目录。FlexNet 将会从 $PATH 中搜寻 Vendor Daemon 可执行文件来进行认证。

当然,在须要更多测试人员应用 Defensics 的状况下,也能够将其部署在专用的证书服务器上以对更多的用户提供证书认证服务。其余详细信息和具体参数可参考 Defensics 及 FlexNet Publisher 相干文档。

之后应用命令 systemctl --user enable --now lmgrd.service 启动认证服务器 Synopsys 提供的 Vendor Daemon。Defensics 便能够通过许可认证开始测试了。

其余配置

在 Linux 零碎中可能存在显示问题及字体含糊的状况,能够参考 Java Runtime Environment fonts – ArchWiki 进行配置。

装置 Defensics 及测试套件

以 root 身份执行 .sh 安装程序进行装置。并且装置过程中倡议勾选启动脚本的生成选项 /usr/local/bin/Defensics

如果一切顺利,启动 Defensics 后在 File -> License Manager 中就能够看到通过验证的 License 状态。之后就能够装置并加载测试套件了。

Defensics 测试

根底配置

在根底配置中设置 MQTT Server 的 ip 地址和端口号,以及用于测试的 MQTT Client 配置。

其中 MQTT 默认为 1883 端口(在启用了 TLS/SSL 时为 8883 端口)。

如果 MQTT Server 启用了客户端认证或音讯主题权限,须要对测试用的两个客户端进行更具体的配置。
另外 Defensics 也提供了更进阶的 Payload 含糊测试和基于 TLS/SSL 连贯的测试。但本次测试仅波及 MQTT v3.1.1 协定规范相干的含糊测试,所以无需进行配置。

在配置了相应的字段值后,Defensics 将会以指定的 Client ID、用户名明码连贯 MQTT Server,并会用指定的 MQTT 主题进行音讯公布和主题订阅,即 PUBLISHSUBSCRIBE

对于更高阶和简单的测试,能够应用 Edit sequence 性能编辑对应的配置文件,来扭转连贯或断开连接时的行为,例如连贯后主动订阅,连贯后立即公布音讯等操作。

可操作性测试

实现配置后在 Interoperability 中进行可操作性测试,来验证不同的报文是否失常进行发送接管。在与 MQTT Server 失常连通的状况下,能够执行的测试组将会以绿色标注。

高级配置

在这一部分,容许用户对具体的测试用例执行过程进行配置,但一般来说默认配置曾经足够。

其中包含了对测试用例执行过程的管制,例如超时阈值、反复次数、尝试次数等。

另外用户也能够依据理论状况进行网络相干的配置,以获取在不同网络情景下的测试后果。此时也能够抉择依据 MQTT Server 的指标 IP 进行主动配置。

另外也能够依据 CVSS(通用破绽评分零碎)提供的破绽分级办法对可能检测到的异常情况进行评估。

仪表配置(Instrumentation)

仪表是指在测试过程中察看和管制被测系统,察看的指标是检测由测试引起的任何故障。仪表还可用于在运行测试时重新启动或以其余形式管制被测系统。

大多数测试套件都启用了默认检测,无需进行额定配置。并且此默认配置的性质因不同的测试套件而异。

抉择测试用例

Defensics 对于 MQTT v3.1.1 协定规范,提供了总计超过 100 万的测试用例能够用来对指标零碎进行全面的含糊测试。与此同时,也反对用户进行基于这些细分的测试用例自行抉择、组合用例,来针对性地聚焦剖析并解决问题。

此次咱们选取局部用例进行测试,其中包含 CONNECT-DISCONNECT PUBLISH-qos-0 SUBSCRIBE-qos-0 三组用例,并同时抉择全副异样音讯用例进行测试。

在针对于异样音讯的测试中,也能够抉择各类不同数据的异样行为数量和水平进行测试。例如文本、二进制数据、数字、字符等;同时也能够配置溢出异样的字节限度来应用值溢出的畸形报文进行测试。

执行测试

抉择好测试用例的品种和异样数据的数量,便能够开始测试。本次测试用时约 6 分钟,其中约 98% 通过测试,约 1%(2779 条用例)后果未知。

剖析保留后果

咱们先来选取其中一条未知后果的异样报文进行剖析。

能够看到 Defensics 为了评估被测对象的健壮性,在含糊测试时尝试应用了不合乎协定标准的异样数据进行测试。例如图中被进行了红色高亮标注局部,这部份两字节数据在 MQTT v3.1.1 协定的 SUBSCRIBE 报文中,批示了订阅主题的 UTF-8 字符串的长度。即示意接下来长度 0x009A (154 字节) 的数据为订阅主题过滤器的 UTF-8 字符串。但该主题过滤器理论长度 18 字节,值应为 0x0012,与理论长度不符。

依照协定的强制性标准申明,在此种状况下,服务端必须敞开传输这个协定违规管制报文的网络连接 [MQTT-4.8.0-1]。

但并未具体规定是否必须有批示谬误起因的报文回传。所以 EMQ X 仅进行了外部错误处理,对异样报文间接抛弃。也不对发送方进行任何信息回传操作,所以 Defensics 将此条后果标记为未知。

但依照协定, 此后果依然符合要求。

通过统计,2779 条后果未知的测试用例中,不同类型的谬误如下表所示:

谬误类型 数量
报文过大 (overflow) 190
固定报头谬误 (fixed-header) 44
固定报头标记位谬误 (flags) 34
报文残余长度值异样 (remaining-length) 1167
报文标识符异样 (packet-identifer) 626
主题过滤器构造谬误 (topic-filters) 304
主题过滤器长度值异样 (topic-filter-length) 414

EMQ X 在面对这些异样报文时,间接作了抛弃解决,并未发回对于错误信息的批示报文。

对于其中一部分谬误类型,因为谬误点位的信息比拟要害,试图对要害信息边界进行猜想甚至可能造成更大、更无奈承受的谬误。
例如下面分析过的字符串长度批示值谬误。如果对主题过滤器及其长度进行猜想,可能会失去谬误的主题过滤器,造成客户端失去非预期的主题订阅。甚至也有可能是主题过滤器长度正确,而主题过滤器的值在传输过程中失落损坏。

这类逻辑谬误在零碎运行中更加难以发现和排查,并且结果更难以承受。所以此时对异样报文间接抛弃成为了更优抉择。

至于其余类型的谬误,因为谬误点位过于显著,相较之下更可能的起因是传输过程中的数据失落、或数据流边界谬误导致的异样。所以更偏向于认为这些数据不是 MQTT 报文,也作了抛弃解决,不去消耗额定的资源对这些异样进行解决。

总结

本文大抵梳理了应用 Synopsys 出品的 Defensics 含糊测试器及配套的 MQTT v3.1 协定测试套件,对 EMQ X 的含糊测试过程,并且选取了局部用例进行测试和后果起因剖析。

能够看到 EMQ X 在对协定的实现上十分残缺,即便应用大量谬误报文进行测试也不会导致 EMQ X 失去提供服务的能力,能够保障协定的安全性,为理论我的项目的稳固运行提供平安保障。

EMQ 致力于为物联网畛域提供高可用、高牢靠的 MQTT 音讯服务器及其他数据基础设施软件。在去年,咱们也与 Synopsys 达成了单干,该公司将全面负责 EMQ 各产线产品整个生命周期的平安和品质风险管理。咱们心愿用户能够通过 EMQ 的产品,构建更加稳固牢靠的物联网平台与利用。

EMQ X 开源我的项目也随时欢迎您的参加,欢送通过 GitHub:https://github.com/emqx/emqx 向咱们提交 PR 或 Issue。

正文完
 0