按照顺序，本来计划要看的应该是《漏洞战争》中的Adobe Reader UAF漏洞，最近一直在看的Adobe产品的漏洞……所以决定转换一下思路，挑了最近新出现的CVE-2021-40444漏洞。刚好404之前有一篇博客写过这个漏洞，我在它的参考资料里面找到了github上面提供的poc生成代码，以及j00sean在twitter上面发的6行代码，以这两者为基础对该漏洞进行分析。

先看github上面的项目，根据Readme中的信息，用于生成Poc的主体代码文件是exploit.py，生成命令为：

python3 [exploit.py](http://exploit.py/) generate test/calc.dll http://<SRV IP>

那么我们先来看一下exploit.py这个文件。

观察exploit.py，用于生成poc的主体函数是generate_payload()，主要功能代码如下（删除了一些不影响理解的代码）：

注意到在第二步中，代码对doc文档中的word/_rels/document.xml.rels文件进行了更新，添加了srv_url + '/word.html'，这样在文档打开的时候，就会尝试连接服务器地址并打开word.html文件；

在第五步中，代码对doc文档会打开的word.html文件进行了更新，添加了word.cab的连接路径；

而word.cab文件又是从命令行中指定的payloadtest/calc.dll，使用lcab工具生成的cab文件。

所以接下来我们要看一下word.html和word.cab文件又干了些什么。

注：我也是自己反混淆完之后才发现lockedbyte的github项目里面有deobfuscate.py文件和deob.html文件，/(ㄒoㄒ)/~~

word.html中包含一段混淆后的javascript代码，首先使用notepad++中的插件进行一下美化：

可以看到代码前段其实算是一个“密码本”，通过_0x127f75 = _0x127f75 - 0xaa;操作以及_0x59985d['push'](_0x59985d['shift']());操作，获取到对应索引值位置真正的字符串，代码的后半段很多内容都是通过在该“密码本”中索引并拼接实现的。

一开始我对_0x59985d['push'](_0x59985d['shift']());操作不太熟悉，还是在IE中确定这句代码实际上是在对数组进行一个原位的前向循环。

最终使用一个python脚本对这段代码进行处理：

得到最终的代码（后半部分）：

其实还有一些内容是可以处理的，但是到此为止已经明显能够看出代码的功能了。它向服务器端请求并插入了http://192.168.6.155/word.cab文件，同时设置script标签的location属性为不同路径下的msword.inf文件。

根据exploit.py，msword.inf文件就是word.dll文件，而word.dll文件的内容是命令行中指定的payload，即test/calc.dll的内容。

而word.cab则是由lcab '../msword.inf' out.cab命令以及patch_cab('out.cab')命令生成的out.cab文件复制得到。

也就是说由于漏洞的存在，导致在请求插入了word.cab之后，能够做到payload的执行

根据wiki，cab文件就是Microsoft Windows中一种支持无损数据压缩以及数字证书的压缩格式。每个cab文档都由文件夹组成，每个文件夹作为单独的压缩块，文件夹中包含了不同的文件，不存在空文件夹。

从数据流的角度看，cab文件由CFHEADER、CFFOLDER、CFFILE、CFDATA四个结构组成。我们以word.cab文件为例，讲解这四个结构。

之后是cFolders个CFFOLDER结构，由于cFolders为1，所以这里只有一个CFFOLDER结构。

之后是cFiles个CFFILE结构，由于cFiles为1，所以这里只有一个CFFILE结构。

cbFile字段存在问题，太大了。

之后是cCFData个CFDATA结构，由于cCFData是7，所以这里有7个CFDATA结构。

根据2.2小结的结论，word.cab则是由lcab '../msword.inf' out.cab命令以及patch_cab('out.cab')命令生成的out.cab文件复制得到的，看一下patch_cab:

它把位于0x2d偏移处的四个字节修改成了0x00415c00，并且对..\\msword.inf进行了替换。

在根据word.cab分析cab文件格式的时候，我们遇到一个问题，CFFILE中的cbFile的值不太对。按道理来说，patch_cab想要修改的应该就是cbFile这个字段，但是m_off的选取不正常，看起来好像是假设CFFOLDER中的abReserve字段也存在一个字节。

为此我修改了一下exploit.py，删除了patch_cab函数的调用，重新观察生成的word.cab文件，此时cbFile处的数据为02 7A 03 00，也就是说未压缩的文件大小为227842字节。

注：如果你检查一下test/calc.dll文件的大小，会发现也是227842字节，因为这个cab文件未压缩，而且只包含calc.dll这一个文件。

因此，虽然目前还不知道为什么要修改cbFile字段，但是patch_cab这个函数应该是存在问题的。

到目前为止，通过分析poc生成代码exploit.py，我们了解了进行漏洞利用的相关文件是如何生成的；同时对生成的word.html中的javascript代码进行了反混淆，确定了其功能；最后以word.cab为模板了解了cab文件格式。

但是仍旧有很多问题：

注：我在调试之前，手工把word.cab中cbFile的字段改成了0x00415c00，之前因为patch_cab存在问题，把这里修改成了0x415c0002，虽然这个修改并不影响最终结果。

操作系统：Win10 专业版 1709

nodejs: 16.11.1

IE: 11.1087.16299.0

因为我的win10虚拟机没装office，为了方便测试，就使用了j00sean在twitter中提到的6行代码：

在IE中输入地址http://127.0.0.1:8080/exploit.html，回车，成功弹出计算器

在procmon监控的事件中，找到了IE写入word[1].cab行为：

找到了IE写入msword.inf行为：

找到了control.exe运行msword.inf行为：

亲自搭建环境测试之后，对于2.4中的第三个和第四个问题已经有了答案：

首先需要将windbg附加到iexplore.exe进程上，不知道是不是操作系统的原因，之前在win7上调试IE的时候没遇到这个问题，但是这次在win10上打开IE后，显示可附加的iexplore.exe有两个，一个是主进程，一个是对应打开标签的子进程，附加的时候一定要看好，需要附加到子进程上。

除了选择附加进程外，还存在另一个问题。之前漏洞调试的时候，因为漏洞比较古老，环境存在差异，导致漏洞利用无法成功完成，程序会陷入异常，这种情况对于漏洞调试反而是好的，你可以直接分析异常环境。但是这次漏洞利用成功完成，可以弹出计算器，这就导致如果不设置任何断点，F5继续执行后，整个流程就一发不可收拾地完成了，反而无法进行漏洞调试。所以必须要找到一个合适的断点，方便进行漏洞调试。

根据MSDN上的文档（参考资料1），FCI(File Compression Interface)和FDI(File Decompression Interface)库用于创建CAB以及从CAB中提取文件，相关功能函数位于cabinet.dll文件中。其中FDI API函数包括：FDICreate, FDIIsCabinet, FDICopy, FDIDestroy。

而从3.1的测试结果来看，IE在请求了word.cab文件后，会自动进行解压缩释放cab里面保存的文件。因此我们完全可以在FDICreate函数处设置一个断点，此时一切尚未发生。

因此步骤就是：附加IE进程，设置断点，F5继续执行，输入URL，回车，程序中断在FDICreate。

目前windbg中断在了cabinet!FDICreate函数的起始位置，在调试跟踪之前，我们需要确定关注的重点位置，看一下此时的函数调用流程：

可以看到在CABINET!FDICreate调用前几个比较有意思的函数：urlmon!FDICreate, urlmon!Extract, urlmon!ExtractInfFile，这几个函数功能从函数名大致就可以猜出来，但是具体都看了什么还无法确定。

从win10虚拟机中找到urlmon.dll并在IDA中打开，查看这几个函数的伪代码。

urlmon!FDICreate函数就是在从cabinet.dll中获取FDICreate等函数的地址，然后调用FDICreate函数，这里不再贴出代码。

urlmon!Extract函数主要调用了urlmon!FDICreate函数，并通过这个函数中获取的cabinet.dll中的函数地址，调用其中的FDICopy、FDIDestroy函数：

根据文档FDICopy函数的功能就是从cab中提取文件。

如果在windbg中检查该函数的第二个参数（我一开始在IDA中看的是64位版本的urlmon.dll，可以看出来第二个参数是cab文件路径）：

果然，这是exploit.html从服务器端请求的word[1].cab缓存下来的路径。所以urlmon!Extract函数基本上就是从word[1].cab中提取文件了。

再看一下urlmon!ExtractInfFile函数：

注意到在这个函数中，在调用完Extract之后，又调用了ExtractOneFile，而且在ExtractOneFile中同样调用了Extract函数。这就比较有意思了，不知道这两次Extract的调用有什么区别。

根据上面的内容，我们确定了程序都调用了哪些FDI API函数，也明确了之后动态调试需要重点关注的位置。有了以上知识，我们开始从IDA伪代码以及windbg调试输出两个角度，确定程序接下来的执行流程。

根据文档，FDICreate函数会创建一个FDI的上下文，从源码上来看，实际上就是由应用程序指定一些回调函数，使用其中的用于分配空间的回调函数分配一块空间存在这些回调函数以及其他相关结构体的地址：

根据调试器的跟踪结果，发现程序在这里分配的空间地址为0xc27b778：

FDICreate函数执行结束后，这块空间数据为：

如果检查07e2b290这里的数据，会发现：

当前从这里的输出来看，7e2b290在这里肯定指向的不是这个字符串，只是恰好相邻，所以被我发现了，这个字符串应该是在之前某步生成的，用于保存提取出来的文件。

其中这里就能猜出来了，cab文件中保存的文件是../msword.inf，这里应该是有一个目录遍历的漏洞，最后msword.inf直接保存在了Low目录下，从而让后面猜测msword.inf的行为能够成功，实现了漏洞的利用。

但是我们还是继续往下看。

在FDICopy函数中，首先调用LoginCabinet函数，这个函数读入了cab文件的CFHEADER的36个字节，检查了文件的signature,版本号以及标志位，同时确定了CFFILE的位置

在最后的doCabinetInfoNotify函数中，程序调用了urlmon!fdiNotifyExtract函数(if ( (this[9])(0, this + 0x1EF) != -1 ))，这个函数在之后还会调用到，它其实进行了主要的cab解压后的文件创建工作，不过在此次调用中并没有进行相关工作。

从IDA中得到函数声明：int __cdecl fdiNotifyExtract(enum FDINOTIFICATIONTYPE a1, struct FDINOTIFICATION *a2);

因此这里的调用中，FDINOTIFICATIONTYPE参数的数值是0，根据文件fdi.h（这个文件你应该可以在自己的操作系统里面搜索到）：

fdintCABINET_INFO:
Called exactly once for each cabinet opened by FDICopy(), including continuation cabinets opened due to file(s) spanning cabinet
boundaries. Primarily intended to permit EXTRACT.EXE to automatically select the next cabinet in a cabinet sequence even if not copying files that span cabinet boundaries.

从IDA中代码中看，如果FDINOTIFICATIONTYPE参数的数值是0，fdiNotifyExtract其实什么都没干：

继续往下看，FDICopy函数调用了FDICallEnumerate，这个函数再次调用了urlmon!fdiNotifyExtract函数(if ( v3(5, this + 0x7BC) != -1 ))，这次FDINOTIFICATIONTYPE参数的数值是5，对应fdintENUMERATE，从IDA代码看，fdiNotifyExtract依旧没有执行什么操作。

之后FDICopy函数调用了FDIReadCFFILEEntry函数，这个函数读入了CFFILE的前16个字节，不包含最后的szName字段，之后又读入了后面的0x100字节的数据。根据iFolder字段判断当前文件所处文件夹索引：

之后FDICopy函数第三次调用urlmon!fdiNotifyExtract函数，这次的FDINOTIFICATIONTYPE参数的数值是2，对应fdintCOPY_FILE。

经过windbg调试，发现程序调用了catDirAndFile函数，形成了解压缩后文件的完整路径C:\Users\zoem\AppData\Local\Temp\Low\Cab425A\../msword.inf:

之后程序会调用AddFile和NeedFile函数，经过NeedFile的判断，程序从urlmon!fdiNotifyExtract函数返回，返回值为0。

在fdi.h中说，如果返回值为0，表示跳过文件不复制。但是如果仔细查看该文件，在关于FDINOTIFICATIONTYPE的注释说明部分，提供了一个在进行FDICopy过程中，FDINOTIFICATIONTYPE取值的典型变化情况：

其中fdintPARTIAL_FILE针对的是同一文件存在于多个cab文件的情况，这里不考虑。从上面的流程可以看出，fdintCOPY_FILE参数传入了两次，如果当前文件是cab中的第一个文件，会传入一次fdintCOPY_FILE，也就是此时的情况，程序并不会进行真正的解压缩行为。

那么在这次传入fdintCOPY_FILE的时候，程序干了些什么呢？其实这里我没有完全弄清楚，它涉及到一个数据结构，但是我没有找到详细的文档介绍，如果从头开始说的话，要回到ExtractInfFile函数的开始部分，上面已经贴了这个函数的伪代码，在调用Extract函数之前，程序调用了StringCchCopyA函数(StringCchCopyA(0x104u, a3 + 0x1C, a1, v11, v14);)，这个函数实际上就是把cab解压的目标目录复制到了a3 + 0x1C这个位置。而在这个语句之前，有这样两句代码：

*(a3+6)这里应该类似于一个标志位。

在第一次执行到AddFile的时候（也就是第一次传入fdintCOPY_FILE的时候），函数代码如下：

根据上面的注释，AddFile这个函数应该是将程序当前查看的解压文件添加到a1指向的一个结构体中，0xC的空间就保存了当前解压文件的文件名信息，以及链表的下一个节点，还有一个标志位（3.3.6小结会提到这个标志位的作用）。

在这里贴出所谓的a1指向的结构体是什么样子的（我不确定大小是不是正确的，或许包含了之后非结构体的数据）：

注意到首四个字节就是解压后大小0x00415c00，偏移0x10的位置指向了分配的0xC大小的空间。

AddFile执行完之后，程序调用NeedFile：

所以这次调用NeedFile会返回0，因此最终fdiNotifyExtract也会返回0。

之后FDICopy函数就没有什么重要操作了。

执行完FDICopy函数之后，Extract函数调用FDIDestroy函数，会删除之前FDICreate函数创建的FDI上下文结构。Extract函数执行完成后，根据一开始得到的函数调用流程，程序会回到ExtractInfFile函数。

程序接下来会判断GetExtnAndBaseFileName函数的返回值是否为5，根据IDA伪代码：

可以确定这个函数是在判断cab中的文件的扩展名，返回值为5时说明文件扩展名是inf。而我们测试的cab中的文件是../msword.inf，符合要求。

之前我们提到过，在ExtractOneFile函数中，程序会再次调用Extract函数，但是除此之外，在调用Extract函数之前，它还执行了下面的代码：

标志位变成了0，也就是说在之后第二次传入fdintCOPY_FILE，程序调用AddFile的时候，程序会在一开始就返回1。

与此同时*(a5 + 0xCA)，也就是偏移值0x328的位置不再是0，而是传入了lpsz，lpsz的首四个字节保存的就是文件名指针。这样在调用NeedFile的时候，程序就会执行到循环体内部：

并且由于文件名相同，函数返回1。

这次fdiNotifyExtract函数不会在调用NeedFile之后返回，而是会继续向下执行：

程序会调用Win32Open函数，该函数会调用系统函数CreateFileA，按照完整路径C:\Users\zoem\AppData\Local\Temp\Low\Cab425A\../msword.inf创建文件

这次因为fdiNotifyExtract成功创建了要解压的文件，因此跳出回到FDICopy函数后，程序的流程会转到FDIGetFile函数的调用上：

下面是FDIGetFile函数的伪代码，关键在于其中的while循环，FDIGetDataBlock函数会读取一个CFDATA的数据，获得其解压后的大小curr_size_written，每次调用write_func对这部分数据进行写入，然后判断尚未写入的数据size_unwritten是否为0，如果不为0，就继续调用FDIGetDataBlock读取下一个CFDATA。而size_unwritten一开始的大小等于cbFile，就是0x415c00。

代码在这里存在一个逻辑上的漏洞，数据全部写入完成，即size_unwritten==0的情况，以及CFDATA读取失败，即FDIGetDataBlock函数返回值为0的情况，这两个情况的后处理方法不同。

如果是CFDATA读取失败，即FDIGetDataBlock函数返回值为0的情况，程序会跳转到LABEL_20，执行close_func关闭文件，此时对缓冲区进行flush，正式将内容写入硬盘；

如果是数据全部写入完成，即size_unwritten==0的情况，程序会跳转到LABEL_13，这部分代码我没有贴出来，有一些数据赋值的操作，我也不太清楚在干嘛，但是最终的一点在于，它调用了fdiNotifyExtract函数，传入的是fdintCLOSE_FILE_INFO参数。

也就是说两者关闭文件的函数不同，fdiNotifyExtract在进行关闭文件操作的时候，代码如下：

关键在于MarkExtracted函数：

可能从伪代码看不出来这个标志位是什么。通过windbg调试，我发现它修改的就是3.3.3小结中提到的调用AddFile的时候分配的0xC空间的第三位，当时是设置成了1，我还不知道指的是什么，现在看来这个第三位应该是是否解压的标志。

FDIGetFile执行完之后，没有什么重要的操作，一直跳出，知道到达GetSupportedInstallScopesFromFile函数（调用ExtractInfFile的位置），然后就执行到了DeleteExtractedFiles函数。

这个函数在if条件语句中检查了上面提到的是否解压的标志标志位，只有在这个标志位是0的情况下，才会继续往下执行其他函数，包括DeleteFileA函数。

因为在FDIGetFile函数中，程序没有正确的对这个标志位清零，因此DeleteFileA函数不会被执行，释放的mfword.inf保留了下来，导致后面可以通过.cpl:../../../AppData/Local/Temp/Low/msword.inf路径执行释放的文件。

到目前为止，我们已经完整分析了整个漏洞利用流程，同时2.4小结提出的四个问题也都得到了解答。

经过分析，漏洞主要存在于两个位置：

我没找到适用于1709的补丁版本，不过主机也是win10的，所以直接比较了主机中和虚拟机中的文件，发现微软并没有对上面提到的两个函数进行修改，而是修改了catDirAndFile函数：

新添加的部分查找了路径中的/字符，并替换成了\\：

至于标志位的清除操作则没有进行修改，可能是因为这个问题无伤大雅吧，因为缺少了目录遍历的条件，释放的文件位于一个随机的文件夹下，攻击者无法定位到释放的文件，因此即使释放的文件没有被正确删除，也不会造成危害。

这篇文章从poc代码，cab文件格式以及IDA静态代码分析+windbg调试三个方面对cve-2021-40444漏洞进行了比较全面的分析。其实漏洞分析本身并不比之前更难，但是明显能够感觉到，因为不像之前有详细的资料可以参考（虽然也有分析文章），不确定哪些地方是真正和漏洞相关的内容，我的个人探索会比较多，再加上本身也想要把整个执行流程弄清楚，因此这篇文章也就比较长。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！