Patrick在2014年的论文中第一次详细的描述了如何在Intel Management Engine (ME) 环境中构造一个持久化 rootkit——DAGGER（暗影匕首）。作为固件层攻击领域的重要里程碑，该研究展示了利用 DMA 技术直接从宿主内存中扫描、读取并窃取敏感数据（如键盘缓冲区中记录的击键码）的方法，同时利用 ME 内部的带外（OOB）机制实现数据潜出。论文分别针对GNU/Linux和 Windows 两大目标系统提出了定制化攻击方法，包括内存数据结构签名扫描、物理与虚拟地址映射以及对系统关键数据结构的定位。研究不仅揭示了 Intel ME 环境中存在的潜在安全隐患，也为固件层反制机制及未来安全防护方案的设计提供了重要启示。对于关注底层安全、固件漏洞以及持久化隐患的研究者来说，这篇论文和其概念验证（PoC）均对后来的系统安全威胁具有极高的参考价值。

Detecting Peripheral-based Attacks on the Host Memory

Patrick Stewin

摘要

对手可以通过在目标平台上部署 rootkit 技术以便以某种隐秘的方式持续攻击计算机系统。行业和政治间谍活动、对用户的监控，以及引导网络犯罪等行为要求对计算机系统进行隐秘攻击。利用某种 rootkit 技术意味着，所实现的攻击代码中的一部分负责隐藏此次攻击。被加载到诸如网卡或者特殊的微控制器等外设的攻击代码目前成为了 rootkit 进化的顶峰。本工作检视了宿主计算机上的此类基于外设的隐秘攻击。外设拥有一块专用处理器以及专用的运行时内存以处理其任务。这意味着这些外设实质上是一个独立的系统。攻击者得益于这种隔离。外设通常通过宿主的主内存同宿主进行通讯。攻击者利用了这一事实。宿主的所有运行时数据存在于主内存中，这包括密码学密钥、口令、已打开的文件以及其他敏感数据。攻击者只需定位这些数据。随后，攻击者可以利用外设的直接内存访问机制暗中读取和修改这些数据。这使得绕过诸如业界最先进的反病毒软件和加固的现代操作系统内核等安全软件成为可能。

检测这样的攻击是本工作的目标。基于独立微控制器的隐形恶意软件被实现为引导技术分析。此恶意软件的概念验证称为 DAGGER，它来自于 Direct memory Access based keystroke code loGGER（基于直接内存访问的击键码记录器）。对此恶意软件的开发和分析揭示了基于外设的恶意软件的重要属性。其检测程序称为 BARM——Bus Agent Runtime Monitor（总线代理运行时监视器）。此检测程序揭示了通过利用某些硬件属性对宿主的主内存进行的基于外设的隐秘攻击。一种永久的并且高效利用资源的测定策略保证了此检测程序同时还能检测瞬时攻击。如果所应用的测定策略只会在特定的时间点进行测定，则此类瞬时攻击将会成为可能。攻击者可以如此利用此种测定策略，通过在两次测定之间对系统进行攻击，并且在系统被测定之前销毁所有进攻痕迹。对于之前提出的预防性保护方式，即输入/输出内存管理单元，此检测程序代表了一种替代解决方案。由于实践方面的原因，之前提出的方法不一定是高效的。这一事实再加上由基于外设的恶意软件所带来的威胁共同要求本工作所呈现的替代检测方案。此检测程序不仅能够揭示攻击，同时能够终止该恶意设备。BARM 立即检测到并且阻止由 DAGGER 引导的攻击。其性能开销可以忽略。更进一步地，BARM 能够向外部平台报告宿主的主内存是否受到了外设的攻击。

与本论文相关的发表

本论文呈现的工作带来了下列通过同行评审的发表：

• Understanding DMA Malware, Patrick Stewin and Iurii Bystrov, DIMVA2012 Proceedings of the 9th Conference on Detection of Intrusions and Malware & Vulnerability Assessment, Heraklion, Crete, Greece, July 26-27th, 2012 ([参见 123] / 第 4 章)

• Extended Abstract – Poster: Towards Detecting DMA Malware, Patrick Stewin, Jean-Pierre Seifert, Collin Mulliner, CCS2011 Proceedings of the 18th ACM Conference on Computer and Communications Security, 2011 ([参见 126] / 第 4 章)

• A Primitive for Revealing Stealthy Peripheral-based Attacks on the Computing Platform’s Main Memory, Patrick Stewin, RAID2013 Proceedings of the 16th International Symposium on Research in Attacks, Intrusions and Defenses (RAID), St. Lucia, October 23-25, 2013 ([参见 122] / 第 5 章)

下列通过同行评审的发表根据第 6 章进行了更新，以考虑到基于 DMA 的恶意软件的场景，这也是本论文关注的焦点：

• Beyond Secure Channels, Yacine Gasmi, Ahmad-Reza Sadeghi, Patrick Stewin, Martin Unger, N. Asokan, STC2007 Proceedings of the 2007 ACM Workshop on Scalable Trusted Computing, 2007 ([参见 52])

• An Efficient Implementation of Trusted Channels based on OpenSSL, Frederik Armknecht, Yacine Gasmi, Ahmad-Reza Sadeghi, Patrick Stewin, Martin Unger, Gianluca Ramunno, Davide Vernizzi, STC2008 Proceedings of the 3rd ACM Workshop on Scalable Trusted Computing, 2008 ([参见 10])

第 1 章 简介

我认为，大多数人甚至都不知道 rootkit 是什么，那么他们为什么要去关心它呢？——Thomas Hesse，索尼全球数字业务前主席

大多数人可能会将 rootkit 这一术语同针对计算机平台的攻击相关联。实际上，对手部署 rootkit 是为了攻击计算机用户。基于 rootkit 的攻击被用于引导行业和政治间谍活动以及网络犯罪 [参见 16，p.22-25]。对手通过引导行业间谍活动来偷取知识产权以减少技术开发周期的成本。政治间谍活动不同于行业间谍活动。在政治间谍活动中，对手所感兴趣的是国家机密而非新技术。网络犯罪分子利用 rootkit 来偷取互联网银行凭证、口令以及其他敏感信息。rootkit 也可被用于引导对最终用户的持久监控。rootkit 还可被用于强制执法，以执行对嫌疑人的监控 [参见 16，p.21]。但是，准确地说，rootkit 到底是什么？它是 后门 吗？它是 特洛伊木马 吗？换言之，rootkit 所包含的恶意负载是什么类型，以及目标计算机是如何被此 rootkit 所渗透的？

术语 rootkit 的若干种定义可以在这样一些文献中找到，例如 Bill Blunden 所著的 The Rootkit Arsenal: Escape And Evasion In The Dark Corners Of The System [16]。他的著作同时评估了 Mark Russinovich（此人以 Windows Internals [106] 系列著作而闻名）和 Greg Hoglund（Rootkits: Subverting the Windows Kernel [60] 一书的作者）对于 rootkit 的定义。最后，Bill Blunden 得出了他自己的定义 [参见 16，p.12]：

rootkit 在一台设备上建立了一个远程接口，此接口使得系统可以被操纵……数据可以被收集（例如监控），以某种难以被观察到的方式（例如隐藏）。

所有这些定义提示了 rootkit 在总体上所展现出来的一个重要属性，即能够隐秘地运作的能力。攻击者通过部署 rootkit 来掩护用于攻击目标计算机的代码。这一点回答了关于 rootkit 的恶意负载的问题。此负载可以被用于执行在用户看来是恶意行为的任何东西。此恶意行为也可以是后门。后门被用于绕过诸如认证请求等安全机制以获得对某台计算机系统的访问权限。后门还可以为攻击者提供对于某台计算机的远程访问权限。在攻击者看来，将此后门隐藏起来是有意义的。此后门应该在计算机用户毫不知情的情况下被使用。因此，后门可以得益于 rootkit 机制。rootkit 负载的另一个例子是监控程序，此程序通过激活目标计算机的话筒和摄像头以暗中监视该计算机的用户。能够捕获由某位计算机用户所输入的所有击键的击键码记录器也是恶意负载的常见范例。

然而，对于攻击者的挑战在于渗透目标计算机平台。此攻击者必须实现某种类型的 rootkit 安装程序。rootkit 安装程序通常被称为 释放器 [参见 16，p.9] [33]。这样的释放器可以基于最常见的渗透机制之一，即特洛伊木马，或者简称木马。木马的目的在于在目标计算机将要安装某个预想的程序、特性或者功能时对其进行误导。与之相反，其结果是用户安装了诸如击键码记录器或者后门等恶意负载。诸如此类的负载通常被部署于高权限环境，并且利用 rootkit 技术加以掩护。另一种常见的渗透方式是利用某个安全漏洞。此 rootkit 安装程序可以实现某种 漏洞利用。漏洞利用是一段利用安全漏洞的攻击代码。所谓的 零日漏洞 相对于非零日漏洞更具威胁性。零日漏洞所利用的是某个此前未知的安全漏洞，这可能对于攻击者更加有利。它使得攻击者能够引导一次对于目标计算机的隐秘渗透。

rootkit 的另一个关键属性是其代码运行于可能的最高权限之上。其目标是获得至少是高于任何潜在的检测机制的权限。这使得 rootkit 能够控制并且修改检测机制。在某种程度下，检测机制将会无法检测 rootkit 或者由此 rootkit 掩护的恶意负载。这是攻击者寻求新的、更加强大的攻击向量的原因。攻击者获得的权限越多，其所获得的对于目标计算机的控制也就越多。

攻击者的目标是获得对目标计算机的绝对控制。rootkit 进化 记录了攻击者和反恶意软件社区之间的军备竞赛。相对于早期的 rootkit，现在的 rootkit 已经前进到了更高权限的执行环境。近年来 [35，36，47，134，135] rootkit 的进化达到了一个新的水平。攻击者开始利用平台外设的隔离执行环境。具有专用处理器、专用内存以及直接访问宿主的运行时内存的硬件特性的外设能够掩护用于攻击目标计算机的恶意负载。这样的攻击被认为是隐秘的。市场上可获得的现代反病毒软件之类尚未考虑基于外设的执行环境。这样的软件执行于宿主处理器上，并且通常只将硬盘和主内存考虑为能够存储恶意代码。

1.1 问题表述

恶意软件是对数据的机密性、完整性以及可用性的威胁。对于基于外设的恶意软件的情况，攻击者可以利用外设的隐形潜力。隐藏在平台外设中的恶意软件不会被反病毒软件所考虑。取决于外设，安全软件甚至不能访问该设备的内部工作。例如某些管理控制器拥有对全部宿主内存的访问，并且提供远程管理特性。为了防止滥用，制造商应用保护机制以阻止对此执行环境的内部工作的访问。

这种机制，如果被基于外设的恶意软件所利用以攻击宿主，则称之为直接内存访问或者 DMA。在本工作中，我们将会引入术语 DMA 恶意软件 以用于诸如此类的攻击。DMA 恶意软件拥有同 rootkit 相似的特性。当前的反制措施无法应对 DMA 恶意软件的挑战。例如，对本意将要在外设上运行的代码进行加载时完整性检测等机制并不能阻止运行时攻击。这同样适用于数字签名的固件镜像的情形。另一种方式是基于延时的证明。此类证明要求一段散列值在一定的时间框架内被计算出来。然而，这同样要求修改外设固件，并且不能阻止瞬时攻击。诸如特殊监控以及内存总线嗅探等其他方式基于特殊硬件或者硬件特性。阻止敏感数据出现在主内存中同样不能奏效。这些数据可以通过 DMA 攻击被转储到主内存中 [脚注 1]。

脚注 1：具体细节可以在 3.2 节“相关工作——反制措施”部分找到。

一种被提议的针对 DMA 攻击的反制措施是使用一种所谓的 输入/输出内存管理单元（I/OMMU）。这样的管理单元可以限制外设对宿主的部分主内存的访问。然而，此技术具有重大缺陷。已有证据表明 I/OMMU 可以被攻击并且绕过 [111，146，147，148]。因此，I/OMMU 不一定可信。某些操作系统，诸如 Windows，并不提供驱动程序以支持 I/OMMU。此外，并非每种芯片组都提供 I/OMMU。更进一步地，I/OMMU 不能处理内存访问策略冲突。例如，Bulygin [25] 展示了如何利用外设以揭示存在于宿主的运行时内存中的恶意软件。我们将相同的执行环境用于第 4 章的攻击研究。例如，如果 I/OMMU 被配置为允许外设扫描宿主的全部运行时内存以揭示 rootkit，那么我们的攻击代码同样可以访问全部运行时内存以偷取敏感数据。因此，本工作并不依赖 I/OMMU 作为一种反制措施。更进一步地，I/OMMU 可能会引入显著的性能开销 [13，150]，这使得 I/OMMU 对于某些场景并不理想。由于这些考虑，我们相信缺少这样一种能够检测恶意内存访问并且具有可忽略的性能开销的运行时监视器。这样一种运行时监视器的缺失正是推动本工作的动力之一。

1.2 研究问题和方法论

我们的研究兴趣基于现代 x86 平台的隐形能力。这些能力被对手以利用以隐藏恶意代码，如同 rootkit 进化所记载，同时参见 2.1 节。这提出了这样一个问题，即不可被检测到的软件是否能够存在。为了检验这个问题，我们考虑了 rootkit 中的下一个逻辑步骤，即利用平台外设以攻击宿主的运行时内存。

我们开发了一种恶意软件的 概念验证（PoC），它执行于某个隔离的外设上。此外设的硬件提供了对宿主的运行时内存的访问。我们以击键码记录器的形式实现了一次攻击。这意味着我们的恶意软件搜索宿主操作系统的键盘缓冲并且监视该缓冲以捕获击键码。对此击键码记录器的评估指导了我们后续的一个研究问题，即宿主系统能否保护自己以对抗基于外设的宿主主内存攻击？为了回答这个问题，我们实现了一个运行时监视器，它执行于宿主 CPU 上。有了这个监视器，我们想要展示这一点，即来自平台外设的对宿主主内存的额外（恶意）访问事实上是可以被检测到的。我们要求基于宿主 CPU 的检测程序能够检测恶意访问，即使它不能访问该恶意外设的隔离执行环境。

我们利用我们的恶意软件样本以得出此类恶意软件的一般属性。随后我们利用了这些属性以检测由恶意软件所引导的内存访问。我们定义了这样一种属性，它是每一种攻击宿主内存的基于外设的恶意软件都体现出来的。基于此，我们将我们的恶意软件概念验证视为对于此类恶意软件典型的。我们实现了基于宿主 CPU 的检测程序以揭示由平台外设通过直接内存访问所引导的非法内存访问。其目标是实现这样一种运行时监视器，它不仅对于宿主 CPU 只造成最小化的性能开销，同时能够阻止瞬时攻击。

