小路的博客

典型智能家居产品安全测评技术研究与实现 (Research and Implementation of Safety Assessment Technology for Typical Smart Home Products)

摘 要 近年来，随着物联网技术的发展，各类智能家居产品逐渐普及，走入寻常百姓家。由于智能家居产品更贴近人们的家庭生活，承载了更多家庭的隐私信息，所以智能家居产品的安全性受到了网络安全界的广泛关注。研究智能家居系统安全测评技术并实现相应的智能家居安全测评系统，对提高智能家居系统的安全性具有重要意义。 该文从物联网技术和网络安全技术的角度，以典型的智能家居系统为例，说明了智能家居设备的分类，基于一般智能家居系统的“端-管-云”系统架构分析了智能家居系统中的库安全风险、平台安全风险、代码安全风险和通信协议安全风险，以及针对这些安全风险的静态和动态安全测评技术，最终设计和实现了一套智能家居安全测评系统。该系统基于Web技术构建，整合了多种现有的独立安全测评工具，实现了基于云端的系统固件、Android应用程序和iOS应用程序静态安全检测功能，以及基于云端的Android应用程序动态安全检测功能。经过对主流的智能家居设备与系统进行测试，该安全测评系统可以有效地检测出智能家居系统中的安全风险，辅助安全研究人员发现智能家居系统中的安全漏洞，从而提高智能家居系统的安全性。

关键词：智能家居；物联网；网络安全；安全测评

Abstract

In recent years, with the development of the Internet of Things technology, various types of smart home products have gradually become popular and have entered the homes of ordinary people. For smart home products are closer to people\’s family life and contain more family privacy information, the security of smart home products has been widely concerned by the network security community. Studying the smart home system security assessment technology and implementing the security assessment system for smart home systems are meaningful to improve the security of the smart home system.

From the perspective of Internet of Things technology and network security technology, the thesis takes typical smart home systems as examples to illustrate the classification of smart home devices, based on the Device-Management-Cloud system architecture of the general smart home system, the library security risk, platform security risk, code security risk and communication protocol security risk in the smart home system are analyzed, as well as static and dynamic security assessment techniques for these security risks, and finally designed and implemented a security assessment system for smart home systems. The system is built on Web technology, integrates a variety of existing independent security assessment tools, implements cloud-based static security detection for system firmware, Android application and iOS application, and cloud-based dynamic security detection for Android application. After testing the mainstream smart home devices and systems, the security assessment system can detect security risks in smart home systems effectively, and assist security researchers to discover security vulnerabilities in smart home systems, thereby improving the security of smart home systems.

Key Words: Smart Home; Internet of Things; Cyber Security; Security Assessment

第1章 绪论

1.1 智能家居发展概述

智能家居是以家庭住宅为平台，综合了物联网技术、人工智能技术、大数据技术等新兴技术，将原有的家电设备智能化或引入新的智能设备，进行智慧家庭管理，以实现智慧家庭生活的技术。根据公开数据显示，2017年智能家居市场规模超过1400亿元，预计2019年将超过2000亿元，在智能家居市场中，以智能路由器、智能音箱、智能摄像机、智能门锁为代表的典型智能家居产品占了很大的比重，同时手机是用户最喜爱的操控方式[1]。智能家居设备与手机联动，用户可以通过手机远程控制家中的各种设备，这为人们的生活带来了极大的便利。

1.2 智能家居安全性现状

与Web互联网时代与移动互联网时代的发展规律相同，随着智能家居设备的蓬勃发展，针对各类智能家居设备的网络攻击数量逐渐增长，手段层出不穷。华为智能路由器中的CVE-2017-17215远程命令注入漏洞被物联网僵尸网络恶意程序用于攻击[2]，腾讯安全团队成功破解亚马逊智能音箱Echo，实现了远程窃听并录音[3]，这些案例都表明智能家居的安全性形势严峻。

1.3 现有的智能家居安全测评方法

由于漏洞广泛存在于智能家居系统中，所以安全研究人员都致力于挖掘智能家居系统的漏洞。目前针对Web系统和移动设备的漏洞检测工具较为普及，对Web安全和移动设备安全的提升有很大帮助。但是目前还没有公开可用的基于智能家居设备的漏洞检测工具，安全研究人员对于智能家居系统的漏洞挖掘，只能使用原有的各种工具以及进行人工分析，厂商开发人员在开发出智能家居产品后，也不容易验证自己的系统是否存在安全漏洞，而消费者更是只能相信厂商的宣传，自己根本无从判断[4]。由此可见，开展对典型智能家居系统安全研究技术的研究，并实现一套智能家居安全测评系统，具有重要的意义。

1.4 主要研究内容

针对智能家居系统中现在存在的安全性差、检测手段缺乏等问题。开展了针对典型智能家居系统安全研究技术的研究。首先在第2章介绍了智能家居设备的类型，并且分析了智能家居的系统架构，在第3章针对已有的系统架构，提出了智能家居系统的安全风险，在第4章，针对这些安全风险，提出了相应的安全测评方法，在第5、6章，介绍了典型智能家居安全测评系统的设计，并对一些安全测评方法进行了实现，最终实现了一套智能家居安全测评系统，在第7章进行了总结和展望。

1.5 本章小结

本章介绍了智能家居设备的发展现状和安全性现状，并且针对现有的智能家居安全测评方法进行了分析，说明了智能家居系统安全研究技术研究与实现的重要意义，最后说明了本文的研究内容。

第2章 智能家居系统架构

在讨论智能家居设备的安全性之前，首先需要讨论智能家居设备的系统架构。对于不同的系统架构，需要分别讨论在这样的系统架构之下有哪些安全风险，以及相应的对策。目前主流的智能家居设备按照其系统架构可以分为三种类型：基于无线局域网的智能家居设备、基于低功耗蓝牙的智能家居设备和基于ZigBee的智能家居设备。本章针对这三种类型的智能家居设备，分析智能家居设备的系统架构和使用的通信协议。

2.1 智能家居设备分类

2.1.1 基于无线局域网的智能家居设备

目前无线局域网是家庭网络接入的最主要方式，无线局域网由IEEE 802.11标准规范定义，工作在2.4GHz和5GHz两个频段上。大多数家庭都会拥有一个无线AP（Access Point, 接入点），用于将ISP（Internet Service Provider, 互联网服务提供商）的宽带或光纤网络供智能手机、笔记本电脑和智能家居产品这类没有以太网接口的设备使用。所以基于无线局域网的智能家居产品是最为普及的。

基于无线局域网的智能家居设备的特点是搭载一个无线局域网调制解调器，用于接入家庭中的无线局域网和互联网。用户首次使用设备时，需要为产品配置网络，配置网络的操作可能通过蓝牙方式或扫描二维码的方式完成，在为设备配置好网络之后，就可以正常使用设备了。其优点是接入网络较为方便，可以利用现有的家庭无线局域网，不存在网络铺设的成本。缺点是无线局域网调制解调器本身耗电量比较大，通常这类设备必须使用电源线缆进行供电，很难使用电池进行供电，所以便携性比较差。代表性的设备有：智能路由器、智能音箱、智能摄像头、智能空气净化器等等。

2.1.2 基于低功耗蓝牙的智能家居设备

有些智能家居设备是不需要时刻与互联网连接，或是对功耗要求比较高，并且不适合设计为使用电源线缆供电，所以这类设备大多采用低功耗的连接方式。低功耗蓝牙技术是一种较为普及的技术，工作与2.4GHz频段上。蓝牙4.0版本或更高版本即支持低功耗蓝牙，同时绝大多数的智能手机都支持蓝牙4.0或更高版本，所以基于低功耗蓝牙的智能家居设备也是数量比较多的。

