理解物联网云平台中部署通用消息传输协议的安全风险

编者按

2022年5月，由网络安全研究国际学术论坛（InForSec）汇编的《网络安全国际学术研究进展》一书正式出版。全书立足网络空间安全理论与实践前沿，主要介绍网络和系统安全领域华人学者在国际学术领域优秀的研究成果，内容覆盖创新研究方法及伦理问题、软件与系统安全、基于模糊测试的漏洞挖掘、网络安全和物联网安全等方向。全书汇总并邀请了近40篇近两年在网络安全国际顶级学术议上发表的论文（一作为华人），联系近百位作者对研究的内容及成果进行综述性的介绍。从即日起，我们将陆续分享《网络安全国际学术研究进展》的精彩内容。

(相关资料图)

本文根据论文原文“Burglars’IoT Paradise: Understanding and Mitigating Security Risks of General Messaging Protocols on IoT Clouds.”整理撰写，原文发表于IEEE S&P 2020。作者在完成论文原文工作时，为西安电子科技大学在读博士生。本文较原文有所删减，详细内容可参考原文或作者的博士学位论文。

01介绍

随着消费物联网的流行，物联网云平台被众多的设备厂商广泛使用。物联网云平台服务最核心的功能之一就是为设备与用户提供通信服务，包括传送用户对设备的控制指令、向用户回馈设备状态与事件等。在物联网云平台的帮助下，用户能够随时随地远程控制和监视智能门锁、插排、温度计等各种各样的设备。为了便捷性与兼容性，物联网云平台通常基于已有的通信协议来构建，如HTTP、AMQP、MQTT等。

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）协议是OASIS的一项即时通信协议标准，具有低开销、低带宽占用的特点，特别适用于计算能力较弱的物联网设备。因此，MQTT协议被众多主流物联网云平台采用，包括亚马逊、微软、IBM、阿里巴巴、涂鸦智能、谷歌等。

然而，不幸的是，MQTT协议最初并非针对存在敌手的环境设计的，因此协议自身没有充分考虑现今消费物联网系统中潜在的威胁。协议自身仅提供了简单的认证机制，物联网云平台提供商不得不自己开发对MQTT协议的保护机制。然而，通用消息传输协议具有复杂的状态转换与敏感实体，消费物联网应用场景却十分复杂，目前没有一个公认的标准来指导开发人员如何在一个通用的通信协议上定制安全措施。与此同时，通信协议在物联网系统中扮演着极其重要的角色，是物联网设备与用户交换信息的基石，因此协议层的任何访问控制漏洞均可能导致严重的后果，包括远程非法控制、敏感信息泄露等。但是，关于商业物联网云平台中基于MQTT协议的通信是否得到了有效的安全保护却鲜有相关工作研究。

本文首次系统性地研究了主流物联网云平台集成和部署通用消息传输协议MQTT时存在的安全风险，发现物联网云平台对MQTT协议定制的安全措施普遍存在隐患，使得敌手利用设计中的漏洞能够开展如下攻击：非法远程控制目标设备；窃取用户隐私信息，如作息规律、位置、同居者等；大规模拒绝服务；伪造设备状态。经评估，这些攻击将带来十分严重的后果，例如，敌手能够远程收集某物联网云平台上所有设备产生的事件消息，进而获得用户的个人可识别信息。

在复杂的消费物联网环境中，大部分的物联网云平台不知如何安全地部署一个通用消息传输协议，即使是相对简单的MQTT协议。通过进一步深入分析，我们发现原协议设计与现应用场景之间存在的差异。现阶段，物联网设备会被不同的用户共享使用，如宾馆旅客、民宿的租客、家庭访客、保姆等，一旦临时用户访问设备的权限被撤销，该用户就不应再具有该设备的控制权；另外，MQTT协议设计了针对其他特殊场景的异常处理消息机制和功耗优化机制，客户端能够在离线后继续发送消息。这种设计与应用场景的差异所带来的复杂性，给安全部署访问控制机制带来了严峻的挑战。通过人工分析与测试，我们发现即使客户端的权限已被撤销，敌手仍能够利用协议中的会话和特殊消息类型来绕过云端的限制继续访问设备，从而违背消费物联网环境中的安全需求。