我们还在我们的研究的最后一部分考虑了网卡。网卡同样可以托管恶意软件。特别是在企业环境中，某个计算机平台被要求向某个中央管理员平台报告其状态。这样的状态报告可以被执行于网卡上的恶意软件修改。因此，我们开发了一种合法报告信道。此信道有助于揭示针对此类状态报告的攻击。

实验研究环境

我们的实验环境基于 Intel x86 硬件。我们用于执行我们的基于外设的恶意软件的隔离环境是 Intel 管理引擎（Intel ME [79]）。Intel ME 是一种特殊的微控制器，它运行某种强大的平台管理固件。管理员可以利用此管理固件远程重装操作系统，即使操作系统已经不可引导，并且该平台不可通过操作系统的网络栈抵达。ME 同样能够在平台处于待机或者关机的情况下运作。由于这些特性，其制造商 Intel 建立了这样的保护机制，它们不能在不付出巨大努力的情况下被绕过。ME 是同宿主系统相隔离的。Intel ME 环境是同宿主完全隔离的，而其他外设可以通过调试寄存器以及其他机制来访问。

从检测程序的角度来看，ME 是用于托管基于外设的恶意软件的执行环境的最坏的案例。宿主 CPU 无法访问 ME 环境。我们将这一最坏案例环境用于我们的研究。我们通过应用某个只能工作在特定芯片组 [脚注 2] 上的漏洞来渗透 ME 环境。请注意，此工作并不致力于查找未被发现的安全漏洞。我们重复利用了某个已知的安全漏洞来设置我们自己的实验环境，是由于缺少一块适合的 Intel 开发板。

脚注 2：此漏洞利用仅适用于刚好具有特定版本 BIOS 的 Intel Q35 芯片组。Intel 通过提供 BIOS 更新堵住了对应的安全漏洞。

1.3 论文贡献的影响

例如为了引导行业间谍活动或者偷取在线银行凭证等，攻击者要求能够隐秘运作的恶意软件。基于外设的恶意软件保证了攻击仍然不可被检测到。能够满足隐秘恶意软件运作的需求的外设存在于几乎每一部现代计算机平台中。诸如显卡、网卡和管理控制器等是台式机、服务器系统以及其他计算机终端的组成部分。移动电话和平板计算机也具有那些带有独立处理器、内存以及对宿主运行时内存的直接访问的外设。这意味着所有现代平台都易受基于外设的恶意软件的攻击。这样的恶意软件执行于隔离环境中，并且处于由操作系统内核所设置的反病毒软件和安全机制的视野之外。由于缺少针对基于外设的恶意软件的检测程序以及在反病毒软件中缺少类似功能，本论文的贡献可能对上述计算机设备及其用户具有重大影响。我们将本论文的主要贡献总结如下：

DMA 恶意软件研究

我们定义了 DMA 恶意软件以便能够区分不同的 DMA 代码。这样的恶意软件执行于某个外设上，并且能够通过直接内存访问攻击宿主。我们开发了一种 DMA 恶意软件实现的概念验证，它能够利用某个隔离的外设来引导隐秘攻击。我们的概念验证称为 DAGGER，它来自于 DmA-based keystroke code loGGER（基于 DMA 的击键码记录器）。DAGGER 可以攻击不同的宿主操作系统。DAGGER 强调了 DMA 恶意软件在实践中是多么地高效。我们识别了 DMA 恶意软件的核心属性以研究诸如此类的恶意软件的属性。这些属性是 DMA 恶意软件检测程序的基础。在一次早期实验中，我们提供了关于 DMA 的副作用存在的证据。我们展示了这样一种效应可以如何利用通常的宿主 CPU 特性进行测定。这是 DMA 恶意软件检测程序开发的第一步（参见第 4 章）。

检测 DMA 恶意软件

我们开发了一种监视器，它能够通过比较实际的内存总线活动和预期的内存总线活动来检测 DMA 恶意软件。我们的方法能够确定并且比较实际的总线活动而不受任何固件或者硬件修改的影响。此检测器基于这样一种特性，它实现了永久的运行时监控并且运行在宿主 CPU 上。我们实现并且评估了这样一种概念验证，我们称之为 总线代理运行时监视器（BARM）。我们的监视器实现了这样一种监视策略，它会考虑瞬时攻击。它只会造成可忽略的性能开销。BARM 可以检测并且立即终止 DMA 恶意软件（参见第 5 章）。

排除了 DMA 恶意软件干扰的合法平台状态报告

我们展示了我们的检测方法同样适用于这样的场景，在此，一部计算机平台必须向某个中央管理员平台报告其状态。我们建立了这样一种合法报告信道，它能够揭示由执行于网卡上的恶意软件所引导的攻击。这意味着我们改良了 BARM 以揭示 中间人（MitM）攻击，并且阻止由网卡引导的中继攻击。我们实现了一种信道以便将平台状态信息安全地传输至一台外部计算机。此平台状态信息允许远程实体评估 BARM 的测定结果。这意味着远程实体可以确定其对端是否受到了 DMA 恶意软件的攻击。我们的信道将宿主 CPU 视为信道的端点，而非完整的目标平台。这排除了网卡作为端点的一部分。我们改良了 BARM 以说明由网卡所造成的内存总线活动。此改良的 BARM 利用 OpenSSL 来实现合法报告信道。我们还修改了 TLS 握手协议以便在通讯会话的最初阶段就说明平台状态信息。我们的修改仍然符合 TLS 规范（参见第 6 章）。

具体的工作细节可以在各对应章节找到。

1.4 论文结构

根据我们的方法论，我们按照如下方式组织论文结构。下一章，我们将会介绍必需的技术背景、预备知识以及假设。用于我们的评估的目标平台是一种基于 Intel x86 的现代系统，参见 2.2，2.3，2.4，2.5 和 2.6 节。这些章节介绍了关于该目标平台的大部分重要术语，特别是宿主 CPU、直接内存访问（DMA）、总线主控以及 输入/输出内存管理单元。我们还在 2.7 节介绍了我们的假设以及由此得出的对手模型。第 3 章覆盖了相关工作。由于我们同时考虑攻击以及攻击检测和防护两端，我们必须认真研究两端的相关工作。关于 DMA 攻击的相关工作描述于 3.1 节。3.2 节呈现了那些考虑了反制措施的前期工作。更进一步地，我们想要使得我们的目标平台能够向外部平台报告其关于基于 DMA 的恶意软件的状态。为了达成这一目的，我们要求一种能够揭示由网卡发动的中间人攻击的通讯信道。这是必需的，由于我们同时将网卡视为能够隐藏 DMA 攻击代码的专用硬件。

我们引导了针对 DMA 恶意软件的研究并且将其结果呈现于第 4 章。关于 DMA 恶意软件的定义给出于 4.1 节。在 4.2 节，我们呈现了 DMA 恶意软件的核心功能。我们自己的 DMA 恶意软件的设计和实现呈现于 4.3 节。4.4 节描述了对于 DAGGER 的评估。4.5 节考虑了反制措施并且特别讨论了 I/OMMU 的问题。在同一节中，我们描述了我们如何能够利用这些属性以显示首个 DMA 副作用。由于宿主 CPU 无法直接意识到由受到攻击的外设所引导的非法内存访问，我们试图触发一种发生于外设访问主内存时发生的副作用。

第 4 章所呈现的 DMA 副作用是推动我们实现我们于第 5 章所介绍的运行时监视器的动力。在第 5 章“DMA 恶意软件检测初步”中，我们展示了 DMA 副作用可以被如何利用以开发检测工具。我们定义了一种通用检测模型，它有助于我们构建检测工具，参见 5.1 节。随后，我们在 5.2 节中呈现了一种基于流行的 Intel x86 平台的概念验证实现。我们在 5.3 节评估了我们的实现。我们同时利用我们于第 4 章开发的 DMA 恶意软件测试了 BARM。最后，BARM 利用了这一事实，即我们的 DMA 恶意软件必须搜索有价值的数据，由此造成了一定量的总线传输。

在第 6 章，我们改良了我们的检测工具以实现一种合法状态报告应用程序。此应用程序将 BARM 测定结果发送至某个外部平台。其目标是实现这样一种安全通讯信道，此信道排除了由运行于网卡之上的恶意软件引导中间人攻击的可能性。在 6.1 节，我们呈现了一种模型以协商一种合法报告信道。我们需要一种诸如 TLS 的安全信道，它绑定于实际的通讯端点，即宿主 CPU。我们关于合法报告应用程序的概念验证基于 OpenSSL，参见 6.2 节。此实现章节同时描述了为了考虑网卡而必需的 BARM 改良。关于我们的实现的评估呈现于 6.3 节。我们还利用我们自己的 DMA 恶意软件 DAGGER 测试了关于网络的 BARM 改良。合法报告信道的安全性考虑于 6.4 节讨论。我们关于此论文的结论以及今后的工作呈现于最后一章，第 7 章。

第 2 章 技术背景、预备知识和假设

在孩子面前放一台计算机并且指望由它来教育他，就好比在他的枕头底下放一本书，只不过更加昂贵而已。——Joseph Weizenbaum，德国/美国计算机科学家

为了理解我们的后续章节，尽管获知大量关于现代计算机架构的细节是有益的，然而在这里解释所有这些晦涩的细节并不现实。因此，我们将读者引向一系列文献 [参见 54，59，118，127] 以获得关于此话题的完整论述。我们将本章限定为理解本工作所必需的最重要的术语。我们从 rootkit 进化 开始。这段进化史突出展示了为何呈现于后续各节的技术背景有助于理解本工作。

2.1 rootkit 进化

在流行的 x86 平台上，rootkit 的能力与其执行环境强烈相关，例如用户模式（3 环）或者内核模式（0 环）。现代 x86 处理器提供所谓的保护环以区分不同权限的执行环境，参见图 2.1。对 rootkit 进化的分析揭示了这一事实，即攻击者在 x86 平台发现了新的、更加强大的执行环境。以下段落总结了不同类型的 rootkit，即用户模式、内核模式、基于虚拟机的、系统管理模式、基于固件的以及基于外设的。这段概述呈现了 rootkit 进化史，并且展示了近年来 rootkit 这一术语是如何变化的。

图 2.1 “-3 环”环境，与 x86 平台上的其他 rootkit 环境相比

请注意，3 环和 0 环实现于硬件（宿主 CPU）中。术语“-1 环”、“-2 环”和“-3 环”被用于强调对应的执行环境的能力，它们并非实现于硬件中。

用户模式 rootkit 使用简单的技术，其基本理念是将 rootkit 伪装成正常的软件 [129]。例如，攻击者向某个运行于用户模式并且具有超级用户/root 权限的普通软件工具中添加所需的恶意功能。此修改过的工具替换了目标平台上的原始工具。用户模式 rootkit 被认为是 rootkit 进化的起点。其名称来源于赋予了超级用户 root 的权限级别。用户模式 rootkit 可以被运行于内核模式的特定检测工具发现。

内核模式 rootkit 基于某种高级技术以便利用操作系统内核组件来隐藏 rootkit [60]。内核模式 rootkit 修改了内核，或者更准确地说，修改了内核代码（例如系统调用）或者内核数据。对内核的修改改变了内核行为以强制实施某些隐形能力，进而隐藏恶意活动 [参见 129]，例如击键码记录器。执行于内核模式的 rootkit 不受那些用于揭示用户模式 rootkit 的技术的影响。

用于控制一台计算机系统的更加强大的 rootkit 称为 基于虚拟机的 rootkit（VMBR），诸如 SubVirt [77] 和 Blue Pill [108]。一种称为 hypervisor 或者 虚拟机监视器（VMM）的控制实例通常被用于在 虚拟机（VM）中托管客户操作系统。而 VMBR 通过利用 VMM 环境以便在虚拟机中托管目标计算机的操作系统。由于操作系统内核执行于 VMM 环境上，VMBR 可以被看作运行于“-1 环”上。因此，一个恶意控制实例被放置于硬件和操作系统之间。VMBR 难于安装，然而反过来说，VMBR 同样难于检测。Blue Pill 可以在计算机运行时托管目标操作系统，即无需关机或者重启。

用于 rootkit 的另一种强大的执行环境称为 系统管理模式（SMM）。SMM 是一种特殊的高权限处理器模式，它用于执行特殊的系统软件。它同样可以被利用以实现所谓的基于 SMM 的 rootkit。在 SMM 中执行的代码运行于宿主 CPU 的最高权限上。这意味着基于 SMM 的 rootkit 在运行时具有多于操作系统内核和虚拟机监视器的权限。因此，基于 SMM 的 rootkit 可以被看作执行于“-2 环” [145]。在 2008 年，Embleton 等人 [49] 和 Wecherowski [144] 展示了 SMM 可以如何被用于 rootkit。SMM 代码存储于固件中，即 SMM rootkit 可以被看作固件 rootkit 的特例。

基于固件的 rootkit 也是非常强大的。在固件中部署 rootkit 非常困难，但是并非不可能。固件是一种存储于闪存存储器上的特殊低级软件。基本输入/输出系统（BIOS）是存储于 x86 平台上的闪存存储器中的固件的一个范例。基于固件的 rootkit 并不是部署于硬盘上。因此，很难检测并且移除此恶意软件。攻击者可以利用此 rootkit 来攻击操作系统，即使用户重装操作系统。Heasman [56] 在 Black Hat Federal 2006 大会上展示了如何实现并且检测基于 BIOS 的 rootkit。Heasman [57] 延续了此项研究。由 Wojtczuk 和 Tereshkin [149]、Loukas K [84，85]，以及 Ortega 和 Sacco [97，98] 等人展示其他 BIOS 固件攻击可以作为 rootkit 的基础。Brossard [21，22] 还展示了 硬件后门是可行的。此作者利用了开源 BIOS coreboot [脚注 3] 及其相关工具以刷新 BIOS 以及外设的只读内存以攻击计算机平台。

脚注 3：参见 http://www.coreboot.org/Welcome_to_coreboot [访问于 2014 年二月 25 日]

隐藏于固件中的 rootkit 也可以被实现为使用平台外设的固件。这样的 rootkit 称为 基于外设的 rootkit。一种潜在地可被利用的外设是网卡 [134]。Heasman [55] 也讨论了如何实现并且检测一种部署于存在于 外设元件互连标准（PCI）设备上的扩展 只读内存（ROM）中的基于 PCI 的 rootkit。外设同实际的宿主系统之间被良好地隔离。因此，这种外设中的执行环境并未被反病毒软件所考虑。这使得外设对于攻击者而言极具吸引力，参见图 2.2。

图 2.2 能够潜在地被 rootkit 利用的专用隔离硬件概述

隐藏于外设中的 rootkit 能够直接访问计算机平台的主内存。因此，它们可以偷取敏感数据，诸如硬盘加密密钥、视频电话通讯会话密钥、在线银行凭证、口令、打开的文件等。这样的 rootkit 也可能修改主内存中的数据。

