英语原文共 17 页

嵌入式固件安全的大规模分析

摘要

随着嵌入式系统更多地被用在人类社会中，其安全性也变得越来越重要。然而，许多争对个体固件映像的分析结果表明，嵌入式系统任然存在很多安全问题。

尽管如此，我们仍然缺乏对保证其安全的技术和工具的全面了解。

本文首次公开提出了对固件映像的大规模分析，将32000个固件映像转换成170万个单独的文件来进行实验。我们利用分析结果对嵌入式设备的安全性提供了新的见解，并强调细化了未来研究中需要面对的几个重要挑战。我们还展示了同时审核不同设备以及将检测结果与其他大型数据（例如ZMap的HTTP调查）相链接的好处。

总而言之，在没有执行复杂的静态分析的情况下，我们在超过693个固件映像中发现了总过38个以前未知的漏洞。此外，通过将类似的文件关联在不相关的固件映像中，我们能够将其中一些漏洞扩展到超过123种不同的产品，其中一些甚至完全影响了互联网中至少140K的设备。

我们相信本项目，并计划提供固件解包和Web服务分析来证明嵌入式设备的安全性。

1. 介绍

嵌入式系统在我们的日常生活中无处不在，他们是各种通用现成（COTS）设备的核心，例如打印机，移动电话，家用路由器，计算机组件和外围设备。他们还存在于许多不太受消费者注意的设备中，例如视频监控系统，医疗植入系统，汽车原件，SCADA和PLC设备，以及我们熟知的任何电子设备。物联网（loT）的兴起会使他们的应用更加广泛，联系更加紧密。

所有这些系统都运行特殊的软件，这些软件被称为固件，通常由供应商作为固件映像或者固件更新提供。文献中存在几种固件的定义。该术语最初是为了描述硬件和软件层之间“某处”存在的CPU微代码而引入的。然而，这个词迅速占据了更广泛的含义。IEEE Std 610.12-1990 将其定义扩展到“硬件设备和计算机指令的组合或作为硬件设备上的只读软件的计算机数据”。

如今，固件这个术语更常用于形容嵌入式硬件设备中的软件。与传统软件一样，固件也可能存在程序以及配置错误，并导致运行该特定程序的设备出现漏洞。另外，跟据汽车模型油门控制失败或被恶意接管，家庭无线路由器被发现存在后门等具体失败经历，嵌入式系统常被认为存在安全隐患。一方面，除了一些争对特定设备或软件版本的工作之外，目前还没有对固件映像进行大规模自我分析的案例。另一方面，虽然手动对固件映像的安全性分析能产生非常准确的结果，但是需要耗费大量的时间并且不能很好的适用于固件映像的大型以及异构数据集。尽管单独的测试结果对于特定的固件或设备版本是有用的，但它不能判断固件映像的整体安全状态。更糟糕的是，同样的漏洞可能残留在不同的设备中，直到其他研究员独立重新发现。当多个集成供应商依赖开发商提供的相同分包商，开发工具，以及SDK时，通常会出现这种情况，此时不同名称的设备可能运行相同或类似的固件；这些固件通常会收到完全相同的漏洞的影响，但是，如果不详细了解这些供应商之间的内部关系，通常无法识别这些类似的设备；因此，即使有更新的固件，某些设备也常常会受到已知漏洞的影响。

方法：

通过实际运行物理设备，即使用动态分析方法对嵌入式设备的安全性进行大规模研究具有几个主要缺点。首先，对数千设备进行研究是非常昂贵的。而且，某些设备难以在特定系统外操作，例如汽车的节气门控制。另一种选择是分析Cui和Stolfo提供的在线设备。但是查看运行中的设备很难找到漏洞，并且在未授权的情况下对在线设备执行任何分析不符合道德。

不言而喻，静态分析因为不需要访问物理设备而优于动态分析。因此我们决定在本次研究中采用这种方法。我们的方法是为尽可能多的设备和供应商收集固件映像。由于固件映像多种多样，并且很难将其与其他文件区分开来，因此这项任务变得相对复杂。由于分布通道，封装格式，安装过程和元数据的可用性通常取决于供应商和设备类型，我们设计并实现了一个分布式架构，以便对收集的固件映像解压缩并执行静态分析。然而，本文的贡献并不在于我们使用的静态分析技术，而是展示了横向，大规模探索的优势。出于这个原因，我们实现了一个关联引擎来比较和查找数据集中所有对象之间的相似性，这使我们能够将已知存在隐患设备中的某种漏洞迅速“传播”到未知是否受到该漏洞影响的其他设备中。

