网络空间安全技术丛书
点击查看第二章
点击查看第三章
物联网渗透测试
IoT Penetration Testing Cookbook

亚伦·古兹曼（Aaron Guzman）
阿迪蒂亚·古普塔（Aditya Gupta）
王　滨　戴　超　冷　门　张　鹿　译

第1章

IoT渗透测试
虽然1999年美国麻省理工学院（MIT）的自动识别实验室（Auto-ID Labs）就首次提出了IoT（物联网）的概念，但嵌入式设备技术在数十年之前就已存在了。IoT设备同嵌入式设备之间的区别在于，在嵌入式设备的设计决策和配置过程中，从未将建立自身同公共互联网的连接考虑在内。正是由于众多制造业公司没有考虑到设备联网的后果，所以随着联网设备数量的不断增多，当前出现了针对IoT设备的大规模漏洞利用，并导致了多起创纪录的大规模分布式拒绝服务（Distributed Denial of Service，DDoS）攻击。本书中，我们将从多个方面介绍针对IoT设备的渗透测试，为测试人员提供具有可操作性的安全实践指导，并帮助用户在现实环境中实现对IoT设备的攻击防护。
读者可以访问以下链接了解IoT的起源：http://autoid.mit.edu/iot_research_initiative 。
要了解针对IoT设备的DDoS攻击详情，可以访问以下链接：https://www.us-cert.gov/ncas/alerts/TA16-288A 。
本章将主要介绍以下主题：

• 定义IoT生态系统与渗透测试生命周期。
• 固件入门。
• IoT中的Web应用。
• IoT中的移动应用。
• 硬件设备基础。
• IoT无线通信简介。
• IoT渗透测试环境的部署。

1.1　简介

本章主要关注开展IoT渗透测试所需的基础知识，向读者介绍IoT设备攻击面的基本概念，为帮助测试人员构建IoT渗透测试的实验环境奠定基础。
我们首先讨论当前IoT渗透测试的现状，以及所有可能存在的攻击面，进而了解渗透测试的进展情况。之后我们将介绍固件安全、Web应用安全、移动应用安全、硬件安全和无线电通信方面的基础知识。
最后，我们将向读者介绍如何对开展渗透测试所需的软硬件工具进行配置。

1.2　定义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 。

1.3　固件入门

固件是一种写入硬件设备的软件，作用是对应用和各项系统功能实施控制。固件中包含底层代码，这些代码能够帮助软件实现对硬件的操作。运行固件的设备称为嵌入式系统，嵌入式系统的硬件资源在存储能力以及内存等方面往往具有诸多限制。举例来说，智能手机、交通信号灯、网联汽车、某些类型的专用计算机、无人机和有线机顶盒都是运行固件的嵌入式设备。
显然，从城市运行所依赖的关键基础设施，到人们生活中必不可少的银行ATM和智能家居，嵌入式技术及运行在嵌入式设备之上的固件控制着我们的日常生活。理解固件的二进制文件中都包含哪些内容以及与之关联的属性是非常重要的。固件通常由bootloader、内核、文件系统以及其他资源组成。根据嵌入式Linux、嵌入式Windows、Windows IoT内核以及各种实时操作系统（Real Time Operating System，RTOS）的区别，固件也有多种类型。本书主要针对基于嵌入式Linux的环境进行介绍，但是，本书中所涉及的原理对于其他平台也是同样适用的。
读者可以从以下链接中了解更多关于固件的内容：https://wiki.debian.org/Firmware。
图1-1展示了固件的组成，即闪存、bootloader、内核和根文件系统。

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

1.3.2　固件的开发供应链

文件系统中包含同设备强相关的代码，这些代码通常采用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章中，我们将通过了解如何识别文件系统、压缩方式，以及如何构建二进制文件的仿真测试环境来实现对固件二进制镜像的逆向分析，进而对固件中常见的漏洞开展利用。

1.4　IoT中的Web应用