除了消费物联网环境带来的新威胁模型，另一项造成安全问题的重要原因是物联网云平台厂商对协议中安全敏感的状态与实体没有充分的认识和保护。例如，MQTT使用ClientId字段来唯一标识一个客户端，当有相同ClientId的客户端新建立MQTT连接时，服务器将断开旧的客户端；而由于最初良性的应用环境，协议标准（MQTT 3.1.1版本）中并没有强调该关键实体需要在部署中被特殊保护。这个认识差异导致其在消费物联网环境中缺乏充分的认证与授权，敌手能够恶意利用ClientId将其他客户端挤下线，甚至劫持会话。

通过对8个主流物联网云平台的实践分析，我们发现这些平台在使用MQTT协议时存在大量的安全问题，使众多设备厂商和用户暴露于上述安全风险之中。我们将发现的问题报告给了受影响的相关厂商与组织，包括亚马逊、微软、IBM、阿里巴巴、百度等，并帮助这些厂商和组织修复相关问题。此外，本文研究发现的问题已被OASIS MQTT协议标准技术委员会认可，截至撰文时这些问题正处于公开讨论解决方案的阶段。

最后，我们提出了一系列的安全设计准则和面向消息的访问控制模型，实验结果证明本文所提方案能防御我们发现的所有攻击并具有较低的开销与负载，为物联网云平台安全地部署通用消息传输协议提供了参考。另外，Eclipse Mosquitto已根据报告与建议修补了相关漏洞（CVE-2018-12546）。

02背景

1. MQTT及其物联网应用

基于云的典型物联网系统包括3个部分，分别为物联网设备、云和用户控制台（如移动APP），如图1所示。位于中心的是负责管理设备与APP通信的云服务器，云中部署有负责消息转发的消息代理；用户使用APP通过云发送消息给设备，如设备控制指令等；同时，设备也与云通信，云将设备上报的状态信息发送给APP，例如温度计的读数、门锁的开关状态等。为了实现通信交互功能，云平台提供商会为设备厂商提供方便其开发的SDK以集成至设备和移动APP中。设备厂商只需在云端简单地配置，利用SDK便可以快捷地在客户端实现云平台约定的通信功能。这种以云为核心转发通信消息的模式已经被许多物联网云平台提供商（亚马逊、微软、IBM、涂鸦智能、阿里巴巴）和设备厂商应用。在整个系统中，云承担着保护用户与设备交互安全的核心功能，例如对设备和APP（用户）进行认证与权限检查。

图1

MQTT协议（本文主要关注MQTT协议3.1.1版本。尽管OASIS于2019年3月推出了最新MQTT协议5版本，它在3.1.1版本基础上增加了新功能，但是截至本文工作完成时尚未发现有商业物联网平台采用）。作为一种低功耗、低带宽占用的即时通信协议，MQTT协议在物联网方面有着广泛的应用。MQTT协议是一种发布-订阅模式的轻量级通信协议，位于OSI网络模型的应用层，工作于TCP/IP或其他可靠、有序的全双工连接之上，如WebSocket。发布-订阅消息模式中，发送方将消息按照某种类型发布而非直接发布给接收方，类似地，订阅者（接收方）根据需求订阅某类消息。

接下来我们以一个物联网应用场景为背景简单介绍MQTT协议工作的基本原理。如图2所示，位于中心的是消息代理，部署于物联网云中，作为连接的中枢，以发布-订阅模式来转发客户端的消息。MQTT协议根据“主题”来管理消息的转发并将发布者和订阅者解耦。因此，消息代理维护着消息主题的列表，每个主题的格式类似于Linux操作系统中的文件路径，以斜线分割层级，如DeviceId/status。想要互相通信的物联网设备和移动APP作为MQTT客户端首先连接至消息代理，之后向消息代理发送消息至某个主题；消息代理随后将收到的消息根据主题转发至订阅了该主题的所有客户端。一个客户端可以订阅某个具体的主题，同时也可以使用通配符（如#）来同时订阅多个主题。

图2

一个MQTT客户端可以发送3种基本类型的消息给消息代理，分别是连接（CONNECT）、发布（PUBLISH）和订阅（SUBSCRIBE）。首先，在建立传输层连接（如TCP连接和WebSocket连接）后，MQTT客户端（物联网设备和APP）发送CONNECT至消息代理来建立一个MQTT会话，类似于HTTP中的会话Cookie，MQTT会话被CONNECT消息中的ClientId字段唯一标识；不过，MQTT是一个长连接协议，建立MQTT连接后会话依赖于客户端和消息代理之间保持的传输层连接，ClientId仅在第一个CONNECT消息中被携带。建立会话后，物联网设备通过发送SUBSCRIBE给消息代理来订阅其“关联主题”，要订阅的主题携带在SUBSCRIBE消息中，如DeviceId/cmd。消息代理在接受订阅后会为每个客户端会话维护其订阅状态，并将发送至该主题的消息转发给订阅者。因此，用户便可以使用移动APP通过PUBLISH消息来向设备订阅的主题/DeviceId/cmd发送控制指令，例如发送“Start”消息来开启空调。同理，设备可以向其关联的主题，如DeviceId/status，周期性地发布自己的状态，如室内温度信息；用户的APP只要订阅此主题即可接收到设备的状态信息。综上所述，整个MQTT的通信过程依赖于4个重要实体：身份（即ClientId）、消息、主题和会话。因此，用户与设备的安全交互就要求对这4个实体进行有效的安全保护。