我们系统执行的大多数步骤在概念上都很简单，并且可以很简单地在一些设备上手动操作。但我们仍列举出了研究人员需要解决的五个挑战，以便在数千种不同的固件映像上进行大规模实验。其中包括：构建代表性数据集（第2节中的挑战A），正确识别单个固件映像（第2节中的挑战B），解包自定义存储格式（第2节中的挑战C），限制所需地计算资源（第2节中的挑战D），最后是找到自动确认分析结果的方法（第2节中的挑战E）。虽然在本文中我们没有为所有这些挑战提出完整的解决方案，但我们简单讨论了解决这些问题的方法和难度，以便对固件映像进行系统，自动化，大规模的分析。

结果分析：

实验中，我们从开源的固件更新站点收集了一组共759273个文件（1.8TB）。经过筛选过滤后，剩下172751个潜在的固件映像。然后我们部署了一个具有90个节点的私有云来对一组共32356个固件候选进行采样，最终产生10GB的分析和报告。

对采样文件的分析使我们自动发现并报告了38个新漏洞（其中一些漏洞尚未解决）并确认了几个已知的漏洞。我们的发现有：

bull;提取到了大约35,000个在线设备（主要与监控摄像头相关联）中使用的私人RSA密钥以及自签名证书。

bull;提取了几十个硬编码密码的哈希值。它们大多数都很弱，能够轻松恢复出原始密码。

bull;确定了许多可能的后门，例如授权密钥文件（列出了允许远程连接到系统的SSH密钥），影响至少2K个设备的硬编码telnetd凭证，影响至少101K设备的硬编码weblogin admin凭证，以及很多设备Web接口中的后门进程和网页。

bull;每当发现新漏洞（其他研究人员或我们）时，我们的基础分析架构使我们能够快速找到可能受同一漏洞影响的相关设备或固件版本。例如，我们的相关技术允许我们正确扩展受影响设备的列表，以查找telnetd硬编码凭据漏洞的变体，最终我们发现漏洞的根本问题分布在多个供应商中。

贡献：

本文做出了如下贡献：

bull;展示了对固件映像进行大规模分析的优势，并描述了与此活动相关的主要挑战。

bull;提出了一个执行固件收集，过滤，解包和分析的框架

bull;实施了几种有效的静态技术，并在32356个固件候选者上运行

bull;提出了一种可以将漏洞信息传播到类似固件映像中的技术

bull;发现了693个至少受一个漏洞影响的固件并报告了38个新的CVE

2 挑战

如前一节所述，对嵌入式固件映像进行大规模分析有明显的优势。但事实上，在系统安全中，某些现象只能通过全局而不是一次研究单个设备（或单个设备系列）来观察。然而，虽然获取单个固件映像，解压缩，并分析提取的文件是轻松的任务，但大规模的测试需要将这些步骤完全自动化，这使其变得更有挑战性。 在本节中，我们总结了我们在设计和实验过程中遇到的五个主要挑战。

挑战A：构建代表性数据集

嵌入式系统环境是异构的，包括各种设备，供应商，架构，指令集，操作系统和自定义组件。这使得编译代表性固件数据集的任务变得更加困难。

硬件架构的真实市场分布通常是未知的，并且很难比较不同类别的设备（例如医疗植入设备与监控摄像机）。那么构建代表性固件数据集需要考虑哪些因素呢？将在特定品牌路由器上测试过的技术推广到其他产品有多容易？将同一个技术应用于不统类别的设备（如电视，照相机，胰岛素泵或电厂控制器）有多容易？

从实际的角度来看，缺乏集中的收集点（例如由恶意软件分析领域中的病毒供应商或公共沙箱提供的收集点）使得研究人员难以收集大型且分类良好的数据集。固件通常需要从供应商网页下载，这对人来说，也不是简单地判断两个固件映像是否应用于同一物理设备。

挑战B：正确识别单个固件映像

固件分析和逆向工程中经常遇到的一个挑战是难以可靠地从固件映像中提取元数据。例如，供应商，设备产品的代码和用途，固件版本和处理器架构，以及许多其他细节信息。

实际上，固件文件格式的多样性使得甚至更难以识别从供应商网站加载的给定文件是固件。固件更新通常采用意想不到的格式，例如用于打印机的HP打印机作业语言和PostScript文档，用于BIOS的DOS可执行文件和用于硬盘驱动器的ISO映像。

在许多情况下，可靠信息的唯一来源是官方供应商文档。虽然在手动查看一些设备时这不是问题，但将分析扩展到数百家供应商以及从Internet自动下载的数千个固件映像很有挑战。事实上，信息检索过程很难自动化并且容易出错，特别是对于某些元数据。例如，我们很难推断出正确的版本号。这使得大规模收集和分析系统难以分辨哪个是最新版本，可用于哪个设备，并且两个固件映像是否对应于同一设备的不同版本。这使构建无偏差数据集的任务更加复杂。