一种能够在独立处理器上执行平台管理代码的特殊微控制器提供了良好的隐形能力，并且同样可以被用于 rootkit。在 Black Hat USA 2009 大会上，Tereshkin 和 Wojtczuk [131] 展示了将此类微控制器用于 rootkit 的理念。他们引入了术语“-3 环”以强调其隐形能力。这样的基于外设的 rootkit 被认为比基于 SMM 的 rootkit 更具隐秘性。Bulygin [25] 展示了如何利用这种特殊的基于微控制器的环境来检测基于 SMM 和基于 VMM 的 rootkit。由于诸如网卡等外设通过主内存同宿主操作系统进行通讯，基于外设的 rootkit 可以通过非法读取或者写入宿主内存来攻击宿主。这种允许外设进行内存访问的机制称为 直接内存访问（DMA，参见 2.4 节）。由于这种机制，基于外设的 rootkit 被认为是绝对隐秘并且不可能被检测到的。这样的 rootkit 技术是本工作关注的焦点。基于外设的 rootkit 可以通过 DMA 访问宿主内存以偷取存在于宿主运行时内存中的口令、在线银行凭证、打开的文件等。它们还可以通过诸如基于内核的后门等其他攻击代码来渗透宿主 [47]。

注意，我们在本工作中避免使用术语“-3 环”。并没有什么“-3 环”是实现于硬件中的。诸如“-1 环”、“-2 环”和“-3 环”等术语仅仅被用于描述 x86 平台上的对应环境的权限级别。所处的环越低，则 rootkit 的能力就越大。在本论文中，我们将会使用术语“恶意软件”，由于我们所分析的攻击并非执行于宿主 CPU 上。因此，root 权限与之无关。我们所关注的恶意软件同原始的用户空间 rootkit 相比只有这一点是共同的，即它们的目标都是隐秘运作。

2.2 典型的基于 x86 的系统架构

典型的 x86 系统架构的主要组件描述于图 2.3 中。中央处理器（CPU）、内存控制器集线器（MCH）和 输入/输出路径控制器（ICH）之间的连接称为芯片组 [54]。这种芯片组解决方案也称为 三芯片解决方案。系统内存（随机访问存储器，或者简称为 RAM）以及显示适配器被连接到 MCH。MCH 控制了对内存的访问。它可以阻止对内存地址的请求，或者将此请求重定向到 ICH，如果该目标地址属于 ICH。诸如闪存存储器、网卡（NIC）等通过 外设元件高速互联标准（PCIe [24]）整合到系统中。此标准为外设和芯片组之间实现了一种串行互连。网卡和其他扩展卡可以通过 PCIe 连接到 ICH。用于存储诸如 基本输入/输出系统（BIOS [参见 54，p.369]）等固件的闪存存储器也被连接到 ICH。

图 2.3 x86 芯片组和外设组件

芯片组组件包括 中央处理器（CPU 或者宿主处理器）、内存控制器集线器（MCH，又称为北桥）以及 输入/输出路径控制器（ICH，又称为南桥）。外设不属于主芯片组。

请注意，Intel 在 Intel 5 系列芯片组 [121，p.15] 中引入了一种所谓的 双芯片解决方案。这意味着 MCH 功能被整合进宿主 CPU，并且被称为 集成内存控制器（IMC [32，p.14]）。同之前的 MCH 一样，IMC 是控制内存访问的控制实例。ICH 被更名为 平台路径控制器（PCH [68]）。本论文中引导的实验基于三芯片解决方案。

其他控制器设备将其他格式通过 PCIe 连接到系统，诸如 通用串行总线（USB [8]）、火线（FW [6]）或者 串行高技术配置（SATA [7]）等。传统 PCI 设备通过一种所谓的 PCI 到 PCIe 桥接 连接到 PCIe 架构 [24]。在笔记本计算机中，个人计算机存储卡国际联盟（PCMCIA）/快速卡（ExpressCard）[139] 设备通过 PCIe 整合到系统中。宿主 CPU 不一定是系统中唯一的处理器。例如，显卡支持一种 图形处理器（GPU）以高效渲染计算机图形。待处理的数据存储于 显存（VRAM）中，它独立于通常的系统内存。具有相似属性的其他设备包括网卡以及位于平台的 MCH 中的 Intel 管理引擎（ME [79]）。它们同样利用独立处理器和独立内存来执行固件。

2.3 基于 Intel x86 的宿主中央处理器

Intel x86 中央处理器（CPU）公布于 1978 年 [参见 59，附录 K.3]。此后，x86 CPU 持续被增强，直到最近，x86 处理器包含若干个单元以支持用于不同计算任务的适当特性。现代扩展包括浮点单元、单指令流多数据流（SIMD [117，p.524]）、流式 SIMD 扩展（SSE [117，p.748]）、x64 [58，p.351]、物理地址扩展（PAE [69，p.2-23]）、多级缓存（L1、L2、L3 缓存 [59，p.117]）、性能监视单元（PMU [参见 104，p.429]），以及虚拟化的硬件支持等，如 Grawrock 所描述 [54]。一块现代 x86 处理器通常也包括多个核心 [参见 59，p.117]，这些核心提供具有不同的位宽的寄存器，即从 16 位到 512 位 [参见 70，第 1.2.1 节]。

为了提供保护机制，CPU 通过所谓的保护模式支持一种权限模型。此模型提供的不同权限等级也称为环，以分隔运行于此硬件上的特定软件。如果处理器处于保护模式，则有 4 种环可用。0 环是权限最高的环，而 3 环的权限最少。操作系统执行于 0 环。因此它同运行于 3 环的应用程序相隔离。1 环被认为是用于设备驱动程序的，而 2 环被用于服务，尽管在实践上 1 环和 2 环并未被使用 [54，p.41]。

系统管理模式（SMM [69]）是另一种处理器模式，仅对于系统固件可用。此模式被引入 x86 架构以实现高级能效，例如通过关闭未使用的硬盘，以及控制系统硬件，例如当系统达到温度限制时打开系统风扇并且关闭系统。SMM 通过中断触发，即 系统管理中断（SMI）。SMI 处理程序代码在系统初始化的早期由 BIOS 从闪存存储器中加载至 系统管理内存（SMRAM）。为了防止由来自除了 SMM 以外的其他处理器模式的代码修改 SMI 处理程序代码，芯片组提供了一个特殊的位，它称为 D_LCK。此 D_LCK 位在 SMI 代码被加载至 SMRAM 之后被设置以对其进行保护。如果此 D_LCK 位被设置，则不可能更改 SMRAM 的内容。

如果某个 SMI 触发了 SMM，当前执行的程序被中断，并且处理器状态将会被保存。随后，处理器执行 SMI 处理程序代码。当此处理程序代码执行完毕时，被保存的处理器状态将被恢复。当处理器从 SMM 切换回之前的处理器模式时，被中断的程序可以继续运行。注意，之前的处理器模式损失了 CPU 周期/时间，由于两种处理器模式不能同时被执行。SMM 可以被看作一种独立的执行环境。SMRAM 是一块独立的地址空间，并且仅在处理器处于 SMM 时可访问。换言之，操作系统不能访问 SMRAM。更进一步地，SMM 中的权限不受限制，执行于 SMM 中的代码可以调用任何 I/O 以及系统指令。

在 Intel 平台上，x86 中的硬件虚拟化扩展称为 Intel 虚拟化技术（Intel VT）[54]。虚拟化机制被用于在单一的硬件平台上并行运行彼此隔离的多个操作系统或者应用程序。一种称为 虚拟机监视器（VMM）的控制实例用于托管 虚拟机（VM）中的客户操作系统。现代 x86 CPU 提供了一种特殊的指令集，称为 VT-x。VT-x 是 Intel VT 的一部分，并且其本意是用于支持硬件虚拟化。此种硬件支持提供了两种特殊的 CPU 操作：VMX root 操作和 VMX 非 root 操作。VMM 运行于 VMX root 操作模式。运行于 VMM 之上的 VM 处于由 VMM 控制的 VMX 非 root 模式。这两种操作模式都支持其各自的保护环，各 4 个。因此，客户系统的软件（内核、驱动程序、应用程序等）可以运行于其被指认的权限级别。VMX 非 root 操作模式中的保护环被认为是低权限的，由于这些环受到运行于 VMX root 操作模式的 VMM 的控制。而 VMX root 操作模式的 4 个环是高权限的。通常，VMM 只会使用最高权限的环。此环通常称为“-1 环”以强调它控制着较低权限的 0-3 环这一事实。

x86 微架构还实施了这样一种流水线概念，它具有诸如分支预测和乱序执行等特别执行优化特性 [118，p.329ff] [127，p93ff]。执行流水线利用微操作进行工作，即运算被作为程式化原子单元而实现。Intel 架构指令被翻译为微操作 [118，p.331]。对于乱序执行，需要一块所谓的 重排序缓冲区（ROB [118，p.333]）来跟踪重命名的寄存器。寄存器重命名发生于乱序执行过程中。微运算中所使用的寄存器通过 寄存器别名表（RAT [118，p.333]）而被重命名，它也被称为 寄存器分配表（RAT [参见 127，p.100]）。

PMU 以 型号特定寄存器（MSR [69，第 9.4 节]）的形式实现，它允许软件开发者对微架构相关的事件进行计数。这有助于程序员编写针对某一 CPU 微架构优化的代码 [104]。例如，MSR 可以被配置为计数在代码执行时发生的缓存未命中、RAT 停止，以及分支预测错误等 [69，第 18/19 章]。用于事件计数的 PMU 寄存器也称为 性能计数器 或者 硬件性能计数器（HPC）。它们仅在 0 环中可用。与性能测定相关的另一种特殊目的寄存器是所谓的 时间戳计数器（TSC [69，第 17.12 节]）寄存器。TSC 寄存器可以在平台重置之后被用于计数 CPU 周期。由不同的权限级别对时间戳计数器寄存器和性能监视单元寄存器的访问可以由 x86 控制寄存器 4（CR4）[参见 69，第 2 章] 来控制。

一种同外设交换数据的特殊输入/输出（I/O）特性是经过由 x86 CPU 提供端口（I/O 端口 [117，p.70，341]）的 I/O 映射 I/O 的概念。此概念与内存映射 I/O（同样由 x86 系统提供 [117，p.343]）互补，在后者的情况下，外设的内存和寄存器都被映射到宿主 CPU 的内存地址空间。外设同样会通过中断与宿主 CPU 通讯，以发出例如新数据可用的信号 [117，p.252]。为了同宿主系统进行通讯，外设也可利用直接内存访问的概念。在此情况下，外设并不直接同宿主 CPU 通讯，参见 2.4 节。

2.4 直接内存访问

PCIe 支持用于外设，或者更准确地说，诸如显卡、网卡以及管理控制器等专用硬件的 直接内存访问（DMA）。DMA 允许快速内存访问而无需宿主 CPU 的介入。DMA 的目的在于从宿主 CPU 移除负载。DMA 允许外设绕过 CPU 获得对全部宿主内存的访问。CPU 可以在 DMA 传输发生时执行其他任务。外设可以拥有它们自己的引擎以执行 DMA。此类 DMA 称为第一方 DMA [133，p.428]。另一种机制称为第三方 DMA [133，p.428]，在此，需要由一个中央 DMA 控制器（DMAC，参见图 2.3）来为不带 DMA 引擎的传统设备（例如基于 工业标准结构（ISA [116]）格式的设备）提供快速内存访问。它也被集成到现代平台中 [64，p.128]。

图 2.4 第三方和第一方 DMA

(a) 第三方 DMA：要求宿主 CPU (1) 通过 I/O 端口配置（源和目标地址）中央 DMA 控制器，以便 (2) 执行 DMA 传输。宿主 CPU 将会被 (3) 中断，如果 DMA 传输完成 [31，p.454]。因此，宿主 CPU 对于第三方 DMA 传输警觉。(b) 第一方 DMA：外设设备可以 (1) 配置其自身的 DMA 引擎。此设备作为总线主控（参见第 2.5 节）以获得对于系统总线的控制来执行 DMA 传输。此设备 可以 中断宿主 CPU，如果该设备 (2) 完成传输。传输同样能够进行，如果此设备并不在 DMA 传输完成时中断宿主 CPU。在此情况下，CPU 对于 DMA 传输并不警觉。

图 2.4 高亮显示了第三方和第一方 DMA 之间与隐秘操作有关的一个重要区别。如果使用第三方 DMA，宿主 CPU 对于 DMA 传输警觉，由于外设需要宿主 CPU 通过 I/O 端口 [脚注 4]（参见 2.3 节）来配置 [参见 31，p.454] DMAC。如果使用第一方 DMA，宿主 CPU 不一定 对此传输警觉。注意，DMAC 或者 DMA 引擎只能访问宿主内存地址，而非诸如宿主 CPU 缓存、宿主 CPU 寄存器或者硬盘等。后一条规则提示从运行时内存中移出至硬盘中的数据对于 DMA 引擎来说也不可访问。

脚注 4：参见诸如 arch/x86/include/asm/dma.h 和 arch/x86/include/asm/io.h 等 Linux 源代码。

2.5 总线主控

计算机平台拥有若干种总线系统，例如 PCIe 和 前端总线（FSB）。因此，平台拥有取决于总线系统的不同的总线主控类型，参见图 2.5。总线主控是一种能够经过某种总线引发数据传输（例如从 I/O 设备到主内存）的设备 [58，第 7.3 节]。某个连接到总线的设备（CPU、I/O 控制器等）本质上并不是总线主控。此设备只是一个 总线代理 [1，p.13]。如果该总线必须被仲裁，则总线主控可以向仲裁器发送一段总线所有权请求 [9，第 5 章]。如果仲裁器将总线所有权授予该总线主控，则该总线主控可以引发数据传输，只要总线所有权被持续授予。注意，此过程与 PCIe 设备不相关，由于其点对点的属性。PCIe 请求不需要被仲裁，因此，总线所有权并非必需。此总线并未如同其在 PCIe 的前身 PCI 中那样被共享。

图 2.5 总线主控拓扑结构

总线主控通过不同的总线系统（例如 PCIe，FSB）访问内存。MCH 为不同的总线控制器仲裁主内存访问请求（基于 [23，p.504] [24] [58，第 7.3 节] [63，第 1.3 节] [64]）。

然而，PCIe 设备的总线主控能力是通过某个特定的位来控制的，它称为 总线主控启用（BME）。BME 位是该外设的标准配置寄存器的一部分，并且通常由执行于宿主 CPU 上的对应设备驱动程序来设置。MCH（位于 PCIe 的视野之外）仍然对从不同的总线接口到主内存的请求进行仲裁 [63，p.27]，参见图 2.5。宿主 CPU 也是一个总线主控，它通过 前端总线（FSB）从主内存中获取数据和指令。I/O 控制器（例如以太网、硬盘控制器等）为 I/O 设备（例如 USB 键盘/鼠标、硬盘、网卡等）提供独立的 DMA 引擎。这意味着如果外设对主内存的访问请求由 MCH 处理，则 PCIe 与之完全不相关。

