基于CVE-2023-36884和CVE-2023-36584漏洞链攻击的深度分析 - 嘶吼 RoarTalk – 网络安全行业综合服务平台,4hou.com

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

xiaohui 技术 2023-12-05 11:31:00
71274
收藏

导语:研究人员观察到一个有趣的Microsoft Word文档(.docx文件)并于2023年7月3日首次提交给VirusTotal。

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

微信截图_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/如若转载,请注明原文地址
  • 分享至
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

发表评论

 
本站4hou.com,所使用的字体和图片文字等素材部分来源于原作者或互联网共享平台。如使用任何字体和图片文字有侵犯其版权所有方的,嘶吼将配合联系原作者核实,并做出删除处理。
©2024 北京嘶吼文化传媒有限公司 京ICP备16063439号-1 本站由 提供云计算服务