物联网安全系列之探索IoT通信安全的研究之道 – 作者:腾讯安全平台部

通信作为IoT系统架构的重要组成部分，是新基建时代的万物互联的连接器，也自然成为了IoT安全研究员们关注的重点，本文整理自Tencent Blade Team在2020年小米AIoT安全峰会上分享的议题速记内容，主要分享如何从架构设计，协议栈实现，实际部署等角度出发，对多种“非主流”却又广泛使用的有线与无线IoT通信机制进行攻击面分析与漏洞挖掘。

第一部分主要是IoT通信安全概述与研究思路，包含我们对IoT通信技术的理解，以及我们团队研究这些通信技术进行安全研究时的一些思路。

这是我们整理的一个IoT通信架构图，大家看到一些物联网架构的时候通常会把物联网分为云管端三部分，我们今天主要关注的是管道，比如说物联网节点和节点、节点与网关、网关与云等通信技术的安全性。首先最下面一层是偏物理层和数据链路层的通信协议，比如说NFC无线射频识别、蓝牙等近场通信技术，我们手机用的蜂窝网络技术，比如说4G、5G等等。中远距离可能就是大家熟悉的一些WiFi协议，还有ZigBee等协议。最后一个是有线的通信协议。

然后讲一下我们团队做IoT通信协议安全研究的视角，也就是我们怎么去分析IoT通信协议的攻击面的。首先分四块，第一块是IoT通信协议的设计缺陷，这是偏底层的一个协议角度，比如说WiFi联盟会定期发布一些WiFi的标准，如果我们要对WiFi协议做研究的话，我们就要时刻跟进新的标准，分析里面是不是存在安全风险。

第二部分是协议栈实现漏洞，同样是WiFi芯片，但是不同的芯片厂商去理解规范的时候，代码实现可能有些差异和安全风险，也需要引起我们的关注。

第三部分是通信模组集成漏洞，比如说通信模组厂商在研发4G、5G模组的时候，这些模组里面跑的一些系统和代码，这里面同样可能存在一些风险。

最后一部分是通信配置漏洞，比如说像小米这样的厂商去用通信模组的时候，如果在代码集成和配置方面有一些问题的话，同样会导致很大的风险。

下一个想讲的点是假如我们从零开始研究一个非主流的通信技术，可以从哪些方面入手？之所以讨论这个问题，是因为在目前的市场情况来看，WiFi、蓝牙这两种技术，大家研究的资料和成果已经非常多了。我们如果对新出来的物联网通信协议进行研究的话，会发现一个很大的问题，研究资料非常少，像我们团队现在就进行了一些比较偏前沿的通信技术研究，比如LoRaWAN、NB-IoT等。我们认为可以从下面这几方面入手。

第一步是前期准备工作，我们需要对协议本身的设计规范有一个了解，我们需要阅读各种文档；

第二步需要搭建一个测试环境，包括无线信号的收发等等，这需要购买一些SDR设备，或者一些厂商提供的开发板。

搭好测试环境之后，我们就有很多风险点可以一步步去尝试了，这些风险点可能分布在各个环节，它可能是在设计之初就有问题，也可能是芯片商进行实践的时候带来的问题，也可能是哪个模组厂商引入的问题。

这些问题有哪些？主要分三块，第一块就是通用风险，无论是有线通信协议还是无线通信协议可能都会有一些问题，比如说数据嗅探、中继攻击、信号重放、信号欺骗、拒绝服务等等。

第二块和第三块内容就需要我们进行一个深度的了解。在认证和加密这块，我们理解到主要还是为围绕着加密密钥做一个安全性的测试，在开发与配置层面，需要我们结合传统的代码漏洞挖掘技能与实际情况做一个深入的分析。

下面也给大家讲一讲我们团队在这块的探索历史，我们团队最早期是在2015年就开始做IoT这块的安全研究。我们当时在2015年GeekPwn演示了对某智能家居App通信协议的破解。