网站，也称为Web应用，已经无须对其进行过多的介绍了。基本的Web应用程序通常最少由前端HTML页面、JavaScript脚本、1台后台Web服务器、1台应用程序服务器和1套数据库组成。随着Web应用的发展，为了降低后端架构或设备的计算载荷，Web应用程序开始更多地依赖JavaScript脚本等前端代码。但是运行在互联网中的Web应用同运行在嵌入式设备中的Web应用略有不同。
读者所熟悉的Web应用组件之间存在更多的依赖关系，因为常见的Web应用会将Web服务器、应用服务器、数据库服务器以及后台运行的微服务进行分离。其中服务器的分离是出于性能和可用性等方面的考虑。而通常嵌入式Web应用被设计为在自包含的环境中运行。从更深层次上来说，也就是对嵌入式Web应用的性能和可用性方面关注较少。
目前IoT领域中主要有两种不同的Web应用模型，分别是混合云模型与独立嵌入式服务器模型。混合云模型中包含了厂商或者供应商提供的基于软件即服务（Software as a Service，SaaS） 的Web应用，作用是同运行在嵌入式设备固件中的Web应用程序建立连接，然后，将数据从厂商的云服务器中同步到本地网络的嵌入式设备中。有些IoT设备则会直接使用IoT云服务提供商的SDK，例如AWS提供的IoT SDK和Azure提供的IoT SDK，并且将这些SDK编译进设备的Web应用程序栈中。为了确保符合机构的服务条款并且遵循所在区域的法律规范，混合云模型的识别非常重要。许多采用混合云模型的IoT公司经常以OEM的方式借助第三方软件开发公司或ODM来管理其Web应用。这些ODM的Web应用通常被贴牌为某款OEM产品，在没有设置通信流量代理的情况下，用户通常不会注意到这种情况。
IoT设备的混合云模型如图1-2所示，其中IoT设备能够连接到互联网。该场景中，在厂商云平台与用户设备之间由设备接口提供Web服务，用户访问设备接口进行操作或者进行数据收集。

如前所述，嵌入式设备的Web应用在设备固件内部运行，以lighttpd或者nginx等程序作为嵌入式Web服务器，而不存在外部依赖。读者可能对这些独立嵌入式Web应用比较熟悉，在打印机、VoIP电话和家庭路由器中都可以找到这些应用。通常情况下，用户输入直接发送到设备固件，如果未对用户输入进行验证或过滤，攻击者则可以向设备发起攻击尝试执行任意命令。在某些情况下，出于防止外部攻击或者便于管理的目的，嵌入式Web应用设计为仅在局域网（Local Area Network，LAN）环境中运行。这也是家用IoT、工控设备和商用设备中的典型情况。通常将设备限定在局域网环境下是出于安全方面的考量，但从我们所了解的情况来看，这种方式难以有效地缓解攻击。这是因为，持有这种观点的设备厂商在现实中发现客户总是会有意无意地将设备连接到互联网上，从而给用户网络带来安全隐患。
图1-3展示了用户通过Web浏览器连接独立嵌入式Web应用的过程，其中该应用不依赖于外部系统。

Web通信
浏览器、嵌入式服务器和Web应用服务器之间的通信通常要么借助简单对象访问协议（Simple Object Access Protocol，SOAP）/XML等Web服务，要么借助基于HTTP/HTTPS符合REST规范的API来实现。SOAP请求中通常包含1个envelope元素、1个xmlns:soap命名空间、1个encodingStyle属性，此外还包括其他元素，例如SOAP中的body元素。读者可以通过访问链接https://www.w3schools.com/xml/xml_soap.asp了解更多关于SOAP协议的内容。
下面展示了一个查询账户余额的HTTP SOAP请求示例：

REST风格的API用到了多个HTTP方法，而这些方法的使用并不符合传统Web应用的用法，例如传统Web应用采用PUT方法更新资源，采用DELETE方法删除资源，而采用REST风格的请求则是通过URL（对于敏感数据不推荐采用此方法进行处理），或者以JSON格式表示的HTTP协议报文等方式调用参数。
在电子邮件分发列表中添加邮件地址test@example.com的REST请求示例如下：

