智能家居攻击与防御方法综述

严 寒,彭国军,罗 元,刘思德

1武汉大学 空天信息安全与可信计算教育部重点实验室 武汉 中国 430072

2武汉大学 国家网络安全学院 武汉 中国 430072

1 引言

物联网被人们视作继计算机、互联网之后信息技术产业的第三次革命,在泛在化物联网构建的场景中,人与物之间跨越了时间和空间的约束,被紧紧联接在一起。根据麦卡锡公司[1]的分析估计,到2025年,物联网(the Internet of Things,IoT)每年潜在的经济总影响为3.9万亿至11.1万亿美元,其中,智能家居作为物联网的一大发展方向,经济规模将达到2千亿至3千亿美元。尚在蓬勃发展中的智能家居市场被传统的家居制造企业和新兴的互联网公司视作金矿,各大厂商纷纷研发推出自己的智能家居系统,并向消费者提供配套的智能设备、云平台及移动应用程序,国外厂商如三星的SmartThings[2]、亚马逊的 AWS[3]、苹果的 HomeKit[4]、谷歌的 Weave/Brillo[5]和微软的Azure[6],国内主要有阿里云IoT[7]、华为HiLink[8]和小米MiJia[9]。

在智能家居产业飞速发展的过程中,其安全状态却不容乐观。厂商急于开发出新功能和新产品吸引消费者从而扩大智能家居市场份额,但受到产品上市时间以及研发成本的限制,安全人员无法在开发周期中投入足够多和广泛的安全测试工作。这些产品安全的疏忽加上智能家居潜在的经济效应,吸引了许多黑客组织对智能家居系统进行漏洞挖掘和利用。

针对智能家居系统最常见的有两种攻击场景,一种是黑客利用设备漏洞对设备进行远程控制或者获取智能家居系统中的隐私数据,比如 Nest恒温器在主人不知情的情况下打开了摄像头[10]; 黑客通过飞利浦婴儿摄像头的漏洞可以监控婴儿[11]。除对用户的隐私造成侵犯之外,由于智能家居设备具有对物理世界的操作功能,非法的攻击行为甚至可能对消费者的财产及生命安全带来威胁,比如攻击者可以对智能门锁进行控制操作,从而非法闯入用户的家,窃取物理财产。

另一种是利用设备安全缺陷控制大规模的设备,形成僵尸网络从而发动分布式拒绝服务攻击(Distributed Denial of Service,DDoS),比如2016年席卷全美国的“Mirai僵尸网络[12]”以及后来的效仿者,就利用了供应商留下的后门[14-15]、不安全的应用服务以及许多设备暴露在公网之上的弱点,在设备之间快速传播恶意代码,利用大量的智能家居设备形成的僵尸网络,造成网络瘫痪、设备拒绝服务等严重后果,对社会的经济活动及人们的日常生产生活造成极大的损失。

供应商及安全研究人员已经意识到问题的严重性,采取一系列的措施来保障智能家居的安全,但智能家居安全所面临的最大挑战在“大”“多”“杂”。智能家居终端节点组成的网络巨大、设备数量繁多,因此智能设备每天都会采集大量异质数据交给云平台进行处理; 尽管大多数设备都是基于嵌入式Linux操作系统的,但设备的特定功能造成设备运行的服务、网络协议、硬件配置都有所差异,这些差异使得安全研究人员很难采取统一的安全分析和防护手段来保护智能家居产品。

相较于传统PC及嵌入式设备,智能家居拥有更复杂的应用场景。总体来说,智能家居系统可以分为云平台、通信管道、终端设备以及移动应用程序四个层面。云平台作为整个生态系统的中枢大脑,其主要安全问题包括平台逻辑缺陷、权限粒度过粗、语音识别漏洞、用户隐私保护和设备恢复与诊断; 终端设备是整个系统中最不可信的一端,而固件安全又是设备安全的基石,由此产生了大量针对固件提取以及固件安全启动与更新的攻击和防御手段,此外,设备用于采集数据的传感器也是黑客关注的焦点;在移动应用程序方面,权限、数据存储及编程质量存在着大量安全问题; 作为连接三个端点的管道,通信协议错综复杂,主要有明文传输及中间人攻击两大风险。

需要指出的是,目前国内外的学术界及工业界对智能家居的攻击及防御方法有很多的研究工作,但这些工作较为分散,本文将系统地梳理研究脉络和重点,对研究热点和难点进行整体论述和分析,为学术界和相关从业者提供一定的参考。

本文主要有如下两部分的工作和贡献:

(1) 从智能家居设备、配套的移动应用程序、云平台和相关的通信管道等四个方面,梳理目前针对智能家居系统的攻击技术和防御措施,并针对性地分析安全现状及梳理安全发展历程。

(2) 对与物联网安全和隐私相关的学术研究进行梳理分析,包括近年来学术界的安全研究人员关注的热点话题以及技术难点,主要介绍针对终端设备的自动化漏洞挖掘技术发展情况,以及主流物联网平台面对动态设备威胁时所采用的防御手段,并对现有工作的不足之处进行讨论,提出了在安全最佳实践快速迭代情况下端侧自动化威胁模型系统的设计思路。

本文的组织结构如下: 第 2章结合智能家居应用模型论述智能家居安全现状,包括物联网中常见的漏洞类型及恶意程序; 第 3章分别从应用模型的四个方面进行攻击与防御技术的综述; 第 4章对当前物联网安全领域的热点及技术难点进行讨论,并提出端侧自动化威胁模型的设计思路; 第 5章总结全文并展望。

2 智能家居安全现状

智能家居在高速发展及大规模应用的过程中,频频爆发出影响巨大的安全事件,这也引发了民众对个人隐私数据及资产的担忧。

本节将提出智能家居应用模型,从智能家居与传统互联网和计算机不同的特性出发,对典型的物联网漏洞类型与恶意代码进行总结和分析,阐明智能家居设备的安全现状。

2.1 智能家居应用模型

信息物理系统(Cyber Physical Systems,CPS)和IoT在其解决方案和体系结构中有很多相似性,但具体实现和侧重点有所差异。CPS是一个综合了计算、网络和物理环境的多维复杂系统,用户通过人机交互接口来监督和控制物理环境,操作结果由物理环境反馈给计算机,正如互联网改变了人类彼此交互的方式一样,网络物理系统也将改变我们与周围物理世界的交互方式。IoT与CPS的区别在于CPS不一定连接到互联网(Internet)中,IoT强调设备之间的连接性,而 CPS强调嵌入式部分。智能家居是 IoT的子集,是IoT在家庭领域的具体应用场景,家庭用户和云平台的出现,使得智能家居相较于传统 IoT,时刻面临着新的复杂攻击,例如隐私泄漏和分布式僵尸网络等。因此,智能家居安全需要研究者从不同于以往CPS和IoT安全的角度出发,来发现问题和设计防护方案。本文主要总结和分析智能家居领域的攻击方法和防御措施。

为了以统一的方式管理数量不断增长的各种智能家居设备,许多公司提出了他们的智能家居平台,各个厂商设计的智能家居系统各有差异,但通过对国内外智能设备云平台的研究分析,可以抽象出统一的拓扑结构,如图1所示。

图1 智能家居系统部署拓扑图Figure 1 Topology diagram of smart home system deployment

拓扑图里面包含三个交互的实体: 云平台、智能家居终端设备、移动应用程序,三个端点之间通过Wi-Fi、蓝牙等通信管道传输数据,其中用户对终端设备和 APP有直接的控制权,云平台还会通过 API接口向厂商及第三方伙伴提供服务。各实体功能主要如下:

云平台:云平台是智能家居系统的大脑。它主要承担四个功能,分别是: 设备绑定、设备命令控制、家庭自动化以及开发者管理。首先,设备绑定需要在设备首次部署时建立所有者账户与所有设备之间一一映射的关系,以保证只有合法的授权用户可以对设备进行命令控制; 其次,授权用户向设备发送的控制命令需要通过云平台进行处理和转发; 另外,大多数智能家居系统提供家庭自动化服务,用户可以定义一系列事件规则以完成自动化,比如当接近下班时间时,房间的空调自动打开,用户回到家后无需再等待温度降低的过程; 最后,设备厂商可以通过云平台对设备做统一管理,比如下发固件更新、异常日志处理、大数据态势感知等。