到了2017年就开始了ZigBee智能家居的研究，当时破解了市面上比如三星、小米以及一些小厂商ZigBee的设备，实现了一个远程控制效果，然后是KNX，这是智能楼宇领域里的有线通信协议。

到了2018年，我们开始了智能音箱安全研究，当时我们破解了市面上销量最高的三款音箱，包括小米、谷歌和亚马逊的音箱。小米AI音箱当初参加了小米早期的几期智能设备众测，拿到了小米最高18万元的现金奖励。

到了2019年我们开始了LoRaWAN安全研究，到了2020年我们演示了对直流充电桩的破解，实现了免费充电的效果，这实际上也涉及了电动车跟充电桩之间的通信协议漏洞。

最后讲一下我们团队在物联网安全规范与商业化探索这块的实践经验，刚刚无论是小米的老师还是其他的专家都讲到了这一点。在腾讯内部我们也有跟腾讯云及安全标准管理团队联合推出了一个腾讯物联网安全技术规范，这个规范文档现在也是网上可以公开下载的，我们也愿意跟业界厂家共同完善这一类的安全规范文档。

除此之外，我们也推出了一个物联网设备的安全等级认证，也就是说厂商可以把设备提交给我们合作的安全测评机构，然后我们根据测评分值颁发不同等级的证书，以此帮助物联网厂商提升其产品的安全口碑。

案例分享

下面将通过三个案例跟大家去探讨一下我们怎么样把刚才的思路践行到每一个研究项目里。

1. ZigBee智能家居

首先是ZigBee智能家居，ZigBee是一种低速短距离的无线通信技术，主要在智能家居领域用得比较多一些，包括像小米、三星都提供了ZigBee智能套件，像智能网关、智能插座等等。

简单看一下ZigBee的安全架构，主要从协议和模型两个角度简单梳理一下。安全模型主要有两种，第一种是集中的安全模型，如右上角图所示，它需要一个可信的中心接入，设备入网的时候需要跟这个可信的中心进行配置，比如说通过安装码生成相应的密钥，这种组网的方式相对来说配网会比较复杂一些，但是安全性会相对高一些。

另外一种是分布式的安全模型，就右下图所示，整个网络不再需要一个可信中心的角色，只需要一个ZigBee路由器就能够对设备进行管理，但是需要每个节点预置通信最基础的密钥，入网时分配网络密钥，这种方式配网相对来说比较简单，但是整体安全性比较低。

在我们进行ZigBee的安全研究过程中，可能我们会去思考这样的一些攻击点，就是我们该怎么样去做以及我们关注哪些点。首先是一个通信配置缺陷的相关问题，因为ZigBee的安全模型更多基于对称加密体制，所以说加密密钥将是重中之重，所以我们对多款ZigBee设备进行了分析。我们发现很多时候这些设备为了能够更方便跟其他厂商的设备组网，提高便利性，其实它会预置一些通用的密钥，这从而也带来了安全风险。

我们在进行实际测试的时候，发现需要一个攻击前提条件，就是得在设备入网时就对设备进行抓包才能实施后面的攻击。尤其是一些真正已经部署到线上的ZigBee项目，一般管理员会把入网的条件给关掉，也就是说一个网络成熟之后，攻击节点如果想接入ZigBee网络发起攻击是存在困难的，因为攻击节点无法成功入网。根据经验，我们觉得会存在这样一种场景或者需求：那就是可能一个设备已经入网了，但是经过某种原因掉线了，再次上线时是否经过某种机制恢复到最初的网络里。