基于低功耗蓝牙的智能家居设备的特点是搭载一个低功耗蓝牙收发器，用于和智能手机进行配对和连接。如果要上传数据到互联网，则需要借助智能手机应用程序来完成，或者使用一种名为“蓝牙网关”的设备，本质是一种既具有无线局域网功能，可以接入家庭网络，又具有蓝牙功能，可以和基于低功耗蓝牙的智能家居设备配对，在两者之间充当了一个“桥梁”，间接建立设备和互联网之间的连接。其优点是功耗低，可以使用电池供电，不必使用电源线缆，便携性较强。缺点是需要和智能手机连接才可以连接到互联网，会增加手机的功耗，如果使用“蓝牙网关”，则会增加成本，同时低功耗蓝牙的传输速度比明显低于无线局域网。代表性的设备有：智能穿戴设备（智能手表、智能手环）、智能门锁、智能体重秤、智能插座等等。

同时需要注意的是，对于基于无线局域网的智能家居设备，很多也出于配置网络或方便用户使用的目的搭载了蓝牙功能，这部分设备在讨论其安全风险时也需要考虑蓝牙方面的安全风险。

2.1.3 基于ZigBee的智能家居设备

低功耗连接技术除了蓝牙之外，还有一种称为ZigBee的技术，中文名为“紫峰”。ZigBee由IEEE 802.15.4标准规范定义，相比蓝牙技术的优势是成本更低。但大多数智能手机并不支持ZigBee协议，所以在智能家居设备高度依赖手机控制的大环境下，还需要增加蓝牙或无线局域网功能，用户才能更容易使用。所以基于ZigBee的智能家居设备数量相对较少。

2.2 智能家居系统架构

对于上述的智能家居设备，目前使用较为广泛的系统架构是“端-管-云”的三元系统架构[5]。其中“端”指的是设备端，也就是智能家居设备本身。“管”指的是管理端，这里指的是智能手机。“云”指的是云服务器，对于智能音箱这类设备，需要有服务器上的人工智能算法支撑语音助手功能，对于其它设备也需要借助服务器来实现远程控制。所以这样的架构称之为“端-管-云”的三元系统架构。

2.3 智能家居系统通信协议

在“端-管-云”的三元系统架构中，这三个部分需要使用各种协议进行通信。在和云端的交互方面，只能通过互联网进行交互，管理端主要使用的应用层协议有HTTP（Hyper Text Transfer Protocol, 超文本传输协议）、HTTPS（Hyper Text Transfer Protocol Secure, 安全超文本传输协议）、MQTT（Message Queuing Telemetry Transport, 消息队列遥测传输）或是厂商的私有协议。设备端就根据设备的类型而不同：基于无线局域网的智能家居设备可以直接通过家庭网络接入互联网，而基于低功耗蓝牙和基于ZigBee的智能家居设备就必须首先和智能手机连接，再通过智能手机接入互联网。

在设备端和管理端的交互方面，当管理端位于家庭网络时，可以通过蓝牙或者本地的无线局域网进行，主要使用的应用层协议有HTTP、HTTPS、MQTT或是厂商的私有协议。但如果管理端离开家庭网络的环境，因为目前互联网依旧主要使用IPv4（Internet Protocol Version 4, 互联网协议第四版），而IPv4地址总数只有232个，目前已经耗尽，运营商无法为每一个接入互联网的设备都分配一个IPv4地址，只能通过网络地址转换的方式，设备端和管理端都只能获得一个私有网络IPv4地址，所以在离开家庭网络的情况下，管理端必须借助具有IPv4全球地址的服务器才能和设备端进行交互。这个过程实际上是要先和服务器进行交互，服务器再对请求进行转发，所以使用的应用层协议和上述与云端的交互中的应用层协议相同。

2.4 本章小结

本章主要介绍了智能家居设备的类型，由此引出了智能家居系统的“端-管-云”三元系统架构，并且说明了这三个部分之间交互使用的通信协议。只有确定了系统架构和通信方式的模型，才能进一步研究智能家居设备的安全风险。

第3章 智能家居系统的安全风险

对于基于“端-管-云”的三元系统架构的智能家居系统，本章将分三个方面考虑其安全风险，分别是设备端的安全风险、管理端的安全风险和云端的安全风险。

3.1 设备端的安全风险

对于智能家居设备，讨论其安全风险，首先要区分智能家居设备使用的操作系统。针对不同的操作系统，将有不同种类的设备端安全风险。

3.1.1 智能家居设备使用的操作系统

根据对市场上产品的调研，智能家居设备使用的操作系统主要有三种。第一种是基于Linux的操作系统，例如M公司的智能家居设备，包括智能路由器、智能音箱等，全部使用的是基于OpenWrt项目的系统。OpenWrt项目是一种专门用于路由器等嵌入式设备的Linux发行版，M公司在OpenWrt项目的基础上构建自己的智能家居业务。第二种是基于Android的操作系统，例如B公司的家庭视听产品采用的是DuerOS，实际是基于Android开发的操作系统。第三种是自研的操作系统，例如H公司的智能家居设备，有部分采用的是LiteOS系统，根据公开资料显示，这是H公司自行研发的操作系统，并非基于Linux操作系统或Android操作系统二次开发。对于这三种类型的操作系统，将会存在不同类型的安全风险。

3.1.2 使用第三方库的安全风险

在实现智能家居设备的各种功能时，经常会使用一些第三方库。这些第三方库可以提供各种功能，而不需要全部从零开发，可以让智能家居设备加速推向市场。但是在使用第三方库的过程中，如果没有使用最新版本的库文件，很可能引入各种已知的漏洞。根据腾讯科恩实验室的研究表明，平均每个物联网产品的软件会调用23.2种第三方库，调用的第三方库版本平均滞后68.75个迭代版本，滞后期为7.8年。由此可见，目前的智能家居设备中，使用第三方库的版本，滞后情况极其严重。而根据这些旧版本第三方库所包含的CVE（Common Vulnerabilities and Exposures, 公共漏洞和暴露）编号来看，远程代码执行漏洞、拒绝服务漏洞、缓冲区溢出漏洞、信息泄露漏洞等这类危害较大的漏洞占比很高[6]。所以因智能家居设备使用第三方库而导致的漏洞，数量很多，同时造成的危害也很大。同时很多开发人员并不知道自己引用了多少第三方库，因为很多第三方库可能将另外的第三方库作为依赖，导致开发人员认为没有引入了另外的那些第三方库。

3.1.3 平台自身安全风险

除了使用第三方库的风险，对于使用基于Linux平台的智能家居设备而言，操作系统平台本身也可能会有一些安全风险。例如Linux本身支持使用SSH（Secure Shell, 安全壳层协议）协议进行远程登录的功能，在分析某品牌的智能音箱时发现，该设备内置了支持SSH协议的第三方库，同时还配置了SSH公钥，这意味着持有私钥的厂商工作人员在技术上是可以登录到每一台智能音箱中，并且窃取想要的信息，这就带来了信息泄露风险，以及消费者对产品的不可信。甚至有些设备使用的Linux内核本身就包含已知漏洞，可以进行权限提升，此类漏洞一旦被利用的后果将难以想象。

对于使用Android平台的智能家居设备而言，在Linux安全风险之外，还会存在Android平台自身的安全风险。

3.1.4 厂商代码安全风险

厂商在实现智能家居设备的功能时，即使可以基于各种各样的第三方库来实现，也必须要自己编写代码来完成业务逻辑。而各个厂商的软件工程水平差异较大，很多厂商的软件工程水平无法和谷歌、微软这样的大型软件公司相比。所以在厂商实现的代码中，也可能有各种安全风险。比较有代表性的有UAF（Use After Free, 释放后使用）漏洞、缓冲区溢出漏洞、堆溢出漏洞、格式化字符串漏洞、数字证书弱校验漏洞、业务逻辑漏洞等等。

除了代码自身的质量问题导致的安全风险之外，未使用的调试接口问题也值得安全研究人员关注。因为智能家居设备属于嵌入式设备，在开发过程中，与Web应用程序、移动应用程序相比更难以调试，所以厂商为了方便自己的开发过程，会引入一些多余的接口。例如将设备外壳去除之后会发现，有些厂商的设备主板上会保留调试接口，这些接口可能允许攻击者绕过安全保护机制并且窃取敏感数据，甚至取得整个智能家居系统的控制权。