可以采用中间人代理来查看基于SOAP协议或符合REST风格的请求报文。常用的Web代理工具包括Burp Suite与OWASP ZAP，借助这些工具可以查看从浏览器和移动应用发送到Web应用后端的所有请求。我们将在第4章中详细介绍如何配置代理来查看应用流量。
对于IoT设备而言，常常采用Web应用对其设备进行控制，因此，无论是从网络内部还是网络外部来看，Web应用都是发起攻击的常见途径。在第4章中，我们将会了解如何识别IoT设备中Web应用的缺陷与漏洞。

1.5　IoT中的移动应用

在IoT领域，移动应用模型同前面介绍的Web应用模型类似。虽然对移动设备平台的安全模型进行深入探讨超出了本书的范围，但是了解移动应用开发模型的基本概念将有助于后面的学习。

1.5.1　混合应用

安装在Android、iOS或Windows Phone设备中的移动应用可以是混合应用也可以是原生应用。虽然同Web应用相比，混合和原生在移动应用中具有不同的含义，但是其原理相似。混合应用既用到了HTML/HTML 5、CSS和JavaScript等Web技术，也用到了部分原生平台硬件，如GPS模块或蓝牙模块。只有使用混合框架提供的插件才能够访问硬件资源。可以将混合应用看作包含了Web应用的封装包，而原生平台可以使用该封装包。这意味着Web开发人员无须学习新的开发语言即可编写移动应用。
混合应用在Windows Phone、Android和iOS等多个平台上可以使用同一个代码库，当考虑将IoT设备应用投放市场时这是一个巨大的优势。通过嵌入式Web浏览器WebView就可以调用Web应用。当前，市场中流行的应用有多种流行的混合框架可以选择，包括Apache Cordova、Adobe PhoneGap以及Xamarin等。
每套移动混合框架都包含一个第三方市场，在其中提供可以实现各种功能的插件。为了实现快速开发，部分框架会采用一种编程语言（C#）编写，然后再翻译成另一种本地语言（Objective C或者Java），例如Xamarin就是如此。然而，从原生平台的高危远程代码执行到隐私泄露，这些移动框架存在着诸多安全隐患，这也并非什么秘密。如果读者在应用中恰好发现用到了某套移动混合框架，那么最好查阅一下相应的漏洞库，兴许就能够找到可以直接利用的漏洞。
为了帮助读者更好地了解混合应用运行的架构，图1-4展示了应用代码、WebView、插件以及移动设备自身之间的各个组件。需要注意的是，大多数封装包的代码和插件都是由混合框架或参与混合框架开发的第三方开发人员开发的。

1.5.2　原生应用

原生应用是为特定操作系统开发的，采用Java、Objective C、Swift等设备平台原生语言编写，其中对于Windows Phone平台而言则需要采用C#语言。原生应用使用各自平台的SDK实现同摄像头、蓝牙和GPS等硬件的交互。原生应用的性能和安全性取决于开发人员对原生平台语言的熟悉程度。如果平台API经常更新并且经常弃用某些类或方法，那么将会增加开发工作的难度。越来越多的平台，例如iOS和Android等平台，正在开发安全的原生API，这样开发人员就无须再利用第三方库即可直接使用安全API，进而提高通信和数据存储的安全性。
同混合应用架构相比，原生应用架构简单得多。图1-5展示了原生应用在设备上直接运行原生代码访问硬件资源的过程，在应用访问硬件资源的过程中未借助第三方组件。

了解每种移动应用模型的优缺点对于高效地开展渗透测试而言非常重要。由于移动应用拥有设备的控制权，因此是针对设备实施攻击的另一个重要突破口，并且同其他方法比起来，有时通过移动应用突破IoT设备要更加容易一些。在第5章中，我们将分解IoT设备，对IoT移动应用中最常见的漏洞展开深入分析。

1.6　硬件设备基础

下面从印制电路板（Printed Circuit Board，PCB）开始，对IoT设备中所涉及的硬件进行介绍。PCB由玻璃纤维、铜箔、阻焊层、丝印层、布线层和基板组成，在其上焊接有电阻、电容、Wi-Fi芯片、EEPROM、串口和微控制器等元件。板上布有多层铜箔作为PCB的导电体，而绝缘层则不导电。在查看印制电路板外观时，准确识别出感兴趣的元件非常重要。这些元件主要包括设备固件直接或间接的输入源。其中，EEPROM芯片、NAND闪存芯片、UART（Universal Asynchronous Receiver/Transmitter）接口和JTAG（Joint Test Action Group）接口通常都是渗透测试过程中最为关注的元件。
数字视频录像机（Digital Video Recorder，DVR）的PCB如图1-6所示。