智能家居终端设备:常见的智能家居设备包括:摄像头、路由器、音箱、灯泡、门锁等。以智能音箱为例,其硬件架构如图2所示,设备通常配置了各种传感器从物理世界采集数据,在本地简单格式化之后将数据发送给云平台,并将云平台反馈的信息显示给用户。设备有两种典型的通信管道可以连接到云平台: (a)配有无线网卡的设备可以通过Wi-Fi与云平台直接通信; (b)没有配置Wi-Fi接口的节能型设备,会通过 BLE或 ZigBee等协议连接到移动APP或智能网关,然后网关和移动APP转发连接到云平台。

图2 智能音箱硬件架构Figure 2 The hardware architecture of smart speaker

移动应用程序:移动 APP为家庭用户提供了友好的交互界面,用户可以通过它完成绑定设备、远程管理设备、定义自动化规则等功能。

2.2 智能设备典型漏洞

由于部分智能家居的开发者缺乏安全意识,设备的保护措施非常脆弱而且漏洞频出。如图3所示,本文以通信层关键设备—路由器为例,对通用漏洞披露(Common Vulnerabilities & Exposures,CVE)中的历年漏洞记录数量进行了统计。自2013年智能家居的概念进入路由器行业之后,路由器的漏洞记录数量较往年有明显增长,在最近三年,每年的漏洞数量都突破了120个。智能路由器的快速发展并没有提高设备的安全性,相反导致了漏洞数量的猛增,给使用智能路由器的家庭用户带来了巨大的安全风险。

图3 CVE披露的历年路由器漏洞记录数量Figure 3 Number of router vulnerability records disclosed by CVE in recent years

国家信息安全漏洞共享平台(CNVD)2019上半年公开收录智能设备安全漏洞 1223个[16],与 2018年同期基本持平。这些安全漏洞涉及的漏洞类型主要包括设备信息泄露、权限绕过、远程代码执行、弱口令等; 涉及的设备类型主要包括家用路由器、网络摄像头等。智能家居的漏洞成因复杂多样,通常将智能家居中最常见的漏洞细分为十个类别[18],下文将结合智能家居应用模型、系统特性和利益相关方责任,通过典型的漏洞实例来对这十种漏洞进行总结分析。

(1) 弱密码、可猜测密码或硬编码密码:由于供应商及消费者的安全意识不足,一些设备的远程管理服务的初始凭据安全强度很低,而用户很少修改默认密码,造成许多僵尸网络的感染途径都是使用暴力破解密码或默认出厂密码,通过 SSH/Telnet登录入侵物联网设备,取得设备的控制权,比如“Mirai”僵尸网络。这种凭证配置不当的情况是普遍存在的,Deepak Kumar等人[19]使用由一些弱凭证或默认配置密码组成的小型字典尝试登录 FTP和Telnet服务,从而识别出使用弱/默认凭证进行身份验证的物联网设备,7.1%的IoT设备和14.6%的家用路由器开启了FTP和Telnet服务,其中有17.4%的用户设置了较弱的FTP凭证,有2.1%的用户使用了较弱的 Telnet凭证。最为流行的弱凭证如表1所示,admin/admin是最常见的,分别占了88%和36%。

表1 最流行的FTP和Telnet弱凭证Table 1 The most popular FTP and Telnet weak credentials

(2) 使用不安全或已遭弃用的组件:智能家居设备通常会使用定制的开源操作系统平台以及第三方的软件或硬件组件,由于开源代码更新较快而且源代码公开,而供应商对已经出现的问题的过期组件更新不及时,因此攻击者可以采用低版本的已知漏洞对设备进行攻击,典型的过期组件有busybox、openssl、ssh、Mini_httpd等。2018年Mini_httpd组件被爆出任意文件读取漏洞(CVE-2018-18778[26]),据估测该漏洞影响全球两百多万台设备; 2020年,轻量级TCP/IP软件库被披露出19个0 day漏洞(Ripple 20[27]),可能导致不同行业的数十亿 IoT设备面临着远程攻击的风险。

(3) 不安全的网络服务:设备运行的网络服务多样,比如UPnP[20]、Telnet、Samba[21],但供应商在实现这些服务类型时很少完全遵循协议和安全编程规范,将端口暴露在互联网上,很容易遭到 DoS或远程代码执行攻击,对设备的安全性造成威胁,如运行在华为HG532 系列路由器[22]上的UPnP服务出现命令执行漏洞(CVE-2017-17215); 为IoT设备提供文件共享服务的Samba被爆出Linux版“永恒之蓝[23]”攻击(CVE-2017-7494)。

嵌入式设备中大多使用轻量级的MiniUPnP库来实现 UPnP协议,自 2013年开始,共披露出 20条漏洞条目,本文统计其漏洞类别分布如图4所示,从分布情况可以看出,缓冲区错误及空指针解引用问题是物联网二进制程序中比较典型的两大代码缺陷。

图4 MiniUPnP漏洞类别分布Figure 4 MiniUPnP vulnerability category distribution

(4) 隐私保护不充分:与其他网络设备相比,智能家居设备配置了大量传感器采集用户的生物信息、监测和记录周围环境信息和用户活动情况,消费者和智能家居之间的亲密关系导致在设备或云平台中存储着用户的大量个人信息,一旦被不安全的、不当的或未经授权的使用,会对用户的隐私造成危害,比如窃取私人照片、泄露用户位置、窃听用户输入,典型攻击案例如表2所示。

表2 隐私保护典型案例Table 2 Typical case of privacy protection

(5) 不安全的生态接口:智能家居系统使用Web、云端或移动接口供各个组件之间交互,攻击者通常会在智能设备的 Web接口中寻找 XSS、CSRF和 SQLi等漏洞,以及在云和移动 APP接口中寻找“弱密码”“信息泄露”“缺乏双因子认证”和“无账户锁定机制”等问题。亚马逊的Ring Video Doorbell Pro使用了不安全的配网模式,如图5所示[24],附近的攻击者通过无线嗅探或监听可以截获网络凭证,从而进入局域网发起进一步的攻击。

图5 亚马逊门锁配网模式下信息泄露Figure 5 Information leakage in Amazon door lock under distribution network mode

(6) 缺乏安全的更新机制:固件安全是设备安全的基石。受到资源的限制,许多基于密码学的安全功能难以直接应用到智能家居领域,如基于数字签名的安全升级。2017年D-Link DIR8xx系列路由器被发现升级逻辑不当[25],设备没有对固件更新进行相应的完整性和合法性校验,攻击者可以向设备安装任意官方版本或自定义的固件,从而接管设备的控制权。我们对 CVE记录的相关漏洞进行了统计,结果显示针对固件更新的攻击在 2018年达到了峰值,而且到目前为止依然有厂商采取不安全的更新机制。

图6 CVE披露的固件更新漏洞历年记录数量Figure 6 Number of firmware update vulnerabilities disclosed by CVE in recent years

(7) 不安全的数据传输和存储:智能家居系统各个组件存储着用户的敏感数据,并通过各种通信管道传输各自的数据内容。Gartner 报告显示[31],物联网市场依然保持着 3A格局(亚马逊、微软、阿里云),其中阿里云借助中国广大的市场以及在云服务上的技术优势,向工业、医疗、交通、城市、航空等领域提供了百亿级 IoT设备的连接能力和上万个行业解决方案,因此本文对阿里云物联网平台上设备数据在各个组件间的流转途径进行了总结,如图7所示。由于计算资源和存储资源的限制,许多智能家居设备都没有检查服务端的证书甚至不对通信过程加密,复杂的加密和认证算法会占用过多的计算资源,降低设备的性能,影响设备的正常运行,对于实时设备是不可忍受的。如果敏感数据内容明文传输或没有以正确的方式进行加密保护,攻击者常常会对其进行中间人攻击,从而获取传输内容,比如Philips婴儿监控摄像头没有提供防止攻击者窃听的加密视频流[11]。

图7 阿里云IoT平台数据流转图Figure 7 Data flow diagram of Aliyun IoT platform

(8) 缺乏设备管理:智能家居设备地理分布位置广泛,供应商对已经投入市场的智能家居设备缺乏安全支持,比如资产管理、更新管理、安全解除、系统监控和响应能力,一旦设备出现故障或漏洞,管理人员无法对错误进行排查、分析和处理。

(9) 不安全的默认配置:供应商虽然提供了安全的机制,但默认配置为不安全的策略。用户的安全意识通常是薄弱的,导致安全机制无法充分地发挥作用,比如谷歌提供的双因素验证可以消除密码泄露带来的撞库风险,但用户对这项安全机制一无所知,因此黑客利用其他网站上的密码泄露,入侵并控制了谷歌的智能家居设备 Smart Nest Thermostat[10]。