因此，我们尝试寻找协议设计中允许设备重新入网的特性，比较幸运的是我们找到了一个这种特性，叫Insecure Rejoin。当节点设备向网络发送该请求，网络将会再次传输网络密钥，这样一来就能够把前面通信配置缺陷的风险在现实项目中实施起来。这种特性不同厂商也有不同的考虑，例如三星技术FAQ中也针该特性做可选项解释：根据安全场景还是便利场景由用户做出选择。这个协议特性反倒给攻击者带来了机会，引入了安全风险。所以基于这样的协议设计上的特性，我们觉得会是一个缺陷，就可以把之前通信配置缺陷的安全问题结合起来。

为了验证刚才提到的这些方式，我们进行了一个实践。实践过程中搭建了一个能够实现批量远程攻击的攻击环境ZomBee，它包括ZigBee的收发设备模块以及树莓派控制设备，攻击设备会不断的嗅探当前的环境，并对这个网络环境尝试攻击。很多时候我们要攻击的是远程目标，那么还可以挂在在大疆无人机上，实施远程的攻击行为。

接下来播放一个视频，这个视频是我们进行验证过程中所做的一些事情。通过无人机把ZomBee靠近攻击目标，然后对当前ZigBee智能家居进行攻击，最终实现了整层楼灯光开关的效果。最后这些漏洞都已经修复了，也进行了相应的安全加固，这是ZigBee的一个案例。

2. KNX智能楼宇

接下来我会介绍一个大家不太熟悉的KNX智能楼宇安全的课题。KNX是基于有线介质的通信协议，主要用于商业和家庭楼宇自动化的开放标准。比如五星级酒店、地铁站，以及比较高端的别墅群等，这些场所一般会采用KNX协议作为场景智能化方案。

KNX的网络架构大概如上图所示，由于KNX是基于有线介质的，那么就不能像ZigBee通过无线电的形式进行攻击了。因此，我们更需要了解这些有线到底是怎么布线，怎么把网络组建起来的。一个简单的KNX的网络大概如左图所示，分三部分，第一部分是KNX TP协议，用双绞线组网的环境，第二部分是KNXnet/IP，这是以太网链路，在进行传输的时候会把这个KNX TP协议进行封装。第三个关键的角色是IP路由器或者IP Interface的设备，最终实现网络互通。

在研究这个网络架构的时候，每种网络可能会有本身特有的攻击方式，同时又采用混合组网的方式，那么在通信部署、网络部署这块应该会存在不少值得关注的安全风险。

简单介绍一下KNX的网络安装方式，一般都是由专业的工具ETS进行网络的安装和调试的。主要分为三部分，首先网络进行拓扑的规划，包括这个区域怎么走线，过程中需要连接哪些设备。

第二点是型号目录，根据要采购的列表，包括西门子、ABB设备等选择相应的设备进行模拟。

第三个功能比较强大，就是做网络诊断。与此同时，我们是能够嗅探整个网络下的数据，同时也能够去对设备进行一些流量的发起，包括重编程等等。

在KNX通信配置风险中，我们觉得可能会有图中标注的三点缺陷。右边这个图其实就是稍微具体一些的KNX网络拓扑，可以对应到刚才介绍的KNX网络架构。蓝色部分表示的是IP路由器，绿色部分表示每个房间都是双绞线连起来的。

具体有哪些缺陷？第一，设计可能存在缺陷，在设计项目的时候，工程师没有把房间隔离开来。比如这个拓扑其实是有一个房间101跟102，他们都是由绿色的线相连的，而且连接在同一个路由器下面，只要能够接入到房间101的KNX设备，就可以控制房间102的设备了，这是从设计上需要考虑隔离的。

另外，我们规划的时候也没有把KNX Secure这个特性加进去，它需要设备的支持，也需要新版ETS软件的支持。但是在设备选型的时候，就没有考虑这些设备，同时在使用一些软件进行配置的时候，用的是低版本的话也不能把安全特性给补齐。

另外就是在网络部署时的一些缺陷，例如刚刚提到的以太网KNXNet/IP，在部署过程中没有考虑到隔离的问题，比如说这个酒店的WiFi其实是跟我们的KNX路由器是在同一个环境的，一旦用户能够连接到这个酒店里的WiFi，其实我们就能够去发起攻击的。