硬件输入
EEPROM是非易失性存储器，以单个字节为单位进行读写。EEPROM可以通过电荷或紫外线照射擦除数据。同其他闪存类似，EEPROM芯片的读写次数有限。我们关注EEPROM芯片的原因在于，固件一方面可以加载到EEPROM芯片中，另一方面也可以从PCB中擦除而读取到EEPROM读写器上，从而便于进一步的分析。图1-7是EEPROM的示意图。

NAND闪存以区块为单位读写，通常用在USB驱动器中，但也可以用在IoT设备和游戏机中。NAND闪存中通常存储着设备的bootloader，bootloader依据指令引导操作系统启动，此外用户还可以对bootloader进行操作，关于bootloader的内容我们将在后文详细介绍。
UART接口是访问设备最为常见的方式。厂商在部署设备时可以使用UART接口进行设备诊断、日志记录等操作，还可以作为调试接口来验证配置，这使得UART接口成为固件中最常见的输入源之一。由于厂商主要使用UART接口进行设备调试，所以通常连接该接口后即可获得root权限。然而有些情况下，通过UART接口访问设备需要输入口令，这时可能需要分析人员额外花费时间进行暴力破解。UART接口芯片包含两条串行线，这两条串行线分别用于接收数据和传输数据（Rx/Tx）。UART收发数据均需要借助数据总线。数据以并行方式从数据总线传输至UART传输器。UART传输器从数据总线中取得并行数据（并行数据通常包含5～8位数据位，其中7位数据位和8位数据位较为常见，因为ASCII标准字符集采用7位编码，扩展字符集采用8位编码）后，添加起始位、校验位以及停止位创建数据帧。接下来，数据帧以串行方式在Tx引脚逐位传输。UART接收器则从Rx引脚逐位读取数据帧，继而将串行数据转换为并行数据，并删除起始位、校验位以及停止位。最后，UART接收器以并行方式将数据帧传输至接收端数据总线。由于是异步通信，因此UART接口工作时不需要外部时钟，发送端和接收端会按照固定的波特率来进行数据采样。PCB上UART接口的引脚定义中包括了Tx、Rx、Vcc（电压）和GND（接地）4个引脚。连接UART接口前需要使用万用表识别出Tx、Rx和GND引脚。有时，个别设备中UART接口的识别可能会比其他设备更加困难一些。有些厂商可能会直接移除PCB上UART接口的排针插座，对于这种情况，研究人员就需要将排针插座重新焊接到PCB上去。还有些厂商会选择覆盖掉UART接口排针插座的丝印，还会将另一块集成电路覆盖在接口的插座上，而对于这种情况解决起来就比较麻烦了。
JTAG接口是遵循IEEE 1149.1标准的另一种国际标准测试协议，主要用于芯片级与系统级测试。类似于UART接口，厂商也可以采用JTAG接口作为调试的输入。JTAG接口能够提供口令保护，但是也可以通过BYPASS（旁路）模式进行访问。通过JTAG接口可以进行固件转储，方便后续对固件的分析，也可以用于固件升级。JTAG接口可以直接访问闪存或者RAM等板载硬件。JTAG接口包含TDI（数据输入）、TDO（数据输出）、TMS（测试模式选择）、TCK（测试时钟）和TRST（测试复位）等5个引脚。JTAG接口可以连接到芯片上的TAP（测试访问口），通过TAP访问芯片上的寄存器时可以改变寄存器状态。与UART接口类似，厂商也会隐藏JTAG接口的排针插座或者线路。
通过拆解设备或者搜索https://fccid.io等第三方网站，可以观察IoT设备中的PCB构造并定位元件位置。美国联邦通信委员会（Federal Communications Commission，FCC）ID是FCC分配的产品ID，其作用是掌握市场上无线产品的具体数据。fccid.io网站真是棒极了！该网站提供了大量关于设备的详细信息。其中，FCC还会公布设备的设计文档、数据表、内部结构图片、外观图片、测试报告、各种手册、设备采用的无线频率等内容。在第6章中，我们将会对硬件攻击方法、硬件细节进行介绍。

