作者:且听安全
原文链接:https://mp.weixin.qq.com/s/q0lbegDjLViLI48N6RjGVw

接上文:

第一部分:样本分析

CVE-2021-40444-Microsoft MSHTML远程命令执行漏洞分析(一)

分析完网上流传的样本后,我准备尝试替换cab文件中的文件后复现漏洞。安装的office软件版本:Microsoft Word 2016 (16.0.4266.1003):

Windows的版本:Windows10 1909 (build 18363.1734)。我们首先在虚拟机上用原始的docx进行复现测试,先修改hosts文件,将域名解析为127.0.0.1:

将ministry.cab和side.html预先存放在一个目录下(目录名根据前期的样本分析,设置为e8c76295a5f9acb7),并在上层目录用python开一个http服务,服务端口为80:

然后尝试打开恶意docx文件,可以看到http服务器上有对应像下载请求:

可以使用Process Monitor来看一下word在打开恶意样本的时候到底做了什么,启动前先设个过滤器:

重新打开docx,Process Monitor会记录word(即winword.exe)的所有操作,可以看到word将side.html存放在临时目录下,并改名为side[1].htm

继续往下翻,还可以看到word将ministry.cab存在了另一个临时目录下,并改名为ministry[1].cab,但是用资源管理器查看时发现文件已经被删除了。

继续往下翻,还可以看到word又在Temp目录下创建了文件championship.inf

而后面则是使用control.exe 执行 .cpl:../../../AppData/Local/Temp/championship.inf,可以合理推测恶意软件已被成功执行(恶意软件的进一步分析已超出本文的范围):

下一步我们准备替换ministry.cab文件中的文件,看能否实际执行成功,所以我们要做的就是重新创建一个cab包,就像这样:

将新的cab替换原来的文件后,再次打开docx,结果并没有预期那样释放我们提供的messagebox.dll(通过浏览Process Monitor监控,没有看到创建文件操作),这一点比较奇怪(后面在漏洞成因分析中,通过逆向urlmon.dll就能发现原因了)。

于是我将自定义的dll重命名为championship.inf(跟原始样本一样),再试一次:

这次应该是成功释放了,不过释放的目录不一样,没有直接存放在Temp目录下,而是在一个随机文件名的临时目录下(这样的话control.exe就没办法找到championship.inf):

看来只能对比新旧两个ministry.cab有什么区别了:

通过对比发现原始的ministry.cab中文件的名称前有../,这也就解释了为什么原始的文件会释放在Temp目录下,而我们自己做的却没有。所以我们得重新创建一个cab,而其中的文件名也是../championship.inf。

为了方便,我们可以先用makecab打包一个xxxchampionship.inf,然后再用二进制编辑软件将文件名的前3个字节其修改为../,再次尝试果然也成功释放到了Temp目录下,但是似乎一直没有被执行,通过仔细查看Process Monitor中的结果,我们发现了下面的一项:

这个championship.inf居然直接被删除了,而对比原始样本,在CloseFile前没有这一项:

这个问题困扰了我一段时间,但是目前我还不想逆向整个漏洞的成因和触发流程。现在整个漏洞利用链条,我们修改过的仅仅是这个cab文件,所以问题肯定就在这个文件上面,而cab文件的头又非常简单,通过几次尝试,终于找到了问题所在:就是CFFILE结构中的cbFile字段:

当我们将该长度改一个比正常值更大的值,则释放的championship.inf文件将不再被删除,恶意代码将被执行:

事实上,当cbFile的大小超出cab包的实际大小时,将发生访问异常,导致championship.inf没有被正常清除,使恶意代码得以执行,详细分析见下一章的漏洞成因分析。


Paper 本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/1795/