基于CVE-2023-36884和CVE-2023-36584漏洞链攻击的深度分析

漏洞链攻击是从以下诱饵开始:

分析时，研究人员观察到一个有趣的Microsoft Word文档(.docx文件)于2023年7月3日首次提交给VirusTotal，名为Overview_of_UWCs_UkraineInNATO_campaign.docx。

该活动被社区归因于Storm-0978(也被称为RomCom组织，因为他们使用了RomCom后门)。

恶意Word文档诱饵

此文档托管在以下URL：

hxxps://www.ukrainianworldcongress[.]info/sites/default/files/document/forms/2023/Overview_of_UWCs_UkraineInNATO_campaign.docx

上面的链接表明该文档很可能是通过电子邮件传播的，电子邮件文本包含指向.docx文件的链接。文件的创建日期和域名ukrainianworldcongress的注册日期都是2023年6月26日。这个时间点表明，这是一个基于电子邮件的活动，其中包含.docx文件的链接。

当该文件最初提交给VirusTotal时，62个杀毒软件中有27个将其识别为恶意文件。

CVE-2023-36584利用的技术分析

微软Office文档一直是攻击者传播恶意软件的常用攻击手段。为了应对这一威胁，微软实施了mow安全，限制Office文档中的各种功能来自不受信任的位置。

Windows将这些文件识别为高风险文件。带有mow标记的文件会生成一个SmartScreen提示，表明它有潜在的危险。当Word文档未标记为mow时，就会被攻击者利用，导致禁用Protected View。

为了理解CVE-2023-36884是如何被特定的诱饵利用的，我们应该首先了解Microsoft Word对Open XML文件格式的实现过程，在本例中是针对MS-DOCX (.docx)文件。

MS-DOCX文件是一个压缩的ZIP归档文件，其中包含用于显示Word文档的多个规范文件。其中之一是位于word/document.xml的XML文件。这是MS-DOCX文件的核心XML组件，它包含文档的文本和格式。

在Microsoft Word中查看MS-DOCX文件时，文档的大部分内容都是通过Word /document.xml导入的。

在.docx诱饵中，word/document.xml使用名为altChunk的导入外部内容元素导入内容，如下图所示。

这个altChunk元素可以导入使用另一种格式的内容，比如富文本格式(RTF)，来自.docx文件的word/document.xml有一个altChunk元素，它使用标识符AltChunkId5指示与外部内容的关系。这个标识符在word/_rels/document.xml.rels的关系文件中被定义。

上图中显示的document.xml.rels代码片段将导入的目标标识为位于word/afchunk.rtf的文件。

RTF文件afchunk.rtf包含两个恶意的OLE (Object Linking and Embedding)对象。第一个OLE对象使用带有objautlink RTF控制字的OLE自动链接类型，在objautlink控制字之后，一个objupdate控制字强制对象在显示之前进行更新，如下图所示。

对象类被定义为Word.Document.8，其数据在其标头中包含LinkedObject结构，后跟表示十六进制字符的ASCII文本。

我们使用Didier Steven的rtfdump.py工具进一步检查afchunk.rtf。下图显示了前面所示的objautlink片段的十六进制(hex)输出，这个输出更清楚地显示了LinkedObject结构。

第一个恶意OLE对象的rtfdump.py输出

此十六进制转储显示\\104.234.239[.]26\share1\MSHTML_C7\file001.url，一个使用服务器消息块（SMB）协议的恶意url。

使用rtfdump.py查看afchunk.rtf，我们发现另一个使用xmlfile类的恶意OLE对象，其标头包含EmbeddedObject结构。嵌入的对象是一个复合文档，其中包含一个URLMoniker，它从URL加载XML文件hxxp://74.50.94[.]156/MSHTML_C7/start.xml，如下图中的蓝色标注。

第二个恶意OLE对象的rtfdump.py输出

漏洞利用链的第一阶段