(10) 缺乏物理加固措施:智能设备的硬件设计远没有计算机和智能手机复杂,这大大降低攻击者通过硬件分析发起攻击的难度。电路板上暴露其MCU、外部存储器等信息,攻击者拆开设备之后通过查询datasheet就可以掌握设备的硬件情况。之后,通过JTAG调试接口或UART等串口,攻击者还可以对固件内容进行相应的读写操作。此外,还可以通过硬件攻击绕过软件保护,比如 Nest恒温器硬件基础设施缺乏合适的保护[32],攻击者可以通过改变设备引导过程绕过固件更新校验。

智能家居系统有着区别于其他联网设备的独特属性。智能家居设备类别繁多、功能各异、交互复杂,催生出了许多攻击面,再加上智能设备硬件设计简单,且存储和计算资源无法支撑传统安全的一些防御措施,导致智能家居相对于传统平台上的产品更容易被攻击者入侵,由于智能设备通常与家庭物理环境紧密联系,通过传感器采集信息并利用执行器(如加热器、加湿器)影响物理环境,智能家居的安全性问题往往会造成严重后果。这些特性为智能家居系统带来了潜在的威胁和漏洞,表3将智能家居中常见的漏洞类型与其相关的特性联系起来,结合2.1节对智能家居应用模型的讨论,确定了其影响的系统层面,并归属了利益相关方的责任,其中考虑到移动应用安全规范与生态已经较为独立与成熟,本文将“端”安全分离为终端设备安全以及移动应用程序安全。

表3 智能家居漏洞类型及其涉及的特性、系统层面和利益相关方责任Table 3 The features,system level and stakeholder responsibilities of each smart home vulnerabilities

2.3 恶意代码攻击威胁

在互联网时代,计算机是恶意病毒、蠕虫入侵的主要对象[33]。随着物联网的发展,智能设备走进千家万户,黑客逐渐把入侵的对象从主机转向安全性更低的智能设备。这些恶意程序的感染途径一般是通过软件漏洞利用以及暴力破解凭证来入侵和远程控制设备。设备被黑客入侵控制后,通常会成为僵尸网络的一员,被用来执行DDoS攻击或其他恶意行为。2019 年,CNCERT 捕获智能设备恶意程序样本约324.1 万个[34],其中 Mirai 家族和 Gafgyt家族的恶意样本就占据了86.1%,被控制的智能设备平均每天会对1528个目标主机发起DDoS攻击。根据卡巴斯基安全报告[35],攻击者在破解路由器telnet密码之后使用最多的十种恶意软件如表4所示。

表4 黑客入侵路由器最常使用的十种恶意软件Table 4 The ten most commonly used malware to attack routers

Mirai家族的恶意代码构建的僵尸网络至今已参与了多次的大型分布式拒绝服务攻击(DDoS),最早也是最受关注的攻击是在2016年9月,相继出现了针对计算机安全撰稿人Krebs个人网站、法国网站托管商OVH以及Dyn公司的网络攻击事件。针对Krebs的初始攻击流量达到了 600 Gbps,这是当时有记录以来最大的一次攻击,而这种压倒性的流量就是由数十万个受控物联网设备组成的僵尸网络产生的。

2016年9月30日,Mirai的源代码在hackforums.net[37]上公开发布,研究人员依靠此代码对 Mirai的结构和传播方式进行分析[12-13,36],如图8所示:

图8 Mirai传播流程[36]Figure 8 Mirai propagation process[36]

√ Mirai首先会进入快速扫描阶段,在该阶段它使用TCP SYN探针扫描设备的Telnet端口;

√ 如果扫描到这两个端口,Mirai将尝试使用预置的凭证字典暴力登录Telnet端口;

√ 首次登录成功后,Mirai会将受害者的IP和相关凭据发送到报告服务器;

√ 之后下载程序将根据受害设备的底层系统环境(MIPS、ARM,x86 等架构)下载相应的恶意代码;

√ 成功感染后,Mirai会通过删除已下载的恶意代码并使用随机字母数字混淆恶意进程名来隐藏其存在,并杀死绑定到TCP/22或TCP/23以及其他竞争性的进程,从而获得设备的独占权;

√ 此时,指挥与控制服务器就可以向受控设备下发攻击命令,同时扫描新的受害设备。

Mirai的出现标志着DDoS攻击活动已经进入一个新的时代——越来越多的物联网设备将成为僵尸网络的目标。

Gafgyt[39]是众多僵尸网络家族中最活跃的一族,2014年,黑客组织Lizard Squad使用Gafgyt家族相继对索尼PSN及微软Xbox Live发起DDoS攻击。2015年1月,Gafgyt的源代码被公开,随后许多变种开始出现(如BASHLITE,Lizkebab,Torlus和Qbot)。

仅到2016年,已经有100万台IoT设备被该恶意软件入侵[38]: 在受感染的100万台终端设备中,有将近95%是摄像机和DVR,大约4%是家用路由器,不到1%是受感染的Linux服务器。由此可见,与过去发现的基于服务器的 DDoS僵尸网络相比,僵尸网络的构成发生了急剧变化。

3 智能家居设备攻击与防御技术

根据智能家居应用模型及攻击向量模型,本章将从三个攻击维度(云、管、端)来讨论针对智能家居系统的攻击方法及防御措施。

3.1 云安全

本节统计了近五年来安全领域顶级会议上有关于物联网平台安全的相关研究,并根据其涉及的研究角度对云平台攻击与防御方法进行总结,如表5所示,具体描述如下:

表5 云平台层面攻击与防御方法总结Table 5 Literature summary of attack and defense methods at the cloud platform level

3.1.1 平台逻辑缺陷

随着智能家居系统的应用场景越来越多样,云管端之间的交互变得越来越复杂,这些依赖关系为平台带来丰富功能的同时也引入了新的攻击面,自动化规则漏洞和实体状态转换不当是最具代表性的逻辑缺陷。

1) 自动化规则漏洞:诸如 IFTTT[41],automate.io[42]和 CloudWork[43]一类的云平台承担了家庭自动化的任务,随着设备的种类及规则的复杂度逐渐增加,Wang等[44]指出自动化规则与规则之间的漏洞有可能被攻击者利用,如条件绕过、条件阻塞、动作恢复、动作冲突、动作循环和动作重复。

缓解措施:对于Trigger-Action平台中的规则间漏洞,Wang等[44]进行了分析和概括,并开发可以检查自动化规则中易受攻击属性的 iRuler,其架构和工作流程如图9所示,iRuler使用规则解析器从移动应用程序中提取触发规则并将其转换为规则表示,模型构建器从规则表示、用户部署配置和设备元数据三者获得中间表示,最后检查引擎对中间表示进行规则漏洞的扫描。iRuler结合了可满足性模理论(Satisfiability Modulo Theories,SMT)和模型检查的功能,为IoT系统建模并检查易受攻击的属性,另外还使用自然语言处理(Natural Language Processing,NLP)进行辅助,用于推断专有触发动作平台中规则之间的不足信息。受限制于真实规则需要大量物理设备支持,iRuler采用人工编写规则的方式来降低成本,因此与真实情况存在一些误差,而且由于Trigger-Action平台内部的规则通常是封闭的,并由各种第三方开发,iRuler的通用性还有待提高。

图9 iRuler的架构和工作流程Figure 9 The architecture and worklow of iRuler

2) 实体状态转换不当:Zhou等[40]对 Alink、Joylink、KASA、SmartThings以及MiJia等5个广泛使用的智能家居平台进行了深入研究,结合固件分析、网络流量拦截和黑盒测试,对参与实体(即设备,云平台和移动应用)之间的交互细节进行了逆向工程,并重点研究了这三个实体在状态转换中的漏洞,发现了5种设计缺陷,如图10所示。由于大多数物联网平台允许设备在用户未授权的前提下登录和解绑,攻击者在获得设备证书的情况下不仅可以伪装成真实设备接收用户指令,甚至能够远程控制受害者的真实设备,这个风险主要存在于二手交易场景中。

图10 实体间非法状态转换图Figure 10 Illegal state transition diagram between entities

缓解措施:针对实体交互中容易出现的问题,Zhou等[40]提出要在实体交互过程中进行严格的设备认证、全面的授权检查以及有效的强化状态转换。有意思的是,单独采用缓解措施中的某个子集是不够的,因为交互中的缺陷是多方面共同造成的。