3.1.5 通信协议安全风险

设备端在实现和管理端以及云端交互时，会使用各种协议。有些协议自身即存在安全风险，例如针对WPA2（Wi-Fi Protected Access version 2, Wi-Fi保护访问第二版）协议的KRACK（Key Re-installation Attacks, 密钥重新安装攻击）漏洞，就对传统认为安全的WPA2协议提出了很大的挑战。

此外如果设备端在发送用户敏感数据时，未使用安全的加密协议，也是一种安全风险。例如设备端直接使用HTTP协议或其它明文协议发送敏感信息，或是虽使用了HTTPS协议，但在SSL（Secure Sockets Layer, 安全套接层）层方面选择了SSL 2.0、SSL 3.0、TLS（Transport Layer Security, 传输层安全协议）1.0这些不安全的SSL版本，或是使用了TLS 1.1、TLS 1.2协议中不安全的安全套件，这些未正确使用HTTPS协议的情况也会带来敏感信息泄露的安全风险。

在其它需要保护敏感数据的情况下，也需要使用各种密码算法，如果选择了不安全的密码算法，同样会带来安全风险，例如在加密数据时使用DES（Data Encryption Standard, 数据加密标准）算法、或使用3DES（Three Data Encryption Standard, 三重数据加密标准）算法时三个DES的密钥没有做到完全不同，在使用对称密码算法时使用了ECB（Electronic Code Book, 电码本）模式或CBC（Cipher Block Chaining, 密文分组链接）模式这种不安全的运行模式。

3.2 管理端的安全风险

对于管理端，目前主流的智能手机操作系统是谷歌公司的Android系统和苹果公司的iOS系统。针对这两种操作系统，有不同种类的管理端安全风险。

3.2.1 Android平台安全风险

根据OWASP（Open Web Application Security Project, 开放Web应用程序安全项目）于2016年发布的十大移动安全风险[7]，结合“端-管-云”三元系统架构的特点，我们可以得出Android平台的如下十种安全风险：

  • M1-平台使用不当，OWASP对平台使用不当的定义较为广泛，具体到Android来说，有程序允许备份风险、组件暴露风险、文件权限错误、证书弱校验等等。这些安全风险都是因为开发人员没有正确使用Android平台提供的功能所造成的，此部分在Android平台安全风险中占多数。
  • M2-不安全的数据存储，此类安全风险与用户隐私信息的存储相关，例如在需要配置无线局域网的智能家居设备中，需要用户输入家庭无线AP的名称和口令，在很多Android应用程序中都使用的是明文存储，这就导致了用户敏感信息泄漏。
  • M3-不安全的通信，此类安全风险与设备安全风险中的通信协议安全风险一致。
  • M4-不安全的身份认证，在“端-管-云”三元系统架构中，管理端需要在服务器上进行身份认证，所以此类安全风险本质是由服务器造成的。
  • M5-加密不足，此类安全风险主要是加密机制被绕过的问题，和M2有明显的区别。
  • M6-不安全的授权，此类安全风险主要是用户权限授权失败的问题。
  • M7-客户端代码质量问题，此类安全风险与设备安全风险中的厂商代码安全风险一致。
  • M8-代码篡改，此类安全风险指的是通过修改本地可执行文件或在不修改可执行文件的情况下动态影响程序的执行，导致客户端代码被篡改，或某些逻辑被绕过。
  • M9-逆向工程，此类安全风险指的是可执行文件在编译的过程中没有进行充分的混淆或其他防护，导致攻击者可以直接通过逆向工程的手段获得程序的源代码。
  • M10-无关的功能，此类安全风险涉及到未在发布版本的应用程序中使用到的功能。对于智能家居设备的管理端而言，通常需要在开发阶段允许管理端在未鉴权的情况下访问设备，以方便开发人员的调试，如果这些接口在发布版本中被保留，则会造成非常严重的问题。

这里需要注意的是，OWASP发布的十大移动安全风险，是针对各种类型的移动应用程序的。但对“端-管-云”三元系统架构中的管理端而言，是一种特定类型的移动应用程序。所以不能完全按照OWASP推荐的顺序考虑管理端的安全风险。例如对于M10-无关的功能这一项，在普通的移动应用程序中可能不一定大量存在，然而在智能家居设备中，结合设备端代码的分析会发现，调试接口的问题是大量存在的。

3.2.2 iOS平台安全风险

与Android平台不同的是，苹果公司的iOS平台是不开放源代码的，同时如果想要为全世界的iOS客户发布应用程序，就必须将应用程序发布至苹果的App Store应用商店，接受苹果公司的审核。同时iOS系统本身也有很多复杂的安全机制限制了恶意程序的泛滥。不过尽管如此，iOS平台上的应用程序依旧有各种安全风险，本节主要列举在Android平台安全风险之外的，iOS平台独有的一些安全风险。

首先就是对iOS系统本身破解的安全风险，也就是俗称的Jailbreak（越狱）行为。Android系统取得root权限是相对容易的，所以许多开发人员都会在程序中检测Android系统是否被破解。但是与Android系统不同的是，很少有开发人员会对iOS系统是否被破解进行检测。这就导致一旦攻击者将应用程序安装到越狱iOS中，攻击者就可以利用和Android系统上相类似的手段对iOS应用程序进行攻击。例如对于发布到苹果App Store的应用程序，苹果公司为了保护知识产权，会对上传的应用程序添加保护，但是在越狱iOS中，有黑客组织提供了破解该机制的工具，可以轻易的去除保护并且进行逆向工程分析源代码。

其次是对iOS系统平台功能滥用的安全风险，默认情况下苹果公司不允许调用iOS隐藏的API（Application Interface, 应用程序接口），但是在iOS开发者社区中，有多种绕过调用限制的方法。iOS应用程序使用的是Objective-C语言进行开发，因为这种语言的固有特性，所以即使苹果公司频繁封杀隐藏API的调用，也还是有很多应用程序开发商挺而走险，冒着被苹果公司除名的风险使用这些隐藏API，以达成一些特殊的目的。例如可以通过隐藏API使应用程序长期在后台运行，并且有可能绕过用户的权限授权，直接获得一些敏感数据。更有甚者在厂商的苹果开发者身份被除名之后，依旧通过更换不同的开发者身份的方式继续违反苹果的开发者协议，这其中不乏国内的一些知名厂商。而这些行为都是iOS用户难以得知的，具有极大的隐蔽性和危害。

最后是iOS系统自身的安全风险，例如在2015年爆出的XcodeGhost病毒，是通过攻击iOS应用程序开发工具Xcode进而感染iOS应用程序本身，这些安全风险是iOS系统所独有的。

3.3 云端的安全风险