同时KNX也提供了设备编程的密钥，如果我们在网络部署的时候没有对这些设备进行密钥的设置，它就会以默认密钥的方式进行设置。我们在攻击的时候就不需要考虑密钥的问题。

最后一个是设备安装的缺陷，在对实际设备部署到整个酒店的过程中，我们会发现这些设备有可能会暴露在客房里或者也可能比较容易让攻击者接触。这几点可能是我们需要考虑的点。

我们有两种攻击方式，第一种通过以太网环境接入到网络发起攻击。另外一个就是走下面的双绞线，通过房间接触到双绞线的设备，从而发起攻击，当然还需要做一些策略的更新等等。

基于初步分析得出来的思路该如何实践呢？我们当时选取了一个比较智能的五星级酒店进行测试。首先通过酒店的WiFi或者说酒店提供的网络入口中进行尝试，最终发现这个酒店能够把以太网环境的安全措施考虑到并隔离开。我们只能走第二步，这可能就需要物理攻击了，但其实对于酒店这种场景来说，住酒店成本并不高，所以说当进入到酒店房间之后，第一步就是看能不能接触到这些KNX设备并进入KNX网络。

右边的图很明显，我们可以看到这个设备其实攻击者可以接触到的，比如酒店的衣帽间可能会有一个小门，这个小门并没有做太多的防护，轻轻就可以打开。就可以看到一个很完整的很真实的KNX设备摆在面前了，根据这个设备，就能够粗略的根据它的走线猜测这个房间大概KNX设备怎么部署的，另外一个房间应该也是类似的环境。

最后我们还需要接入到这个网络中，我们当时采购了一个KNX设备，再结合笔记本电脑，包括像ETS这些测试工具，通过双绞线接入到网络。之后我们就会开启下一步对网络的踩点，网络踩点过程中，通过传统的扫描、嗅探的方式去发现网络设备，更重要的是IP路由器，它其实是从逻辑上进行跨区域的隔离，如果说能够发现网络环境的IP路由器，那么是有可能通过软件的方式把这个路由打通，实现跨越攻击的。

当结合踩点的信息以拓扑的信息，大家就能够把酒店的网络环境猜测出来，接着进行相应的后续攻击。后续主要是发起攻击，但是有两种情况，第一种情况就是攻击未跨区域的，比如在同一个路由器下的，这种情况下我们就能直接发起攻击了。但是针对跨区域、跨路由器的，我们还需要用重编程修改相关配置。这个是关于我们在KNX智能楼宇这块的安全研究。

3. LPWAN

最后，再介绍一个大家可能觉得非主流或者是没有接触到的，但实际上已经普遍应用在很多场景的通信协议，叫做LPWAN（低功耗广域网）。本次议题介绍的是低功耗广域网其中一种协议，叫LoRaWAN，先科普一下低功耗广域网是什么。刚才提到的ZigBee，KNX等都是需要接电源的，这样它就能够长期上电工作。但是有一种场景，设备使用的频率是没有这么高的，传输数据也没有这么多，比如说智慧停车里的地磁，以及智慧消防，智慧路灯，智慧水电表，它们是通过电池进行供电的，为了适应这种场景，就会有一种在物联网中以低电量进行长距离传输的无线通信网络的存在。

主流通信技术包括了LoRA、NB—IoT以及Sigfox，我们主要是结合云上的应用场景选择了LoRaWAN做研究，虽然说LoRa已经能实现低功耗广域网的通信了，但实际上可以是明文传输也可能是传输编码后的数据，相对来说安全可靠性其实并不高。所以LoRaWAN提出来之后，也可以弥补这块的空白，它其实是基于LoRa物理层协议的通信协议标准，使得整个网络更加安全。