3.1.2 权限粒度过粗

针对平台权限控制,安全人员需要从两个层面考虑: 一是正常权限使用者在用户不知情的情况下滥用被赋予的权限,如任意访问用户敏感数据; 二是攻击者滥用通过远程劫持等途径获得的高级别权限,如OAuth令牌泄露。

1) 敏感数据使用不当:设备上的恶意应用程序有可能滥用用户给予的权限并泄漏数据,Fernandes等[47]设计了安全模型FlowFence,它要求敏感数据的使用者明确声明预期的数据流而且强制执行声明的流,从而有效地阻止其他非法流。

对于当前物联网平台许可模式中的设计缺陷,Jia等[48]提出了一种适用于IoT平台的基于上下文的全新访问控制模型 ContexIoT,提供对敏感操作的细粒度上下文识别,并通过具有丰富上下文信息的运行时提示来提供上下文完整性,以帮助用户执行有效的访问控制。与 FlowFence不同,ContexIoT不需要额外的开发人员工作而且满足向后兼容的需求。

2) OAuth令牌滥用:Trigger-Action平台通过OAuth令牌连接多个设备和服务以执行用户创建的自动化动作,因此攻击者一旦掌握了OAuth令牌,就可以远程操控平台上任意用户的设备[45]。虽然供应商在设计和测试云平台时下了很大工夫,但Yang的报告显示[46],在使用OAuth的前600个Android移动应用程序中,有41%容易受到远程劫持的影响。

缓解措施:为了解决攻击者滥用 OAuth令牌的问题,Fernandes等[45]引入了采用分散式操作完整性(Decentralized Action Integrity)的去中心化触发动作平台(Decentralized Trigger-Action Platform,DTAP),作为对OAuth协议的扩展。

3.1.3 语音识别漏洞

虚拟个人助理(Virtual Personal Assistant,VPA)平台提供的语音识别功能除了对说话者的语音内容识别之外,还包括对说话者身份的识别,这两种新颖的功能给使用 VPA的智能家居带来了严重的安全问题。

1) 语音内容识别:如图11 VPA平台架构所示,VPA生态系统允许第三方人员在平台上发布类似于应用程序的技能,与传统智能手机平台上的 APP不同,VPA的大多数逻辑发生在服务器上,设备端只负责处理语音识别、录音、播放和一些基本配置。智能音箱通过准确识别说话人的语音命令来执行相应的指令操作,但Kumar等人[49]发现为Amazon Echo系列设备提供支持的语音识别引擎Amazon Alexa并不能对语音命令执行绝对正确的解释,攻击者可以通过技能抢注攻击(Skill Squatting Attack)将用户的语音命令解释为恶意应用程序。鉴于攻击者巧妙地利用一些常见的口语错误,Zhang等[50]设计了第一个语言模型指导的模糊测试工具 LipFuzzer,用来大规模评估意图分类器的安全性,系统地发现潜在的易于误解的口语错误,但贝叶斯网络非常依赖于数据集的规模和质量,因此LipFuzzer的训练模型还可以进一步改进。Zhang等[51]发现VPA不仅会因为发音而曲解语音命令,还会因为缀词的使用导致语音抢注攻击(Voice Squatting Attack),另外攻击者可以利用语音伪装攻击(Voice Masquerading Attack)在技能切换或技能终止时继续维持当前技能的控制权,恶意的技能只会假装转交控制权给其他技能,并继续收集用户的私密信息。

图11 VPA平台架构[58]Figure 11 The architecture of VPA platforms[58]

缓解措施:为了解决Squatting Attack带来的问题,Kumar等人[49]和Zhang等人[51]提出基于单词和基于音素的对新技能调用名称的分析,避免出现发音相似的技能,同时训练一个检测器对用户意图进行判断以避免出现Masquerading Attack。

2) 声纹识别:除了对语音命令内容识别,一些智能语音助手还可以支持对说话者身份识别[52],但用户的声音却有可能成为黑客的通行证,Jia等人[53]基于神经网络设计了语音合成系统,可以模仿说话者的语音命令,绕过 VPA的认证。但这个语音合成系统生成的语音水平强烈依赖于语音数据集的数量及质量且对重音的转换效果不佳。

与 Jia设计的欺骗攻击(Spoofing Attack)不同,Chen等人[55]首次提出了针对声纹识别系统的黑盒对抗攻击FAKEBOB,对抗攻击相对于欺骗攻击的优势在于其攻击的隐蔽性更高,它的主要设计思路是在一段语音上加入人耳无法识别的扰动音频,从而生成对抗语音。FAKEBOB在开源和商业声纹识别系统上达到了 99%的攻击成功率,而且现有的四种防御手段(局部平滑、量化、音频压缩和时间依赖性检测)对FAKEBOB的缓解效果有限。

3.1.4 用户隐私泄露

智能家居与家庭用户的亲密关系导致智能设备能够接触并收集到消费者的隐私信息,除了对通用隐私保护的安全研究之外,近些年来智能音箱上Skill的流行也对隐私安全造成了新的威胁,研究人员对此也进行了深入研究。

1) 通用隐私保护:对于智能家居设备收集的用户隐私数据,部分组织和政府推动了数据保护法规的产生,但由于家庭用户缺乏足够的隐私意识,供应商也没有提供透明且方便的隐私安全配置选项,这些指导方针很难被广泛地采纳。

缓解措施:Bastys等[65]利用访问控制和信息流控制来保护用户隐私,并开发了一个框架来检测攻击者控制的URL泄漏隐私数据。Apthorpe等[57]采用基于上下文完整性理论的调查方法,可量化地测试这些法规所规定的条款是否确实符合目标人群预期的隐私规范。Pardis等[63]采用三轮德尔菲法与22位隐私与安全专家进行意见咨询,从而向物联网消费者提供隐私安全判断上的参考。

2) Skill与隐私泄露:3.1.3 集中总结了从语音、声学接口方面针对VPA设备技能的安全研究,除此之外,与Android生态系统中恶意应用频繁窃取用户隐私信息类似,由于 Skill认证过程和发布审核政策存在缺陷,VPA平台还存在这些问题: 过度的资源访问特权[56]—通过在技能描述中提供合理的借口,绕过权限审查; 隐蔽的后端代码更新[58,62]—Skill(技能)的后端代码运行在开发人员的服务器上,代码在认证发布之后可以随意更新; 任意的内容篡改[56]—攻击者向新闻技能链接的网站添加不当内容。

Cheng等人[58]对两个领先的VPA平台(Alexa和谷歌)的内容及隐私策略进行了深入研究,提交了234个Alexa技能(Skills)和381个谷歌动作(Actions),这些操作均故意违反了VPA平台所声明的特定隐私政策,但结果所有Alexa Skills和39%的谷歌Actions可以通过认证,这表明 VPA平台在认证过程中并没有严格执行安全审核策略。

缓解措施:为了帮助VPA平台提供商增强其技能认证过程的可信性,Cheng等人[58]提出了一系列可行的缓解措施,包括: 培训认证团队; 在技能认证过程中深入检查; 自动化技能测试工具检测违反策略的技能; 在技能生命周期中加强技能行为的完整性以缓解VPA后端代码更新漏洞。

从上面相关研究内容来看,保护用户隐私简单来说需要从以下3方面考虑:

√ 用户需要了解设备的功能[59]以及这些功能如何影响隐私安全,并且在使用智能家居前对可能出现的隐私安全风险充分了解。

√ 包括隐私监管机构、政府、消费者组织在内的第三方需要通过发布隐私指导及法规[60-61],来帮助用户建立对最低隐私及安全措施的共识,同时引导供应商在产品的整个生命周期充分考虑隐私安全问题。

√ 供应商应当向用户提供透明、方便的隐私说明及选项,为消费者提供直观可靠的隐私提示,参与制定并遵循第三方的安全指导,贯彻数据/权限最小化原则。

3.1.5 设备诊断恢复

由于智能家居设备之间通过自动化规则联动,并与家庭物理环境紧密结合,由攻击或设备故障带来的设备异常会造成严重后果,因此在设备遭受攻击破坏之后,及时对设备进行诊断和恢复越来越被安全人员所重视。