对于智能家居系统而言，云端主要使用的是Web服务器，提供了身份认证、请求转发、数据存储等功能。而Web安全是网络安全领域中的一个比较传统的研究方向。根据OWASP于2017年发布的十大Web应用程序安全风险[8]，结合“端-管-云”的三元系统架构，可以得出Web常规的十种安全风险，具体内容如下所示

  • A1-注入，此类安全风险是因为Web应用程序接受了客户端不可信的输入，从而导致了SQL（Structure Query Language, 结构化数据查询语言）注入、NoSQL（No Structure Query Language, 非结构化数据查询语言）注入、操作系统命令注入和LDAP（Lightweight Directory Access Protocol, 轻量目录访问协议）注入的缺陷。可能导致服务器被攻击者完全控制。
  • A2-失效的身份认证，此类安全风险是因为Web应用程序错误地使用了框架中的身份认证机制，或是自行实现了有缺陷的身份认证机制。可能导致攻击者进行不经过身份认证直接访问用户的敏感数据。
  • A3-敏感数据泄漏，此类安全风险是因为Web应用程序无法正确保护敏感数据，通常是其它类型的攻击，加上敏感数据没有正确地进行加密而导致的结果。
  • A4-XML（Extensible Markup Language）外部实体（XML External Entity, XXE），此类安全风险是因为XML处理器未能正确处理XML文件中的外部实体引用。攻击者可以利用XXE进行未授权的访问。
  • A5-失效的访问控制，此类安全风险是因为Web应用程序没有对经过身份认证的用户实施正确的访问控制，从而导致攻击者可以进行横向越权攻击，访问到其他用户的敏感数据。
  • A6-安全配置错误，此类安全风险是因为没有正确配置Web应用程序框架中提供的安全特性，导致安全特性被绕过。
  • A7-跨站脚本（XSS），此类安全风险是因为Web应用程序将攻击者不可信的输入作为了HTML（Hyper Text Markup Language, 超文本标记语言）实体，导致页面被改变甚至执行外部的JavaScript代码，进而窃取用户登录凭证或其它敏感信息。
  • A8-不安全的反序列化，此类安全风险是因为Web应用程序将攻击者不可信的输入作为了反序列化函数的输入，在程序中生成了不安全的对象，从而导致多种类型的攻击产生。
  • A9-使用含有已知漏洞的组件，此类安全风险是因为使用了含有已知漏洞Web应用程序框架，例如开发人员使用了旧版本的Spring MVC、Struts 2、MyBatis等框架，导致了漏洞的引入。
  • A10-不足的日志记录和监控，此类安全风险是在攻击发生后由于缺少日志的记录和监控，导致很难追溯到攻击行为的源头。

3.4 本章小结

本章主要讨论了在智能家居系统的“端-管-云”三元系统架构中，设备端、管理端和云端的安全风险。在确定了各种不同类型的安全风险后，才能面向这些安全风险提出有针对性的安全测评方法。

第4章 智能家居系统安全测评方法

针对智能家居设备，在按照设备端、管理端和云端三个方面讨论了安全风险之后，就可以面向不同种类的安全风险，提出有针对性的安全测评方法。对于一个实际的智能家居系统，可以应用这样的安全测评方法开展安全研究工作，进而发现其中的安全风险。和讨论安全风险的方法类似，讨论安全测评方法同样需要针对设备端、管理端和云端这三个方面分别进行。

4.1 针对设备端的安全测评方法

根据设备端的安全风险，和智能家居设备硬件的一般结构，可以得出下面的安全测评方法和流程。

4.1.1 设备硬件拆解与分析

针对设备端的安全测评，主要是基于设备的硬件和软件来进行。对于硬件，首先要进行设备的拆解，大多数的智能家居设备使用普通的拆解工具都可以较为容易的进行拆解。在拆解外壳之后我们可以分析设备的主板，识别和确认主板上主要芯片的型号，并且观察主板上有无预留的调试接口或USB接口。若有调试接口或USB接口，可以以此为入手点进行分析，查看设备启动时输出的日志，获得更有价值的信息。甚至对于某些设备可以直接从调试接口取得设备的权限。

4.1.2 设备固件获取

硬件的分析主要靠设备拆解进行，而对于软件则必须获取智能家居设备的固件（firmware），也就是智能家居设备内置的嵌入式操作系统，获取固件的方法有很多，下面列举一些主要的获取方式。

通过设备厂商官方网站获取，很多设备厂商会在官方网站提供旗下产品的技术支持板块，在该板块会提供设备升级包的下载，直接下载这些升级包就可以获得设备的固件，例如M公司和D公司的智能路由器产品就提供了这样的下载渠道。但并非所有的厂商都提供了这样的方式。

通过调试接口获取，基于上一节的分析，有些厂商在主板上预留了调试接口，通过连接到调试接口，有可能获取到设备的命令行权限，从而可以执行内存导出命令获得在内存中的代码和数据，例如H公司的智能摄像头产品就存在这样的问题，但H公司的智能音箱产品，虽有调试接口，但需要鉴定权限之后才能连接，就不能通过这样的方式获取了。

通过对软件更新的流量进行捕获获取，这种方法需要结合管理端分析的技术来进行，在管理端绝大多数厂商都提供了在线软件更新的功能，如果在下载软件更新包时使用了明文协议，或者虽然使用了加密协议下载软件更新包，却使用明文协议发送了检查更新的请求，导致软件更新包的下载链接泄漏，这些情况都可以获取到固件。例如M公司的智能音箱产品，在使用配套软件进行软件更新时，获取软件更新下载链接的检查更新操作使用了HTTP明文协议，泄漏了软件更新下载链接，可以直接在浏览器中访问此链接获取到完整的固件。但对于H公司的智能路由器产品 ，虽可以通过这样的方式获得固件，但经过分析发现固件为加密固件，就无法进行分析了。

![检查更新/]()图4-1 M公司智能音箱软件更新捕获的流量

通过拆解设备主板的存储器获取，这种方式是更为有效的一种获取方式，但获取过程可能有破坏性。首先需要拆解设备外壳，并在主板上确定存储器芯片的位置、型号和焊接方式，之后需要使用焊接技术将存储器芯片取下，和特殊的编程器进行连接，并将编程器连接至计算机，通过计算机上的编程器专用软件提取出存储器中的内容，从而获得固件。例如B公司某家庭视听产品，首先拆解设备外壳并确定存储器芯片的型号为：三星电子KLM4G1FETE-B041，然后使用RT809H型号编程器进行存储器内容提取，最终得到了这款智能家居设备的固件。当然这种办法需要有拆解设备的能力，同时还需要专业的焊接设备和焊接人员支持，才能保证拆解之后的设备还可以继续使用，否则的话可能会对这款设备造成永久损坏。

![小度音箱主板图/]()图4-2 B公司某家庭视听产品主板图

![RT809H-Overview/]()图4-3 RT809H型号编程器

![Programmer-Software-Processing/]()图4-4 使用软件提取存储器固件示例

4.1.3 设备固件操作系统和文件系统分析

获取到的设备的固件一般是一个后缀名为bin二进制文件，所以还需要对这个文件进行提取和解压。提取和解压固件需要使用一款名为Binwalk的开源工具，Binwalk可以分析固件二进制文件中的操作系统、文件系统等信息，还可以将文件系统中包含的文件提取和解压，得到文件系统中的所有文件。

4.1.4 设备固件使用第三方库的分析

在确定了设备固件的操作系统和文件系统，并使用Binwalk解压得到文件系统中的所有文件后，就可以针对固件进行分析了。为了确定因使用第三方库而引入的安全风险，首先需要确定固件使用了哪些第三方库。在基于Linux的系统中，第三方库以可执行文件（elf文件）和动态链接库（so文件）的形式存在。可执行文件主要用于为用户使用提供接口，而绝大多数的功能实现都位于动态链接库文件中。在Linux系统中，动态链接库位于几个特定的路径下，例如/lib、/usr/lib和/usr/share/lib等，所以只需要确定动态链接库的名称，到以上路径下去搜索，即可定位到动态链接库文件的位置。例如OpenSSL是一个用于加密、数字签名、消息摘要和实现公钥基础设施的第三方库，其动态链接库名称为libcrypto.so，只需到上述路径搜索该文件即可。

获得到动态链接库文件之后，需要由版本检测算法来确定第三方库的版本，对于大多数动态链接库，在其二进制文件中就定义了版本信息，所以可以使用程序读取文件并按照特定的正则表达式进行搜索，即可得到其版本信息。依旧以OpenSSL库为例，在libcrypto.so文件中，OpenSSL的版本可以使用OpenSSL [0-1].[0-9].[0-9][a-z]?这一正则表达式来进行匹配。

在获取了第三方库的版本之后，就可以查询CVE数据库，来确定当前版本的第三方库存在哪些安全风险，在已知第三方库的名称和版本的情况下，受影响的CVE编号是很容易确定的。