简单来看一下LoRaWAN的网络架构，一般是分三种角色。第一角色是节点，包括刚才提到的很多传感器就属于LoRaWAN节点的范畴，主要作用是传输LoRaWAN数据，最终还是以AES作为安全基础的。第二个是网关，它不做数据解析，仅仅是把LoRaWAN的数据传到核心网，核心网会去负责设备的管理，包括一些解析和数据的展示等等，核心网这块可能是大家在物联网通信关心并不多，或者接触比较少的一点。

针对这种设备形态多，供应链复杂的情况，我们要关注哪些点？我们更加关注的就是代码实现的安全风险。简单看一下LoRaWAN的节点，通常LoRaWAN的节点有两种模式，第一种模式是由右图所示，MCU加射频芯片的低成本方式，MCU会跑应用程序和LoRaWAN协议栈。

左边的图虽然成本可能会高一些，但是会用得比较多，它是MCU外接一个通信模组的形式。MCU是一个真正的应用程序，但是可能复杂的设备还包括实时操作系统。模组里包含着AT处理逻辑以及LoRaWAN协议栈。从这里看就会发现这边其实是有很多可以值得挖掘的点。

应用程序的安全，实时操作系统的安全，模组厂商的安全以及芯片在协议栈等问题。那么有什么办法可以影响更多的设备呢？那就是协议栈。在研究过程中，我们发现LoRaWAN协议栈里存在的一个安全风险，这是个通用的安全漏洞，能够影响许多使用LoRaWAN协议栈的设备。最终可以实现的效果就是设备入网过程中，攻击者可以不需要知道设备密钥就可以发起恶意数据包，最终导致设备掉线、不可用等等。

重点关注一下核心网，像LoRaWAN相对来说比较开放一些，我们能够根据一些开源的核心网去了解究竟这些物联网的核心网到底是怎么样的。我们是选取了一个Chirpstack的核心网，它有一些关键组件，包括网络服务器、应用服务器等等。在核心网的研究过程中，需要知道它主要负责什么功能，包括设备的管理、数据存储以及LoRaWAN的解析。

我们会发现核心网引入了很多WEB安全的攻击面，包括通信安全，HTTP，数据库安全，还有管理后台的安全，我们研究中还发现了很多安全风险，通过网络空间扫描工具，对LoRaWAN核心网进行测试，发现确实存在这样的安全风险。这可能也是之前研究物联网安全时没有考虑到的一个点，从通信角度，核心网也是值得探索的一个关键点。

总结

讲了前面这些例子，更多是想探讨一下我们的研究思路。我们更多是结合供应链的角度以及风险点，然后进行一个非常详细的测试。同时在新基建时代背景下，像5G、LPWAN等新通信技术有了一个很高很广阔的研究前景，值得大家进一步探索。

另外提一些建议，今天来到会场看到小米做这一块确实考虑得比较全面一些，包括安全基建、自动化扫描工具，以及对外的安全赋能，我们希望物联网终端厂商或者云厂商在建立一个项目或者建立一个机制的时候，需要完善物联网安全技术团队和体系，包括安全标准的制定，安全测试以及安全开发流程的引入，从而提升整个物联网方案的安全性和隐私保护能力。

Tencent Blade Team

Tencent Blade Team由腾讯安全平台部成立，专注于人工智能，物联网，移动互联网，云虚拟化，区块链等前沿技术领域的安全研究，目前已向Apple、Amazon、Google、Microsoft、Adobe等诸多国际知名公司报告了200多个安全漏洞，并与之建立了长期友好的合作关系。近两年，团队研究成果登上了BlackHat，DEFCON，CanSecWest，HITB，POC，XCon等顶级安全大会讲台。与此同时，Tencent Blade Team也将研究成果全方位输出到实际业务场景中，与腾讯各大业务团队均建立了紧密的合作关系，致力于提升腾讯产品的安全性、创造更安全的互联网生态。

延展阅读

物联网安全系列之远程破解Google Home