1) 设备诊断:为了能够快速定位某个设备被攻击或者配置错误的原因,ProvThings[66]以平台为中心,对移动APP和设备API执行有效的自动化检测,通过日志审计实现攻击调查和系统诊断。以往利用数据挖掘技术检测异常的工作存在很高的误报率和漏报率,HAWatcher[67]从智能应用程序的执行、物理交互及用户活动三个通道收集语义并相互关联,提升了设备异常检测和诊断的效果,但 HAWatcher只能挖掘短时间内前后事件的相关性,无法对长时间间隔的事件进行关联。

2) 设备恢复:为了可以在短时间内恢复攻击者控制的设备,Xu等[68]为设备管理者引入了恢复系统CIDER,管理员根据识别出的漏洞指示CIDER强制设备重置以清除攻击者根植在文件系统的后门,并在设备上安装修补的固件。由于重置系统不会触及到 bootloader,因此 CIDER没办法恢复受损的bootloader(如 bootkit攻击)。

3.2 管安全

智能家居系统三大实体组件之间依靠各种通信协议交换命令和消息数据,大致可以分为互联网协议(IP)和低功耗协议(LE)。表6给出了本文总结的针对这两大类通信协议的常见攻击及防御手段,具体描述如下:

3.2.1 互联网协议安全

基于IP协议的应用层协议可分为DNS、HTTP、UPnP、MQTT(消息队列遥测传输)、CoAP(受限应用协议)和私有协议。IP协议为设备和移动端与云提供直接通信的服务,并依靠TCP和TLS/SSL协议保证安全性。

1) 数据协议安全:MQTT和CoAP等数据协议已在IoT部署的Machine-to-Machine/Man(M2M)通信中得到广泛使用,但安全性和隐私风险值得关注。Maggi等[69]在白皮书中表示,暴露的MQTT和CoAP主机以及错误配置的系统可能会将凭据、敏感信息和与行业相关的过程数据泄露给潜在攻击者,此外目前已经出现的漏洞甚至可能使攻击者获得对设备的远程控制或使其处于DoS状态。

由于 MQTT协议的固有缺陷或不当使用,主流的 IoT云平台与设备通信消息协议的安全性很容易受到攻击,Jia等[70-71]在对MQTT协议分析过程中发现存在四种攻击方式: 未经授权的 MQTT消息(Unauthorized MQTT Messages)、管理MQTT会话的错误(Faults in Managing MQTT Sessions)、未经验证的 MQTT身份标识(Unauthenticated MQTT Identities)、MQTT主题的授权之秘(Authorization Mystery of MQTT Topics),利用这些漏洞进行攻击会造成严重后果。

缓解措施:针对这些漏洞,Jia等[70]提出依照保护协议实体的设计原则以及采用增强的访问控制模型来强化MQTT的安全性。

2) 基于HTTP的协议安全:Samue等人[72]揭示了攻击者利用像 HTTP这样的不安全协议在系统软件更新过程中进行中间人攻击的可能。UPnP等协议基于HTTP构建,因此不可避免地继承了HTTP的许多缺陷。2006年,Armijn Hemel[73]对互联网网关设备协议(IGD)的研究表明UPnP容易受到各种攻击—内网计算机可能会暴露于外部网络; 2011年,Daniel Garcia[74]在DEFCON 19上发布了一个工具集,使得攻击者可以轻易利用Hemel发现的漏洞,通过WAN接口将NAT规则注入到远程设备中; 2013年,Rapid 7[75]在Internet上发现了8000万个易受攻击的UPnP设备,包括来自 1500多家供应商的数千种型号,未经身份验证和未加密的应用层协议等问题使攻击者能够大规模利用设备,从而导致其他攻击,如分布式拒绝服务攻击(DDoS)。

传输层安全性协议(TLS)及其前身安全套接层(SSL)可以为应用层的协议提供机密性和完整性的保障,但TLS/SSL也并非绝对安全。 2011年,研究人员[76]发布了名为BEAST(针对SSL / TLS的浏览器攻击)攻击的 POC,该攻击使中间人攻击者能够从加密的SSL / TLS 1.0会话中发现信息。2012年,CRIME攻击[77]利用 TLS 1.2及更早版本在加密压缩数据时没有适当混淆未加密数据长度的漏洞,攻击者可以通过观察长度差异来猜测注入内容是否匹配,从而挖掘私密内容。2013年,AlFardan等人[78]提出Lucky Thirteen攻击,在MAC验证中使用格式错误的数据包来推断时间延迟,以从密文中统计推断明文。2014年10月,Google安全团队披露了针对SSL 3.0的降级漏洞 POODLE[79],可以让攻击者破解小段的加密数据。此外,Bleichenbacher[81]攻击和DROWN[82]攻击进一步利用加密填充的问题说明了实现安全通信协议的困难。由于许多IoT通信都支持TLS / SSL协议的较早版本,因此容易受到中间人(Man-in-themiddle,MITM)攻击。

缓解措施:对于基于HTTP的协议,应使用TLS/ SSL来增加完整性和机密性。虽然TLS/SSL并不是绝对的安全,但只要供应商在服务端及客户端部署最新的版本并正确配置,就可以抵挡绝大部分攻击。

3) DNS与隐私保护:DNS服务使用递归查询请求的方法来完成 IP地址与域名地址的转换,为Internet的正常运作提供关键性的基础服务。Kintis等人[83]发现 EDNS客户端子网(edns-client-subnet,ECS)破坏了DNS通信的私密性: 在ECS下,开放递归DNS会将部分隐私提供给上层机构。

缓解措施:禁用DNS中的ECS功能可以帮助用户保护隐私安全。

3.2.2 低功耗协议安全

低功耗协议主要有Zigbee、Z-Wave和Bluetooth-LE(BLE),支持低功耗设备与家庭网关(Hub)和移动APP之间的通信。

1) 蓝牙协议安全:蓝牙低功耗(Bluetooth Low Energy,BLE)是蓝牙 4.0规范的一部份。总体而言,BLE作为一种通信协议,面临的主要攻击手段可以分为监听攻击和中间人攻击,针对这两种攻击方法,BLE使用通信加密及身份认证这两个安全机制进行防御。

Ryan[84]公开存在于BLE4.0及4.1版本中蓝牙密钥交换协议的一个严重缺陷,这使得 BLE通信容易受到攻击者窃听。Bluthooth SIG在4.2版本[85]中引入LE安全连接对该漏洞进行再修补,加上规范本身复杂性高,增加了破解临时密钥(Temporary Key,TK)的难度。尽管4.2版本引入了许多确保安全要求的流程,但制造商和销售商仍具有选择安全级别的能力,从而可能导致各种安全事故[86]。对于蓝牙协议来说,MiTM 攻击是一个严重的安全问题,Sun等[88]和Sivakumaran等[87]针对最新版本 BLE的密钥登录配对协议进行MITM攻击; Jasek[89]开源了针对BLE的MITM 工具—gattacker,可以对未实现蓝牙安全功能(配对)的设备发起拒绝服务、欺骗、数据拦截、控制设备等攻击; Zegeye[90]对绑定阶段的长期密钥(Long Term Key,LTK)进行暴力破解攻击。

BLE协议中使用UUID来唯一标识特定BLE属性(服务、特征、描述符),从而可以建立起应用与设备之间的关系,Zuo等人[116]开发了 BLESCOPE对18166个使用了BLE的应用进行分析,发现有11141(61.3%) 采用“直接连接(Just Works)”配对,在没有对应用做认证的情况下,攻击者可以随意连接到这些设备,此外,很多 BLE设备采用了静态的 UUID,攻击者可以通过嗅探UUID来对BLE设备进行指纹识别。

缓解措施:低版本的LE协议普遍存在严重缺陷且攻击工具易得,缓解方案有限,开发者应当禁用协议中不安全的部分并保持更新。遵循BLE 4.2的供应商和制造商应采用安全模式1级别4,而遵循BLE 4.0和BLE 4.1的供应商和制造商应采用安全模式1级别3[110]。

2) ZigBee安全:ZigBee技术为物联网环境中的通信提供高效且安全的短距离通信,并尽可能降低功耗。

ZigBee设备使用帧计数器对抗重放攻击,但一些攻击者使用特定的软件和硬件设备绕过这一防御措施。比如AVR RZ Raven USB[91]可以用作ZigBee的终端节点,以嗅探并捕获网络流量,并从中获得网络密钥。除使用硬件设备,Wright还使用python开发了Killerbee[92]用于捕获和分析ZigBee流量。DoS是针对 ZigBee的另一种常见攻击,它可以损耗低功耗设备的电池寿命,Vidgren等人[91]从理论上提出,攻击者可以伪装成路由器或信任中心(Trust Center,TC)连续发送请求消息到终端节点,设备必须不断响应请求,从而对电池造成损伤。ZigBee的协议设计也存在一些问题,Zillner等[118]指出ZigBee联盟定义的默认信任中心链接密钥在所有设备上是相同的,这让设备劫持攻击成为可能。