4.1.5 设备固件厂商代码分析

针对设备固件厂商代码的分析，和一般的二进制文件分析相类似，可以应用二进制文件分析的手段和工具进行。对于智能家居设备而言，很多功能的实现需要使用C语言和底层进行交互，所以主要是针对C语言的逆向工程分析。由于C语言的自身特性，在分析时较为关注的内容是溢出、UAF、格式化字符串等问题。

4.2 针对管理端的安全测评方法

4.2.1 静态代码分析

（1）Android 平台的静态代码分析

Android平台上的应用程序的开发语言是Java、C和C++语言，安装文件格式为apk格式，本质是zip压缩包文件，其中包含了Java字节码文件（classes.dex）、Android动态链接库文件（位于lib文件夹中）、Android配置文件（AndroidManifest.xml）、资源文件（位于res文件夹中）和资产文件（位于assets文件夹中），可以通过Android应用反编译工具得到上述文件的可阅读版本。具体分析内容如下：

  • Android配置文件，可以了解Android应用程序的全貌，包括所需的权限、包含的活动、服务、内容提供者和广播接收器以及他们所接受的意图类型等。
  • Java字节码文件，可以了解Android应用程序的Java层逻辑，大部分智能家居应用程序将主要的业务逻辑都放在了Java中，所以这有利于我们分析智能家居应用程序的业务。
  • Android动态链接库文件，可以了解Android应用程序的原生层逻辑，大部分智能家居应用程序将比较敏感和底层的操作放在了原生层，所以针对Android动态链接库文件的分析往往是得到底层通信协议和发现通信协议中的缺陷的关键

（2）iOS 平台的静态代码分析

iOS平台上的应用程序的开发语言是Objective-C、Swift、C和C++语言，安装文件格式为ipa格式，本质也是zip压缩文件，其中包含了Unix可执行文件（与应用程序同名）、NIB界面布局文件、Apple配置文件（Info.plist）以及其它各类资源文件，可以通过解压缩工具直接得到上述文件的可阅读版本。

  • Apple配置文件，和Android配置文件类似，可以了解iOS应用程序的全貌，包括所需的权限、权限请求声明、安全选项配置等。
  • Unix可执行文件，iOS应用程序不支持第三方动态链接库，第三方库都以静态链接的方式编译进了这个可执行文件。所以我们可以了解iOS应用程序的逻辑以及使用了哪些第三方库。

4.2.2 动态代码分析

动态代码分析，主要有两种形式，一是进行程序调试，二是进行动态二进制插桩。程序调试是使用调试器软件附加到目标进程之上，取得进程的控制权，允许插入程序断点、单步执行和调试、查看内存与寄存器的内容等等。动态二进制插桩是在不修改程序二进制的情况下，通过修改函数调用栈或附加调试器修改内存的方式影响程序的运行，可以做到查看和修改函数实参、返回值，调用函数或取消函数调用等等。

在Android平台上进行程序调试，可以选择编译为user-debug（用户可调试）模式的Android系统，这样便可以调试该系统上的任意应用程序，如果没有这样的系统，也可以修改目标应用程序的Android配置文件选项，将其中的“android:debuggable”选项设置为“true”，也可以对该程序进行动态调试。

在Android平台上进行动态二进制插桩，目前主流的框架有Xposed框架和Frida框架。Xposed框架是通过替换Zygote进程的二进制文件实现的动态二进制插桩，Xposed可以装载自行开发的模块，实现对Java代码调用的拦截和修改，优点是可以进行永久的动态二进制插桩，缺点是每次修改模块需要重新引导Android系统。Frida框架是通过Linux的ptrace系统调用实现的动态二进制插桩，和调试器的原理一致，优点是不需要重新引导Android系统，缺点是不能进行永久性的动态二进制插桩。

在iOS平台上进行程序调试，需要使用越狱iOS，并且将调试服务器传输至iOS设备中并以root用户启动，这样才可以进行程序调试。

在iOS平台上进行动态二进制插桩，同样需要使用越狱iOS，目前一般使用Frida框架进行，使用方法和Android上的类似。

4.3 针对云端的安全测评方法

针对云端的Web服务器的安全测评，如果为非厂商安全测试人员进行测试，则只能进行盲测，可以使用各类Web漏洞扫描工具进行测试，或进行手工测试。对于厂商内部测试，一般会使用各类代码审计的框架进行。

4.4 本章小结

本章主要从设备端、管理端和云端的安全风险出发，讨论了针对这些安全风险的安全测评方法，为安全测评系统的实现打下基础。

第5章 智能家居系统安全测评系统的设计

在第4章中，研究和分析了智能家居系统安全测评方法，对于其中可进行自动化的安全测评方法，可以设计一款智能家居系统安全测评系统。本章主要阐述该安全测评系统的设计方案以及使用的技术。

5.1 系统功能

智能家居系统安全测评系统具有系统固件分析功能、移动应用静态分析功能和移动应用动态分析功能。其中移动应用静态分析功能支持Android和iOS平台应用程序，而移动应用动态分析功能仅支持Android平台应用程序。

![/]()图5-1 智能家居系统安全测评系统功能图

5.1.1 系统固件分析功能

系统固件分析功能支持第三方库的风险分析和平台风险分析。移动应用动态分析支持分析OpenSSL等九种使用量较大的第三方库，还支持一些平台风险分析功能，例如Linux用户帐户检测、计划任务检测和Linux远程登录可用性检测。

5.1.2 移动应用静态分析功能

针对Android平台的移动应用静态分析功能支持Android应用程序的权限检测、组件暴露检测、SSL弱校验检测。

针对iOS平台的移动应用静态分析功能支持iOS应用程序的权限检测。

5.1.3 移动应用动态分析功能

针对Android平台的移动应用动态分析功能支持针对Android应用程序的进程监控功能，包括敏感API调用、网络连接目标IP地址、明文数据传输、文件读写和数据库读写操作的监控。

5.2 系统总体设计

智能家居系统安全测评系统分为管理模块、安全测评模块、数据库模块和Android代理模块四部分。

![/]()图5-2 智能家居系统安全测评系统架构图

5.2.1 管理模块

管理模块使用浏览器-服务器架构（B/S架构），实际为一个Web服务器，功能是处理用户上传的固件和安装包文件、处理用户的检测请求、向安全测评模块发送检测请求、解析安全测评模块的检测结果并展示给用户，还负责管理反向代理模块及其端口分配。

5.2.2 安全测评模块

安全测评模块使用客户端-服务器架构（C/S架构），提供固件解压、Android应用程序安装包解压、第三方库版本检测和平台风险检测模块等功能。还包含一个套接字服务器，用于接受管理模块发送的检测请求并返回检测结果。

5.2.3 数据库模块

数据库模块使用关系数据库技术，存储CVE漏洞、平台风险检测点、第三方库类型、第三方库各版本对应的CVE漏洞集合、Android代理设备信息等。管理模块通过数据库接口访问数据库模块。

5.2.4 Android代理模块

Android代理模块是一个Android应用程序，需要申请root权限。功能是管理Android设备上的动态检测模块，并且可以在管理端注册此台Android设备，使得该设备可以接收安全测评模块的检测脚本，并执行Android动态检测。

5.3 相关技术简介

在实现智能家居设备安全测评系统的过程中，使用了各种技术，本节对使用到的技术进行介绍。

5.3.1 管理模块使用的技术

  1. （Java Platform, Enterprise Edition），此前称为J2EE，允许开发者使用Java技术构建和部署Web应用程序。管理模块使用Java EE技术作为Web服务器实现的方式。
  2. 框架，Spring框架提供了一个简单的方式开发Java EE应用程序，可以简化许多Java EE开发的流程。管理模块使用Spring框架来构建Web服务器。
  3. ，MyBatis提供了一种便捷的访问JDBC（Java Database Connectivity, Java数据库连接）接口的方式，支持各种类型的SQL语句，简化了Java EE应用程序和数据库的连接。管理模块使用MyBatis作为和数据库连接的手段。
  4. ，Bootstrap允许Web开发者构建更美观和协调的HTML界面，而不必自行编写许多样式表文件。
  5. ，jQuery简化了JavaScript语言的开发，同时还提供了异步执行HTTP请求的功能。