2.6 输入/输出内存管理单元

Intel 引入了一种称为 用于直接 I/O 的 Intel 虚拟化技术（VT-d [2]）的技术作为若干构建块之一，以便为 x86 系统提供硬件支持的虚拟化。VT-d 可以被看作一种 输入/输出内存管理单元（I/OMMU）以便有效地辅助虚拟化要求，诸如对运行于同一虚拟机监视器上的不同虚拟机进行可靠的隔离。VT-d 的应用主要与虚拟化相关联。有了 VT-d，虚拟机监视器或者操作系统等可以创建内存保护域。例如，互相隔离的物理内存子集可以被指认给虚拟机或者 I/O 设备驱动程序的内存。未被指认一块保护域的 I/O 设备没有对该域的物理内存的访问权限。这些访问限制通过地址翻译器而实现。系统软件对由 Intel VT-d 提供的所谓 DMA 重映射（DMAR）引擎进行配置。这样的引擎将例如由 I/O 设备触发的内存请求映射到物理内存。VT-d 可以阻止内存请求，如果该设备未被指认保护域。请注意，激活的 I/OMMU 可以为宿主 CPU 引入显著的性能开销 [13] [150] [88，p.129]，其结果是此技术的使用经常被避免。

为了允许系统软件配置 DMAR 引擎，BIOS 需要将对应信息以 高级配置与电源接口（ACPI [44]）表的形式加载至主内存。系统软件可以利用这些信息（例如 DMAR 引擎数量）来设置保护域。请注意，在主内存中存储 ACPI 表这一做法带来了严重的安全威胁。这些表可以通过直接内存访问来访问，并且可以如同 Wojtczuk 等人 [148] 和 Sang 等人 [111] 所描述的那样被修改。负责正确配置 DMAR 引擎的系统软件可能会失效，如果此漏洞被攻击者所利用。

2.7 信任和对手/攻击模型

此攻击者模型提供了关于一种隐秘 DMA 攻击场景的描述。攻击者能够 远程地 利用恶意负载来渗透存在于计算机平台中的专用硬件。这可以通过利用与操作系统或者固件相关联的零日漏洞 [例如参见 47] 来实施。我们假设攻击者能够在运行时对目标平台进行攻击。这不仅可以通过远程利用固件漏洞来实现，也可以通过分别由 Duflot [45] 和 Triulzi [135] 所描述的远程固件更新机制来实现。除了上述远程利用以外，攻击者还能够在本应作为拥有者的实体获取并且在目标平台上部署外设之前渗透该外设。

此专用硬件支持如 2.4 节所述的第一方 DMA 并且通过内存总线访问主内存，如图 2.5 所示。我们假设目标计算机平台拥有通常的最新防御机制，诸如反病毒软件和宿主防火墙。此平台的用户并未应用诸如硬件防火墙等额外的硬件以保护此计算机平台。我们假设只有隐秘攻击可以算作成功的攻击。因此，攻击者想要利用专用硬件的隐形潜力以隐藏攻击。对于主内存的攻击（例如对于机密性和完整性的侵犯）只来自于外设并且是通过 DMA。攻击者并未实施这样一种要求外设和宿主之间进行协作以提高隐秘攻击成功率的攻击。我们进一步假设攻击者能够保证对完整性的侵犯（内存写访问）不会导致攻击的暴露。额外的硬件将会显著降低隐秘攻击的成功率。例如，最有可能的情况是攻击者致力于偷取数据以引导行业间谍活动或者获取在线银行凭证等。为了实现这一点，攻击者必须通过 DMA 从主内存中读取数据（对机密性的侵犯）或者向主内存中写入数据（对完整性的侵犯）。

我们将某个计算机平台视为可信的，如果它满足所应用的安全策略。这意味着在我们的案例中，没有基于 DMA 的恶意软件通过 DMA 读取或者写入平台的主内存来攻击宿主平台。我们依赖于一种最小化的 可信计算基（TCB [37，p.66] [99，p.8]），它包括宿主 CPU 和内存芯片硬件，以及它们之间的通讯路径（前端总线、内存控制器集线器、内存总线）。执行于宿主 CPU 上的软件（系统软件和应用软件）在平台被攻击之前处于可信状态。这意味着软件被正确地加载和启动，并且行为符合预期。我们并不依赖诸如 I/OMMU 等预防性措施，由于 2.6 节所述的安全性问题。

第 3 章 相关工作

黑客的思维模式并不能真正看到另一面，即对受害者发生了什么。——Kevin David Mitnick，安全专家

由于我们在方法论中决定同时思考两方面，即攻击以及对攻击的检测和化解，我们必须详细论述两个方面的相关工作。更进一步地，我们想要使得我们的目标平台能够将其关于基于 DMA 恶意软件的状态报告至外部平台。为了实现这一点，我们要求一种能够揭示由网卡发动的 中间人（MitM）攻击的通讯信道。这是必要的，由于我们同样将网卡视为能够隐藏攻击代码的专用硬件。

3.1 DMA 攻击

直接内存访问可以成为一种足够有效的方式以引导对于宿主系统的隐秘攻击。我们的工作分析了那些能够在运行时实现恶意软件功能并且应用 rootkit/隐形能力的攻击。在最坏的情况下，基于 DMA 的恶意软件还能够在平台重启以后，以及在待机和关机模式下存活。在下文中，我们将会区分这两类外设之间的区别，即可以从机箱外部连接到宿主平台的外设以及直接连接到芯片组的外设。

3.1.1 可以从外部连接的设备

自 2004 年始，利用诸如 USB 设备 [90]、特殊的 PCMCIA 卡 [61，11] 以及火线设备 [43，42，17] 等额外硬件进行的若干种 DMA 攻击就已经出现。由 Maynor [90，p.55ff] 所描述的此类攻击使用了一部摩托罗拉移动电话，以通过 USB 利用攻击代码渗透目标设备。此攻击通过在目标平台的屏幕上显示一个窗口来暴露自己。因此，此攻击与其说是完全可运作的恶意软件，不如说是一个概念验证。

Dornseit [43] 和 Dornseif 等人 [42] 展示了如何利用一部通过火线连接到目标的苹果 iPod 以引导一次 DMA 攻击。作者提到，他们可以利用 DMA 读取来复制屏幕内容、字符串和关键素材。更进一步地，通过 DMA 写入，作者可以更改屏幕内容、引导一次权限提升攻击，并且向宿主的运行时内存注入代码。Boileau [17] 同样覆盖了一种基于火线的 DMA 攻击。作者能够攻击一台基于 Windows XP 的笔记本计算机。在 2007 年，Piegdon 和 Pimenidis [101] 发表了另一篇关于与火线相关的 DMA 攻击的论文。他们描述了如何偷取 SSH 私钥以及注入任意代码。此注入的代码实现了同目标设备之间具有管理员权限的互动访问。作者必须搜索被宿主 CPU 用于实现虚拟地址空间的数据结构以查找运行于宿主 CPU 上的进程。Blass 和 Robertson [15] 描述了 Tresor-Hunt，这是另一种基于火线的攻击以欺骗硬盘加密机制。更准确地说，绑定到宿主 CPU 的加密机制受到了攻击。CPU 绑定意味着密钥数据从未被释放到主内存。该数据一直保存在宿主 CPU 的寄存器中。Tresor-Hunt 的基本理念是向内核空间注入代码（某个中断处理程序被挂钩）。该攻击代码将密钥数据从处理器寄存器转储到内存，在这里，它可以通过 DMA 捕获。Blass 和 Robertson [15] 利用火线来转储宿主的物理内存。然后，他们扫描整段转储的内存以查找中断描述符表，进而挂钩某个中断处理程序，它最终将会释放加密密钥。

David Hulton [61] 展示了如何利用通过 cardbus 连接到目标平台的 现场可编程逻辑门阵列（FPGA）外设来捕获存在于主内存中的口令和私钥。更进一步地，Hulton 的 FPGA 设备能够解锁屏幕保护程序并且执行任意代码。为了在宿主内存中查找目标内存地址，作者对所有物理内存页进行了签名扫描。

由 Breuk 和 Spruyt [18，19] 记载的项目致力于将 DMA 攻击整合到漏洞利用框架。作者讨论了 PCI、火线、USB、SATA、DisplayPort、雷电和 PC 卡（即 PCMCIA、cardbus、快速卡）。他们的概念验证基于火线。为了在宿主的运行时内存中查找目标地址，作者实施了针对全部内存页的签名扫描。Inception 工具能够通过“火线、雷电、快速卡、PC 卡，以及任何其他 PCI/PCIe 接口”攻击目标平台 [87]。此工具能够做的事情包括转储主内存、解锁系统，并且引导针对基于 Windows、Mac OS 以及 Linux 的目标的权限提升攻击。描述了利用雷电进行 DMA 攻击的策略的后续研究由 Sevinsky [114] 所贡献。作者并未描述通过雷电进行的具体的 DMA 攻击。

3.1.2 牢固建立在平台机箱内部的设备

在本工作中，我们明确地专注于隐秘性。攻击者必须不依赖对目标设备的物理访问以增加隐秘渗透的成功率。因此，3.1.1 节所呈现的攻击设备并不被考虑在我们的信任和对手模型中，参见第 2.7 节。我们专注于源自平台外设的攻击。本节考虑了源自诸如特殊的管理控制器、网卡和显卡等平台外设的 DMA 攻击。

Tereshkin 和 Wojtczuk [131] 说明了 Intel ME 的 DMA 引擎可以被用于写入宿主内存。作者描述了一种允许向 DMA 环境注入代码的漏洞。Tereshkin 和 Wojtczuk 的代码并未实现任何恶意软件行为。它通过向一段已知的硬编码的宿主内存地址进行写入从而暴露自身。因此，这种方法实现了一种概念验证而非真实的恶意软件功能。我们利用 Intel ME 用于我们自己的攻击研究，参见第 4 章。我们的基于 DMA 的攻击以击键码记录器的形式实现了完全可运作的恶意软件，它执行于管理引擎的环境中。

Duflot 等人 [47] 和 Delugré [35，36] 所描述的基于网卡的攻击专注于隐秘攻击、恶意软件功能和 rootkit 能力。由 Duflot 等人 [47] 所呈现的攻击在运行时利用了网卡固件的漏洞。被攻击的网卡被用于通过添加后门的方式来攻击宿主系统。作者描述了宿主可以如何访问网卡的内部内存。这提供了一种可能性以便利用执行于宿主 CPU 的代码来检测攻击代码。据我们所知，没有任何反病毒软件之类能够利用这一点。应该指出，宿主能够访问网卡的内部内存并不是一种常见特性。例如，我们所用于自己的攻击研究（参见第 4 章）的 Intel ME 的运行时内存是宿主不可访问的。由 Delugré [35，36] 发表的工作与 Duflot 等人 [47] 发表的工作非常相似，两起攻击都使用相同的网卡型号。由 Delugré [35，36] 实现的恶意软件致力于实现 rootkit 能力。

Arrigo Triulzi [134，135] 呈现了一种隐秘的安全 shell。它可以通过 DMA 提供内存检测功能。网卡和显卡的组合被用于隐藏此 shell。此 shell 通过远程重刷固件而被安装。网卡和显卡通过 PCI 到 PCI 传输进行通讯。作者提议 PCI 到 PCI 传输计数作为反制措施，但是并未描述如何实现。与显卡相关的其他工作由 Vasiliadis [140] 发表。作者描述了一种方法将性能开销从宿主 CPU 转移到显卡的 GPU 上。部分代码仍然需要运行在宿主 CPU 上。CPU 和 GPU 通过共享内存进行通讯。此性能开销将会在诸如解包或者运行时多态等技术被应用时出现。因此，Vasiliadis [140] 同时描述了 GPU 辅助解包和运行时多态，但是并未描述任何利用 DMA 攻击宿主系统的特定恶意软件。Ladakis 等人 [80] 实现了一种运行于 GPU 上的击键码记录器。此击键码记录器类似于我们所发布的击键码记录器 [123] [脚注 5]。他们重用了相同的签名扫描以查找键盘缓冲区。更进一步地，此方法要求在宿主 CPU 上以内核模式执行签名扫描。这一致命弱点可以被用于检测此攻击。作者事实上需要一个基于内核的零日漏洞来增加隐秘攻击的成功率。根据作者所述，特殊的调试工具可以被用于分析执行于 GPU 上的进程。这些工具可以被用于开发一种针对基于 GPU 的恶意软件的反制措施。在显卡环境中被捕获的击键码随后发生了什么并不清楚。Ladakis 等人 [80] 并未考虑潜出。

脚注 5：我们所发表的击键码记录器 [123] 是我们在第 4 章所研究的攻击的基础。

最近，Domburg [41] 展示了如何在硬盘控制器上安装攻击代码。攻击代码存储于硬盘控制器的内存存储器上，并且被加载到硬盘控制器的动态内存中，以便在硬盘控制器的处理器中执行。作者并未描述如何利用硬盘控制器的 DMA 引擎攻击宿主运行时内存。由 Zaddach 等人 [152] 呈现的类似工作同样基于硬盘控制器。作者展示了一种隐秘的硬盘后门。然而，他们所攻击的是硬盘上存储的数据，即他们并未展示如何利用该控制器的 DMA 引擎攻击宿主系统的主内存。因此，他们的攻击不属于本论文的范畴。我们专注于针对平台的主内存的隐秘攻击。

3.2 反制措施

不同的方法被提议出来，它们可以看作针对 DMA 攻击的反制措施。例如，测定固件 [脚注 6] 是一种用于检查固件二进制文件的完整性的方法。它假设固件并不会引导 DMA 攻击，如果其二进制文件未被修改。签名固件的方法同样致力于使用户相信该固件不会引导 DMA 攻击。其理念是经过厂商数字签名的固件是可信的。除了这两种方式以外，后续各节还描述了相关工作，诸如基于延时的证言、运行时监视、总线嗅探、敏感数据保护以及 I/OMMU 等。

脚注 6：在此案例中，测定是指导出散列值。

3.2.1 测定固件

可信计算小组（TCG）[136] 提议在加载时 证明 外设固件。更准确地说，此方法基于一块额外的芯片 [脚注 7]，它称为 可信平台模块（TPM [99]）。TPM 类似于一块牢固地固定在计算机平台的芯片组的智能卡芯片。然而，TPM 可以在二进制代码被执行之前以该代码的散列值的形式存储完整性测定信息。这意味着测定是在加载时进行的。此类测定可以被用于检查平台是否可信。当前版本的 Intel 管理引擎执行环境也采用一种所谓的验证启动机制以允许使用散列值对外设固件进行证明 [79，第 15 章]。然而，在加载阶段引导的测定并不能排除运行时攻击。在运行时重复进行测定将会造成显著的性能下降。它同样不能阻止 瞬时攻击，在此，攻击者利用两次测定之间的时间框架。更进一步地，并不能保证宿主 CPU 能够访问用于存储固件代码的所有外设 ROM 组件。