对该漏洞利用链的初步研究得出了一个流程图，该流程图由@zcracga创建，并于2023年7月12日由@r00tbsd共享。该流程图有助于可视化通过漏洞利用链工作的不同阶段。

漏洞利用链流程图

我们最初关注的域是afchunk.rtf中恶意OLE对象的两个URL。如前所述，这些OLE对象从以下URL请求内容：

\\104.234.239[.]26\share1\MSHTML_C7\file001.url
hxxp://74.50.94[.]156/MSHTML_C7/start.xml

当Windows客户端连接到SMB服务器时，该客户端会发送Windows NT LAN Manager（NTLM）凭据进行身份验证。因此，当受害者主机访问位于\\104.234.239[.]26\share1\MSHTML_C7\file001.URL的URL时，它会将受害者的NTLM凭据及其主机名和用户名泄漏给攻击者控制的SMB服务器。收集到的信息稍后将用于攻击链。

下图显示了嵌入file001.url中的HTML代码。

file001.url片段

通过检查file001.url，UName变量包含受害者的用户名。这是攻击者控制的SMB服务器从受害者泄露的NTLM凭据中收集的用户名。如果上图显示的变量d不为空，则漏洞利用链将用户名与攻击者传递的值连接起来，该值用于创建名为2222.CHM的CHM文件的路径，该文件包含在名为file001.zip的文件中。

在攻击链的这一阶段，2222.chm不存在，或者它可能是攻击者使用的其他攻击的一部分。file001.url的进一步行为将在后面解释，因为它与2222.chm密切相关。

afchunk.rtf中的第二个恶意OLE对象来自hxxp://74.50.94[.]156/MSHTML_C7/start.xml。此start.xml文件包含一个iframe，用于从同一服务器和目录路径加载另一个名为RFile.asp的文件。

start.xml中引用RFile.asp的iframe片段

RFile.asp负责在服务器上加载另一个文件，该文件的攻击特定路径定义为：

file[:]//104.234.239[.]26/share1/MSHTML_C7/1/__file001.htm?d=__

该路径由受害者的

RFile.asp中的代码段

滥用Windows搜索处理程序

file001.htm的核心行为是执行JavaScript，如下图中的代码片段所示。

file001.htm片段

file001.htm中的JavaScript使用iframes来加载几个文件。它首先加载一个保存的搜索文件，该文件的文件名由受害者的IP地址和以字符串file001.search-ms结尾的五位标识符组成。我们将把这个文件称为其文件名file001.search-ms的最后一部分。

接下来是三个HTTP请求，在它们的url中使用字符串.zip_k*。除了执行计时或无操作（no-op ）操作外，此行为没有明显的价值。

最后，MSHTML重新加载file001。Search-ms然后加载redir_obj.htm。

这些请求的顺序很明显，因为预期的目的并不明显。根据相关网络流量示例中的时间戳，我们推测通过服务器端操作实现了这种事件顺序的绕过，其中对.zip_k*文件的请求被用作延迟机制。下图显示了在Wireshark中过滤流量的数据包捕获(pcap)，突出显示了一个HTTP GET请求与其HTTP响应之间的两秒延迟。

使用zip_k.asp延迟响应请求

在检查文件redir_obj.htm时，我们发现了如下图所示的代码片段。这段代码从本地路径加载一个文件，该文件使用在初始SMB连接期间捕获的泄漏的主机名和用户名分别作为CompName和UName变量，其用于打开文件file001.zip中名为1111.htm的HTML文件。

来自redir_obj.htm的片段

重新创建Windows搜索处理程序文件

我们使用Windows文件资源管理器创建一个空白保存的搜索文件，文件扩展名为.search-ms，以控制包含2222的ZIP文件的位置。提取CHM并说明这个漏洞利用链是如何工作的。我们在File Explorer中启动搜索并保存结果，这创建了一个.search-ms文件。这个保存的搜索文件是一个空白模板，可以重现这个漏洞利用链中使用的搜索处理程序文件行为。

