在嵌入式设备中寻找软件错误

11.1.1缺乏透明度

今天，许多智能设备在大规模攻击中被攻破，并可能被滥用形成大型僵尸网络攻击(受损设备的网络)。据报道，创纪录的分布式拒绝服务(DDoS)攻击(即网络洪泛)产生了620 Gbps到1 Tbps的流量[241，344］．据报道，这些DDoS攻击使用了数十万个被入侵的嵌入式/智能设备，包括几十种不同型号的商用现货(COTS)产品，如IP/CCTV摄像头和家庭路由器。这些设备大多是使用制造商设置的默认或硬编码凭据而被入侵的[345］．运行在这些设备上的恶意软件完全控制了产生的流量，而且大多数智能设备不嵌入任何感染检测或预防机制。更糟糕的是，设备的用户或所有者往往没有意识到这个问题，也无法解决它。事实上，设备的设计并不是为了供最终用户检查和修改的(例如，如第4章中讨论的用于进行取证)。13）.

11.1.2缺乏控制

另一个重要的问题是，智能设备通常是作为固定的软件(即固件)和硬件平台提供的，通常与云服务绑定，并捆绑在一起作为一个用户几乎无法控制的封闭系统。这种客户锁定的负面后果的一个例子是Revolv智能恒温器。Revolv谷歌的制造商被其竞争对手Nest收购，一年后，Nest停止了云服务，提供了Revolv安装在家中的恒温器无法使用[271］．对于设备应该运行哪种软件，使用哪种云服务，或者设备应该做什么，用户通常没有选择余地。为这类设备选择、安装和使用替代软件即使不是不可能，也是很困难的，这往往是因为硬件和软件设计的单一用途、缺乏公开文件，以及制造商采取的任何反篡改措施。

11.1.3缺乏对攻击的抵抗力

实际上，互联网扫描僵尸网络非常活跃，一些设备在连接到互联网后几分钟内就会被破坏[344］．为了被认为是值得信任的，设备需要有一定程度的抵抗攻击。这是令人震惊的，因为在本质上，许多反复出现的智能设备安全问题已经“解决”多年。如果漏洞和相应的攻击情况最终可以避免，那么很重要的一点是，除了恶意软件作者之外，谁应该为被入侵的智能设备造成的损害负责。设备所有者可能在法律上负有责任，但终端用户通常没有任何方法来检测或防止这种妥协，或应用安全配置。另一方面，制造商目前往往没有法律责任，因此没有动机(如经济、法律)来防止潜在的脆弱性和妥协。

11.1.4本章组织机构

解决这些问题需要分析嵌入式设备的软件和固件，并识别和修复它们的漏洞。本章描述了系统和一致地实现这一目标的可能步骤。我们首先提供一个适合于分析的嵌入式系统分类。然后我们描述分析它们的可能步骤。我们从获取用于分析的软件的方法开始，这对于嵌入式设备本身通常是一个挑战。然后，我们描述如何对获得的固件包执行静态分析，这有许多优点，如速度和可伸缩性。然后，我们描述了可用于动态分析固件的技术，与静态分析相比，动态分析具有更大的代码覆盖率和更低的误报率的优势。

11.1.5嵌入式系统的分类

嵌入式系统的一般定义很难建立[261］．然而，嵌入式设备与现代通用计算机(如普通的台式电脑或智能手机)之间有两个被广泛接受的差异，即:(a)它们被设计来实现一个特定的目的，以及(b)它们与物理世界通过外围设备．上述两个标准涵盖了各种各样的设备，从硬盘控制器到家庭路由器，从数码相机到可编程逻辑控制器(plc)。这些族可以根据以下几个方面进一步分类，例如它们的实际计算能力[171，它们与计算和物理环境的交互程度，它们的使用领域，或施加在它们身上的时间限制。

11.2.1收集固件包

嵌入式系统部署的环境是异构的，跨越各种设备、供应商、CPU/硬件架构、指令集、操作系统和定制组件。这使得编译一个代表而且平衡数据集是固件软件包的一个难以解决的问题。缺乏集中的收集点，比如由软件/应用市场、防病毒供应商或恶意软件分析领域的公共沙箱提供的收集点，使得研究人员很难收集到大型的、经过良好筛选的数据集。固件通常需要从供应商的Web页面和FTP站点下载，而且要判断两个固件包是否用于同一物理设备并不总是那么简单，即使对人来说也是如此。

在固件分析和逆向工程过程中经常遇到的一个挑战是从固件包中可靠地提取元数据的困难。这些元数据可能包括设备的供应商、产品代码和用途、固件版本或处理器架构，以及无数其他细节。

11.2.2从设备中提取固件

从在线存储库中获取固件作为固件包是很方便的，因此是首选的，但这并不总是可能的。首先，固件可能不可用，例如，因为还没有更新，也没有计划更新。有时固件只通过授权和合格的维护代理分发，例如，在工业或关键系统的情况下。为了防止假冒产品、软件逆向工程或保护其安全性，固件根本不发布的情况也很常见。

在这种情况下，最好的(有时也是唯一的)解决方案是从设备本身提取固件。有多种可能的方法来解决这个问题([529]和[564提供过程的详细概述)，每种方法都有自己的一组优点和问题。在最简单的情况下，固件可以通过连接到一个调试接口(例如，JTAG，和串行端口，如UART, SPI, I2C)来提取。需要注意的是，JTAG是一个低层协议，许多不同的机制可以在它之上实现。调试机制允许转储一些内存(例如，ROM, RAM或Flash内存后面的Flash控制器)，但不一定要转储其他内存。当闪存被焊接到印刷电路板(PCB)上，并且独立于处理器时，可以使用Flash编程器/读取器将其解焊并提取其内容。不幸的是，闪存的标准、类型和pinouts种类繁多。你可以设计自己的闪存芯片适配器来读取和转储内存内容(如代码、数据)[75］．然而，一些廉价的通用程序员可能足以转储足够多的Flash存储器模型[38］．最后，高级Flash程序员甚至支持数十万种不同的Flash内存模型[198］．

然而，当设备是一个Flash微控制器时，Flash存储器集成在微控制器中，通常是不能直接访问的。在这种情况下，微控制器本身提供了访问Flash存储区域的机制，但通常这种机制还附带一些Flash区域保护机制，这些机制通常是任意的和微控制器特定的。由于保护措施本身的实施存在漏洞，有时可以绕过这种保护机制[447，556］．然而，这样的攻击可能并不总是成功，人们可能会使用更昂贵的入侵硬件攻击，如线性代码提取(LCE) [549或用显微镜直接读出存储器[158是唯一的选择。

11.2.3开箱固件

固件包分析的下一步是解包并提取其中包含的文件或资源。这个阶段的输出很大程度上取决于固件的类型，以及所使用的拆包和提取工具。在某些示例中，可执行代码和资源(如图形文件或HTML代码)可能直接嵌入到二进制blob中，该blob被设计为由引导加载程序直接复制到内存中，然后执行。其他一些固件包是在一个压缩和模糊包中分发的，其中包含一个逐块的Flash内存映像副本。这样的映像可能包含几个分区，这些分区包含一个引导加载程序、一个内核、一个文件系统，或者这些分区的任意组合。

11.2.4固件开箱框架

11.2.5修改和重新包装固件

在分析固件和设备安全性期间，修改和重新包装固件可能是一个可选步骤。修改可以在整个固件包级别上执行，也可以在单独解包的文件级别上执行(这些文件最后重新打包到固件包中)。这样的步骤在测试一些东西时可能是有用的。首先，它可以检查特定固件是否有错误、修改和新版本固件的真实性检查。如果这些检查缺失或执行不当，那么固件更新机制就会被用作攻击矢量，或作为对系统进行进一步分析的一种方式[57，162］．其次，它可以用来增加固件的额外安全相关功能，如漏洞、良性恶意软件和更高级的分析工具。例如，当没有其他方法来交付漏洞时(例如，非网络本地漏洞，如内核特权升级)，或者提供一些(部分)形式的对运行的设备/固件的内省，这可能是有用的。163］．

的firmware-mod-kit工具(262是最有名的(可能是为数不多的)固件修改工具。不幸的是，它支持的固件格式数量有限，虽然可以扩展它以支持更多的格式，但这需要大量的手工工作。此外，对于某些格式，它依赖于外部工具来执行一些重新打包。这些工具是由不同的人或实体以不同的形状和形式开发和维护的，因此没有统一的方法来修改和重新打包固件包。

11.3.1固件包的简单静态分析

11.3.1.1配置分析

对于绝大多数复杂的嵌入式设备(如第1节所述的i型设备)。11.1.5)，而服务配置存储在设备的文件系统中，用户可配置的信息通常存储在其他地方——存储在内存中一个称为非易失随机访问存储器(NVRAM)的区域中，NVRAM在电源循环之间保持其状态(在某些方面类似于闪存)。许多设备将NVRAM视为键值存储，并包括诸如此类的实用程序nvram-get而且nvram-set，以及用于获取和设置存储在那里的值的专用库。例如，在路由器上，当前的Wi-Fi密码短语和基于web的配置接口凭证通常会存储在NVRAM中，软件会查询NVRAM，以便于设备及其服务的身份验证。

所有其他设备配置，不执行固件升级，将是静态的。因此，任何硬编码的密码或证书(如在[151)，可以被对手利用来破坏设备。为此，Costin等人[155]显示了许多设备配置的用户帐户和密码是弱的、完全丢失的或以纯文本形式存储的实例。因此，固件静态分析的第一步是检查其服务的配置:检查配置不正确的服务，例如，由于使用不安全的默认值和硬编码的凭证。在没有对设备进行物理访问的情况下，配置文件在估计所使用的程序集和设备的初始全局配置方面还有进一步的作用。例如，通过检查它的引导脚本，我们能够了解它的固件中存在的哪些服务(可能有数百个)被设备实际使用，这可以帮助减少后面描述的更复杂的分析方法所花费的时间。

手动方法通常足以分析一些固件映像，并且在有限的范围内，可以分析设备配置等内容。例如，要估计由固件启动的进程集，可以检查启动脚本的内容，例如:/etc/rcS．

数字11.1详细说明了从IP摄像头的固件中获取的引导脚本。我们可以观察到设备的主要功能是由/bin/webs二进制，然后我们将使用Sect中详细的方法进一步分析它。11.3.2．

在新窗口中打开图像

11.3.2固件包的静态代码分析

开发用于在嵌入式设备固件上执行自动静态代码分析的工具，与在商用PC系统(即Type-0设备)的软件上执行分析相比，具有许多复杂性。第一个挑战是CPU架构的多样性。这就限制了可以使用的现有工具的数量，当尝试大规模分析工具时，将不可避免地不得不处理来自许多不同架构的固件。在这种情况下，为了便于分析，算法要么必须为每个被分析的体系结构重新实现，要么必须将特定于体系结构的拆卸固件指令提升为一种常见的，所谓的中间语言(IL)或中间表示(IR)。对于更简单的设备(例如，那些类型iii)，一个进一步的困难是通常的非标准方法，通过不同的设备固件执行(例如，它可以是中断驱动的)，并与内存和外部外设交互。更复杂的固件(例如，Type-I设备的固件)倾向于更紧密地跟随更传统的设备(Type-0设备)的执行行为。

11.4.1无仿真的设备交互动态分析

当分析设备时，设备交互动态分析的最简单形式是用“黑盒”方式测试设备。这种方法的一般想法是在正常操作中设置和运行分析下的设备(例如，连接到以太网LAN, WLAN，智能手机)，然后用各种工具和手工技术(例如，通用或专门的模糊器，网络渗透)测试它，并通过外部可观察的副作用，如设备重启，网络守护进程崩溃，或XSS工件[439］．一些独立和互补的研究报告了类似的方法和结果[259，280，292］．

虽然简单且易于执行，但这种动态分析类型有一定的局限性，其中一些是由于方法的“黑盒”性质造成的。例如，在执行动态分析时，很难知道整个系统/设备发生了什么，也就是说，系统的内省缺失或很难实现。此外，在这种方法中，不容易详细控制正在执行和分析的具体内容，分析主要是由提供给设备的数据和操作驱动的。除此之外，某些类型的漏洞可能不会立即产生副作用[430]或外部可见(例如，守护进程的崩溃并不一定会暴露网络端口)，因此在分析过程中可能会遗漏或错误解释这些错误。

11.4.2设备交互动态分析与仿真

作为上述方法的扩展，仿真可以与设备交互动态分析相结合，以提供所需的深度和广度，因此优于其他静态或动态分析方法。这种方法的一般思想是在分析主机和实际运行的设备之间分割嵌入式固件的执行。分析主机通过调试(如JTAG)或串行(如UART)接口与设备连接。因此，一个要求是所分析的设备必须至少提供这样的接口，无论是否有文档记录。分析宿主然后运行一个动态分析环境，它通常是一个模拟器(例如，基于qemu的)，通过附加层和插件(如符号执行和污染分析)进行扩充或扩展。分析主机可以访问模拟器和运行设备的执行和内存状态。固件首先在扩展模拟器环境中进行分析。在固件模拟和分析过程中，分析主机将分析固件的某些部分从模拟器传输到正在运行的设备上执行。这有时是必需的，例如，当固件需要在设备上有外设但模拟器中没有外设的情况下执行I/O操作时。与设备之间的运行和状态传输通过连接的调试或串行接口进行。 On the one hand, by using this approach it is possible to control exactly what is to be analyzed because the emulator is under the full supervision of the analysis host. On the other hand, this approach enables broader and deeper coverage of the execution because the device can complement the execution of firmware parts that are impossible to execute within the emulator.

这是《阿凡达》所遵循的方法[591，其目的是提供S2E的符号执行[140，而Avatar2 [429着重于与更多工具更好的互操作性。前景(312]探究系统调用层的转发和代理[341提供了一个非常快的调试接口。《盗梦空间》(125]提供了在测试期间使用的分析环境，当源代码可用时。

11.4.3无设备动态分析与仿真

以设备交互的方式执行动态分析肯定有它的优点，但是这种方法有许多限制，并且很难完全自动化。首先，与设备与仿真交互方法相关的许多任务中，不容易扩展人工操作人员的干预和所需的专业知识。其次，与大量设备的获取、拆卸、连接、配置和重置相关的物流操作的自动化和规模化具有挑战性。因此，需要更容易和更可行的动态分析技术来扩展和自动化。其中一种技术是基于完全或部分仿真的无设备分析。

Davidson等[175)提出了5MSP430微控制器家族的固件bug检测工具。外资企业利用KLEE [120]对固件进行符号执行，以检测内存安全违规(如缓冲区溢出和内存越界访问)，以及外设误用(如试图写入只读内存)。5需要源代码的可用性，这是不常见的，并且能够处理各种细微差别和固件自动化分析期间面临的挑战，特别是在处理类型iii设备的固件时。然而，当从设备读取I/O时，总是假设读取的值返回不受约束(完全是符号)的值，这导致了状态爆炸问题。这限制了可分析的程序的大小。

在[156]，作者通过自动化和大规模的嵌入式固件仿真来进行无设备的动态安全性分析。同样的,FIRMADYNE［137提出了一个自动化的、可扩展的系统，用于对基于linux的嵌入式固件进行仿真和动态分析。

这两种工作的总体思想是抓取固件包，然后将其解压缩到最小的根文件系统(即，rootfs)，可以随后通过“系统模拟”(与“用户模拟”相反)作为一个整体进行虚拟化和执行，例如使用QEMU [69］．模拟器首先用于启动特定于体系结构的模拟主机操作系统，例如用于ARM或MIPS的Debian，这取决于正在动态分析其固件的设备的体系结构。然后将固件根文件系统上传到模拟主机操作系统，在那里启动它的Linux引导序列脚本，很可能是在chroot在仿真主机操作系统下的环境。一旦固件的Linux引导序列结束，所分析的设备/固件的各种服务(例如web服务器、SSH、telnet和FTP)应该正在运行，并为日志、跟踪、检测和调试做好准备。工作在[137]通过运行一个定制的操作系统内核来扩展这种方法，该内核能够模拟一些缺失的驱动程序。