5.3.2 安全测评模块使用的技术

  1. ，Binwalk是Python下的一个软件包，可以分析固件二进制文件中的操作系统、文件系统等信息，还可以将文件系统中包含的文件提取和解压。安全测评模块使用Binwalk处理固件二进制文件。
  2. ，Jadx是一款Android反编译工具。安全测评模块使用Jadx处理Android应用程序安装文件。
  3. ，Frida是一款动态二进制插桩工具。安全测评模块使用Frida实现Android动态检测功能。

5.3.3 数据库模块

MariaDB，MariaDB是MySQL数据库的开源版本。数据库模块使用MariaDB作为数据库的实现。

5.3.4 Android代理模块使用的技术

  1. ，Frida是一款动态二进制插桩工具。Android代理模块可以管理手机上的Frida模块，实现Frida的一键安装、启动、停止以及卸载。
  2. ，Frp是一款使用Go语言开发的反向代理工具。因为Frida的实现是将Android设备作为服务器端，而计算机作为客户端，为了能使得位于网络上的服务器穿越网络地址转换访问到没有IPv4全球地址的Android设备，所以需要使用反向代理工具。Android代理模块可以管理手机上的Frp模块，实现Frp的一键安装、端口管理、启动、停止与以及卸载。

5.4 本章小结

本章阐述了智能家居系统安全测评系统的设计方案以及所用的技术，在明确了设计方案之后，即可按照该方案实现整个安全测评系统。

第6章 智能家居安全测评系统的实现

在第5章中叙述了智能家居系统安全测评系统的设计方案以及所用的技术，本章将对系统的实现方法以及系统的测试加以详细说明。

6.1 系统实现

在智能家居系统安全测评系统的具体实现中。用户使用浏览器访问管理模块的各项功能，在使用各项功能时，管理模块会请求数据库对应的信息，并且将检测请求发送给安全检测模块，安全检测模块在执行检测后将检测结果返回给管理模块，并由管理模块呈现给用户。

对于Android动态分析功能，首先需要在Android设备上安装Android代理应用程序，然后由代理应用程序配置好Frida服务器和Frpc模块并将其启动，代理应用程序会请求管理模块绑定一个供Frida控制端连接的远程端口，并向管理模块注册自身。完成此操作后用户即可选择列出的Android设备并执行检测，管理模块会首先将检测请求发送给安全检测模块，安全检测模块将对应的检测脚本发送给Android设备，并收集返回信息返回给管理模块，再由管理模块呈现给用户。

6.2 管理模块实现

管理模块在界面上为用户提供了系统固件静态分析、Android应用静态分析、Android应用动态分析、iOS应用静态分析这四个安全检测功能，同时还有第三方库CVE漏洞、安全检测历史和frps控制台三个辅助功能。下面将按照顺序介绍每个功能的实现方式。

6.2.1 主页实现

系统主页是一个导航页面，用于展示和介绍系统的主要功能，点击各个按钮可以快速访问对应的功能模块，没有实际的功能。

![/]()图6-1 智能家居设备安全测评系统主页

6.2.2 系统固件静态分析页面实现

系统固件静态分析页面承载了固件分析功能，用户只需要上传获得到的智能家居设备固件文件（后缀名为bin）并点击“开始分析”按钮，系统将自动对上传的设备固件文件进行分析，分析完成后将在“分析结果”区域显示分析的结果。

![/]()图6-2 系统固件静态分析页面

下面阐述管理模块是如何对固件分析请求进行处理的。

第一步，管理模块在收到固件分析的请求后，将上传的固件文件保存至服务器的/attach/uploads/firmware/{随机UUID}/路径下，由于有随机的UUID存在并且在安全配置中禁止前端直接访问此路径，这样可以确保安全性。

第二步，管理模块会请求安全检测模块执行固件解压和提取操作，得到固件的基本信息，包括固件的名称、路径、大小、文件系统和文件系统根目录，此操作将为后续的检测打下基础。

第三步，管理模块会请求数据库，从数据库中获取已知的第三方库种类，为第三方库漏洞检测做准备。

第四步，管理模块会请求安全检测模块进行第三方库版本识别，管理模块将第三方库的名称发送给安全检测模块，安全检测模块会检测第三方库是否被使用，如果被使用了则调用版本识别算法，识别出版本返回给管理模块。

第五步，管理模块会请求数据库，从数据库中获取指定版本第三方库的漏洞情况，数据库将返回一个当前版本第三方库包含的CVE编号列表，此处并没有对CVE漏洞本身是否存在进行检测，因为如果要检测则需要构建数量众多的漏洞检测算法脚本。本系统选择的是用第三方库版本去匹配CVE编号列表，这些信息是整理自CVE漏洞库，所以具有权威性和正确性。

第六步，管理模块会请求数据库，从数据库中获取已知的平台风险，为平台风险检测做准备。

第七步，管理模块会请求安全检测模块进行平台风险检测，安全检测模块会检测是否存在这些平台风险，然后将结果返回给管理模块。

第八步，管理模块将检测结果返回给浏览器，呈现给用户。

6.2.3 Android应用静态分析页面实现

Android应用静态分析页面承载了Android静态分析功能，用户只需要上传Android应用程序安装包文件（后缀名为apk）并点击“开始分析”按钮，系统将自动对上传的Android应用程序安装包文件进行分析，分析完成后将在“分析结果”区域显示分析的结果。

![/]()图6-3 Android应用静态分析页面

Android应用静态分析功能的工作原理与系统固件静态分析相类似，区别是缺少系统固件静态分析的第三、四、五步骤，因为Android应用程序使用的第三方库差异较大，同时对智能家居系统的安全性影响较小，所以没有检测第三方库的使用情况。

6.2.4 Android应用动态分析页面实现

Android应用动态分析页面承载了Android动态分析的功能，用户首先需要在取得了root权限的Android设备上配置并启用Android代理应用程序，然后该设备才能在Android应用动态分析页面上显示。用户可以点击“检测”按钮，选择需要检测的目标进程以及检测项目，点击“开始检测”后，用户可正常在Android设备上使用智能家居设备管理端程序，在页面上点击“停止检测”后，即可获得检测结果。

![androidDym/]()图6-4 Android应用动态分析页面

下面将阐述管理模块是如何对Android应用动态检测请求进行处理的。

第一步，在加载Android应用动态分析页面或者用户点击了“刷新设备”按钮时，管理模块会请求数据库中的已保存的在线Android代理设备，并显示在界面上。如果用户已在Android设备上安装并启用了Android代理应用程序，界面将会显示该设备。

第二步，在用户点击某个设备行中的“检测”按钮后，管理模块会请求安全检测模块获取该设备的进程列表，并将其显示在界面上。用户需要选择一个目标进程并勾选需检测的项目，检测项目即对应Android动态分析功能中的五个检测点。

第三步，在用户点击了“开始检测”按钮后，管理模块会将设备的信息、目标进程和五个检测点的选择情况发送给安全检测模块，安全检测模块会按照要求选择对应的检测脚本进行检测。

第四步，在用户点击了“停止检测”按钮后，管理模块将从安全检测模块收集检测结果，并显示在页面上。

此外，页面还提供了自定义检测的高级功能，允许用户自行编写检测脚本并执行上述流程。

6.2.5 iOS应用静态分析页面实现

iOS应用静态分析页面承载了iOS静态分析功能，用户只需要上传iOS应用程序安装包文件（后缀名为ipa）并点击“开始分析”按钮，系统将自动对上传的iOS应用程序安装包文件进行分析，分析完成后将在“分析结果”区域显示分析的结果。

