物联网渗透测试（一）：简介

编者按：本文节选自华章网络空间安全技术丛书《物联网渗透测试》一书中的部分章节。

简介

本章主要关注开展 IoT 渗透测试所需的基础知识，向读者介绍 IoT 设备攻击面的基本概念，为帮助测试人员构建 IoT 渗透测试的实验环境奠定基础。

我们首先讨论当前 IoT 渗透测试的现状，以及所有可能存在的攻击面，进而了解渗透测试的进展情况。之后我们将介绍固件安全、Web 应用安全、移动应用安全、硬件安全和无线电通信方面的基础知识。

最后，我们将向读者介绍如何对开展渗透测试所需的软硬件工具进行配置。

定义 IoT 生态系统与渗透测试生命周期

在过去的几年中，基于 IoT 设备不断上涨的数量、为业务提供的便利性、自身的易用性以及为信息安全带来的潜在风险等诸多因素，IoT 设备赢得了广泛关注。由于 IoT 概念的火爆就出现在我们身边，所以即便是作为一个普通人也可以感受到这个技术奇点>¹距离自己并不遥远。而对 IoT 和互联网越来越高的依赖度使得人们不由地对人身安全、隐私安全与信息安全产生了担忧。同时，IoT 设备几乎已经用在所有行业领域，如消费、娱乐业、工商业、医疗业、工业、能源业以及制造业等领域。但是，过往案例已经证明了无论是消费者还是将 IoT 技术商用的厂商和开发者，都难以采取有效的方式来确保设备安全。如果指望设备厂商在制造设备时采用诸如安全设计之类的方法提供安全保障，又严重依赖于设备所面向的行业，那么需要厂商对行业业务具有深刻的理解，这对厂商显然提出了非常高的要求。

¹ 技术奇点是一个根据技术发展史总结出的观点，认为未来将要发生一件不可避免的事件：技术发展将会在很短的时间内发生极大的接近于无限的进步。一般设想技术奇点由超越现今人类并且可以自我进化的机器智能或者其他形式的超级智能的出现所引发。由于其智能远超今天的人类，因此技术的发展会完全超乎全人类的理解能力，甚至无法预警其发生。之所以被称为奇点，就是像物理学上引力接近无穷大时产生的黑洞的物理属性一样，已经超出一般正常模型所能预测的范围。—译者注

各个行业也可能因垂直细分与所处区域而制订不同的测试规范。因此，为了确保不违反相关法律规定，在对 IoT 设备开展渗透测试之前需要了解有关的法律法规。在部分地区，我们以美国为例，只要研究是出于符合社会规范的善意目的，通过合法渠道获得被测设备，在受控环境下开展测试，并且也未违反 2016 年 10 月颁布的《计算机欺诈和滥用法案》（Computer Fraud and Abuse Act，CFAA），那么是允许安全人员对消费级设备开展安全研究的，并且不受《数字千年版权法》（Digital Millennium Copyright Act，DMCA）的追究。这也就意味着当前对网联汽车、摄像头、各种智能家居设备、视频游戏机和越狱移动设备的安全研究都是合法的。在经过与《数字千年版权法》和安全界的漫长协调之后，广大安全研究人员取得了一个巨大的胜利。

在取得相关法律法规许可的情况下（这也是我们开展安全测试的依据所在），接下来将对设备固件、Web 应用、移动应用、硬件和无线电通信开展安全评估。首先，我们需要了解 IoT 所涉及的所有领域，包括渗透测试方法和生命周期，进而识别出所有可能的攻击面。下面我们来了解一下 IoT 设备中各组件的基本原理，以便知晓其攻击原理。

渗透测试方法

无论是否出现攻击事件，对应用、网络和设备开展安全测试、查找其中隐藏的漏洞对于保障互联网安全都是至关重要的。无论是由厂商、第三方咨询公司、企业安全团队，还是由普通的安全人员来实施测试，测试方法的选择都取决于能够提供给测试人员的信息。理想情况下，一次全面的测试应该包括整个 IoT 系统及其基础设施，而不仅仅是 IoT 设备本身，但考虑到成本与技术能力，现实中的通常只针对 IoT 系统中的某个子集开展测试。

