本博客是讨论与物联网/工业物联网生态系统及其安全性相关的基本概念的系列文章的一部分。如果您还没有浏览过该系列以前的博客，我建议您先浏览这些博客。如果您只对 MQTT 安全性感兴趣，请随时继续。IoT Security

物联网安全 – 第 1 部分（101 – 物联网介绍和架构）

物联网安全 – 第 9 部分（软件定义无线电简介）

物联网安全-物联网介绍及其架构

物联网安全-2.物联网攻击面

物联网安全3.物联网10大安全漏洞

物联网安全-4.低功耗蓝牙BLE

物联网安全-5.ZigBee协议物联网安全-6.ZigBee安全物联网安全-7.物联网固件逆向

物联网安全-8.软件无线电（Software Defined Radio，SDR）简介

物联网安全-9.软件无线电简介（Software Defined Radio，SDR）:软件部分

在这篇文章中，我们将介绍最著名和最广泛使用的物联网协议之一——MQTT、安全问题和对 MQTT 的攻击。但在此之前，让我们首先了解一下MQTT到底是什么，以及为什么它是物联网供应商眼中的苹果。请注意，我们将交替使用术语客户端和节点以及服务器和代理来表示相同的内容。

1 引言

MQTT 是消息队列遥测传输的缩写。它是OASIS和ISO标准。它基于客户端/服务器发布/订阅消息机制的原则。与其他物联网协议一样，它轻量级且易于使用和实施，适用于受限和自动化的环境，如 M2M（机器对机器）和物联网。它是一种在TCP上运行的应用层协议，可以在任何其他提供可靠，有序和双向通信的网络协议（例如websockets）上运行。

| TCP Port | Communication Type | | ——– | —————— | | 1883 | Plain text | | 8883 | TLS |

在撰写本文章时，该协议的最新版本是 5.0。协议规范可以在这里找到 – https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html

1.1 使用和普及

MQTT 因其简单性、灵活的架构和云就绪性而在工业物联网 （IIoT） 生态系统、工业控制系统 （ICS）、企业物联网等中广受欢迎。我们认为MQTT将在不久的将来在工业控制系统（ICS）和IIoT基础设施中发挥极其重要的作用。

1.2 架构概述

MQTT 网络的中心是一个 MQTT 代理。所有 MQTT 节点都连接到代理。把它想象成一个星形网络。节点可以订阅和发布消息。节点通过发布或订阅代理通过代理相互通信。简单来说，代理根据订阅将消息从一个节点转发到其他节点。

物联网生态系统的哪些组件将充当代理，节点完全取决于基础设施的要求， 生态系统， 和实施.

节点可以是（但不限于）：

1. 物联网边缘设备

2. 物联网网关

3. 应用程序服务器

4. 移动应用

5. 云应用

6. 另一个 MQTT 代理（桥接时）

同样，经纪人可以是（但不限于）：

1. 物联网网关

2. 基于云的 MQTT 服务器

3. 移动应用

2 MQTT 通信

2.1 通信概述

那么，节点如何指定向谁发送消息以及接受消息来自谁？这是使用称为主题的东西完成的。节点基本上在主题上发布消息，其他节点可以向代理指定它们要订阅的主题。可能是时候定义一些关于主题的术语和解释了

1. Topic– 主题或主题名称只是附加到消息（应用程序有效负载）的标签。主题名称的语法类似于树结构（想想文件系统树，没有开头）。例如，有效的主题可以是 。/payatu/office1/boardroom/temperature

2. Topic Level– 主题中的每个项目代表一个主题级别，并且主题级别具有父子关系，例如，在 office1 中位于会议室的父主题级别。payatu/office1/boardroom/temperature

3. Topic level separator– 每个主题级别都用正斜杠分隔。/

4. Topic Filter– 节点可以通过指定主题过滤器在对 MQTT 代理的单个请求中订阅一个或多个主题。主题过滤器基本上是匹配一个或多个主题的表达式（想想简单的正则表达式）。有两个通配符可用于匹配多个主题。

1. a/b/#主题过滤器将匹配“B”下的任何主题级别及其任何子级，即 .它不会匹配或a/b/ca/b/c/da/x/ca/b

2. a/+/c/d主题过滤器将匹配 ，但不匹配。a/b/c/da/x/c/da/b/y/d

