深入了解在钓鱼攻击中被广泛使用的Microsoft RTF格式文件和OLE漏洞

过去几年间，攻击者针对的平台发生了巨大变化。根据Recordedfuture于2019年3月发布的报告显示，在2016年之前，浏览器一直是攻击者最常使用的感染媒介，但现在Microsoft Office应用程序则成了首选，后者常见于钓鱼攻击的恶意附件文档中。

对象链接和嵌入（OLE）是基于组件对象模型（COM）的技术，是Microsoft Office文档的功能之一，它允许在文档中嵌入或链接其他Windows应用程序创建的对象，从而创建复合的文档结构，为用户提供更丰富的使用体验。在过去的几年中，OLE被各种大肆滥用，攻击者要么通过加载COM对象编排和控制进程内存，要么利用COM对象的解析漏洞，隐藏恶意代码或连接到外部资源来下载其他恶意软件。

Microsoft RTF格式文件在钓鱼攻击中被广泛使用的原因之一是它具有包含多类漏洞的特点，且使用群体广泛，传播上也十分有效。Microsoft RTF文件可以嵌入各种形式的对象类型，再利用它们的漏洞帮助其进一步利用。在过去，常见到攻击者利用RTF格式文件的OLE特性，将RTF文档链接到外部恶意代码，或是将其他文件格式的漏洞嵌入自身，将其用作漏洞容器。显然，RTF文件格式是非常通用的。

在以下几节中，我们将概述Microsoft RTF格式文件近期的一些漏洞利用和感染策略，最后总结了有助于自动分析RTF漏洞的关键要点，并为通用分析方法设定了方向。

RTF控制字

一个RTF文件由未格式化文本、控制字、控制符号和组组成，控制字定义了文档呈现给用户的方式。由于这些RTF控制字具有跟文档相关的参数和数据，它们的解析错误可能成为利用的目标。过去也出现过利用控制字嵌入恶意资源的攻击。因此，对那些使用数据和提取流的目标控制字的检查就变得非常重要。RTF规范中，定义的使用数据的控制字有数百个。

因此，一个RTF解析器必须能够处理攻击者通常使用的控制字混淆机制，才能进一步帮助分析。下图是之前某例，通过控制字参数在数据存储控制字中引入可执行负载的过程。

在RTF文件中叠加数据

叠加数据指的是在RTF文档末尾的附加数据，由攻击者（以明文或加密的形式）嵌入诱饵文件或其他资源，通常在执行时再将其解密。超出一定大小的叠加数据应被视为可疑的，必须进一步提取和分析，但Microsoft Word RTF解析器在处理RTF文档时会忽略叠加的数据。

下图是一个RTF攻击实例，攻击者在文件末尾叠加了大量数据，把CVE-2015-1641的漏洞利用嵌入了诱饵文档和多阶段的shellcode中。

RTF文件中的对象链接和嵌入

RTF文档中链接或嵌入的对象表示为RTF对象，准确地说是RTF目标控制字的“对象”。链接或嵌入的对象数据以十六进制编码的OLESaveToStream格式，作为参数存储到RTF子目标控制字“ objdata”中。修饰符控制字“ objclass”确定嵌入在RTF文件中的对象的类型，并帮助客户端应用程序呈现该对象。然而，作为“objdata”控制字的参数的对象数据有可能被严重混淆，使逆向工程和分析工作更耗时，或是让一些RTF解析器无法分析。考虑到OLE是近年来最主要的攻击载体之一，有一个强大的RTF文档解析器，对提取对象和对对象数据作深入检查是非常关键的。

对象链接–将RTF链接到外部资源

使用对象链接，可以将RTF文件链接到远程对象，该对象可以是到远程服务器上托管的恶意资源的链接。生成的RTF文件则充当下载器，随后通过调用特定的资源处理程序来执行下载资源。链接的对象由嵌套的控制字“ objautlink”指示，并检查修饰符控制字是否为“object”，如下图所示：

如上所示，RTF控制字“objdata”的参数的对象数据是OLESaveToStream格式的OLE1.0NativeStream，其后是NativeDataSize，指示包装在NativeStream中的OLE2.0复合文档的大小。根据RTF格式规范，如果对象链接到容器应用程序（在本例中为RTF文档），则复合文档的Root Storage目录条目将具有StdOleLink的CLSID，以指示链接的对象。同样，当对象为OLE2.0格式时，链接的源数据在OLESteam结构的MonikerStream中指定。如下所示，在解析对象数据时，ole32.OleConvertOLESTREAMToIStorage函数负责将OLE1.0 NativeStream数据转换为OLE2.0结构化的存储格式。跟随指向OLE流的指针lpolestream，能使我们看到已解析的提取本机数据。下面是winword.exe进程解析带有链接对象的RTF文档时的内存快照。

启动带有外部对象链接的RTF文档，将弹出一个对话框，要求更新链接对象中的数据，如下所示：