1.7　IoT无线通信简介

同IoT设备建立连接并与其进行交互的最常见方式是采用无线射频（Radio Frequ-ency，RF）通信方式。目前市场上有许多不同的无线频率、调制模块和协议，其中既有专有无线协议，也有标准协议。因此打开设备外壳，用户往往能够发现其中包含了一个或多个用于无线通信的芯片。这对于需要接收多种不同无线通信协议和频率的IoT网关和IoT Hub来说尤为常见。无线技术与无线通信设备的一个优势在于能够实现设备的远程控制。当通过无线通信方法对设备开展漏洞利用时也正是利用了这一点。因此，了解每种无线技术所能达到的最远通信距离对实际测试而言非常重要。有的无线协议支持105英尺（约32米）远的距离，而有的可能只支持20厘米远，差别非常大。在IoT生态系统的众多无线协议中，最常用的协议主要包括Wi-Fi（802.11）、ZigBee（802.15.4）、Z-Wave、蓝牙（802.15.1）和低功耗蓝牙等。

1.7.1　Wi-Fi

多年以来，Wi-Fi一直是众多设备最常采用的无线技术，其通常使用2.4 GHz或5 GHz ISM频段。同时也提出了多套Wi-Fi协议标准，例如802.11a、802.11b、802.11g、802.11n和802.11ac等。其中802.11b和802.11g协议使用2.4 GHz频段，802.11a、802.11n和802.11ac协议使用5 GHz频段。2.4 GHz频段根据不同频率又分为14个无线子信道。在部分地区，Wi-Fi路由器还必须采用特定的广播信道。

1.7.2　ZigBee

ZigBee是基于IEEE 802.15.4协议为物理层和媒体接入控制层实现的规范，支持低功耗无线Mesh网络。不同地区的ZigBee协议使用不同的ISM频段，但主要还是在全球使用2.4 GHz频段，在美国使用915 MHz频段，欧盟使用868 MHz频段。ZigBee网络由协调器（ZigBee Coordinator，ZC）、路由器（ZigBee Router，ZR）和终端节点（ZigBee End Device，ZED）组成。建立ZigBee网络时协调器自动启动进行组网。每个网络只允许有一个协调器，它是整个网络的信任中心，负责对入网节点的认证与验证，并且拥有唯一的入网密钥。路由器主要负责在各节点之间传送数据，并将协调器与终端节点连接起来。
为了确保报文在网络中的正确传递，路由器需要一直处于工作状态。终端节点就是IoT设备，例如电灯开关、传感器、摄像头或者监控设备。终端节点不能在网络中路由数据，在没有数据传输的情况下会以低功率模式休眠。ZigBee网络基于两个安全密钥，即网络密钥和链路密钥。网络密钥是网络中所有设备共享的128位密钥，主要用于确保传输通信的安全。链路密钥是只在相互通信的两个设备之间共享的128位密钥，主要用于确保ZigBee应用层单播通信的安全。链路密钥可以预先分配给设备或通过密钥交换进行分发。但是在ZigBee网络中，已知设备配对过程中的密钥交换存在漏洞，攻击者能够利用该漏洞嗅探网络密钥交换过程，进而影响整个网络的安全。
2015年，Blackhat安全大会上分享了一个关于ZigBee网络漏洞利用的议题，该议题的幻灯片链接为https://www.blackhat.com/docs/us-15/materials/us-15-Zillner-ZigBee-Ex-ploitedThe-Good-The-Bad-And-The-Ugly-wp.pdf 。

1.7.3　Z-Wave