Windows系统文件Windows. storage .search .dll处理.search-ms文件。为了成功地将ZIP文件解压缩到redir_obj.htm文件中指定的目录中(由图11中所示的JavaScript iframe加载)，需要进行一些更改。

首先，include元素必须包含一个本地路径作为它的网络路径，并使用FILE_ATTRIBUTE_NORMAL，实现为变量attributes="128"。

基本.search ms文件，已更改为触发ZIP提取

接下来，autoListFlags属性必须打开第二个最低有效位，如下图所示。这将产生一个完整的搜索，其中还包括任何ZIP存档的内容。

在Windows.Storage.Search.dll中进行.search-ms处理的示例

此时处理.search ms文件将在目标计算机上按以下路径创建一个目录：

C:\Users\[USERNAME]\AppData\Local\Temp\[Temp1_zip_filename]

ZIP文件的内容随后被提取到该目录中。

search-ms根据早期SMB泄露的主机信息处理ZIP文件的放置和内容提取。

结果证实了从ZIP文件中提取的两个文件：1111.htm和2222.chm。

在利用Office中以前的RCE漏洞CVE-2021-40444时，也观察到了类似的行为。在该攻击中，攻击者会利用Microsoft Compressed Archive（CAB）路径遍历提取漏洞来实现类似的目标：将HTML文件提取到计算机上的可预测路径。

在讨论1111.htm和2222.chm文件之前，我们首先应该了解Windows安全区域。

Windows安全区域和其他障碍

Windows安全区域也被称为Internet Explorer安全区域或URL安全区域，Windows安全区域是微软用来确定来自不同来源文件的权限机制。通常，从internet检索的文件被标识为来自“internet Zone”，并标记为受限权限的mow。

此数据存储在名为Zone.Identifier的文件的备用数据流（ADS）中，用于指示文件的安全区域。来自“Internet Zone”的文件的ZoneId值为3(安全区域3)。

为了使攻击链的其余部分成功，1111.htm和2222.chm文件的ZoneId值都必须在其Zone.Identifier ADS（安全区域1）中标识为1。然而，这是一个障碍，因为从远程路径下载并由.search-ms提取的ZIP内容的ZoneId值为3，并且该内容会自动标记为MotW。

为了成功利用，还必须克服另外两个障碍:

障碍1：当Windows Search使用.Search ms完成时，它会删除[Temp1_zip_filename]目录。这将生成一个竞争条件，以加载临时目录中的文件。

障碍2：默认情况下，Windows不会搜索CHM文件的内容。2222.chm文件是此漏洞利用链的一部分，但它不会使用Windows搜索的默认设置从ZIP存档中提取。

使用CVE-2023-36584绕过MotW

在使用CVE-2023-36884对这个漏洞链进行分析期间，研究人员发现了一个漏洞利用途径，微软将其命名为CVE-2023-36584。

Windows Search在搜索期间遍历ZIP存档中的所有文件。Windows Search检查每个文件的文件扩展名，以确定其内容是否也需要搜索。如果是，Windows Search将该文件写入临时目录，并将mow添加到其中。

这个实现生成了一个固有的竞争条件。在将解压缩文件写入磁盘和用mow标记它之间有很短的时间窗口。如果我们在这个窗口中延迟Windows搜索，我们可以解决竞争条件并最终绕过mow。

先前利用CVE-2022-41049的技术通过向ZIP存档中的文件添加只读属性来绕过motw，这避免了对区域的修改。这避免了对Zone.Identifier ADS的修改，并阻止了提取的文件接收MotW。这项技术启发了我们，并使我们发现绕过MotW。

技术1：服务器端ZIP交换

服务器端操作使我们能够解决这些问题，我们发现了一个从检查时间到使用时间(TOCTOU)的漏洞，当从远程服务器下载ZIP归档文件时，可以利用该漏洞。