脚注 7：TCG 规范并不禁止以固件形式实现 TPM。Intel [参见 79，p.108] 拥有一种基于固件的 TPM 解决方案。

3.2.2 签名固件

经过签名的固件镜像同样不能阻止运行时攻击。固件更新只能被刷入对应的 ROM 芯片，如果该固件镜像拥有有效的数字签名。例如，只有经过主板厂商数字签名的 BIOS 固件镜像可以被刷入对应的 ROM 芯片 [79，第 14 章]。这并不能排除运行时攻击。此类攻击已经被 Wojtczuk 和 Tereshkin [149] 以及 Butterworth 等人 [26] 所展示。

3.2.3 软件/基于延时的证言

其他证言方式由诸如 Li 等人 [83，82] 所呈现。这些方式基于 基于延时的证言，即外设不仅需要计算出一段正确的校验和，它还必须在限定的时间内计算出该值。被攻击的外设将会被认为已经暴露，如果校验和错误或者计算该校验和耗时过长。基于延时的证言要求修改外设固件，并且宿主需要知道该外设的准确硬件配置以便能够对其进行验证。Li 等人 [83] 同时说明他们的方法不能正确地工作，如果外设会造成大量总线流量。他们在其评估中仅仅考虑了一部外设。更进一步地，Nguyen [96] 揭示了 Li 等人 [83] 的证言方法中存在的严重问题。同样不清楚的是，基于延时的证言能够在多大程度上阻止瞬时攻击。

3.2.4 监视方法

另一种有趣的方法由 Duflot 等人 [46] 所呈现。网卡特定的调试特性被用于监视固件执行。这些特性对于其他外设并不可用。另一个缺陷是对宿主造成的显著性能问题（某一个 CPU 核心 100% 使用）。我们的目标同样是开发一种运行时监视器。与 Duflot 等人 [46] 所描述的监视器相反，我们的监视器要求 (i) 独立于外设的内部工作方式，以及 (ii) 造成的性能开销显著减少，参见第 5 章。

另一种运行时监视方式由 Zhang 等人 [153] 所呈现。此方式类似于 SMM。作者提议周期性地检查外设固件和配置。然而，作者并未描述在 I/OMMU 被正确配置之前，存储着监视器的 SMRAM 是如何被保护起来使其不受 DMA 攻击的。作者同样并未解释检查间隔。因此，必须假设瞬时攻击并未被考虑。同样不清楚的是，检查全部外设到底需要多少时间。实现描述和评估都没有。因此，该提议的方法在实践中切实可行这一点并未被证明。

3.2.5 总线嗅探方法

Moon [92] 和 Lee [81] 遵循另一种基于硬件的方法。作者提议了这样一种系统，它能够嗅探内存总线以检查对于内核完整性的侵犯。此方法能够阻止瞬时攻击。然而，作者并不致力于检测 DMA 攻击。更进一步地，他们的嗅探监视器组件基于特定硬件（Leon3 处理器）。它和被监视的宿主系统（同样基于 Leon3 处理器）拥有相同的计算能力。探究这样一种内存嗅探方法是否能够被利用以检测基于 DMA 的恶意软件将会十分有趣。

由 Eckert 等人 [48] 呈现的一种相关方法考虑了一种 DMA 攻击。提议的系统可以被用于检测经过 DMA 传输至宿主内存的恶意软件。因此，作者只考虑了从外设到宿主内存的写入操作。此系统无法阻止基于 DMA 读取的攻击，在此，攻击者捕获了存在于主内存中的诸如密码学密钥或者在线银行凭证等信息。在其描述的攻击场景中，作者假设攻击代码执行于宿主处理器上。因此，他们同样通过总线嗅探来扫描通过 DMA 写入宿主内存的数据以查找恶意软件签名。作者承认其基于签名的检测方式存在缺陷。此提议的系统要求基于 FPGA 的硬件，并且同样不清楚的是，他们的实现专注于第一方还是第三方 DMA。

3.2.6 敏感数据保护

已有若干种方法被呈现，用以保护诸如密码学密钥等敏感数据等，以防止内存攻击。有人提议仅在处理器寄存器或者缓存中存储敏感数据，而非在主内存中 [93，94，119，141]。然而，Blass 和 Robertson [15] 展示了如何利用基于 DMA 的攻击以强制宿主将敏感数据泄漏到主内存中，参见 3.1.1 节。

3.2.7 输入/输出内存管理单元

如同 Duflot 等人 [47] 以及 Müller 等人 [95] 所提议的那样，存储于主内存中的敏感数据也可以通过 I/OMMU 进行保护。如同我们已经在我们的信任和对手模型中所考虑到的那样，我们并不会依赖 I/OMMU（参见 2.7 节）。这是由于 I/OMMU 必须被配置无误 [83，p.2]，以及 I/OMMU 可以被成功地攻击 [111，148，147，146]。更进一步地，I/OMMU 将会由于内存访问策略冲突而不适用 [123]，并且它们并不被每一种芯片组和操作系统所支持。Sang 等人 [112] 同样确认了 I/OMMU 具有缺陷。在将 I/OMMU 看作一种反制措施时另一个应当被考虑的问题在于，根据 Ben-Yehuda 等人 [13] 和 Yassour 等人 [150] 的研究结果，激活的 I/OMMU 可能造成显著的性能开销。

3.3 在考虑平台状态报告的前提下加固通讯信道

本章所呈现的相关工作均未考虑作为托管恶意软件的网卡可以引导 中间人（MitM）攻击的情况。我们将 可信信道 这一概念用于此目的 [52，10]。可信信道拥有安全信道的全部属性。此外，可信信道的概念允许将通讯端点的配置数据绑定到安全信道，以保证该端点的合法性（同一性和完整性）。然而，还存在与可信信道相关联的其他方法，它们将会在下文讨论。为了防止 中继攻击（攻击者中继了某个第三方平台的可信配置数据），要求在安全信道和将要被报告至该端的配置数据之间实现一种安全绑定。并非所有下文所呈现的相关工作都实现了这样一种安全绑定。

3.3.1 基于可信平台模块的方法

存在着众多由 可信计算小组（TCG）[脚注 8] 所提议的基于 可信计算（TC [99]）的方法。众多方法加强了现存的安全信道协议，诸如 传输层安全（TLS [38]）或者 互联网安全协议（IPSec [76]）将端点配置数据绑定到安全信道 [120]。我们同样倾向于从已有的安全信道协议中得到好处。

脚注 8：参见 http://www.trustedcomputinggroup.org/ [访问于 2014 年二月 25 日]

Smith [120] 描述了如何将平台认证和用户认证结合起来以认证一个端点。为了做到这一点，他们引入了两步握手的 TLS 扩展。然而，Smith 的描述不够详细。中继攻击和端点配置更改不在此工作的范围内。Sadeghi 等人 [110] 也引入了一种可信信道的概念。他们的概念基于密钥传输。我们倾向于使用分担式密钥协商协议。我们将密钥素材视为对相关端点的贡献。更进一步地，由 Sadeghi 等人 [110] 描述的参考实现使用 TLS 以隧穿他们的信道。配置数据并未同基于 TLS 的安全信道绑定。

TCG 开发了 可信网络连接（TNC）架构 [138]。TNC 主要应对网络访问。网络认证和策略强制实施是 TNC 关注的焦点。这并非我们关注的焦点。基于完整性的配置信息被用于判定某个平台是否被允许接入网络。TNC 致力于这样一种规范，它基于证言目的对 TLS 进行扩展（用于证明的 TLS 扩展，或者简称为 TLS 证明 [130，p.51]）。此文档并不使用 TCG 网站 [脚注 9] 公开。然而，TCG [137] 发布了一篇称为“绑定到 TLS”的文档，此文档考虑了当客户端请求网络访问时的中间人攻击。基于 TNC 的另一种方法由 Rehbock [103] 所讨论。作者将 TNC 架构扩展到基于网页的环境。

脚注 9：参见脚注 8。

Marchesini 等人 [89] 的目的是对网页应用程序的可信度进行证言。他们基于所提议的 Bear 平台 引入了一种架构。此平台实现了这样一种信任模型，它致力于将长寿命密码学密钥对（由认证权威机构所认证）映射到短寿命平台配置部分。作者承认他们的平台存在诸如 检查与使用之时差（TOCTOU，同时参见 3.2 节）等问题。

由 Goldman 等人 [53] 描述的方法同样致力于将配置数据连接到安全信道的端点。作者利用 TLS 的前身，即 安全套接字层（SSL [50]）协议进行工作。其基本理念是在由可执行代码得出的完整性测定列表之上附加 SSL 证书的测定结果。作者并未说明他们如何准确地防止中间人攻击。SSL 证书可能来自其他平台，或者在我们的攻击场景中，来自于通过 DMA 进行证书偷运的网卡。更进一步地，此网卡可以在运行时攻击端点以攻击数据和密码学密钥。McCune 等人 [91] 利用一种同 Goldman 等人 [53] 类似的协议。作者利用诸如 Intel 可信执行技术（TXT [参见 54]）等现代芯片组特性以显著减小 TCB。在他们的对手模型中，作者确实明确地允许 DMA 攻击。其原因是他们提议了一种能够得益于隔离执行环境的安全架构。当代码在该环境中执行时，中断和 DMA 被关闭。更进一步地，每当使用此隔离环境时，宿主处理器的状态就被要求保存和恢复。其结果是性能的损失。因此，此方法仅适用于快速安全操作。保护通过 USB 键盘输入的用户输入是完全不可能的，由于需要 DMA 将击键码从键盘复制到主内存。

Dietrich [39，40] 也提议了一种基于 TPM 以及 TLS 的可信信道概念。他致力于在同远程平台的会话过程中报告平台配置更改。他的方法要求对 TPM 的修改。这样的硬件修改在实践中是否能够强制实施尚不清楚。Cheng 等人 [29] 同样致力于通过将基于 TCG 的平台配置报告方法同 TLS 信道相结合以防止中间人攻击。然而，作者并未呈现一种实现。他们同样未能清楚地描述他们将哪种 TLS 握手信息用于所提议的信道的协商。由 Yu 等人 [151] 所描述的方法同样将基于 TPM 的平台配置数据同 TLS 协议相结合。作者强烈地专注于 TLS 重新协商攻击 [参见 102]。他们宣称此种攻击即使在使用安全信道的情况下也是可能的。我们怀疑这一点，由于 Yu 等人 [151，p.3] 所描述的攻击协议流展示了这一点，即中间人需要将合法的平台配置数据上传至服务器。因此，服务器能够检测到负责引导重新协商攻击的代码。作者并未解释中间人想要伪造可信的平台配置数据是否可能。

一种与隐私相关的十分有趣的可信信道方法由 Cesena 等人 [27] 呈现。所提议的信道结合了 TLS 和 直接匿名证言（DAA [20]）协议，后者被 TCG 所采用。在此上下文环境中，DAA 允许平台证明它包含一块 TPM，而无需暴露它是何种特定的 TPM。这有助于保护隐私，如果要求避免将不同的会话同某一特定平台的 TPM 连接起来。除了 DAA 以外，所提议的信道同我们的可信信道非常相似。作者以类似于我们的解决方案的方式利用 TLS 握手信息。

Sadeghi 和 Schulz [109] 改良了安全信道协议 IPSec 以实现这样一种可信信道。该方法利用 互联网密钥交换协议版本 2（IKEv2 [75]）作为基础以便将平台配置信息绑定到此信道。配置数据也可以在 IPSec 会话期间被传输。作者还考虑了他们的方法可以如何被整合到 TNC 架构中。尽管所呈现的方法是向后兼容的，只需对 IKEv2 进行最小化的修改即可使其完全得益于可信信道。

平台配置信息也可以被包含在 Diffie-Hellman（DH）密钥交换过程中，如 Stumpf [128] 所述。作者依赖于这样一条命令（TPM_Quote），它负责获取一份关于存储于 TPM 之中的完整性测定数据的签名报告。DH 方法并不能化解由加载时测定造成的缺陷。

Lyle 和 Martin [86] 引入了一种考虑了网页服务技术的信道。他们的特殊环境并不允许应用一种基于 TLS 的信道。他们将 TCG 平台配置报告方法同所谓的消息级加密 [参见 86，p.4] 相结合。Chang 等人 [28] 将 TCG 方法同 安全实时传输协议（SRTP [12]）/ Z 实时传输协议（ZRTP [154]）相结合。SRTP/ZRTP 为 网际协议通话技术（VoIP [34]）传输提供了安全信道。作者致力于提供一种结合了 TCG 方法和 SRTP/ZRTP 的可信信道。

然而，所有这些提议的基于 TPM 的方法均未充分考虑运行时攻击（特别是基于 DMA 的运行时攻击）。它们同样受制于 3.2 节开头描述的缺陷。请注意，我们关于可信信道的工作最初同样基于 TPM。在本工作中，我们采用了另一种攻击场景的可信信道概念，在此，攻击来自于外设。我们的信任模型（参见 2.7 节）考虑了另一套不同的 TCB。我们并不依赖于加载时完整性测定。TPM 并非必需。我们的测定基于一种运行时监视器，它能够根据内存总线传输推导出状态信息，参见第 5 章。我们在本工作中所使用的安全通讯信道考虑到了这些测定。此信道基于我们在前期工作 [52，10] 中所引入的可信信道概念。

3.3.2 基于协处理器和智能卡的方法

由 Jiang 等人 [74] 和 Chess 等人 [30] 描述的方法基于一块安全协处理器。协处理器被用于通过实现一种称为可信协服务器的概念来建立信任。协服务器执行经过评估和认证的程序以便将主服务器认证为能够监视它们的行为的。协服务器在对抗物理操作方面更加安全。然而，它们相对于现货供应的硬件更加昂贵。这样的协服务器通常被实现为具有专用的处理器、内存、DMA 引擎以及以太网连接器 [72，73] 的 PCI(e) 板卡的形式。因此，它们是基于 DMA 的恶意软件的理想宿主。

由 Akram 等人 [5] 提议的可信信道协议本意是用于一种特殊的智能卡场景。作者专注于一种针对智能卡用户的隐私保护协议。因此，他们的方法仅适用于涉及智能卡的场景，在此，用户的身份必须不被暴露。在 Akram 等人 [4] 的一篇早期发表中，作者呈现了另一种信道，其本意是用于运行时认证和智能卡应用程序的验证。此信道是作者所实现的框架的一部分。此信道协议经过了作者的验证。由 Akram 等人 [4] 所描述的信道同样专注于智能卡场景。另一种基于智能卡的方法由 Wang 等人 [143] 呈现。作者提议并且形式化验证了一种用于 数字版权管理（DRM [3]）场景的可信认证协议。此协议也考虑了平台配置值。作者并未评估他们所提议的协议的实现。