3. a/b/c/+主题过滤器将匹配，但不匹配或a/b/c/da/b/c/xa/x/c/da/b/c/x/y

4. 单级通配符 – 用于匹配特定主题级别中的任何项目。让我们看一些例子来说明：+

5. 多级通配符 – 它用于匹配特定主题级别及其所有子主题级别的任何项目。必须在主题名称的叶子处指定它。通配符的一些示例：##

6. 两种通配符都可以在单个主题过滤器中使用，例如a/+/c/#

7. 例如，单个通配符筛选器也有效，并且#+

5. Topic starting with $ character– 以 $ 字符开头的主题名称（例如 $foo/bar/boo）通常用于 MQTT 服务器实施和管理目的。是特定于服务器的信息或根据规范的控制 API 广泛使用的主题前缀。然而，这不是一项任务。服务器实施可以自由使用他们选择的任何前缀，例如 AWS IoT 对所有内部/管理内容使用主题前缀。这些主题存在某些条件和限制：$SYS/$aws/

1. MQTT 服务器将不匹配以通配符开头的主题过滤器或以 $ 字符开头的主题名称。#+

2. 节点不应使用以 $ 字符开头的主题名称与其他节点交换消息。换句话说，它们不应用于特定于应用程序的消息。

2.2 通信示例

下面的示例演示了一个场景，其中我们有 4 个节点连接到 MQTT 代理。三个节点（节点 1、节点 2 和节点 3）使用不同的主题筛选器订阅他们选择的主题。然后，一个节点 （Node1） 向代理发布有关主题的消息。在三个订阅节点中，代理仅将消息发布到两个节点（Node2 和 Node3），因为它们的主题过滤器与发布消息的主题匹配。

假设设置与上述相同，如果 Node1 向代理发布了有关以下主题的消息，则将从代理接收每个主题的消息的节点是 –

|发布消息的主题 |将接收消息的节点 | | ———————————– | ———————————– | | a/b | Node1 and Node3 | | a/b/c | Node3 | | $SYS/broker/foo | None |

3 MQTT 协议介绍

由于本文章侧重于介绍，因此我们不会详细介绍协议内部细节。但是，我们将在这里讨论协议和通信的重要方面，如果需要，可能会写一篇关于 MQTT 协议内部的详细文章。

3.1 MQTT 控制数据包简介

客户端（节点）和服务器（代理）之间的通信通过 MQTT 控制数据包进行。MQTT 控制数据包由一到三个部分组成：

1. Fixed Header– 这存在于所有数据包中。这指定控制数据包类型、标志和剩余数据包长度

2. Variable Header– 这存在于某些数据包中。此标头的内容因数据包类型而异。通常，数据包标识符是某些数据包类型中的字段之一。

3. Payload– 这存在于某些数据包中，例如连接、发布、订阅、回退、取消订阅和取消后退。在 PUBLISH 数据包中，有效负载是应用程序消息，并且是可选的。

MQTT 版本 16.5 规范中定义了 0 个 MQTT 控制数据包。

| Packet Type | Description | | ———– | ——————————— | | Reserved | Reserved | | CONNECT | Connection Request | | CONNACK | Connection Acknowledgement | | PUBLISH | Publish a message | | PUBACK | Publish Acknowledgement (QoS = 1) | | PUBREC | Publish Received (QoS = 2) | | PUBREL | Publish Release (QoS = 2) | | PUBCOMP | Publish Complete (QoS = 2) | | SUBSCRIBE | Subscribe Request | | SUBACK | Subscribe Acknowledgement | | UNSUBSCRIBE | Unsubscribe Request | | UNSUBACK | Unsubscribe Acknowledgement | | PINGREQ | Ping Request | | PINGRESP | Ping response | | DISCONNECT | Disconnect notification | | AUTH | Authentication exchange |

3.2 服务质量

该协议通过服务质量标志定义了三个级别的通信可靠性。此标志的值决定了发送方和接收方之间的通信方式，即使用不同的控制数据包。我们在这里提到了术语发送方和接收方，因为客户端（节点）和服务器（代理）都可以充当发送方或接收方，具体取决于谁将消息发送给谁，例如，它可以从节点发送到代理或从代理到节点。让我们看一下三个级别

1. QoS level 0 - At most once delivery– 这是一种不可靠的消息传递机制，接收方不会发送确认，这意味着如果消息丢失，则会丢失:)。