但是，这不是针对受害者的理想利用策略。这个错误可以通过插入另一个控制词“objupdate”来消除，它在内部调用链接对象的IOleObject::Update方法来更新链接的源。

随后，URL Moniker的注册服务器URLmon.dll实例化。

COM对象实例化后，将启动与外部资源的连接，并基于服务器在响应中返回的内容类型标头，URL Moniker会在注册表中查询Mime数据库并调用已注册的应用程序处理程序。

有关如何执行URL Moniker的详细信息以及确定要调用哪些适当的处理程序的算法请见此处。我们再过去见到过多个此类RTF的漏洞利用，比如CVE-2017-0199，CVE-2017-8756以及其他使用Monikers下载和执行远程代码的漏洞。

虽然Microsoft在较新版本中将上述漏洞中使用的COM对象列入了黑名单，但将来可能会出现类似的技术，这实质上需要对OLE结构化存储流进行分析。

对象嵌入–包含OLE控件的RTF

如前所述，在容器文档中以OLE2格式表示嵌入式对象。当对象以OLE2格式存储时，容器应用程序（此处为RTF格式文件）为每个嵌入的对象创建OLE复合文件存储（OLE Compound File Storage），而相应的对象数据存储在OLE复合文件流对象中。存储嵌入式对象的容器文档的布局如下所示，Microsoft文档描述请见此处。

从以往看，RTF漏洞利用通常是嵌入多个OLE控件来绕过漏洞缓解的，并通过加载易受攻击的OLE控件来利用内存损坏漏洞。RTF文档中嵌入的OLE控件通常由嵌套的控制字“objocx”或“objemb”表示，后面跟着“objclass”，其参数为呈现对象的OLE控件的名称。下面是曾经发生过的一起攻击案例，它利用COM对象中的一个漏洞，并加载另一个OLE控件来帮助嵌入了恶意代码的漏洞利用进程。显然，提取这个对象数据、OLE2复合文件存储和每个流对象以进一步检查隐藏的恶意shell代码是非常重要的。

对象嵌入–包含其他文档的RTF

恶意RTF文档可以使用OLE功能来嵌入其他文件格式（如Flash文件和Word文档），以利用各自的文件格式漏洞，进一步协助并建立漏洞利用的过程。在过去多起RTF攻击中，都有观察到到攻击者使用OLE功能嵌入OOXML文档，来操纵进程堆内存，并绕过Windows缓解措施的举措。在RTF文件中，嵌入的对象通常由嵌套控制字“objemb”表示，嵌套控制字“objclass”的参数是一个与版本相关的“ProgID”字符串。在下图中，是近期一起类似的攻击案例。

下面是另一个实例，其中PDF文件嵌入在复合文档中。如前所述，嵌入式对象与呈现该对象所需的所有信息一起物理存储。

在嵌入式对象中，创建应用程序的标识符存储在CFB存储对象的复合文件目录条目的CLSID字段中。如果我们查看前面的实例，在手动提取和检查对象数据时，会在CFB存储对象中观察到以下CLSID，它对应于CLSID_Microsoft_Word_Document。

在对OLE2流对象进行解析、提取嵌入的OOXML后，我们看到了可疑的ActiveX对象加载活动和嵌入的恶意代码。显然，提取RTF中的嵌入式文件并进行进一步分析是很重要的。

RTF文件中的OLE软件包

RTF文档还可以通过OLE包嵌入其他文件类型，例如脚本（VBSsript，JavaScript等）、XML文件和可执行文件。RTF文件中的OLE包由ProgID字符串“package”表示，作为嵌套控制字“objclass”的参数。打包程序格式是没有关联的OLE服务器的旧式格式。查看注册表中关联的CLSID，没有特定的数据格式映射到包。

这本质上意味着OLE包可以存储多种文件类型，如果用户单击对象，就会导致对象的执行。众所周知，RTF文档通过OLE包嵌入脚本，然后使用别名(如前几节所述)将文件放入所需目录中，然后执行，从而交付恶意软件。下面的示例中，攻击者利用了CVE-2018-0802嵌入可执行文件。

由于已经发现许多RTF文档通过OLE包传递恶意软件，因此查找这些嵌入对象并分析它们是否携带额外的负载是非常重要的。RTF中嵌入的可执行程序/脚本可能是恶意的。寻找OLE包和提取嵌入式文件应该是一项基础的任务。

通过以上漏洞利用交付策略，可以使我们迈出建立RTF文档分析框架的第一步。首先，自动化分析任务以及RTF控制字检查最基本的是要检查链接或嵌入的对象，以下是关键要点：

· 使用RTF文件作为容器，可以嵌入许多其他文件格式的漏洞利用，本质上是将RTF文档武器化。

· 对调用提取恶意代码、负载或资源处理程序的OLE对象的分析变得非常重要。

· 如果RTF文档有很多附加数据，则必须进一步查看。

· 非OLE控制词和OLE包也需要分析可能存在的恶意内容。