第 4 章 关于一种基于直接内存访问的隐秘恶意软件的研究

我们信仰上帝，我们监控所有其他人。——美国空军情报、监控和侦察机构之美国空军技术应用中心的座右铭

恶意软件开发者和反恶意软件社区之间的军备竞赛达到了一个新的水平。针对内核级别的 [60]、基于虚拟机监视器的 [77]，以及基于系统管理模式的恶意软件 [49] 的反制措施已经被提议出来 [51，107，25]。其结果是，研究者探索了新的环境以用于隐藏恶意软件。恶意软件可以被放置在诸如显卡和网卡等专用硬件上以攻击宿主平台 [参见 134，135，47]。除了其他组件以外，这些设备带来了一块专用的处理器和专用的运行时内存。这些设备可以独立于宿主系统而运作。反病毒软件不能检测存储于独立内存中并且执行于另一块处理器上的恶意软件。攻击者可以利用这些设备，或者更准确地说，利用其直接内存访问机制，通过直接攻击宿主运行时内存而绕过构建于操作系统中的保护机制。我们将这种执行有目标的基于 DMA 的隐秘攻击以定位并且读取或者修改目标数据的代码称为 DMA 恶意软件。这样的数据可能是用于加密硬盘的密码学密钥、在线银行账户的凭证、即时通讯聊天会话，以及存在于文件缓存中的已经打开的文档等。

在本章中，我们将 DMA 攻击特征化，并且推导出术语 DMA 恶意软件。我们这样探索该术语，即通过检测 DMA 恶意软件是否能够在显著提升针对计算机平台发动隐秘攻击的成功率的同时保持高效性和有效性。为了进行此项评估，我们构建了自己的 DMA 恶意软件 DAGGER——一种基于 DMA 的击键码记录器（DmA-based keystroke loGGER），它将其所捕获的数据潜出至某个外部实体。我们对此 DMA 恶意软件的高效性、有效性，以及特别是隐秘性感兴趣。我们之所以选择实现一种击键码记录器，是为了显示“短寿命”数据也能够被 DMA 恶意软件所捕获。

我们的实现基于 Intel 管理引擎，它是流行的 x86 平台的一部分。Intel ME 被实现于商用以及消费级平台（参见 Intel 博锐平台 [66]）以支持不同的应用，诸如 Intel 主动管理技术（iAMT [79]）或者 身份保护技术（IPT [67]）。我们的 DMA 恶意软件 DAGGER 并非执行于宿主处理器上。它执行于由 Intel ME 提供的处理器上，并不需要额外的硬件。DAGGER 实现了对于用户输入的隔离的运行时攻击。此外，我们的 DMA 恶意软件能够偷取密码学密钥，在攻击中针对操作系统内核结构，以及从文件缓存中复制文件等。尽管 DMA 恶意软件不能被反病毒软件检测到，攻击者仍然面临某些挑战。DMA 恶意软件必须是有效的，即它应该能够成功攻击不同系统。DMA 恶意软件还必须是高效的，即运行得足够快以查找并且处理数据，即使是在处理虚拟内存地址以及随机放置的数据时。这样的恶意软件已经超出了利用 DMA 硬件的能力。

本章的主要贡献包括：

• DMA 恶意软件定义：有不同类型的代码用到 DMA。为了清楚地区分某段代码应该被看作无害、攻击，还是 DMA 恶意软件，我们引入了一种适当的定义。

• DMA 恶意软件核心功能：我们列举了一系列要求，它们是 DMA 恶意软件为了实施成功的攻击所必须满足的。

• DMA 恶意软件原型实现的评估：为了显示 DMA 恶意软件在增加隐秘攻击的成功率的同时保持了有效性和高效性，我们实现了 DAGGER。DAGGER 执行于隔离的 Intel ME 之上。DAGGER 能够隐秘地运作并且攻击多种操作系统。我们的实现是快速并且高效的，因此它可以在平台启动过程的早期捕获击键码。这使得 DAGGER 能够在 Linux 下捕获例如硬盘加密口令等。

• DMA 副作用检测方法：我们呈现了一种检测方法，它可以揭示执行于隔离硬件环境中的 DMA 恶意软件。我们的工作展示了 DMA 恶意软件能够造成非预期的副作用，而我们可以利用那些被广泛使用并且跨平台可用的 CPU 特性来检测它们。

4.1 DMA 恶意软件定义

为了定义 DMA 恶意软件这一术语，我们首先对不同类型的基于 DMA 的代码进行了特征化，这有助于清楚地区分简单的 DMA 应用、DMA 攻击以及 DMA 恶意软件，在此，后者明确地专注于隐秘性。注意，DMA 恶意软件超出了控制 DMA 引擎的能力以外。实现了恶意功能的基于 DMA 的代码被看作严重的威胁。这样的代码可以在渗透和运行时隐秘运作。例如对于长期攻击而言，如果代码能够在平台重启以及关机和待机模式下存活，这也是一种优势。因此，我们可以在评估利用 DMA 的代码时优先考虑下列判据。即该基于 DMA 的代码：

• (C1) 实施了恶意软件功能

• (C2) 不需要物理访问以增加隐秘渗透的成功率

• (C3) 在运行时应用了 rootkit/隐形能力

• (C4) 能够在重启/待机/关机模式下存活

我们将一种二进制体系用于我们的优先级：

23	22	21	20
C1	C2	C3	C4

此体系区分了 16 种基于 DMA 的代码。我们可以为每一种得出一个独特的数值。例如，某段基于 DMA 的代码并不实施恶意行为（C1=0），不会在宿主上留下痕迹（C3=1），不依赖物理访问（C2=1），并且不能在重启之后存活（C4=0），则它被映射到二进制结构 0110。此结构对应于十进制的第 6 类。所得出的数字越大，则该基于 DMA 的恶意代码越危险。

我们关于 DMA 恶意软件的定义如下：

定义：DMA 恶意软件是执行于专用硬件之上，通过一种称为直接内存访问的机制攻击计算机系统，并且至少满足判据 C1、C2 和 C3 的恶意软件。

当其被应用于第 2 章所介绍的目标平台时，此定义意味着：该 DMA 恶意软件基于第一方 DMA，并且其 DMA 引擎可以被攻击代码配置为不涉及宿主 CPU。攻击代码执行于具有其自身的处理器和运行时内存的专用硬件之上，例如网卡。控制了网卡可以增加攻击者在潜出时隐藏数据的成功率。表 4.1 将我们的二进制体系应用到第 3 章“相关工作”所呈现的 DMA 攻击上。此表还描述了哪些相关工作根据我们的定义属于 DMA 恶意软件。在本章，我们同样致力于开发一种 DMA 恶意软件的概念验证，它至少满足判据 C1、C2 和 C3。

表 4.1 DMA 攻击范例对于判据 C1-C4 的满足情况

攻击呈现于	C1 C2 C3 C4	DMA 恶意软件
[90]（USB）	- - - √	-
[43，42，17，101，19，18，15，87]（火线）	√ - √ √	-
[11，61，87]（PC 卡）	√ - √ √	-
[131]（Intel ME）	- √ - √	-
[35，36，47]（网卡）	√ √ √ √	√
[134，135]（显卡和网卡）	√ √ √ √	√
[80]（显卡）	√ √ - -	-

注意，此评估基于公开可获得的材料。如果我们仅仅依靠可获得的资源不能确定某个判据是否满足，我们假设该判据被满足。

4.2 DMA 恶意软件核心功能

在攻击宿主时，攻击者仅仅控制 DMA 引擎并不够。此引擎允许攻击者读取和写入宿主内存。然而，在大多数情况下，目标内存地址未知。本节描述了 DMA 恶意软件的核心功能，即克服地址随机化、内存映射，以及搜索空间限制。

攻击者必须确定内存地址。然而问题在于，例如分配给内核数据结构的内存空间在平台重启之后并不一定是位于原来的内存地址。数据结构被操作系统 随机放置于内存中。这可以以某种自然的方式发生，例如，当某个驱动程序分配内存并且获取下一段未分配的可用内存块时。该块的内存地址在平台重启之后不一定与原来相同。或者，操作系统可以应用某种随机化算法以保证数据结构不会被放置于相同的内存位置。当然，攻击者可以扫描全部系统内存以查找目标数据的签名。但是这对于扫描一台具有 4 GiB 或者更多的物理内存的系统来说非常低效。

操作系统利用 虚拟内存地址 [参见 31，第 15 章] 进行工作，而 DMA 则利用 物理内存地址 进行工作。操作系统创建了所谓的页表，它们被宿主 CPU 用于将虚拟内存地址映射到物理内存地址。这种映射在利用 DMA 解析内存地址指针时绝对必要。一种称为 CR3 的特殊宿主处理器控制寄存器包含页表的物理内存地址。攻击者不能访问 CR3 寄存器。DMA 引擎的可视性被限制在宿主内存以内。如果不进行深入分析，攻击者就必须扫描全部内存地址空间以查找相关数据。有两种潜在的方式使得攻击者可以克服这一困难。第一种方法是分析操作系统是否将上述数据结构放置在近似相同的内存区域。第二种可能性是实现操作系统的内存管理机制，即攻击者必须找到某种方式以访问由操作系统创建的内存页表。只要有了对页表的访问，攻击者就可以遍历页表并且由此解析由一个数据结构指向另一个数据结构的指针。这仍然需要已知的起始点用于搜索。

4.3 DAGGER 的设计和实现

我们将会在下一小节呈现我们的基于 DMA 的击键码记录器 DAGGER 的一般设计的概述，然后我们在 4.3.2 节解释 DAGGER 的实现细节。

4.3.1 一般设计

我们的 DAGGER 设计如图 4.1 所示。DAGGER 是一种 DMA 恶意软件。即 DAGGER 必须至少满足 DMA 恶意软件定义中的判据 C1、C2 和 C3。DAGGER 包含 3 个主要的组件：

• 搜索：通过 DMA 在宿主内存中查找有价值数据的地址。

• 处理数据：在搜索过程中识别的区域内读取有价值数据。

• 潜出：以某种宿主不可见的方式潜出信息。

图 4.1 DAGGER 一般设计

DAGGER 执行于具有 DMA 能力的设备上，于是它可以从宿主运行时内存中 (1) 搜索并且 (2) 处理数据。它控制了某一通讯路径以潜出数据 (3)。

4.3.2 基于 Intel ME 环境的实现

为了评估 DMA 恶意软件，我们选择在 Intel ME 上实现 DAGGER。Intel ME 为实现我们于下文所述的 DMA 恶意软件提供了某些有用的特性。

Intel ME 的核心是一块植入于平台 MCH 中的嵌入式微控制器。此隔离环境包含 只读存储器（ROM）、静态随机访问存储器（SRAM）、用于访问宿主内存的 DMA 硬件 [25，131]，以及一块处理器，如图 4.2 所示。ME 的嵌入式处理器是一块 ARCtangent-A4（ARC4）处理器。此隔离环境持续可用，与电源状态无关，甚至在待机或者开关机状态下仍然可用。它只要求芯片组被连接到某个电源。执行于此嵌入式微控制器上的应用程序被实现为固件（ME FW）的形式，并且与 BIOS 共同存储于闪存存储器中。最重要的 ME 固件范例是 Intel 主动管理技术。然而取决于计算机平台的种类（商用或者消费级），ME 还可以运行其他固件。例如由 Intel ME 执行的其他固件包括 Intel 身份保护技术、报警标准格式 [131，p.46]、用于温度和风扇控制的 Intel 安静系统技术（QST [131，p.46]），以及 集成可信平台模块（iTPM [79，p.109]）。

图 4.2 Intel 管理引擎环境

Intel 管理引擎（ME）环境包括 MCH 中的管理引擎。更进一步地，此环境包括一部分隔离的内存以及一部分隔离的持久性闪存处理器。ICH 同样包含 ME 环境组件，特别是用于实现带外通讯的组件。

ME 固件可以通过一个称为 ME 接口（MEI [79，p.71]）的 PCI 设备同宿主进行通讯。例如，MEI 可以提供所执行的 ME 固件的版本。ME 环境提供了额外的 PCI 设备 [脚注 10] 以支持诸如文本控制台和硬盘重定向等某些 AMT 特性。一个串口被模拟为实现文本控制台重定向 [参见 79，第 5 章]。发送至此端口的文本输出被通过网络转发至远程控制台。有了这项能力，管理员可以远程控制 BIOS。为了实现硬盘重定向，一块本地硬盘被 ME 环境模拟 [参见 79，第 5 章]。管理员可以通过本地模拟硬盘远程挂载存储介质（例如一张含有操作系统安装程序的 CDROM 以恢复此启用了 AMT 的平台上的操作系统）。

脚注 10：这些设备可以作为总线主控，参见 2.5 节。

在平台加电过程中，ME 固件镜像被加载至 ME 内存。ME 固件本身运行于微控制器内部的 ARC4 处理器上，它还会使用某些系统内存，如图 4.2 所示，以存储运行时数据。此运行时内存由某一内存区域提供，并且对于主 CPU 和操作系统不可见。这种隔离由芯片组强制实施 [79]。

ME 环境引入了 带外（OOB）通讯，即由 iAMT 使用的特殊网络流量信道。启用了 iAMT 的计算机平台由远程管理控制台通过 OOB 管理。OOB 同样持续可用，而与电源状态无关。OOB 可以看作运行于相同硬件上的隔离网络连接。ICH 实现了必要组件以便为 ME 环境提供 OOB 特性。固件将专门用于例如 iAMT 的网络流量过滤出来并且将这些数据包重定向至 ME。宿主对于重定向的 ME 网络流量并不警觉。此类流量由 TCP 端口号来识别。

4.3.3 针对 Linux 和 Windows 目标的攻击实现细节

我们实现了两种击键码记录器原型以攻击两类目标，即基于 Linux 和 Windows 的操作系统。我们决定查找并且监控目标操作系统的 32 位版本的键盘缓冲区地址。与 64 位版本相比，32 位版本必须处理更加复杂的内存管理，例如，攻击者在映射内存地址时必须考虑 物理地址扩展（PAE [105，p.769]）或者某些内存偏移量。在下一小节中，我们描述了我们是如何实现如 4.2 节所述的 DMA 恶意软件核心功能的。这些原型在其 监控阶段 捕获短寿命的击键码。每种原型以不同方式处理用于不同目标缓冲区的 搜索阶段。这是由至少两大原因决定的。原因之一是为了评估 DMA 恶意软件的尽可能多的方面。另一个原因是不同的操作系统拥有不同的内存管理属性。我们使用一种由 Tereshkin 和 Wojtczuk [131] 所描述的漏洞以便在运行时渗透 ME 环境。为了调用我们的代码，我们挂钩到某个被我们识别为库函数 memset 的 ME 固件函数上。Tereshkin 和 Wojtczuk [131] 假设他们挂钩了某个计时器中断处理程序，但是他们实际上挂钩了 ME 固件函数 memcpy。我们之所以选择挂钩 memset 是由于我们确定此函数被更加频繁地调用。