| Sender | Flow | Receiver | | ———————————————— | —– | —————————– | | Sends PUBLISH with QoS = 0. Transaction complete | —-> | Receives the message (or not) |

2. QoS level 1 - At least once delivery– 这可确保消息至少收到一次。接收方应该发送 PUBACK 数据包以响应 PUBLISH 数据包。

| Sender | Flow | Receiver | | ———————————————————— | —– | ——————– | | Sends PUBLISH with QoS = 1 | —-> | Receives the message | | Receives the PUBACK. Discards message. Transaction complete. | <—- | Sends PUBACK |

3. QoS level 2 - Exactly once delivery– 当消息丢失或重复不可接受时，将使用此方法。这是一个 4 步过程。

| Sender | Flow | Receiver | | ———————————————- | —– | ————————————————— | | Sends PUBLISH with QoS = 1 | —-> | Stores the Packet ID. May Initiate onward delivery. | | Discards message. Stores PUBREC with Packet ID | <—- | Sends PUBREC with the same Packet ID | | Sends PUBREL with same Packet ID | —-> | Discards Packet ID for any future packets received | | Discards stored state. Transaction complete | <—- | Sends PUBCOMP with the same Packet ID |

3.3 数据包和使用

我们将简要讨论一些操作（以及相应的数据包，其内容），因为描述所有控制数据包以及每个字段对于这个 101 风格的文章来说将是矫枉过正。但是，我们敦促您仔细阅读协议规范，以很好地了解内部结构。

这是一个逻辑 MQTT 连接请求。这是建立底层连接后从客户端发送到服务器的第一个 MQTT 控制数据包。它包含连接的一些重要信息。数据包的可变标头中的一些重要信息包括：

1. Protocol–它包括协议名称和版本

2. Connect Flags– 一个字节指定有效负载中是否存在的相应值，例如用户名、密码、Will 标志、干净启动等。客户端基本上使用“Will”的东西来告诉服务器在 will 主题上发送特定的（will）消息，并在客户端突然断开连接时使用其他 will 数据。

3. Keep Alive– 两个数据包传输之间的时间（以秒为单位），如果经过，客户端必须发送 PINGREQ 数据包。

4. Properties– 某些数据包（包括 CONNECT）在变量标头的末尾包含规范中定义的标准属性。

有效负载中的一些重要信息包括：

1. Client Identifier– 连接到服务器的每个客户端都指定一个唯一的客户端 ID。这用于维护会话状态。请注意，这不是 MQTT 身份验证的一部分。

2. User Name– 如果在变量标头中设置了用户名标志，则有效负载包含用户名

3. Password– 实际密码，如果在变量标头中设置了密码标志。

此数据包是 CONNECT 数据包的响应，包含有关连接请求状态的信息。它可以接受或拒绝连接。变量标头包含连接原因代码、连接确认标志和属性。连接原因代码是一个单字节，用于指定连接请求的成功、失败和错误，例如“错误的用户名或密码”、“协议错误”、“成功”、“格式错误的数据包”等。规范中定义了 22 个连接原因代码。

这用于发布有关主题的应用程序消息。变量标头包括：

1. Topic Name– 要在其上发布消息的主题。

2. Packet Identifier— 仅适用于 QoS = 1 或 2 的数据包，因为发送相应的确认数据包需要它。

3. Properties– 发布特定属性。查看规格了解更多详情

数据包的有效负载包含正在发布的应用程序消息。有效负载中的数据格式特定于应用程序。因此，开发人员可以自由决定他们想要交换哪种数据，例如JSON，XML，文本，二进制等，例如AWS IoT使用JSON格式在AWS事物和IoT Core之间进行数据交换。

对 PUBLISH 的响应取决于 QoS

1. QoS = 0– 无回应

2. QoS = 1– 普巴克

3. QoS = 2– PUBREC（随后是PUBREL和PUBCOMP的交换）

它用于订阅一个或多个主题，以接收在同一主题上传递的应用程序消息。变量标头包含数据包标识符和属性。有效负载包含主题筛选器列表，每个主题筛选器后跟一个描述其订阅选项的字节。