![/]()图6-5 iOS应用静态分析页面

需要注意的是，上传的iOS应用程序安装包文件必须去除保护（一般安全界俗称为“脱壳”操作），本检测系统不提供iOS应用程序保护的去除功能，用户需要手动进行此操作。首先使用越狱iOS设备登录App Store下载目标应用程序，然后运行苹果App Store应用保护去除工具，得到已去除保护的iOS应用程序安装包文件。

iOS应用静态分析功能的工作原理与系统固件静态分析相类似，区别是缺少系统固件静态分析的第三、四、五步骤，因为iOS应用程序不支持动态链接库，无法执行这样的检测。

6.2.6 辅助功能实现

在辅助功能方面，第三方库CVE漏洞查询功能可以在不执行固件检测的情况下直接访问数据库模块中保存的漏洞情况。安全检测历史功能可以查看已经执行过的检测历史记录。Frps控制台是Frp模块自身提供的页面，展示了连接到反向代理的设备和设备的传输流量的情况，有助于诊断Android动态分析中无法找到Android代理设备的问题。

6.3 安全检测模块实现

安全检测模块包含了一些Python脚本，实现了各类检测功能。还实现了一个套接字服务器，用于接收管理模块发送的请求。

6.3.1 套接字服务器实现

套接字服务器绑定了本机的8081端口，使用的是多线程的TCP服务器。管理模块请求使用的是JSON字符串，包含命令字段和参数字段。在接收到管理模块发送的请求后，首先解析出命令字段，将命令字段分解为命令集合和具体命令。例如管理模块在要求安全检测模块执行固件信息获取操作时，请求的命令字段为“FwService.get_fw_info”，其中“FwService”代表命令集合，所有和固件相关的操作都属于该命令集合，“get_fw_info”代表具体命令，表示要执行固件信息获取。然后解析出参数字段，参数字段由各个检测功能模块按照约定的名称自行提取。解析成功后就会调用对应的模块，并将结果返回。提供给管理模块的响应也使用JSON字符串，包括状态码、状态原因和具体的数据。

![/]()图6-6 套接字服务器对一次请求的处理流程图

6.3.2 固件文件解压模块实现

固件文件解压模块接收管理模块中固件分析功能发送的固件文件信息，该模块首先调用了Binwalk对固件进行分析，判断出固件的操作系统和文件系统，然后再次调用Binwalk对固件进行解压，获得固件文件系统的根目录，并将这些信息通过套接字服务器返回给管理模块。

6.3.3 APK文件反编译模块实现

APK文件反编译模块接收管理模块中Android静态分析功能发送的APK文件信息，该模块直接调用Jadx命令行工具对APK文件进行反编译，并返回APK文件的各类信息。

6.3.4 IPA文件解压模块实现

IPA文件解压模块接收管理模块中iOS静态分析功能发送的IPA文件信息，该模块直接调用解压缩工具对IPA文件进行解压，并返回IPA文件的各类信息。

6.3.5 固件第三方库版本识别模块实现

固件第三方库版本识别模块接收管理模块中固件分析功能发送的固件信息和第三方库名称，该模块将调用对应第三方库的版本识别算法。以OpenSSL库为例，OpenSSL的动态链接库文件名称为“libcrypto.so.1.0.0”，“libcrypto.so”为一个符号链接指向了“libcrypto.so.1.0.0”，文件所在目录可能为“/lib”、“/usr/lib”、“/usr/lib/ssl/”、“/usr/local/lib/”或“/usr/local/lib/ssl/”中的一个。所以首先程序在上述目录中寻找目标文件，如果未找到则返回未使用该第三方库，假设文件位于“/usr/local/lib/”中，然后程序再尝试打开文件“/usr/local/lib/libcrypto.so.1.0.0”，将其读入内存中，由于OpenSSL的版本号格式符合正则表达式“OpenSSL [0-1].[0-9].[0-9][a-z]?”，所以就通过该正则表达式，在文件内容中以二进制的形式进行匹配，匹配成功即完成了版本识别算法并返回了版本号。其他第三方库版本识别算法和OpenSSL相类似。

![/]()图6-7 OpenSSL第三方库版本识别算法流程图

6.3.6 平台风险检测模块实现

平台风险检测模块接收管理模块中固件分析功能、Android静态分析功能或iOS静态分析功能发送的文件信息，该模块调用不同的平台风险检测算法进行检测，并取得返回结果。各个平台风险检测算法的原理差异较大，这里仅以Android SSL弱校验风险为例进行说说明。

Android SSL弱校验风险指的是在Android应用程序中，使用SSL进行通信时，没有对服务器的证书进行校验，检测方法即是检测是否存在将“checkServerTrusted”方法体设置为空的情况。所以程序需要首先遍历由APK文件反编译模块生成的Android应用程序Java伪代码树，在其中匹配该函数的存在并检测其方法体是否为空。若检测到了即返回存在该项风险，否则返回不存在该项风险。

6.3.7 Frida管理模块实现

Frida管理端模块接收管理模块中Android动态分析功能发送的请求，该模块首先从请求中提取目标设备在本地映射的端口号和目标进程名称，然后调用Frida的设备管理器和该设备建立连接并附加到目标进程上，再根据请求中启用了的检测项目，下发相应的JavaScript检测脚本到设备上，并读取设备返回的内容即可。若使用的是自定义JavaScript检测脚本，则会下发用户上传的检测脚本到设备。

6.4 数据库模块实现

数据库模块使用了MariaDB关系数据库，图6-8给出系统数据库设计的E-R图。下面简要介绍数据库中的各个表结构。

  1. cve：存储了CVE漏洞的基本信息，包括CVE漏洞的CVE编号、级别、描述和适用平台。
  2. device：存储了Android代理设备的信息，包括客户端ID、设备名称、Android版本和API级别、代理模块版本、映射端口以及在线状态。
  3. third_library：存储了第三方库的种类，包括库名称和描述。
  4. library_risk：存储了第三方库版本和CVE编号的映射关系，每个映射关系包括第三方库名称、第三方库版本和CVE编号。
  5. platform_risk：存储了平台风险检测点，包括风险名称、风险描述、风险级别、风险适用平台以及用于安全检测模块的检测指令。

在前期工作中，需要在CVE漏洞库中收集第三方库版本和CVE编号的映射关系，通过阅读某个第三方库的所有CVE编号，识别出每个CVE编号受影响的第三方库版本，然后将这些信息整理成表格再批量导入数据库中。

![/]()图6-8 智能家居系统安全测评系统数据库E-R图

6.5 Android代理模块实现

Android代理模块是一个Android应用程序，提供了对Frida服务器和Frpc的管理功能，实现了这两个模块的版本获取、下载、安装、启动、停止和卸载。除此之外Android代理模块还需要向管理模块请求绑定的端口，并且向管理模块注册本设备。

![Screenshot_20190527-203916_SecIoT_Agent/]()![Screenshot_20190527-203908_SecIoT_Agent/]()图6-9 Android代理应用SecIoT Agent运行截图

上图6-9给出了Android代理应用SecIoT Agent运行示例。该模块的具体实现过程如下：

![/]()图6-10 Android动态检测实现示意图

Frida服务器和Frpc版本的获取是通过HTTP请求进行的，Android代理模块会请求管理模块，而管理模块会返回版本号，执行此操作后才允许安装Frida服务器和Frp客户端。

Frida服务器和Frpc的下载也是通过HTTP请求进行的，Android代理模块会识别出设备的体系结构，然后下载合适版本的软件包。

Frida服务器和Frpc的安装和卸载需要root权限才能执行，安装操作是将Frida服务器组件的文件写入至“/data/local/tmp/seciot/frida/{版本号}/”路径下，例如“/data/local/tmp/seciot/frida/12.5.0/”，还要将Frp客户端组件的文件写入至/data/local/tmp/seciot/frp/{版本号}/”路径下。卸载即是直接删除上述两个路径。