2. 物联网云平台的安全措施

作为一个通用的消息传输协议，MQTT并非专门针对敌手环境设计，例如，该协议中没有定义详细规范的授权流程，仅提供了简单的辅助认证功能：客户端可以在CONNECT消息中携带username和password字段来作为认证凭据。为了保护诸如智能门锁、安全摄像头、火灾报警器等敏感物联网设备，物联网云平台通常会自己定制安全措施来认证MQTT客户端并授权客户端所能发布和订阅的主题。我们通过调研8个现有主流物联网云平台，总结出已被广泛部署的安全措施如下。

（1） 认证机制。MQTT可工作于WebSocket和TLS之上，不同的传输层协议自身具有的认证功能为云平台认证MQTT客户端提供了方便；同时，不同的云平台提供商还可能提供其他综合云服务，例如AWS还提供身份、存储、计算等其他通用云服务，这些其他功能的差异也导致云平台部署了多种不同的认证措施。

Web认证机制。MQTT作为应用层协议需在传输层连接建立后开始会话，因此部分平台利用Web技术中的认证机制在客户端开启MQTT会话前对其进行认证。例如，AWS IoT 会在WebSocket连接建立时利用HTTP的Cookie等信息来对客户端进行认证，这允许物联网平台在已有技术架构上方便地验证来自第三方身份提供商的身份，例如AWS就用此法对来自Amazon Cognito的身份进行验证。该方法常被用于认证移动APP客户端。

客户端证书。云平台预分配给客户端一个自己信任的CA签名证书，在客户端建立TLS连接时使用TLS客户端认证模式来对客户端进行认证；物联网设备容易在出厂时内置一个证书，因此这种方式常被用来认证设备客户端。

MQTT认证。云平台可以利用MQTT提供的username与password机制来对客户端进行认证。设备厂商在平台上和客户端上配置相应的用户名与密码，在MQTT会话开始时，客户端在开始MQTT连接时的CONNECT消息中携带相应的用户名和密码，而云会在收到该消息时进行认证。

（2） 授权机制。如上文所述，在MQTT中消息代理基于主题转发消息，因此，物联网云平台要限制物联网设备只被授权用户访问，就需要限制客户端所能访问的MQTT主题。具体而言，物联网云平台会根据设置的安全策略来限制客户端的具体能力，而不同物联网云平台给设备厂商提供了不同粒度的能力来定制安全策略。尽管不同的物联网云平台有不同的访问控制设计，但是一个物联网设备通常具有唯一的与其关联的一组主题，该设备仅允许向该组主题收发消息，本文称其为“设备关联主题”；而用户权限通常根据其可访问的设备被动态配置，即根据用户绑定的设备自动授予设备关联主题权限。例如，一个智能门锁的一个关联主题是device/lock/uuid/status，其中uuid是设备唯一标识；只有绑定了这个设备的用户会被动态地分配该主题的订阅、发布权限，而其他用户对该主题的访问将被拒绝。

（本文选取了文章部分章节，更多精彩内容请阅读《网络安全国际学术研究进展》一书。）

作者简介

贾岩，南开大学网络空间安全学院师资博士后，2020 年 12 月毕业于西安电子科技大学。他感兴趣的研究方向为挖掘真实网络和系统中设计与实现的新型漏洞，目前主要关注 IoT、智能家居安全，研究成果发表于IEEE S&P、USENIX Security、ESORICS、Blackhat等知名国际会议。他获得众多厂商和组织的认可与致谢，包括亚马逊、苹果、IBM、微软、OASIS标准组织、三星等。

版权声明：本书由网络安全研究国际学术论坛（InForSec）汇编，人民邮电出版社出版，版权属于双方共有，并受法律保护。转载、摘编或利用其它方式使用本研究报告文字或者观点的，应注明来源。

标签： 网络安全 传输协议 安全措施