此数据包是 SUBSCRIBE 数据包的响应，包含有关订阅请求的接收和处理的信息。它可以根据任何问题有选择地授予或拒绝主题筛选器的订阅请求。变量标头包含数据包标识符和属性。有效负载包含订阅原因代码列表，其中每个原因代码对应于订阅请求中的相应主题筛选器，即原因代码的顺序与订阅请求中主题筛选器的顺序相同。原因码是一个单字节，用于指定成功、失败、对应于相应主题筛选器的错误，例如“未授权”、“主题筛选器无效”、“授予 QoS 0”、“不支持通配符订阅”等。规范中定义了 12 个订阅原因代码。

此数据包用于取消订阅一个或多个主题。变量标头包含数据包标识符和属性。有效负载包含客户端要取消订阅的主题筛选器列表。

此数据包是对取消订阅数据包的响应，用于确认收到取消订阅请求。变量标头包含数据包标识符和属性。有效负载包含取消订阅原因代码列表，其中每个原因代码对应于取消订阅请求中的相应主题筛选器，即原因代码的顺序与取消订阅请求中主题筛选器的顺序相同。原因码是一个单字节，用于指定成功、失败、与相应主题筛选器对应的错误，例如“成功”、“未授权”、“主题筛选器无效”等。规范中定义了 7 个取消订阅原因代码。

其他数据包包括：

1. PINGREQ 和 PINGRESP 用于连接保持活动状态或心跳

2. 当应该在 MQTT 会话中使用扩展或外部身份验证机制时，将使用 AUTH。

3. 断开连接以关闭 MQTT 会话。

4 MQTT 安全性

现在我们了解了 MQTT 的工作原理，让我们从进攻和防御的角度关注 MQTT 的安全方面。以下所有信息均基于我们在 MQTT 安全研究以及物联网产品和基础设施渗透测试项目方面的经验。我们将尝试在此文章中保持简单。在以后的文章中，我们将深入探讨对 MQTT 的不同攻击的技术方面。下面我们将尝试回答在物联网渗透测试中遇到新协议时通常会出现的一些问题。

4.1 工具

是否有任何工具可以帮助进行 MQTT 分析和评估？值得庆幸的是，有一些选择可用：

1. 开源库、客户端、服务器实现。这里唯一的问题是它们是僵化的，没有安全角度的指导，您最终可能会编辑或编写自己的脚本来完成这项工作。

2. EXPLIoT Framework有一些非常简洁的MQTT插件，用于发布，订阅甚至MQTT身份验证破解。它可以与标准MQTT服务器以及AWS IoT MQTT服务器进行交互。

3. 模糊测试 – Scapy 具有 MQTT 数据包创建功能，可用于创建您自己的模糊器。

4.2 侦察

好的，所以我们有了工具，现在怎么办？我们从哪里开始？第一件事是在 MQTT 代理上执行侦察，获取尽可能多的关于 MQTT 网络的信息。

1. 是否可以在没有身份验证的情况下进行连接？

2. 当您订阅所有主题时会发生什么，即#

3. 您是否可以访问任何主题？有哪些可用信息？$SYS/

4. 您是否能够读取任何敏感信息？

5. 您是否能够发布任何或敏感主题？

6. 物联网生态系统中哪些主题是重要和使用的？这也可以通过对设备固件或移动应用程序（如果它是 MQTT 网络的一部分）进行逆向工程来找到。

7. 客户端 ID 是如何生成的？客户端 ID 是否有任何模式？

8. 是否使用TLS？

9. 如何在云上使用从设备发送遥测数据？

4.3 分析

一旦我们收集了有关 MQTT 实现的基本信息，我们就可以利用它对生态系统发起不同的攻击。生态系统是指 MQTT 基础架构的所有组件，包括设备、网关、云代理和应用程序、移动应用程序等。我们将列出一些想法，让您的灰色细胞工作：

1. 订阅 可帮助您了解在进行身份验证或不进行身份验证的情况下可以访问哪些主题以及传递的消息。#

2. 如果 Broker 需要身份验证，您可以发起密码暴力攻击或基于字典的攻击

3. 反转固件或移动应用程序可能会为您提供敏感信息，例如

1. 客户端标识

2. 凭据

3. 证书和密钥

4. 使用的主题

5. 在特定主题上交换和预期哪些数据，以及它如何影响组件的行为。

4.4 攻击