Windows使用系统文件zipfldr.dll来提取ZIP存档的内容。这个Windows DLL文件读取ZIP文件的标头并将数据缓存在内存中，同时ZIP存档的内容被提取并保存到磁盘。Zipfldr.dll公开了一个API，该API可用于通过在ZIP存档中指定文件索引来提取文件。

读取文件标头后，在使用zipfldr.dll对其进行解压缩之前，我们可以将远程服务器上的ZIP文件替换为包含不同名称文件的ZIP文件，从而导致MotW无法写入。

这种技术之所以有效，是因为urlmon.dll使用文件路径来写入最初从缓存在内存中的ZIP标头读取的MotW，以便绕过将MotW写入文件。

该技术解决了前面提到的关于利用CVE-2023-36884的两个障碍。成功解压缩了.chm文件，否则将无法解压缩，并且这些文件不会立即删除。

下图显示了一个Process Monitor（procmon）视图，说明创建名为2222.txt的替代文件的尝试失败。此条件允许以前保存的2222.chm避免MotW。

使用TOCTOU漏洞绕过mow

我们无法确认这就是攻击者在原始漏洞利用链中使用的确切技术。但是，VirusTotal对初始.docx诱惑的沙箱分析的行为日志显示，创建了一个名为1111.txt的文件，表明可能有一个镜像1111.htm的替代文件名。

技术2：服务器端延迟

除了第一种技术外，我们还发现了另外两种可以显著延迟mow编写的技术。此场景防止写入MotW属性，并允许从安全区域1中的另一个线程执行文件。

从ZIP存档中提取文件后，在将MotW添加到Zone.Identifier ADS之前，我们可以从攻击者控制的SMB服务器引入时间延迟。这是可能的，因为SMB2协议的关闭操作包括关闭请求和结束基于SMB的文件传输的关闭响应。

当客户端接收到来自传输文件的所有数据时，它将SMB关闭请求发送回服务器，并等待SMB关闭响应。文件已被传输，但传输操作尚未完成，直到客户端收到关闭响应。这是一个同步操作，可以延迟相当长的一段时间。

下图中的procmon列表显示了在111.222.11[.]20的SMB服务器在下一次操作之前传输了一个名为served.zip的文件后的30秒延迟。这表示关闭请求和关闭响应之间有30秒的延迟。

在这个30秒的窗口中，1111.htm文件是一个没有MotW的安全区域1文件。在30秒后最终发送了关闭响应后，该过程继续，并将MotW写入1111.htm。

mow绕过

技术3：服务器端延迟

在从ZIP归档文件传输大文件时，Windows从远程共享中读取文件的一部分，将数据附加到磁盘上的本地文件中，然后从远程共享中读取其他部分，直到文件完全写入磁盘。如果我们在文件末尾附加随机数据，就可以在Windows将mow添加到文件之前延迟SMB服务器对文件的写入。该文件在写入过程中是可用的，因为它是用读写dwShareMode打开的。

我们通过在流程中引入10秒延迟来测试这个预设，如下图所示。

使用延迟阅读响应的mow

微软安全更新地址CVE-2023-36884

开发此漏洞利用链的攻击者知道SMB文件传输期间临时保存的本地文件的路径是可预测的。但在微软2023年8月的安全更新之后，临时保存的本地文件名中添加了一个通用唯一标识符（UUID），可以使路径随机。

微软2023年8月安全更新后临时保存的本地文件路径

如上图所示，在我们的测试运行期间，临时保存的文件在临时保存的本地文件的目录路径中包含UUID字符串90be3ab -6ec5-4f3f-bdd8-1e22ee6c326c。

在ZIP存档的SMB文件传输过程中，zipfldr.dll通过调用CTempFileNameArray::GetTempLocation函数创建一个临时文件夹，该函数调用CTempFileNameArray::_TryCreatingInPath。