1. 黑盒测试

由于黑盒测试成本相对较低，因此黑盒测试是最为常见的测试方法。黑盒测试是在不了解设备所采用的技术原理或实现方式的情况下进行的测试。通常情况下，安全研究人员或第三方咨询公司都会采用黑盒测试方法，但有时内部安全团队也会采用该方法进行风险评估。

漏洞公开注意事项

如果在安全研究过程中挖掘出了漏洞，那么披露漏洞时需要遵循厂商要求的漏洞公开流程。如果厂商未制订漏洞公开流程，那么计算机安全应急响应中心（CERT）可以协助安全研究人员以适当的方式提交漏洞。关于 CERT 的漏洞公开处理流程的详细内容可以参考链接http://www.cert.org/vulnerability-analysis/vul-disclosure.cfm中的内容。

2. 白盒测试

如果测试人员能够接触到源代码、网络拓扑图、架构图、数据流图以及其他目标设备所采用技术的详细信息，那么此时开展的测试即白盒测试。通常来说，预先能够向测试人员提供的目标设备或应用的信息越多，测试效果就会越好。白盒测试的成本相对较高，但能够确保对设备的安全控制措施及其实现情况进行更加全面、彻底的筛查。

3. 灰盒测试

相对于被测机构内部人员而言，如果测试人员对被测系统的了解有限，仅能获取到被测系统的部分信息，那么此时所开展的测试即灰盒测试。在灰盒测试过程中，测试人员通常只知道所用到的应用程序栈和库文件，但是没有关于 API 的详细文档。

读者可以访问以下链接了解更多开展安全研究过程中有关《数字千年版权法》（DCMA）的内容：https://www.ftc.gov/news-events/blogs/techftc/2016/10/dmca-secu-rity-research-exemption-consumer-devices。

固件入门

固件是一种写入硬件设备的软件，作用是对应用和各项系统功能实施控制。固件中包含底层代码，这些代码能够帮助软件实现对硬件的操作。运行固件的设备称为嵌入式系统，嵌入式系统的硬件资源在存储能力以及内存等方面往往具有诸多限制。举例来说，智能手机、交通信号灯、网联汽车、某些类型的专用计算机、无人机和有线机顶盒都是运行固件的嵌入式设备。

显然，从城市运行所依赖的关键基础设施，到人们生活中必不可少的银行 ATM 和智能家居，嵌入式技术及运行在嵌入式设备之上的固件控制着我们的日常生活。理解固件的二进制文件中都包含哪些内容以及与之关联的属性是非常重要的。固件通常由 bootloader、内核、文件系统以及其他资源组成。根据嵌入式 Linux、嵌入式 Windows、Windows IoT 内核以及各种实时操作系统（Real Time Operating System，RTOS）的区别，固件也有多种类型。本书主要针对基于嵌入式 Linux 的环境进行介绍，但是，本书中所涉及的原理对于其他平台也是同样适用的。

读者可以从以下链接中了解更多关于固件的内容：https://wiki.debian.org/Firmware。

图 1 展示了固件的组成，即闪存、bootloader、内核和根文件系统。

图 1　固件组成示意图

固件深度分析

首先让我们先了解一下 bootloader。bootloader 的作用主要包括 RAM 初始化（目的是存储易失性数据）、串口初始化、机器类型检测、内核参数链表（kernel tagged list）设置、 initramfs（基于 RAM 的初始文件系统）加载以及内核镜像调用等。bootloader 通过板级支持包（Board Support Package，BSP）初始化硬件驱动，其中板级支持包通常由第三方厂商开发。可以将 bootloader 存储在单独的电可擦除可编程只读存储器（Electrically Erasable Programmable Read-Only Memory，EEPROM）中，但这种情况一般不太常见，更为常见的形式是直接将 bootloader 写入闪存存储器。从某种程度上说，我们可以将 bootloader 看作启动 PC 时的 BIOS。深入分析 bootloader 的各项功能已经超出了本书所讨论的范畴，这里我们只对本书用到的 bootloader 特性进行介绍。ARM、MIPS 架构中部分常见的 bootloader 包括：Redboot、u-boot 以及 barebox 等。当 bootloader 启动内核之后，文件系统就完成了加载。