Frida服务器的启动是直接启动Frida服务器的可执行文件即可，而Frpc在启动之前会要先向管理模块请求绑定一个远程端口，在请求到端口后再进行配置文件的写入以及启动。

在所有模块启动成功后，Frpc会先和Android设备的27042端口建立连接来连接到Frida服务器，再和服务器上的Frps建立连接，充当反向代理的功能，并且向Frps注册绑定一个远程端口。之后Android代理模块会向管理端注册自身的信息，表明该设备处于在线状态，并提供设备的其他信息。如果用户关闭了模块，则Android代理模块会向管理端注册自身下线。

在Android设备上的目标进程接收管理模块的动态检测请求时，首先安全检测模块会根据管理模块的请求，连接到服务器上的映射端口，该映射端口的套接字由Frps管理，Frps会通过和Frpc的连接将数据传输到Android设备上，最终发送至Frida服务器中，就好像安全检测模块的Frida管理端和Android设备的Frida服务器直接建立了连接一样。Android代理模块不负责传输检测数据，这些数据全部经由Frp的代理隧道传输。当用户开始使用被检测的应用程序时，可使Android代理模块进入后台运行，但不能将其退出。

6.6 系统测试

6.6.1 系统固件分析功能测试

针对系统固件分析功能的测试，使用了M品牌的两款智能路由器产品和一款智能音箱的固件、以及H公司的一款智能路由器产品、一款智能音箱产品和一款智能摄像机产品进行测试，固件的来源为通过官方网站获取、通过对软件更新的流量进行捕获获取以及通过拆解设备主板的存储器获取，全部为官方最新版本的固件。测试结果如表6-1所示。

表6-1 系统固件分析功能测试结果

序号 固件来源 第三方库数量 (检出数/总检测数) 第三方库风险数量 (单位：项) 平台风险数量 (检出数/总检测数)
1 M品牌路由器1 4/10 2 1/4
2 M品牌路由器2 6/10 2 2/4
3 M品牌智能音箱 6/10 13 2/4
4 H品牌路由器 固件加密，无法分析 固件加密，无法分析 固件加密，无法分析
5 H品牌智能音箱 固件加密，无法分析 固件加密，无法分析 固件加密，无法分析
6 H品牌智能摄像机 固件加密，无法分析 固件加密，无法分析 固件加密，无法分析

由测试结果可以得知，M品牌对于其路由器产品的安全性较为重视，因为M品牌的路由器出货量较大，且路由器产品关乎家庭入口安全。但是M品牌智能音箱产品的安全性明显弱于路由器产品，M品牌智能音箱产品是目前国内销售量最大的智能音箱产品，此检测结果显示出其安全的脆弱性，实在是令人担忧。同时H品牌产品的固件全部进行了加密，无法进行分析，安全性较强。

6.6.2 移动应用静态分析功能测试

针对移动应用静态分析功能的测试，Android平台方面使用了H品牌的智能音箱应用、智能摄像机应用、随身Wi-Fi应用、HO品牌的智能摄像机应用、HQ品牌的智能摄像机应用，以及M品牌的智能家居应用和智能音箱应用进行测试，应用版本全部为应用商店中的最新版本，测试结果如表6-2所示。iOS平台方面使用了H品牌的智能音箱应用、智能摄像机应用和HO品牌的智能摄像机应用进行测试，应用版本全部为应用商店中的最新版本，测试结果如表6-3所示。

表6-2 移动应用静态分析功能（Android平台）测试结果

序号 应用程序名称 所需权限数量 (单位：项) 平台风险数量 (检出数/总检测数)
1 H品牌智能音箱应用Android版 40 1/2
2 H品牌智能摄像机应用Android版 23 2/2
3 HO品牌智能摄像机应用Android版 23 2/2
4 HQ品牌智能摄像机应用Android版 37 1/2
5 H品牌随身Wi-Fi应用Android版 33 2/2
4 M品牌智能家居应用Android版 77 2/2
5 M品牌智能音箱应用Android版 39 1/2

表6-3 移动应用静态分析功能（iOS平台）测试结果

序号 应用程序名称 所需权限数量 (单位：项) 平台风险数量 (检出数/总检测数)
1 H品牌智能音箱应用iOS版 5 2/2
2 H品牌智能摄像机应用iOS版 6 2/2
3 HO品牌智能摄像机应用iOS版 6 2/2

由测试结果可以得知，无论是哪种品牌，其Android版应用所需权限数量都远超iOS版，这也符合我们一般的认知。同时两个平台都能检测出一些平台安全风险，证明了系统的有效性。

6.6.3 移动应用动态分析功能测试

针对移动应用动态分析功能的测试，使用了H品牌的智能家居应用、智能音箱应用、智能摄像机应用，以及M品牌的智能家居应用和智能音箱应用进行测试，由于该项测试测试时间越长输出日志数目越多，所以没有统计日志数量，测试结果如表6-4所示。

表6-4 移动应用动态分析功能（Android平台）测试结果

序号 应用程序名称 敏感API调用日志 连接IP地址日志 明文传输日志 文件读写日志 数据库读写日志
1 H品牌智能家居应用Android版 有 有 无 有 有
2 H品牌智能音箱应用Android版 有 有 有 有 有
3 H品牌智能摄像机应用Android版 有 有 有 有 有
4 M品牌智能家居应用Android版 有 有 有 有 有
5 M品牌智能音箱应用Android版 无 有 有 有 有

由测试结果可以得知，移动应用动态分析功能有效。敏感API调用为动态申请权限，该功能从Android M版本开始提供，M品牌智能音箱应用Android版未对Android M进行适配，所以无此项日志。

6.7 本章小结

本章阐述了智能家居系统安全测评系统的实现方法和对系统的测试结果。展现了智能家居系统安全测评系统的全貌和细节，实现了所讨论的智能家居系统安全测评技术。

第7章 总结和展望

本文针对智能家居系统的安全性问题，从网络安全的视角，首先说明了智能家居设备的分类，并提出了智能家居系统“端-管-云”的三元系统架构。然后从“端-管-云”三元系统架构出发，分别分析了智能家居系统中这三部分的安全风险，并讨论了针对这三类不同安全风险的安全测评技术。最后根据讨论的智能家居系统安全测评技术，设计并实现了一套智能家居安全测评系统，这套系统基于Web技术构建，整合了Binwalk、Jadx、Frida等多种现有的独立安全测评工具，实现了基于云端的系统固件、Android应用程序和iOS应用程序的静态安全检测功能，以及基于云端的Android应用程序的动态安全检测功能，涵盖了智能家居系统安全测评技术的主要部分。经过对主流的智能家居设备与系统进行测试，该系统可以有效地检测出系统中的各类安全风险，能辅助智能家居厂商或第三方安全测评机构的安全测评人员对智能家居系统的安全性进行评估，并根据安全测评系统产生的安全风险提示判断智能家居系统中存在的安全漏洞，这对智能家居安全研究具有重要的意义。

在智能家居系统安全测评技术的研究过程中，针对智能家居设备引导加载器中安全风险，以及对智能家居操作系统内核的风险，尚没有做深入的研究，同时针对厂商自研操作系统的分析也没有开展。此外，关于智能家居设备硬件的研究，是在华为公司开展的，华为公司拥有专业的硬件焊工，以及专业的硬件焊接设备，还有各类存储器芯片的编程器，这些资源对智能家居设备硬件的研究提供了很大帮助，但这些资源同时也是智能家居设备硬件研究的门槛，在学校中并不具备这些资源。这些是研究中需要解决的问题和可以深入的方向。

在智能家居安全测评系统的设计与实现过程中，针对智能家居设备固件的动态分析，以及对iOS平台应用程序的动态分析，是尚未实现的部分。同时系统所支持的第三方库种类和平台风险点数量依旧较少，在基于现有系统框架的基础上补充这些数据，可以提升检测的效果。这些是设计与实现系统中需要解决的问题和可以深入的方向。

参考文献