我们的 Linux 变体基于如图 4.3 所示的签名扫描。我们分析了可获得的 Linux 源代码以得出我们的目标的签名，即键盘缓冲区的物理地址。此缓冲区地址是 USB 请求块（URB）结构的一部分，该结构定义于 Linux 源代码的 include/linux/usb.h 文件中。所需的结构字段称为 transfer_dma。此内存偏移量随内核版本不同而不同。我们通过利用 多重启动管理器（GRUB）来解决这个问题，使其在固定的物理内存地址放置一个标识符。我们实现了一个函数以便通过 DMA 读取该标识符并且对内核版本号进行分析以得出对应的偏移量。随后，我们的原型进入搜索阶段，即签名扫描。

图 4.3 USB 请求块签名扫描（简化）

(1) 开始查找指向 USB 设备结构的指针，这样的候选指针对齐到 0x400 边界。结构字段 transfer_dma 的值必须对齐到 0x20 边界。如果这两个条件同时为真，此 USB 设备结构中的产品字符串将被 (2) 检查是否包含子字符串”USB”和”Keyboard”。在签名扫描的最后一步 (3) 检查键盘缓冲区是否包含 垃圾信息，即无效的击键码。

由于我们的 Linux 原型针对的是内核数据结构，我们可以将搜索空间限制为系统内存的最前面 1 GiB。标准 Linux 系统拥有一种 1 GiB / 3 GiB 的内存分割方案，即 1 GiB 用于内核空间，3 GiB 用于用户空间。我们能够通过经验性地分析内核将我们的签名搜索所需的数据结构放置于哪块内存区域来进一步限制搜索空间。我们已经确定对于 Ubuntu Linux 内核版本 3.0.0 在一次新鲜的平台重启之后，该内存区域介于 0x33000000 至 0x36000000 之间。此键盘缓冲区的地址在待机或者休眠之后不会改变。通过这种方式，我们克服了低效扫描全部系统内存以查找随机放置的签名这一困难。在攻击 Linux 内核时，将虚拟地址映射到物理地址并不是一个大问题。通常，在 32 位版本中，一段内核虚拟地址（或者更准确地说，内核逻辑地址 [参见 31，第 15 章]）通过减去一个固定的偏移量而被映射到它的物理地址。在 64 位 Linux 版本中，无需使用这样的偏移量。因此无需获知 CR3 处理器寄存器的状态。

针对基于 Windows 的目标平台的搜索策略与此不同。为了能够利用搜索路径执行下文所述的搜索，虚拟地址必须被映射到物理地址。这种映射是通过由 Windows 内核创建的页表而实现的。这些页表的内存地址被加载至 CR3 寄存器，这是攻击者利用 DMA 所不能访问的。在利用某个简单的驱动程序进行了一些经验测试之后，此用于 系统进程 的页表的物理地址被证明为采用以下两个值之一：0x122000 或者 0x185000，对于 Windows Vista/7 系统。此系统进程是在 Windows 启动过程中所创建的首个进程。有了这一知识，DAGGER 便可以访问由内核创建的页表并且克服将虚拟地址映射到物理地址这一困难。DAGGER 实现了一种考虑到 PAE 的页表遍历算法。

我们的 Windows 恶意软件查找一个名为 DeviceExtension 的结构，它由 USB 键盘驱动程序 kbdhid.sys 所维护。此结构包含一块存储着近期按键的击键码的缓存。kbdhid.sys 的源代码不可公开获得。获得关于此驱动程序的内部信息的最便捷方式是使用 IDA Pro [脚注 11]、Windows Debugger（WinDbg）工具，以及由微软以 pdb 文件形式提供的调试符号 [脚注 12]。为了最终确定该缓冲区在 DeviceExtension 结构中的位置，我们的研究始于启动过程的早期 [参见 105，第 13 章]。我们了其他的 Windows 内部结构。为了查找用于搜索的起始指针，我们分析了 内核处理器控制区域（KPCR [105，p.62ff]），或者更加准确地说，KiInitialPCR，即用于处理器 0 的 KPCR。我们同样检查了 对象管理器名称空间目录（OMND，Windows 对象管理器的一部分）。我们确定了 KiInitialPCR 很适合于推导出一条指向 DeviceExtension 结构的路径，如图 4.4 所示。KiInitialPCR 并非定位于固定的内存地址。DAGGER 不得不在其能够开始如图 4.4 所示的搜索之前应用一个额外步骤。

脚注 11：参见 http://www.hex-rays.com/products/ida/index.shtml [访问于 2014 年二月 25 日]

脚注 12：参见 http://msdn.microsoft.com/en-us/windows/hardware/gg462988 [访问于 2014 年二月 25 日]

图 4.4 查找 DeviceExtension 结构（简化）

有了 KiInitialPCR 作为起始点，DAGGER 找到了 OMND，它通过散列值表提供了一条指向驱动程序对象 kbdhid 的路径。此对象包含指向设备对象的指针。此设备对象提供了 DeviceExtension 结构，它包含击键码缓冲区。

KiInitialPCR 的内存位置由 winload.exe 二进制文件中的一个名为 OslpLoadAllModules 的函数决定，如图 4.5 所示。此二进制文件由 Windows 启动管理器 bootmgr 所加载，而后者又由 主引导记录（MBR）代码所加载。此函数以某种或多或少地随机化的方式加载 硬件抽象层（HAL）库 hal.dll 以及 Windows 内核镜像。此内核镜像在一个固定的相对地址包含 KiInitialPCR。OslpLoadAllModules 的反汇编代码类似于某种 地址空间布局随机化（ASLR [105，p.757]）机制。

图 4.5 查找 KiInitialPCR（简化）

OslpLoadAllModules 决定了 Windows 内核镜像和 HAL 的准确位置。

用于内核镜像和 HAL 的内存缓冲区由 OslpLoadAllModules 通过一个名为 BlImgAllocateImageBuffer 的函数分配。该函数返回对于某一 Windows 系统固定的地址值。这些值可能会因系统不同而不同。对于函数 BlImgAllocateImageBuffer 的可能的返回值，共有 64 种不同的 4 kiB 对齐的虚拟地址的理论可能值。这些地址需要被检查以发现内核镜像基地址。对 BlImgAllocateImageBuffer 的反汇编揭示了用于地址随机化的种子拥有 5 位的值。这提示了对于（两种）可能的加载顺序情况中的每一种各有 32 种可能的地址，这两种可能的情况是指到底是先加载内核镜像，然后加载 hal.dll 还是反过来。只要 KiInitialPCR 在内核镜像内部具有固定的虚拟地址，同样多的待检查的虚拟地址数量同样适用于直接搜索 KiInitialPCR，而无需处理内核镜像。为了保证 DAGGER 找到的是正确的 KiInitialPCR，我们实施了一种 KiInitialPCR 签名检查。如果 DAGGER 识别到了正确的 KiInitialPCR，它就会继续利用图 4.4 所示的搜索路径查找键盘缓冲区。

我们利用以太网控制器来潜出所捕获的击键码。更准确地说，我们利用 Intel ME 环境的 OOB 特性。然而，没有文档解释如何使用这一特性。因此，我们不得不分析固件以判明如何利用 OOB 信道来潜出击键码。我们能够找到用于在 ME 运行时内存中发送网络数据包的传送环缓冲区。更进一步地，我们还能够从该传送环缓冲区中找到负责发送下一个网络数据包的固件代码。为了潜出所捕获的数据，我们准备了网络数据包，例如如图 4.6 所示的 DHCP 发现数据包。它包含记录下来的击键码。然后，我们将准备好的网络数据包复制到传送缓冲区。随后，我们通过网卡触发，将此数据包发送至某个外部平台。请注意，如果利用外部平台分析网络流量，则很容易发现被传送的数据包。为了增强此设计的隐秘性，我们 [124，125] 实现了一种隐秘计时信道，它基于所谓的 Jitterbug [参见 115]。

图 4.6 包含来自键盘缓冲区的字节的网络数据包

此 wireshark 实例执行于某个外部平台上。此网络数据包已经被 wireshark 分析为包含 4 个字节，它代表了所记录的击键码数据。

4.4 评估

我们使用一台具有 Q35 芯片组、2 GiB 内存、一块四核 3 GHz CPU，以及 iAMT 固件（版本 3.2.1）的 x86 平台来评估 DAGGER，利用 4 种不同的 32 位操作系统内核：Windows Vista 商用版（服务包 2）、Windows 7 专业版（服务包 1），以及 Ubuntu Linux 内核版本 2.6.32 和 3.0.0。

4.4.1 DMA 恶意软件功能的实现

我们根据 4.1 节所述的 DMA 恶意软件定义设计并且实现了我们的 DAGGER 原型。(C1) 显然满足，由于 DAGGER 实现了可运作的击键码记录器功能。DAGGER 在渗透过程中不需要物理访问 (C2)。我们在运行时利用基于软件的漏洞渗透 ME 环境。DAGGER 利用了专用硬件以实现 rootkit 属性 (C3)。我们运行了宿主性能开销测试（内存：MEM，网络：NET，以及 CPU），由于宿主和 ME 环境共享网卡以及内存芯片。并行的网卡和内存访问必须被仲裁，并且可能因此造成延迟。我们的测试结果如图 4.7 所示，并未显示出显著的开销。我们所能检测到的最高开销在搜索阶段扫描宿主内存时大约为 1.5%。这种最小化的性能开销不太可能使得 DAGGER 暴露。

图 4.7 宿主性能 CPU、内存和网络开销测试

我们使用时间戳计数器以测定开销时间。我们测试了通过网络（NET）以及在内存（MEM）中复制一个 100 MB 的测试文件所需的时间，以及并行计算此测试文件的 SHA1 散列值 10 次所需的时间，这是为了对全部 4 个 CPU 核心（CPU）造成压力。每组基准测试执行了 3 次：没有击键码记录器（基线）、击键码记录器处于搜索模式，以及击键码记录器处于监控模式。对于监控模式，我们将击键码记录器配置为大约每分钟持续发送大约 1000 个网络数据包。这相当于 500 次击键和 500 次释放按键事件。我们重复了每项测试 1000 次。图中的横线表示 1000 次运行的平均值。

如图 4.8 所总结的搜索时间非常短，并且我们所进行的极具侵略性的内存压力测试并不代表通常的计算机系统的内存使用。DAGGER 拥有完全只读的操作以保证其隐秘性。流行的网络嗅探工具 Wireshark [脚注 13] 在 Linux 和 Windows 系统上不能检测到任何 DAGGER 流量。宿主防火墙也不能阻止这些流量。即使反病毒软件知道 DAGGER 的签名，它也不能访问 DAGGER 的内存以成功应用签名扫描。此外，我们还运行了一种名为 Mamutu [脚注 14] 的软件，除了其他功能以外，它专注于检测击键码记录器行为。即使是专门的软件也不能发现 DAGGER 的任何痕迹。关于判据 C4，我们成功地检查了 DAGGER 的攻击代码能否在平台重启、待机以及关机之后仍然完全可运作。我们确定这取决于一个 iAMT 的 BIOS 选项。我们的代码不能在冷启动之后存活，如果此选项未被设置。

脚注 13：参见 http://www.wireshark.org/ [访问于 2014 年二月 25 日]

脚注 14：参见 http://www.emsisoft.com/en/software/mamutu/ [访问于 2014 年二月 25 日]

图 4.8 搜索时间测试结果 (a) 和 (b)

在 Linux 下利用若干种键盘的测试结果显示了搜索时间约为 1000 ms 的最佳案例和将近 30000 ms 的最差案例，如 (a) 所示。对于所有键盘的平均值为 3281 ms。有利于比较的信息是：对于 Linux（参见 4.3.2 节），扫描全部内存区域用时被测定为 13000 ms。而 30000 ms 的最差案例是由于我们所未能直接处理的错误 DMA 传输。这导致 DAGGER 重复进行搜索阶段。在 Windows 7 上，最佳搜索时间约为 50 ms 而最差搜索时间约为 120 ms，参见 (b)。对于所有键盘的平均值为 93 ms。因此，我们为 Windows 平台所实现的搜索策略的性能远远好于 Linux 的基于签名扫描的策略。

4.4.2 有效性和高效性

DAGGER 是高效的，由于它可以永久性地从键盘缓冲区捕获短寿命数据。为了表明 DAGGER 同样是有效的，我们利用不同的 Windows 和 Linux 版本以及若干种键盘测试了 DAGGER。测试得出的搜索时间总结于图 4.8，这确认了 DAGGER 非常高效。我们为每种内核和每种键盘重复测试 100 次。我们的测试发生于平台启动或者重启之后以改变每次运行时的目标地址。Linux 测试结果提示我们能够进一步限制搜索空间。我们能够在我们的测试中最常遇到的最低地址附近开始搜索。大约 2500 ms 的搜索时间是由于目标地址靠近 0x33c00000。因此我们能够跳过大约 2500 ms，如果我们在 0x33c00000 处开始搜索。更进一步地，我们能够跳过介于 0x34000000 和 0x36000000 之间的地址范围，由于我们几乎没有在此区域发现目标。大量目标被发现于 0x36e00000 附近，即还可以节省大约 12500 ms 的搜索时间。这会增加错失键盘缓冲区地址的几率。这意味着我们可以以牺牲有效性为代价来获取更好的搜索时间。在最佳案例下，搜索时间快到足以捕获诸如硬盘加密口令等。我们利用某个 Linux 系统成功地测试了这一点。Windows 内核可以将内存页交换到硬盘上——而 Linux 则不会。交换的内存页不能被 DMA 恶意软件所发现。因此我们同样对 Windows 进行了一项测试以检查内存交换对 DAGGER 是否有任何影响，如图 4.9 (d) 所示。

图 4.9 搜索时间测试结果 (c) 和 (d)

(c) 中的图像比较了不同的目标内核。DAGGER 在 Windows 7 上的性能略好于 Windows Vista。Linux 2.6.32 相对于 Linux 3.0.0 将目标内存结构放置得更加靠近 0x33000000，因此 DAGGER 在攻击 Linux 2.6.32 时拥有更多的位于 1000 ms 左右的命中率。(d) 中的结果确认了内存交换对于 DAGGER 的高效性和有效性没有影响。平台重启仅被应用于改变交换行为。尖峰是由于搜索阶段的重启。

4.4.3 ME 固件条件