固件可以采用的文件系统类型有很多，有时根据设备的区别也会采用某些专有文件类型。部分较为常见的文件系统类型包括 SquashFS、cramFS、JFFS2、YAFFS2 以及 ext2 等。其中设备（尤其是消费级电子设备）最常采用的文件系统是 SquashFS。分析人员可以使用诸如 unsquashfs 或者改进后的 unsquashfs 等工具从 SquashFS 文件系统中提取数据。有部分厂商会对 SquashFS 文件系统进行改进，以确保能够对非标准的 SquashFS 文件系统压缩算法提供支持，比如说 LZMA 压缩算法（在 SquashFS 4.0 之前，官方支持的唯一压缩格式为.zlib），而此时就需要用到改进后的 unsquashfs 工具进行解压，同常规的标准 SquashFS 文件系统相比，非标准的 SquashFS 文件系统启动时的偏移量同之前会有所区别。在本书后面的内容中，我们将会对偏移的定位与识别进行专门的介绍。

读者如果想了解有关嵌入式 Linux 文件系统的更多内容，可以访问以下链接：http://elinux.org/images/b/b1/Filesystems-for-embedded-linux.pdf。

Sasquatch 是一套能够对非标准 SquashFS 文件系统进行解压、从中提取文件系统的工具，即可以从以下链接下载：https://github.com/devttys0/sasquatch。

与之类似，固件镜像也可以采用 LZMA、.gzip、.zip、.zlip 和.arj 等多种文件压缩类型。每种文件类型在压缩后的文件尺寸、压缩时间、解压时间以及设备自身的业务需求等方面都各有擅长。从渗透测试的角度出发，我们可以把文件系统看作存储配置文件、服务、账户口令、散列值、应用程序代码以及启动脚本的地方。在下一章中，我们将介绍如何查找设备中的文件系统，以及如何确定其采用的压缩方式。

固件的开发供应链

文件系统中包含同设备强相关的代码，这些代码通常采用 C、C++或者 Lua 之类的编程语言编写。与设备相关的代码，甚至是固件自身，都可以外包给第三方开发人员，即原始设计制造商（ODM），也可以由内部开发人员同原始设备制造商（OEM）协作开发。ODM 是嵌入式设备开发供应链中的一个重要环节。在亚洲，有很多这样的小公司，并且开发成本也较为低廉。有些 OEM 信任自己产品线上的 ODM，而有些 OEM 则会选择对单一产品报价最低的 ODM。在某些行业中，ODM 也可以称为供应商。需要特别注意的是，ODM 是能够同多家不同的 OEM 开展合作的，甚至可以采用相同的代码库。读者可能已经知道这个情况，或者惊讶于为什么一个严重的软件漏洞公告就会影响到十余家设备厂商。究其原因就在于 ODM 自身并未建立安全开发生命周期流程，而 OEM 对此也疏于验证。一旦 ODM 完成了应用开发成果的交付，这个成果可能是 OEM 的一个 SDK 也可能是固件，OEM 就会直接把交付的代码融入固件之中，实现起来可能就是简单地在 Web 界面添加 OEM 的一个 logo。根据 ODM 和 OEM 代码融合方式的不同，实现过程也有所区别，其中一种较为常见的方式是，ODM 向 OEM 直接提供二进制文件。OEM 负责固件分发、固件管理以及对设备自身提供支持，其中也包括解决第三方研究人员提交的固件安全问题，如果 ODM 持有源代码，而 OEM 仅能拿到二进制文件，那么 OEM 难以有效缓解固件中的安全隐患，从而将面临巨大的压力。

在第 3 章中，我们将通过了解如何识别文件系统、压缩方式，以及如何构建二进制文件的仿真测试环境来实现对固件二进制镜像的逆向分析，进而对固件中常见的漏洞开展利用。

图书简介：https://item.jd.com/12623610.html