Z-Wave是另一种低功耗无线通信协议，该协议支持主从模型的Mesh网络。Z-Wave使用低于1 GHz的频段，具体频段因地区而异（美国使用916 MHz频段，欧盟使用868.42MHz频段）。基于Z-Wave协议实现的物理层和媒体接入控制层经ITU认可成为国际标准G.9959。采用Z-Wave协议的设备最远通信距离能够达到328英尺（约100米），但在Mesh网络中，当流量通过Z-Wave设备时最远距离能够达到600英尺（约200米）。Z-Wave网络采用4字节（32比特）的HomeID进行标识，该标识也是控制器或主节点的唯一标识。每个节点加入网络时，控制器会为其分配1字节（8比特）的NodeID。HomeID不同的节点间不能通信。Z-Wave协议可以采用AES加密算法，这也是Z-Wave Hub所支持的加密算法，但是到底是否实现对于厂商而言是可选的。Z-Wave协议还具有良好的信号干扰检测特性，能够防止拒绝服务（Denial of Service，DoS）攻击。
关于Z-Wave协议的更多内容请访问网站http://www.z-wave.com 。

1.7.4　蓝牙

蓝牙是一种常用的短距离数据通信的无线技术标准（IEEE 802.15.1）。蓝牙在2.4 GHz～2.485 GHz频段进行广播，最远通信距离可以达到100米，但常用于10米以内的通信。由于大量IoT设备采用蓝牙作为主要通信手段，后文将对蓝牙和低能耗蓝牙（Bluetooth Low Energy，BLE）的渗透测试技术进行介绍。关于蓝牙的其他内容可以参看链接https://www.bluetooth.com/what-is-bluetooth-technology/how-it-works。

1.8　IoT渗透测试环境的部署

介绍完了IoT技术的所有基础概念，下面我们开始着手搭建IoT渗透测试环境。由于IoT设备用到了多种技术，因此在对软硬件开展渗透测试时会用到多款工具。其中既包括需要花钱采购的商用工具，也包括免费工具。为了不影响测试，部分硬件和无线电分析工具需要提前采购。尽管Web应用代理工具的许可费用并不高，但是在这里我们还是尽可能地选择花费不多的工具，如果有免费工具的话则尽可能使用免费工具。

1.8.1　软件工具要求

软件工具主要包括固件、Web应用以及移动应用测试工具。对于这三种类型的测试工具而言，除了用于Web测试的Burp Suite之外，大多数测试工具都是免费的。为了方便应用，建议最好提前部署好虚拟环境，并将固件分析、Web应用测试、移动应用测试（测试内容有限）以及无线电分析过程需要用到的大多数工具安装好。本节中，我们将所有可能用到的工具进行了汇总。
1.固件分析工具
幸运的是，大多数固件分析工具都是免费并且开源的。有些工具会自动更新，而另一些工具虽然已经长期没有更新，但仍然可以用于测试。读者可以使用下面列出的固件工具来分析固件镜像、提取镜像以及在运行时附加到固件进程中以方便调试：

• Binwalk
• Firmadyne
• Firmwalker
• Angr
• firmware-mod-toolkit
• Firmware Analysis Toolkit
• GDB
• Radare2
• Binary Analysis Tool（BAT）
• Qemu
• IDA Pro（可选）

2. Web应用渗透测试工具
Web应用渗透测试的常见工具主要包括Burp Suite和OWASP ZAP。Burp Suite有免费版和专业版之分，专业版的价格也不算离谱。而ZAP则是完全免费并且开源的，在需要控制成本的情况下，ZAP不失为一种比较好的选择。在对Web服务和API进行测试时，还可以加载插件。但是，如果要安装Burp Suite的插件，则需要先购买专业版。这里列出的所有工具都是跨平台的，它们要么是基于Java开发的，要么可以内置在浏览器中：

• Burp Suite
• OWASP Zed Attack Proxy（ZAP）
• REST Easy Firefox Plugin
• Postman Chrome Extension

3.移动应用渗透测试工具
同固件分析工具一样，大多数移动应用安全工具也都是免费并且开源的。根据下面所列出的移动平台可以对移动应用渗透测试工具进行分类。
（1）Android
在撰写这本书的时候，网上已经有很多Android渗透测试工具和虚拟机了。有些工具完全侧重于APK代码的静态分析，还有些工具则侧重于应用运行时的动态分析。已发行的大多数Android渗透测试虚拟机都是免费的，其中包含了测试Android SDK等Android应用所需要的工具。虽然我们列出了一些Android渗透测试工具，但是依然建议读者下载与自己的测试需求最为契合的Android渗透测试虚拟机，并在虚拟机中安装其他用到的渗透测试工具。
在这里，虽然没有明确要求Android测试工具同本机相互隔离，但是为了确保移动应用测试环境更加稳定，并避免出现文件依赖问题，我们还是建议读者将Android测试环境同本机隔离起来。