缓解措施:ZigBee提供了选择各种安全模型的功能[93],供应商应采用基于 TC的集中式安全模型,它被认为是最充分的安全流程。同时供应商应从ZigBee提供的两个安全级别(高安全性和标准安全性)中选择高安全性的。

3) Z-Wave安全:Z-Wave将安全性机制分为两个主要类别: 安全性 0(S0)和安全性 2(S2)。其中Curve25519模型被认为是S2类密钥交换过程最安全的选择,但Genkin等人[94]最近却对这个模型进行了侧信道攻击。到目前为止,并未出现针对Z-Wave的通用性攻击方法,但由于供应商或用户对Z-Wave协议的不当设置或使用,出现了一些针对特定实现的利用。比如在Z-Wave与可能不包含足够安全机制的传统设备进行通信时,攻击者可以采用重放攻击;供应商不一定会采取Z-Wave提供的AES-128加密,Hall等人[95]测试了 33个 Z-Wave设备,发现只有 9个支持使用加密,并推出一个称为EZ-Wave的工具,可以帮助攻击者执行各种对Z-Wave的渗透测试。

缓解措施:选择使用Z-Wave的设备应当选择安全性更高且支持OTA的Z-Wave Plus[110]。

4) 侧信道攻击:正确地采用加密措施能够保护通信管道免受监听攻击及中间人攻击的威胁,但一些研究人员发现事件及加密流量之间的因果关系可以用来推断智能家居中的敏感信息。PingPong[97]可以从网络流量中自动提取设备事件(例如打开/关闭灯泡)的数据包级签名特征,攻击者可以用它来发起被动推断攻击、异常检测等。Zhang等[98]提供了一种基于侧信道的设备行为推断技术—HoMonit,它从APP源代码或UI交互界面提取出设备意图,与从加密的无线通信信道(ZigBee和 Z-wave)推断出的设备状态进行比对,从而发现设备的异常状态。侧信道信息泄露是一把双刃剑,HoMonit的初衷是检测行为不当的 APP,但攻击者利用这种技术也可以发起侧信道推理攻击从而获取用户的隐私信息。由于HoMonit从数据包的大小和时序信息中捕获流量指纹,因此其精度很容易受到非标准化无线流量模式的影响。此外,Luo等[99]提出一个名为ALTA的应用程序级隐私泄露分析方法,利用程序分析提取触发规则从而构建应用程序的指纹特征,并结合从 APP描述及输入提示中处理得到的敏感信息,最后通过运行时动态流量分析来推断用户正在运行的应用。

缓解措施:针对这类攻击手段,Apthorpe等[100]提出使用流量整形保护消费者免受侧信道流量监听的威胁。

3.3 端安全-设备

终端设备承载了从物理世界采集、简单处理数据,并根据处理结果通过执行器影响物理环境的功能。本文对终端设备攻击手段进行了总结归纳,如表7所示,常见的端侧攻击角度有固件启动、固件更新、设备传感器、过期组件。

表7 终端设备攻击与防御方法总结Table 7 Literature summary of terminal equipment attack and defense methods

3.3.1 固件提取

固件安全是设备安全的基石,提取固件通常是攻击者的首要任务,表8给出了本文总结的固件提取的8种常用方法。

表8 固件提取常用方法总结Table 8 Summary of common methods for firmware extraction

Clinton等人[101]展示了从UART、JTAG等硬件引脚直接访问Echo文件系统的难点,Barnes[102]在此基础上结合设备暴露的调试接口以及硬件配置不当(允许设备从外部SD卡启动),成功获取设备shell并远程监听用户。随着某些供应商混淆或删除JTAG接口以保护其知识产权,与Flash存储器直接进行交互变得非常有用(如腾讯blade team通过这种方法提取Amazon Echo 固件[103])。

3.3.2 过期组件

在成功提取出固件之后,攻击者通常会对固件进行解包,然后静态逆向分析二进制程序。Costin等人[105]完成了固件映像的首次公开大规模分析,将32000个固件映像解压缩为170万个单独的文件,然后对其进行静态分析,发现了一系列漏洞。值得注意的是,攻击者挖掘出一个0 day付出的成本是很高的,Feng等[111]的研究揭示了近年来IoT攻击普遍存在的一个被忽视的原因: IoT漏洞是公开可用且易于利用的,而今天的IoT攻击几乎都是使用已知漏洞来发动恶意攻击。

缓解措施:及时修补漏洞对于提升设备安全性有很大帮助。供应商可以通过空中下载技术(Over the Air,OTA)来修补不安全的服务和过期的组件等缺陷。

3.3.3 固件安全启动

Jeong[112]提出使用 FTDI FT2232H 芯片组进行Bit-banging,实现对 NAND flash固件内容的读写,同时,考虑到ECC、坏块和JFFS2擦除标记等问题,他编写了自动化修改和重建固件镜像的程序。具备了重构固件的能力,攻击者就可以通过自定义Bootloader、内核或文件系统植入恶意代码从而持久化攻击,目前很多厂商针对后面两者的攻击采取了一些缓解措施,如重置按钮、内核映像校验和写入保护。YANG等人[104]实现了名为UbootKit的蠕虫攻击,该蠕虫针对IoT设备的引导加载程序,可以在不同的设备之间传播,并以root权限控制设备。

缓解措施:与软件漏洞可通过 OTA修补不同,对于一些底层的漏洞或固有的设计缺陷,需要在产品设计之初采用安全的框架,例如要实现固件的安全启动,供应商需要在片上代码中添加了完整性验证程序。

3.3.4 固件安全更新

UbootKit攻击能够成功发起,是因为大多数物联网设备都缺少对 Bootloader的完整性验证,但UbootKit在感染第一个僵尸设备时,依然需要攻击者拆开设备从而暴力刷写Flash中的固件,攻击途径较苛刻。不过一些智能设备缺少安全的固件更新机制,攻击者可以通过合法的固件升级接口上传自定义固件,例如 Nest Thermostat固件引导过程存在后门[30],攻击者可以通过 USB上传恶意固件,绕过设备对固件签名的验证; Philips Hue智能灯对固件更新进行加密和签名,但 Ronen等人[106]的研究显示,Philips Hue在灯泡之间重用对称加密和签名密钥,攻击者能够通过边信道攻击提取主加密密钥,并将其与通信协议中发现的漏洞结合在一起,从而上传恶意的OTA更新以感染灯泡。

3.3.5 设备传感器攻击

在智能音箱设备中,语音识别(SR)系统已经成为一种越来越流行的人机交互方法,Zhang等人[107]设计了一个人类无法听见(频率> 20 kHz)的海豚音攻击(DolphinAttack)。如图12所示,攻击者调制出超声载波上的语音命令,音频信号通过麦克风电路的非线性特性可以成功地解调,恢复调制前的低频音频命令,语音识别系统对命令进行解释执行,其中超声波只能发射5英尺的距离。

图12 “海豚音攻击”原理图Figure 12 Schematic diagram of “DolphinAttack”

意识到攻击范围的限制,Roy等[108]通过聚集来自扬声器阵列的超声信号将攻击范围扩大到 25英尺。除了空气,声波还通过可能振动的其他材料传播。Yan等[109]利用声音在固体介质导波传播的独特特性,将超声中各种听不见的语音命令传递给来自不同制造商的多种目标设备,实现了以较低的功率要求进行较长距离的攻击,同时实现了与语音设备的多轮交互。

除了对麦克风这一传感器的攻击研究之外,Tu等人[113]在“Trick or Heat”中利用放大器中的整流效应对温度传感器进行带外信号注入攻击,从而控制温度传感器信号的直流电压。

传感器是智能家居的基础,现有对传感器的安全研究表明,除电磁干扰之外,声音和光等不同类型的信号注入都会对传感器造成危害。由于这些攻击所利用的物理现象各不相同,如调制解调、混叠效应和整流,因此缓解措施没办法通用。

3.4 端安全-APP