在几年前的研究中，我们发现的一件事是，几乎所有的 MQTT 实现在重复的客户端 ID 方面都具有相同的行为。这种情况是，当客户端连接到服务器时，如果发送此 CONNECT 请求的新客户端提供的客户端 ID 已被当前连接到服务器的另一个客户端使用，则服务器将继续并断开当前连接的客户端的连接，并允许新客户端连接。此行为可能有正当理由，因此不会将其视为错误。但是，此问题可能会导致 MQTT 网络中的 DoS。所需的信息是生成客户端 ID 的逻辑，如果它们使用模式，则变得很容易。在这种情况下，您只需要一个脚本来生成客户端 ID 并连接到代理，以有效地踢出大多数（如果不是全部）当前连接的客户端，换句话说，会导致 MQTT DDoS。

有时（真实故事！）客户端 ID 可能用于对客户端进行身份验证或提供对敏感主题的访问。在这种情况下，使用与上述相同的技术，您可以访问 MQTT 网络并接收或操作敏感数据。

同样，根据是否实施身份验证以及您对合法事物的凭据/密钥的访问权限，您可以欺骗合法客户端并操纵遥测数据，就好像它来自实际客户端或接收发往合法客户端的敏感信息一样。

注意：我们已经发现并已经披露了一些使用此技术的已知 MQTT 实现的漏洞。我们目前正在等待披露时间表完成，以便我们可以在其上发布详细的文章。

IoT 协议是为受限环境创建的。它们相对较新，与传统协议和应用程序的可移植性和数据交换由应用程序处理，除非协议标准指定了交换机制。这根本不是一个复杂的问题，但这打开了一个新的攻击面。应用程序开发人员通常信任来自设备的遥测数据，因为这些数据本质上是最小的，并且可能会忘记筛选已知攻击。这意味着，根据应用程序端处理数据的方式，如果遥测数据包含恶意构建的有效负载，则它可以利用应用程序。让我们举一个非常简单的ICS/IIoT基础设施示例，其中某个房间的温度定期发送到应用程序，应用程序将其显示在Web UI上。假设攻击者可以访问 MQTT 网络并且可以发布到同一主题，现在发布 XSS 有效负载，如果温度数据未被应用程序过滤，这势必会利用浏览器。

免责声明：这种技术基本上适用于任何物联网协议，其中遥测数据使用受约束的物联网协议从设备传输到云（并可能将其转换为HTTP等传统协议），然后馈送到标准应用程序进行存储，处理或显示，而无需首先过滤它。

使用上面提到的各种技术，如果您可以接收敏感消息（通过订阅有趣的主题）和/或能够将您选择的消息发布到敏感主题，那么 MQTT 网络的游戏就结束了。发布有关主题的消息的一个示例可能是通过向设备发送有关主题的特定命令来控制设备，该主题希望从网关/云/用户接收命令。太可怕了！

4.5 缓解措施

MQTT 的一切都不错，否则一开始没有人会使用它。与任何其他协议一样，MQTT 中的漏洞和问题源于不安全的配置和实现的使用。作为保护 MQTT 实施的基线，您应该考虑的一些事项是：

1. 使用红绿灯

2. 请勿使用客户端 ID 进行身份验证或主题访问控制。

3. 使用随机生成的客户端 ID

4. 不要向客户端公开主题。如果需要，请使用基于身份验证的访问控制。$SYS/

5. 将来自设备的应用程序消息视为受污染，并根据该数据的使用情况筛选它们以查找已知攻击。

6. 不要在设备固件中对凭据进行硬编码。

7. 设备（客户端）应仅查看或访问所需的主题。

8. 记录所有活动。

9. 如果不需要，则更喜欢记录有关主题的消息，而不是在这些主题上发布消息并使其可供订阅。例如，Mosquitto服务器具有本地登录的配置选项，而不是发布有关任何主题的消息。$SYS/$SYS/

10. 启用和使用云提供商（AWS、Azure 等）安全通知，以应对 MQTT 基础架构中的不当行为或潜在攻击，例如多次失败的身份验证尝试。

5 结论

我们希望这篇博文能为您提供有关 MQTT 协议、其工作原理、使用方式以及如何对基于 MQTT 的物联网/IIoT 生态系统进行安全评估的良好高层次概述。上述工具、攻击和技术将提高评估效率，并为您提供更深入地检查任何 MQTT 实现的安全研究的方向。