好书荐读｜《物联网渗透测试》篇一
本书介绍了物联网渗透测试的原理和实用技术，旨在希望对读者开展IoT安全研究以及渗透测试有所帮助。主要内容包括IOT威胁建模、固件分析及漏洞利用、嵌入式web应用漏洞、IOT移动应用漏洞、IOT设备攻击、无线电入侵、固件安全和移动安全最佳实践、硬件保护以及IOT高级漏洞的利用与安全自动化。
作者简介：亚伦•古兹曼（Aaron Guzman）
Aaron Guzman是洛杉矶地区的安全顾问，在Web应用安全、移动应用安全以及嵌入式设备安全领域具有丰富的经验。Aaron Guzman在众多国际会议以及一些地区性会议上分享过他的安全研究成果，这些国际会议包括DEF CON、DerbyCon、AppSec EU、AppSec USA、HackFest、Security Fest、HackMiami、44Con以及AusCERT等。此外，Aaron是开放式Web应用程序安全项目（Open Web Application Security Project，OWASP）洛杉矶分会与云安全联盟（Cloud Security Alliance，CSA）南加利福尼亚分会的负责人，还是Packt出版的《Practical Internet of Things Security》一书的技术审稿人。他为CSA、OWASP、PRPL等组织出版发行的很多IoT安全指南类书籍提供过帮助。Aaron主持了OWASP嵌入式应用安全项目，为嵌入式与IoT社区解决常见的固件安全漏洞提供了卓有成效的指导。
作者简介：阿迪蒂亚•古普塔
Aditya Gupta是IoT与移动安全公司Attify的创始人，同时也是IoT和移动安全研究员。他开发了广受欢迎的培训课程Offensive IoT Exploitation（IoT漏洞利用技术），同时也是黑客在线商店Attify-Store的创始人。Gupta多次在BlackHat、DefCon、OWASP AppSec、ToorCon等国际会议上发表演讲。在过往的经历中，Gupta曾与多个机构合作，帮助它们构建安全架构，开发内部自动化检测工具，挖掘Web和移动应用漏洞，主持制订安全规划方案等。
1.内容提要
虽然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中的移动应用。
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设备要更加容易一些。在后续章节中，我们将分解IoT设备，对IoT移动应用中最常见的漏洞展开深入分析。
下一篇将对如下内容进行展开：
硬件设备基础。
IoT无线通信简介。
IoT渗透测试环境的部署。
作者：温柔的养猫人，来自华章图书
- 用户评论