许多智能家居设备都有配备相应的移动应用程序,用以配置、控制和监控设备。安卓研究人员[117]使用PlayDrone抓取并分析了Google Play中上百万的应用程序,大部分应用程序都出现了权限不当、存储不安全、编程质量不过关等问题,智能家居相关的应用程序也不例外。表9 给出了本文总结的针对IoT移动应用程序的常见攻击与防御方法。

表9 移动端攻击与防御方法总结Table 9 Literature summary of mobile attack and defense methods

权限使用不当:三星的SmartThings是目前智能家居平台中拥有最多移动应用程序的平台,但其安全性不容乐观,Fernandes等[115]分析表明应用商店中超过55%的SmartApps特权过高而且与SmartApps异步通信的SmartThings事件子系统的安全控制不充分,攻击者可以利用这些缺陷窃取锁定密码以及伪造假火警。此外,Sivaraman等[119]证明了恶意移动应用程序在家庭网络会侦察家庭中的网络设备情况,并通过端口映射将家庭内的脆弱设备或服务暴露给攻击者。

缓解措施:为避免应用程序可以请求不必要的权限,Tian等人[120]设计了 SmartAuth,自动从移动APP的描述、代码和注释中收集与安全相关的信息,并生成授权用户界面。Au等人[121]开发了PScout,该工具可使用静态分析从Android OS源代码中提取权限规范,这些规范应当被开发人员遵守来提高移动应用的安全性。He等人[122]研究了家庭物联网的访问控制和身份验证模型的局限性并设想了基于功能的安全模型。

Schuster等[124]将环境形势先知(environmental situation oracles,ESO)引入物联网生态系统中作为一流的对象,设计并实施了一种新的物联网访问控制方法,物联网访问控制框架可以使用 ESO来强制执行情境约束。

实体交互安全:糟糕的应用程序设计加上 APP与设备之间的不恰当交互有可能导致整个智能家居系统进入不安全的状态。基于此,IoTSan[123]利用模型检查对智能家居中配套的移动应用程序执行静态分析,从而预测有可能违反系统安全性能的自动化交互操作。与IoTSan执行的静态分析不同,Celik等人[125]提出一种动态的、基于策略的 IoT实施系统IOTGUARD,可通过监视设备和Trigger-action 平台应用程序的行为来保障用户安全。IOTGUARD架构如图13所示,其系统包括三个组件: 代码插桩、数据采集及安全服务,代码插桩用于收集应用程序在运行时的信息,数据收集在程序运行时接收事件及其对应操作,安全服务根据一系列物联网安全策略对数据收集结果进行评估,并强制执行符合安全要求的操作。IOTGUARD的设计及实施完全基于SmartThings及 IFTTT平台,通用性还不够高,另外用户与终端设备之间也存在着大量复杂交互,IOTG UARD的监视对象还可以继续扩展。

图13 IoTGuard系统架构Figure 13 Architecture of the IoTGuard system

APP接口安全:Google的 Nearby Connections API帮助Android Things或APP发现附近的设备并与它们建立通信,Antonioli等人[126]对这个闭源专有的API进行逆向分析,发现并实施两类攻击: 连接操纵(connection manipulation,CMA)和范围扩展攻击(range extension attacks,REA),对使用该API的所有Android应用程序造成威胁。

基于APP的模糊测试:移动应用的分析方法相较于嵌入式设备更加成熟,因此 Chen等人[127]提出基于APP分析的黑盒Fuzz测试框架—IOTFUZZER,框架利用了供应商编程到 APP中丰富的命令(种子)消息、URL和加密/解密信息,避免了对设备固件提取和复杂的逆向过程。但对于消息经由云平台转发到设备的通信架构,IOTFUZZER模糊的请求可能会被云过滤并触发防火墙警告,从而影响进一步测试。

4 研究热点与挑战

本文统计了2015—2020年上半年之间,除去综述类及调研类文章之外,中国计算机学会推荐的网络与信息安全领域CCF A类和CCF B类英文会议与期刊中有关于智能家居安全的90篇文章,对文章中重点研究的内容进行了总结概括,并以词云的形式展现出近些年来安全人员的研究热点。

从图14可以看出,隐私保护、通信加密和传感器是研究人员最为关注的话题,这是因为智能家居配备了大量的传感器采集家庭生活中的数据,但设备端受到计算资源的限制,处理数据的能力有限,这些敏感数据通常会上传到云端进行处理。如何保证传感器有效过滤掉异常输入、隐私数据在各个实体之间传输的过程不被泄露以及云平台不会滥用用户的数据,已经成为智能家居从业人员亟需解决的问题。其次,设备种类的增长以及家庭成员的多元化也使得身份验证及访问控制能力受到挑战,不仅要提高安全性,而且还要兼顾到用户在认证过程中的体验感。最后,没有绝对安全的系统,智能家居也不例外,一方面需要安全人员利用模糊测试等技术构建全流程的自动化安全评估,实现在产品上线前的安全把关; 另一方面需要供应商在设计和开发产品的过程中要考虑到设备被入侵或产生异常的情况,建设基于云的IoT安全防御框架,在产品上线后云平台要具备特殊情形下快速响应和恢复的能力。

图14 智能家居安全领域研究热点词云图Figure 14 A word cloud of research hotspots in the field of smart home security

4.1 基于云的IoT安全防御

IoT设备在本质上是易受攻击的,首先各种 IoT设备的功能截然不同,更新换代的周期较长且地理分布位置广泛,其次IoT设备的数量在不断增长,许多设备的存储及计算资源有限,无法将传统安全的一些防御措施部署到设备中,这些因素给设备的管理者及维护者提出了安全性挑战。由于安全漏洞在不断涌现,新的攻击向量也不断在被提出,设备的安全性随着时间在持续衰退,因此IoT云服务商应该不断地监控设备运行状态及审核设备配置情况,例如出站流量的激增可能表明设备已经被僵尸网络控制正在参与 DDoS攻击; 为设备证书提供安全数字签名的加密算法可能随着计算机和密码学发展而削弱。如图15所示,利用基于云的IoT安全防御机制可以及时发现设备异常行为及缺陷状态,并通过控制台、邮件、手机短信等渠道向设备管理者告警。

图15 基于云的IoT安全防御系统原理图Figure 15 Schematic diagram of cloud-based IoT security defense system

IoT安全性的基础在于控制、管理和配置设备之间的连接,目前已有一些物联网平台向IoT开发者提供基于云的安全防御服务,对设备的使用情况进行审核、对设备的运行状态进行实时监测。最基础的设备监控是从设备与云的通信流量中检测异常行为,如流量大小及频率激增,这种方式不会给设备带来额外负担,但云平台获取的设备信息有限,无法对设备的当前状态作出全面且精准的判断,因此 AWS及Azure这两个全球最具竞争力的物联网平台[128]向开发者提供了安装在设备上的代理,收集物联网操作系统中的原始安全数据,并将数据发送到云平台中心进行处理、聚合、分析、决策。本文对国内外主流的物联网平台进行了调研,发现只有四个平台对开发者提供了设备监控服务,其中华为和谷歌的物联网平台仅从平台日志中获取基础项目指标,如流量指标及连接情况; AWS及Azure由于在设备上安装了代理,能够采集到更多的设备数据,因此具有更强的风险识别能力。

表10 基于这四个云厂商提供的安全防御能力,对 IoT平台网络监控及行为异常检测能力之间的异同进行了分析总结,其中华为仅对设备消息流量的速度及大小进行监测,当超过阈值时,平台会上报告警; 谷歌使用Cloud Monitoring API查询和查看设备的运行指标,除了设备流控之外,还具备对活跃设备数量、设备连接失败次数、设备身份验证识别次数等情况进行监控的能力。亚马逊 AWS及微软Azure相比前两个的基础监控能力,利用平台的资源整合及计算能力对代理收集的设备数据进行多方位的分析,能够对证书安全、设备认证、设备连接、流量异常、端口异常、日志痕迹等多个风险类别进行监测识别。值得一提的是,微软的代理服务基于C或C#编写,而AWS IoT设备防御程序的代理SDK基于Python编写,对计算机硬件资源和媒体文件的访问能力不如前者,因此Azure具备更强大的设备状态监测能力,能够对设备上出现的命令执行、类恶意软件及文件异常等行为持续分析和监控。

表10 主流物联网平台安全防御服务检测项目Table 10 Test items of security defense services for mainstream IoT platforms

4.2 自动化漏洞挖掘技术