• 发行版Android渗透测试虚拟机：Android SDK、Android Emulator
• Enjarify
• JD-Gui
• Mob-SF
• SQLite Browser
• Burp Suite
• OWASP ZAP

（2）iOS
由于iOS平台比较特殊，因此在开始渗透测试前需要准备好OS X计算机和已越狱的苹果设备。如果不满足这两个前提条件，那么是无法对iOS应用开展渗透测试的。下面是对iOS应用进行渗透测试时用到的部分工具。
下面列出的是需要在OS X计算机上安装的iOS应用渗透测试工具和安全评估工具：

• idb
• Xcode Tools
• Class-Dump
• Hopper（可选）
• Mob-SF
• SQLite Browser
• Burp Suite
• OWASP ZAP

下面列出的是为开展渗透测试需要安装在越狱设备上的软件：

• Cydia
• openURL
• dumpdecrypted
• ipainstaller
• SSL Kill Switch 2
• Clutch2
• Cycript

1.8.2　硬件分析工具需求

根据所分析设备的不同，硬件分析工具也有所不同。然而，有一些基本的分析工具对于所有硬件甚至是电气元件都是适用的。设备商在制造设备时会使用不同型号的螺丝、外壳和保密位以防止用户拆解硬件。有时，螺丝会隐藏在标签或橡胶垫下，分析人员需要撕开标签或者揭开橡胶垫才能找到封装设备的螺丝。在硬件拆解过程中，确定螺丝型号至关重要。只有确定了螺丝型号，我们才能够借助专用工具拆解设备，绕过厂商设置的阻碍。图1-8可以帮助测试人员区分出螺丝类型。
下面列出了本书中将要用到的硬件工具和硬件分析软件。
1.硬件工具
开始硬件测试前需要提前购买一些硬件工具。以下是拆解设备、查找接地引脚以及访问设备接口所需要的工具：

• 万用表

• 用于硬件拆解的IFixit classic pro tech toolkit工具套装
• Bus Pirate
• USB转串口转接器：Shikra、FTDI FT232、CP2102、PL2303、Adafruit FTDI Friend
• JTAG接口转接器：Shikra、JTAGulator、Arduino with JTAGenum、JLINK、Bus Blaster
• 逻辑分析仪（可选）：Saleae Logic等

读者可以访问以下链接了解更多的信息：

• https://www.ifixit.com/Store/Tools/Classic-Pro-Tech-Toolkit-/IF145-072-1
• http://int3.cc/products/the-shikra
• https://www.sparkfun.com/products/12942
• http://www.grandideastudio.com/jtagulator/
• https://www.saleae.com/

2.硬件分析工具
下面列出的都是免费的硬件分析工具。这些工具能够帮助读者连接Console口等硬件接口，或者将固件以side-loading方式刷入设备：

• OpenOCD
• Spiflash
• Minicom
• Baudrate

1.8.3　无线电分析工具需求

为了嗅探无线网络流量，需要准备特定的无线芯片组。在本书中我们将主要关注ZigBee和Z-Wave协议流量的嗅探。在无线网络流量嗅探过程中，部分特定软件需要配合无线网卡与软件狗进行使用。无线网卡和分析软件的使用建议如下。
1.无线电分析硬件
下面列出了用于分析无线电频谱的硬件设备：

• Atmel RZ Raven USB设备（KillerBee攻击框架）
• Attify Badge（或者C232HM-DDHSL-0线缆同Adafruit FTDI Breakout开发板的搭配）
• HackRF One
• Yardstick One
• 带有Xbee Shield模块的XBee扩展板
• Ubertooth
• BLe适配器

2.无线电分析软件
下面列出了常用的无线电分析软件工具，列出的大部分工具在本书中都会用到。

• KillerBee框架
• Attify ZigBee框架
• GNU Radio
• BLEAH
• GQRX
• Ubertooth tools
• Blue Hydra
• RTL-sdr
• Hackrf packages
• EZ-Wave