为了能够真正成为隐秘的，DAGGER 确保了 ME 固件一直运行并且正确运行。iAMT 提供了一种网络服务器以用于远程平台管理 [参见 79，p.215]，它仍然可用。此服务器在本地平台的 Linux 和 Windows 上正确响应。利用 MEI（参见 4.3.2 节）工作的固件工具在 DAGGER 活动时仍然能够正常工作。我们在 Windows 下成功地测试了 AMT 状态工具（作为 本地管理服务驱动程序 的一部分）和 管理连接工具（作为 管理开发者工具包 7.0 的一部分）。在 Linux 下，我们成功地测试了 Intel AMT 开源工具和驱动程序（版本 5.0.0.30），或者更加准确地说，ME Status 和 ZTCLocalAgent 工具。注意，我们确定 DAGGER 仍然能够运行，即使已经在 BIOS 中禁用了 iAMT 固件。看起来 ME 环境不可能通过任何 BIOS 选项完全禁用。

4.4.4 I/OMMU

为了测试 I/OMMU（参见 2.6 节）能否作为对抗 DAGGER 的反制措施，我们在 BIOS 中启用了 Intel VT-d。就我们所知，Windows 并不能直接支持 I/OMMU。我们仍然能够成功攻击 Windows Vista 和 Windows 7，即使 I/OMMU 被激活。Linux 通过额外的努力支持了 I/OMMU 配置。我们同样在 BIOS 中启用 VT-d 并且通过内核命令行激活了 I/OMMU 支持。有了这些额外的步骤，我们能够阻止 Linux 版本的 DAGGER 从操作系统内存中读取短寿命的击键码。这种保护在默认状态下并未开启。在下一节中，除了其他内容以外，我们将会讨论与 I/OMMU 有关的其他问题。

4.5 关于反制措施的考虑

利用执行于宿主 CPU 之上的软件来扫描 DMA 恶意软件非常困难。例如，当前的反病毒软件并不会扫描外设的运行时内存，或者宿主 CPU 不能访问此运行时内存，由于某些隔离机制。对于扫描方法的最坏案例是 DMA 恶意软件改变了扫描软件的行为，使其得出错误的结果。如 TCG [136] 所提议的加载时固件镜像检查并不能防止运行时攻击。更进一步地，所有 ROM 组件是否都可被宿主访问这一点并不清楚。

4.5.1 I/OMMU 相关问题

对于 DMA 攻击的情况，I/OMMU（参见 2.6 节）的恰当配置被诸如 Duflot 等人 [47] 所提议为一种预防性的反制措施。这要求由系统软件配置 I/OMMU。不正确的配置不能被排除 [83，p.2]。

假设 I/OMMU 是安全的。然而，情况并非总是如此。Sang 等人 [111] 展示了 I/OMMU 配置可以被传统 PCI 设备所欺骗。Wojtczuk 等人 [148] 揭示了 I/OMMU 可以通过修改由 BIOS 提供的 DMA 重映射引擎数量而被攻击（参见 2.6 节）。这是在 I/OMMU 被系统软件配置之前完成的。我们用于 DAGGER 的环境能够执行此类攻击。此威胁只能通过执行名为 SINIT 的依赖于硬件的特定代码来化解。然而，之前至少发生过一次这样的情形，即芯片组厂商未能在芯片组发布时释出 SINIT 代码 [147，p.22]。此代码对于初始化一个用于诸如虚拟机监视器等的众所周知的、可信的环境来说是必要的。它检查 DMA 重映射引擎，并且由此能够阻止由 Wojtczuk 等人 [148] 所呈现的攻击。

SINIT 属于可信计算基并且增加了它的大小。前期工作展示了 SINIT 代码可能包含可被利用的安全漏洞，这些漏洞可以被用于欺骗 I/OMMU 机制 [参见 148]。最近，Wojtczuk 和 Rutkowska [146] 呈现了另一种可以被用于绕过 I/OMMU 机制的攻击。为了防止由 Wojtczuk 和 Rutkowska [146] 所呈现的攻击，SINIT 以及 BIOS 更新必须被应用。Wojtczuk 等人 [147] 呈现了另一种 I/OMMU 攻击。注意，SINIT 一般在基于虚拟机监视器的平台上被触发。基于通常的操作系统的平台不一定能够依靠 I/OMMU。同样值得提到的是，SINIT 要求激活额外的平台特性，即 可信执行技术 和 TPM [54]。这意味着诸如那些不想激活 TPM 的用户将不能依靠 I/OMMU。注意，TPM 是一种可选设备 [参见 54，p.212]，并且默认被关闭。

为了得到针对 DMA 恶意软件的完全保护，正确配置 I/OMMU 是绝对必要的。然而，I/OMMU 仅在其上方的用于保护整个平台的机制是安全的的情况下才能被看作是安全的。这是一项困难的任务。因此，其他方法由 Li 等人 [83] 和 Duflot 等人 [46] 所考虑。Li 等人 [83] 宣称他们的方法要求对固件进行扩展、并不能在外设造成大量 PCIe 流量的情况下正确地工作，以及验证组件需要知道精确的硬件配置。由 Duflot 等人 [46] 所呈现的方法高度针对网卡，并且不适用于诸如 Intel ME 等隔离执行环境。值得注意的是，诸如我们所实现的恶意软件能够在不进行任何网卡固件修改的情况下控制网卡，即数据潜出不能被由 Duflot 等人 [46] 所描述的方法检测到。更进一步地，此方法对于宿主 CPU 具有显著的性能问题（某个 CPU 核心 100% 使用）。

由 I/OMMU 强制实施的内存访问策略可能是不充分的，或者甚至可能在某些应用场景中阻止某些其他特性的使用。考虑诸如 CoPilot [100] 和 DeepWatch [25] 等由硬件支持的恶意软件扫描工具。I/OMMU 可以被配置为阻止 CoPilot 或者 DeepWatch 正常工作，或者允许这些系统访问宿主内存以扫描恶意软件。在后一种情况下，DMA 恶意软件可以利用 CoPilot 或者 DeepWatch 的执行环境来攻击宿主。例如，DAGGER 利用了 DeepWatch 的环境，即 Intel ME。自从 iAMT 版本 5 开始，Intel 支持对于将要执行于 Intel ME 之上的固件进行验证启动 [参见 79，p.271]。固件将会在加载时被检查。此加载时检查的结果被提供给系统软件。据我们所知，此结果并未在实践中被使用。此机制不能阻止由我们的概念验证所应用的运行时攻击。这意味着 DAGGER 证实了我们的这一假设，即诸如通过零日漏洞（参见 2.7 节）已经渗透目标系统的攻击者仍然能够雷打不动，即使诸如此类的额外安全机制已经就位。I/OMMU 的恰当配置是对抗 DMA 恶意软件的第一步。但是，如果不能解决上述问题，成功的部署并不能被保证。

4.5.2 基于 DMA 副作用的检测方式

一种可能的检测方式基于 DMA 副作用，这种副作用是我们在对自己的 DMA 恶意软件原型 DAGGER 进行首次实验的时候就观察到了的。我们的检测机制基于多种被广泛使用并且跨平台可用的 CPU 特性。

就目前为止，我们开发、实现并且评估了我们的机制，它能够检测到那些并非由宿主系统引发的非预期的恶意 DMA 使用。如果某个外设必须以宿主 CPU 的名义处理数据，则其 DMA 使用由宿主 CPU 引发。利用网卡发送一个网络数据包就是这样的一个范例。预期的 DMA 使用源自外设，并且其本意是用于运行于宿主 CPU 上的软件。接收一个网络数据包就是关于预期 DMA 使用的一个范例。我们的方法能够检测一种普遍的副作用特征。因此我们相信它除了我们自己所实现的 DMA 恶意软件原型以外，还适合于检测其他类型的 DMA 恶意软件。我们对于检测恶意 DMA 使用的调查基于这一知识，即主 CPU 和平台外设都能够在同一时刻请求对主系统内存的访问。内存控制器集线器对并行内存访问请求进行仲裁，参见图 2.5。对于我们来说的有趣问题是，这种并行内存访问是否引入了任何可以测量的副作用。如果此副作用存在并且可测量，则我们可以利用这些副作用来检测恶意行为。

我们启动了一种 Linux 内核并且只启动了一个 root shell 以保持系统负载最小化。只有一个 CPU 核心在线。我们执行了 3 次内存压力测试：没有击键码记录器（基线）、击键码记录器处于搜索模式，以及击键码记录器处于监控模式，同时参见 4.3.3 节。我们使用了一个 100 MB 的文件用于测试，通过将其从某个基于内存的文件系统中的一个位置复制到另一个位置。我们重复了此测试 1000 次并且计算了平均值。结果如图 4.10 所示。此图表揭示了我们如何利用不同的更加专门化的测量工具来精炼我们的策略。

图 4.10 内存压力测试

搜索阶段和监控阶段被表示为相对于基线的值。

首先，我们尝试通常的系统工具 GNU time 以测定延时。GNU time 测量的是某个进程的系统资源使用，在我们的案例中即为内存压力测试工具。如图 4.10 左侧显示，所运行的测试结果的平均值几乎相同。我们得出结论，即 GNU time 的测量分辨率不足以揭示我们的实验中的延迟。

我们利用一种更加精确的，基于硬件的测量工具，即 TSC [参见 69，第 17.12 节] 重复了我们的测量。TSC 对时钟周期进行计数，参见 2.3 节。其结果呈现于图 4.10 中间。我们能够得到或者重现 2% 的开销，如果我们的原型恶意软件处于搜索模式。DMA 最初被引入是为了消除 CPU 负载。这意味着执行内存传输而无需涉及宿主 CPU。因此，这种开销是一种惊喜，也是关于可检测的 DMA 副作用确实存在的第一组证据。当我们的原型恶意软件处于监控模式，我们在使用 TSC 时并不能观测到显著的开销。两种模式之间的关键区别在于，在搜索模式中，恶意软件需要复制至少一个内存页以便在其中搜索有价值数据。而在监控模式中，此恶意软件只需从键盘缓冲区复制 4 字节。

我们利用第三种方式重复了测量，即利用 HPC，用于代码优化的一种基于硬件性能监视工具，参见 2.3 节。这些计数器是位于 Intel 处理器上的特殊目的处理器寄存器 [69，第 18/19 章]。它们对特定事件进行计数，诸如缓存未命中、分支预测错误，以及资源停止等。类似的 HPC 在诸如 ARM 和 SPARC 等平台上同样可用。我们用于我们的实验的 Intel 平台支持 340 种事件 [脚注 15]。我们评估了它们的全部，并且确定资源停止是一种特别有效的 DMA 副作用。对于某些特定事件，HPC 事件计数相对于 TSC 测量更加精确。我们假设资源停止的次数是我们所能利用 TSC 测量得到的延迟的直接结果。作为一个范例，我们在图 4.10 中呈现了一种名为 RAT_STALLS:ROB_READ_PORT（参见 2.3 节）的硬件性能计数器所得到的结果。相对于基线，其开销高达 2 倍以上。如果没有我们的原型恶意软件，我们的测量结果是 1359898 次计数事件。如果我们的原型恶意软件处于搜索模式，平均值为 3161868 次计数事件，而在监控模式中时则为 1535054 次计数事件。后者只是略高于基线。这组精炼的测量结果展示了我们的测量越精确，则 DMA 副作用的可见性就越好。

脚注 15：我们使用了性能 API 以便在上述实验中配合 HPC 工作，它可以从此处获得：http://icl.cs.utk.edu/papi/software/index.html [访问于 2014 年二月 25 日]

基于我们的发现，DMA 副作用可以被测量。这意味着我们能够设计一种 DMA 恶意软件检测机制。此机制通过建立一组测量基线并且将 TSC/HPC 的测量值与之进行比对而达到目的。在运行时，我们的系统监控 TSC/HPC 测量值并且将其与参比值进行比对。如果这些值偏离参比值，则 DMA 恶意软件就被检测出来了。我们承认关于此种基于延迟的检测方法的某种实际实现仍需进一步调查。在第 5 章，我们呈现了一种改良的检测器，它同样基于 HPC。更进一步地，对于我们的改良的方法，对于检测 DMA 恶意软件而言，人为施加的内存压力不再是必需的。在本节，我们仅仅作为反制措施来讨论 I/OMMU 和一种基于 DMA 副作用的检测方法。

4.6 本章小结

在本章中，我们研究了 DMA 恶意软件，即隐藏于专用硬件中的恶意软件。诸如此类的恶意软件可以通过直接访问宿主内存来绕过运行于宿主 CPU 之上的保护机制。我们实现并且评估了 DAGGER，一种基于 DMA 的击键码记录器。专用硬件使得我们的原型能够得益于 rootkit 属性。DAGGER 能够隐秘地运作。它不可由诸如反病毒软件等检测到。我们能够得出结论，与其他已知的 DMA 恶意软件相比，DAGGER 是一种具有代表性的恶意软件概念验证。因此，我们将会在后续章节重复使用 DAGGER 以开发一种可靠的 DMA 恶意软件检测器。

DMA 恶意软件不仅仅是控制一个 DMA 引擎。我们的评估确认了 DMA 恶意软件是高效的，即使诸如内存地址随机化等障碍已经就位。我们同样展示了 DMA 恶意软件可以是有效的，即它可以攻击若干种操作系统。这确认了 DMA 恶意软件的隐秘性无需以牺牲高效性和有效性作为代价。宿主并没有可靠的方式以保护其自身。纵观本章，我们强调了 I/OMMU 具有若干问题，并且宿主不一定能够依赖这种预防性措施以对抗 DMA 恶意软件。除了可能的漏洞以及不同的预设条件必须被满足以成功部署 I/OMMU 以外，最为明显的问题是普通的操作系统并不支持 I/OMMU，或者支持不充分。因此 DMA 恶意软件可以攻击诸如 Windows 等操作系统。用于扫描专用设备以查找恶意软件的通用并且可靠的方法并不存在。需要一种可靠并且更加通用的 DMA 恶意软件检测机制。其他研究者也调查了 I/OMMU 的替代品。

在本章中，我们讨论了一种替代方法。我们的检测方法基于这样一种现象的观察，即来自隔离硬件（通过 DMA）和来自宿主 CPU 的并行内存访问造成了可测量的副作用。因此我们可以得出结论，即非法 DMA 操作不再是隐秘的。此外，我们不得不承认用于此检测方法的实验设置包含大量人为因素。我们得出结论，当前的设置不足以作为可以在实践中应用的检测工具。然而，我们展示了硬件性能计数器可以作为可靠的检测工具的基础。我们揭示了测量工具必须具有足够的测量分辨率。硬件性能计数器满足这一要求。我们将会在下一章更加详细地调查这一点。

没有替代品，只有那些其内部工作方式对于宿主可以访问，即完整的内存和只读存储器访问的专用硬件应该被部署。这使得宿主能够时时刻刻地检查该设备以查找恶意代码。关于这一点的一个前提条件是一种合理的测定策略，以及扫描程序得以首先加载。具有专用处理器、专用运行时内存以及 DMA 引擎的设备对于宿主平台来说是一种威胁。本章展示了需要额外的保护机制以确保平台的机密性和完整性，以及特别是它们的可信性。

原文始发于微信公众号（赛博堡垒）：Intel ME之暗影匕首初章：检测针对宿主内存的基于外设的攻击 （上篇）