在通用平台上,模糊测试在漏洞挖掘中的能力已经得到展现,它通过向目标程序发送畸形输入,获得程序的崩溃状态,从而发现潜在漏洞。虽然研究人员提出了许多方法将模糊测试技术应用到嵌入式设备上,但由于物联网设备上的程序对硬件配置有着强烈的依赖性,目前的研究工作依然有很大的不足和局限性,表11给出了本文对固件模糊测试工具的综合比较结果,具体描述如下:

模糊测试技术根据对目标程序的了解情况,可以分为: 黑盒测试、灰盒测试和白盒测试。由于供应商通常不会公开智能设备的源代码,因此针对智能设备的白盒测试相对较少。黑盒测试将目标程序视作黑盒,依照约定的输入规则生成输入样例,程序的执行状态无法对测试样例的生成进行指导。代表性的工具有boofuzz[129]、Sulley[130]和 Peach[131],这些工具需要安全人员对通信的数据格式进行复杂的分析,而 IoTFuzzer[127]利用了与设备配套的移动应用(带有丰富的种子、URL及加解密信息),可以生成更符合规则的测试用例。但这些黑盒测试工具的效率都不高,因为无法收到目标程序的反馈,而且真机的吞吐量很低。

Muench等人[133]的研究已经表明,因为台式机处理器性能要远胜于物联网设备,基于全仿真的方法实际上比真实设备要快。尽管 Chen 等人[132]提出的全系统仿真平台 Firmadyne,相对于本地执行已经有了较大的提升,而且Firmadyne解决了由于缺少实际硬件而导致的程序异常,但测试样本的吞吐率最快也没有超过15 个/秒。除了全系统仿真之外,还有以 QEMU[134]为代表的用户模式仿真器以及以Avatar[135]为代表的混合模式仿真器,前者通过动态二进制转换提高了吞吐量,但在目标程序有系统调用的情况下,会因为目标程序依赖的环境与宿主机的差异而产生错误; 后者将仿真器与真实的硬件结合起来,解决了环境依赖带来的问题,但因为频繁的软硬件交互,其吞吐量甚至低于真机。

仿真器只能解决黑盒测试效率不高的一部分原因。以 AFL[136]、LibFuzzer[137]、honggfuzz[138]为代表灰盒测试工具通过监控目标程序引导测试用例生成,从而提高代码覆盖率以及测试效率。特别是AFL,它以提高代码覆盖率为目标,以目标程序的执行状态为反馈,不断丢弃无法生成新路径的输入,并将能产生新路径的输入补充到输入队列中,其优越性已在工业界和学术界得到广泛认同,DARPA发起的Cyber Grand Challenge中的大多数决赛选手都将AFL用作主要的漏洞发现组件。不幸的是,AFL通过用户模式QEMU支持二进制模糊测试,因此AFL无法简单应用于测试IoT程序。为了解决AFL受到特定的硬件依赖性的制约,TriforceAFL[139]将QEMU的系统态仿真与 AFL相结合,实现了基于全系统仿真的模糊器。Zheng等人[140]在此基础之上,提出了一种新颖的技术,即增强进程仿真 Firm-AFL,它结合了全系统仿真的通用性和用户模式仿真的效率。但是由于其全系统仿真由 Firmadyne支持,因此Firm-AFL能够测试的固件数量取决于Firmadyne能正确地仿真的数量。

4.3 思考与讨论

对于自动化漏洞挖掘技术在智能家居领域的应用,受限于硬件资源、硬件的复杂异构、代码未公开这三个因素,具备通用性的自动化漏洞挖掘工具尚未出现,目前在传统平台上表现出色的模糊测试工具在种子生成、固件仿真、设备监控、状态异常检测等方面还有比较大的局限性。

对于物联网平台提供的基于云的 IoT安全防御措施,智能家居设备的计算资源和存储能力是有限的,Azure使用代理技术获得了良好的设备监控能力,但这种方法对设备性能的影响是不可忽略的,因此无法将这种技术部署到所有产品中。研究人员还需要提供统一的IoT威胁管理解决方案,在无安装代理的情况下改进安全态势管理。提供全网络监控和行为异常检测能力,需要三层威胁防护支撑: 设备配置文件审核、IoT感知行为分析,以及面向IoT的威胁情报。

设备管理者利用基于云的 IoT安全防御可以及时发现已存在的风险,并通过补丁和框架来缓解,但安全性不是一个静态公式,这要求安全运营团队能够连续建模、监视和迭代安全最佳实践,因此需要将风险建模与验证的过程尽可能自动化。

基于此,本文提出基于 Docker集群的端侧自动化威胁模型,如图16所示。该系统由四部分组成:威胁建模与生成、设备管理、Docker集群以及设备风险库。

图16 端侧自动化威胁模型架构Figure 16 End-side automated threat model architecture

威胁建模与生成完成了从风险挖掘到自动化模板生成的过程。安全人员需要从设备功能中梳理设备的攻击面,从中建立新的威胁模型。威胁模型经过基于模板融合的自动代码生成方法,根据设备连接协议自动化生成威胁验证脚本。已经建立好的风险模型将存储在风险库中,安全人员可以通过设备管理模块对所有的模型进行管理和利用。

现有的风险评估方法大多是针对传统网络系统的,如高校网络[141-143]、办公网络[144-145]、工控系统[146-148],这些方法大多只关心单个主机的安全性能,而忽略了集群效应(如流量攻击),本文提出的方案第一次将风险评估方法使用在智能家居系统中,使用 Docker集群来模拟设备的整个生命周期,可以满足大规模智能家居设备模拟的需求,能够降低真实设备运行时占用的计算资源和存储资源,节省风险模型验证的成本。另外,一些传统方案在真实网络环境中做渗透测试,模拟攻击的结果直接影响线上用户,造成用户体验不佳,而本文的方案由于不使用真实设备也不介入线上环境,风险验证的结果不对线上用户造成影响。

5 总结展望

智能家居包含的网络节点众多、设备种类繁杂,使用的协议多样,这些特点给智能家居的安全性提出了很大挑战[149]。本文在调研了关于智能家居安全的文献之后,首先提出了一个由终端设备、云平台、移动应用程序及通信管道组成的应用模型,然后分别从这四个层次的角度系统化阐述针对智能家居的攻击向量及缓解措施的主要研究工作,最后对近些年学术界频繁探讨的热点议题进行了总结,介绍了主流平台基于云的IoT安全防御方法,针对模糊测试在智能家居上的应用这一技术难点进行了讨论,并提出了基于Docker集群的端侧自动化威胁模型。

为维护智能家居的安全,不仅仅需要安全研究人员的努力,还需要以下多方共同努力,来实现一个可信可管且安全的智能家居生态环境:

√ 供应商应对每个层面的组件进行正确的安全性开发;

√ 用户应当提高安全隐私意识并使用安全的配置策略;

√ 政府和国际组织应制定相关的法律法规;

√ 物联网标准和联盟组织应不断推动物联网安全的规范化和标准化。

结合前文对智能家居研究热点及挑战的讨论,对于后续发展,本文相关展望如下:

1) 用户隐私保护

智能家居的广泛应用使得家庭用户在隐私保护方面面临更大的风险,要改善智能家居的隐私保护现状,需要消费者、供应商及第三方(如政府)的共同努力,如何在敏感信息的实用性和安全性之间做出合适的权衡是这三个利益相关方需要考虑的重点。

2) 访问控制策略

现有研究通常针对单个设备本身进行分析,强调个体强壮性,大多忽略了实体之间相互依赖的交互行为对安全的影响。由于各个实体间广泛存在的依存关系,安全人员很难为智能家居中的各个实体划分出明确的安全边界职责,这使得静态访问控制方法效果不佳,因此在现有的智能家居系统中,过度特权已成为普遍现象,研究人员需要进一步考虑交互的多样性和平台的差异性,从实体间的相互依赖行为入手,设计动态的访问控制策略。

3) 固件托管

由于物联网设备的多样性,很难为异构设备设计通用的动态分析平台,固件托管通过对固件依赖进行建模分析,以软件实现的方式代替硬件依赖,但现有的固件托管工具大多仅适用于基于 Linux的系统,对于实时操作系统(RTOS)和裸机系统(Bare metal)的固件仿真工具还非常不成熟,因此固件托管的支持范围还可以进一步扩展。

4) 设备异常检测和防御

由于计算资源和存储受限,大多数物联网设备没有为系统和网络部署必要的监测和防御措施,如何在物联网设备上利用更少的系统软件和硬件资源来实现传统安全上的防御效果,需要安全研究人员对原有防御系统从轻量级角度进一步优化。