挑战C：解包自定义存储格式

假设分析人员成功收集了一份代表性且标签清晰的固件镜像数据集，下一个挑战在于定位和提取重要的功能块（例如，二进制代码，配置文件，脚本，Web界面）可以执行分析例程。

虽然这个任务很容易解决传统的软件组件，其中标准化的机器代码（例如，PE和ELF），资源（例如，JPEG和GZIP）和文件组（例如ZIP）的分布和TAR）存在，嵌入式软件的分布缺乏标准。供应商已经开发了自己的文件格式来描述闪存和内存映像。在某些情况下，这些格式使用非标准压缩算法进行压缩。在其他情况下，这些格式被混淆或加密以防止分析。单个固件，其中引导加载程序，操作系统内核，应用程序和其他资源在单个存储器映像中组合在一起对于解包是特别具有挑战性的。

像文件雕刻这样的取证策略可以帮助从二进制blob中提取已知的文件格式。不幸的是，这些方法有一些缺点：一方面，它们往往过于激进，只能提取与文件模式匹配的数据。另一方面，它们的计算成本很高，因为每个解包器必须针对双向固件blob的每个文件偏移进行尝试。

最后，如果提取的二进制文件与任何已知的文件模式都不匹配，则无法确定此文件是否是数据文件，或者只是解压缩程序无法识别的另一个容器。通常，我们尝试解压缩至少到达未压缩文件。在某些情况下，我们的提取更进一步，并尝试提取部分，资源和压缩流（例如，对于ELF格式的文件）

挑战D：可扩展性和限制计算

执行大规模分析的主要优点之一是能够跨多个设备关联信息。例如，这使我们能够自动识别不同固件映像中易受攻击组件的重用，即使是来自不同供应商的也是如此。

捕获固件映像之间关系的全局图像需要对每对未压缩文件进行一对一比较。模糊散列（例如sdhash和ssdeep）是此类任务的常用且有效的解决方案，它们已成功用于类似的域，例如，关联属于相同恶意软件系列的样本。但是，如3.4节中更详细的描述，计算从26,275个固件映像中提取的对象之间的相似性需要进行1012次比较。使用更简单的模糊散列变量，我们估计在单个双核计算机上，此任务将花费大约850天2。这种简单的估计突出了与大规模固件分析相关的可能的计算挑战之一。即使我们拥有完美的数据库设计和高度优化的内存数据库，仍然很难计算，存储和查询所有解压缩文件对的模糊散列分数。分布式计算基础架构可以帮助减少自任务本身可并行化以来的总时间。但是，由于比较次数与要比较的元素数量呈二次方增长，因此对于大型图像数据集，此问题很快变得不可行。例如，如果想要为我们的整个数据集构建一个模糊哈希数据库，这个数据集的大小只是当前采样数据集的五倍，那么这项工作就需要超过150个CPU年，而不是850个CPU天。我们尝试使用sdhash提供的GPU辅助模糊散列只会导致有限的加速，这不足以对我们数据集中的所有文件进行全面比较。

挑战E：结果分析，确认

前四个挑战主要与数据集的收集和固件图像的预处理有关。一旦成功提取和识别嵌入式设备使用的代码或资源，研究人员就可以将注意力集中在静态分析上。尽管此步骤的细节和目标超出了本文的范围，但在3.3节中我们提供了一些简单静态分析的示例，并且我们讨论了大规模执行这些技术的优势。然而，关于静态分析结果的确认方式仍然存在一个重要的研究挑战。例如，我们可以考虑一种情况，即研究人员将新的漏洞检测技术应用于数千个固件映像。这些图像被设计为在特定的嵌入式设备上运行，其中大多数是研究人员无法获得的，并且获取起来既困难又昂贵。由于缺乏适当的硬件平台，仍无法手动或自动测试受影响的代码以确认或否认静态分析的结果。

例如，在我们的实验中，我们确定了一个包含PHP 5.2.12横幅字符串的固件商品图像。这使我们能够轻松识别与该PHP版本解释器相关的几个漏洞。但是，这还不足以确定PHP interterter是否容易受到攻击，因为供应商可能已应用修补程序来纠正已知的漏洞，而不会在版本字符串中反映出来。此外，供应商可能使用了一个体系结构和/或一组编译选项，这些选项产生了组件的非易受攻击构建。遗憾的是，即使存在针对该漏洞的概念证明攻击，如果没有适当的硬件，也无法测试固件并确认或否认存在问题。确认固件设备静态分析的结果是一项繁琐的任务，需要专家进行人工干预。将这种努力扩展到数千个固件映像甚至更难。因此，我们认为需要开发新技术才能准确地大规模处理这个问题。

3 配置

在本节中，我们首先介绍我们的分布式静态

资料编号：[5708]