基于CVE-2023-36884和CVE-2023-36584漏洞链攻击的深度分析
2023-12-5 11:31:0 Author: www.4hou.com(查看原文) 阅读量:18 收藏

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

微信截图_20231115000613.png

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

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

1.png

恶意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的导入外部内容元素导入内容,如下图所示。

2.png

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

3.png

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

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

4.png

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

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

5.png

第一个恶意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,如下图中的蓝色标注。

6.png

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

漏洞利用链的第一阶段

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

7.jpeg

漏洞利用链流程图

我们最初关注的域是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代码。

8.png

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的文件。

10.png

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

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

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

该路径由受害者的

10.png

RFile.asp中的代码段

滥用Windows搜索处理程序

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

11.jpeg

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响应之间的两秒延迟。

12.png

使用zip_k.asp延迟响应请求

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

13.png

来自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"。

14.png

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

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

15.png

在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。

16.jpeg

使用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。

17.png

mow绕过

技术3:服务器端延迟

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

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

18.png

使用延迟阅读响应的mow

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

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

19.png

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

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

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

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

20.png

调用UuidCreate

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

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

21.png

调用DeleteFileW

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

ActiveX攻击面

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

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

22.png

在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,如下图所示。

23.png

加载2222.chm

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

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

24.png

2222.chm的内容

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

25.png

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函数,提示用户进行确认,如下图所示。

26.png

SmartScreen警告

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

27.png

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

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

文章翻译自:https://unit42.paloaltonetworks.com/new-cve-2023-36584-discovered-in-attack-chain-used-by-russian-apt/如若转载,请注明原文地址


文章来源: https://www.4hou.com/posts/lkll
如有侵权请联系:admin#unsafe.sh