使用BinDiff查找zipfldr.dll补丁版本中的更改，我们在CTempFileNameArray::_TryCreatingInPath函数中发现了一个值得注意的新代码块，如下图所示。

调用UuidCreate

Microsoft添加了对UuidCreate的调用，如果路径没有使用新的UUID构造，则从ZIP存档中提取内容将失败。

zipfldr.dll补丁版本中另一个有趣的更新是ExtractZipToFile函数。在提取文件后添加新代码，它将在文件写入后立即追加mow。如果SetFileAttributes失败，文件将被删除，如下图所示。

调用DeleteFileW

尽管微软2023年8月的安全更新缓解了这一漏洞链，但该链的其他步骤仍可以被利用。

ActiveX攻击面

在安全区域1中运行文件会导致对ActiveX控件更宽松的策略，并提供更大的ActiveX攻击面。这允许执行可能被利用来执行恶意代码的旧ActiveX代码。

增加的ActiveX攻击面使我们能够触发攻击链中的下一步。下图中的1111.htm中的代码片段将导致下一步。

在WebBrowser控件中重新加载1111.htm

这段来自1111.htm的代码创建了一个隐藏的弹出窗口，并在隐藏的弹出窗口中运行ActiveX WebBrowser控件。WebBrowser控件是一个包装器，它允许在基于windows的应用程序中使用web浏览功能。开发人员经常使用此ActiveX控件在应用程序中嵌入HTML查看器。

提升命令执行的安全区域

虽然安全区域1允许我们避免mow并增加ActiveX攻击面，但可以将文件提升到安全区域0以执行命令。标记为安全区域0的文件表示“本地计算机”区域，这是最受信任的区域，并提供最大允许权限。

在这个阶段，WebBrowser控件将页面从区域1中的网络路径重定向到同一页面的本地路径。现在已经从本地路径加载了1111.htm文件，它将在安全区域0中执行。

接下来，1111.htm通过调用ms-its加载2222.chm，如下图所示。

加载2222.chm

Windows使用这个ms-its处理程序来显示microsoftcompiled HTML Help (CHM)文件。该函数在its .dll模块中实现，该模块加载提取的2222。chm文件。

下图显示了在HTML Help Workshop中查看文件时2222.chm的内容。

2222.chm的内容

CHM文件包含一个名为file1.htm的文件，该文件重定向到file1.mht（由inetcomm.dll处理，它是Microsoft互联网消息API的一部分）。然后file1.mht使用showHelp方法加载fileH.htm。然后fileH.htm重定向到fileH.mht，最后fileH.mht执行如下图所示的脚本。

fileH.mht代码段调用open函数

上图中来自fileH.mht的代码片段使用window.open方法调用ShellExecuteExW API以在以下位置打开文件：

file[:]//104.234.239[.]26/share1/MSHTML_C7/ex001.url

绕过SmartScreen

上图中名为ex001.URL的Internet快捷方式（URL）文件指向文件[:]//104.234.239[.]26/share1/MSHTML_C7/ex001.zip/file001.vbs。

下载的file001.vbs文件包含旨在绕过SmartScreen保护的恶意Visual Basic脚本（vbs）。

当URL文件指向远程UNC路径时，URL文件将下载并运行从该路径返回的内容。执行内容调用ShellExecuteW API，该API触发CheckSmartScreen函数，提示用户进行确认，如下图所示。

SmartScreen警告

但是，我们的文件位于ZIP存档中，因此它触发的行为流略有不同。文件 file001.vbs在利用链中被下载，并使用MotW提取到用户的本地临时目录中，但它会立即执行，不会出现任何弹出警告。下图中的procmon列表对此进行了说明。

立即启动Wscript.exe，成功绕过SmartScreen

如上图所示，从远程目录中检索文件ex001.zip，然后从zip归档中提取文件001.vbs。稍后在进程事件列表中，我们为wscript.exe找到一个进程创建条目，以运行VBS文件，如蓝色突出显示的那样。