作者：且听安全
原文链接：https://mp.weixin.qq.com/s/q0lbegDjLViLI48N6RjGVw
接上文：
第一部分：样本分析
分析完网上流传的样本后，我准备尝试替换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没有被正常清除，使恶意代码得以执行，详细分析见下一章的漏洞成因分析。
本文由 Seebug Paper 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/1795/