CVE-2023-36025 Windows SmartScreen安全功能绕过漏洞分析

在复现了该漏洞后，由于没有详细的漏洞细节披露，只能推测微软可能patch的位置，问题可能有两处：

1. explorer在解压zip文件后没有调用SmartScreen进行检查，这种情况问题微软就可能patch在explorer解压文件，调用程序执行文件这块的执行逻辑。  

   
   

2. explorer正确解压了文件，并且在执行恶意vbs文件前正确调用了SmartScreen进行检查，只是绕过了SmartScreen执行逻辑，导致返回了安全的结果，如果是这样，patch就可能出现在smartScreen中。

可以看出问题出现在explorer,在未修复的版本中没有调用SmartScreen进行检查而是直接启动了wscript去执行我们的恶意vbs文件。  

接下来逻辑就比较清晰，往上追溯堆栈，寻找可能为执行逻辑相关的dll文件，然后根据堆栈调用与diff来寻找功能代码，定位漏洞点。    

经过枯燥的审计过程，通过对其中的堆栈进行审查，发现了几个强相关dll文件，分别为windows.storage.dll与zipfldr.dll。  

其中前者更多是关于explorer的各种操作的dll依赖库，而后者更专注于对压缩文件夹的处理，通过zipfldr.dll,explorer能够像处理普通文件夹一样处理ZIP文件。用户可以在其中查看、打开、复制和移动文件，就像它们是常规文件夹一样。

通过图上windows.storage.dll的调用堆栈，配合diff可以发现，漏洞出现在windows.storage.dll中的CInvokeCreateProcessVerb::ProcessCommandTemplate函数中。

通过对CInvokeCreateProcessVerb::ProcessCommandTemplate函数的功能审计，可以确定该函数是用来处理和执行一个命令模板。  

我们关心的逻辑主要在关于CheckSmartScreenWithAltFile的验证部分。在未安装补丁版本中可以看到部分执行逻辑如下：

explorer首先调用ParamIsApp判断将要执行或者下载的文件是否带有参数，如果没有参数则调用ShouldDownloadItem判断该文件是否需要下载，如果需要下载则调用DownloadItem函数。  

该函数通过调用SHELL32!CLocalCopyHelper::Download实现下载后返回Shell Item对象。  

下载后调用CInvokeCreateProcessVerb::InitSelectedItem函数对shell item对象进行了一系列的初始化，并且检查文件路径是否恶意。  

最后调用CheckSmartScreenWithAltFile进行smartscreen验证。  

CheckSmartScreenWithAltFile中通过IsSmartScreenEnabled实现com调用到smartscreen.exe进行合法验证，如果验证失败，则调用SafeOpenPromptForShellExec弹框警告。  

以上的思路似乎都没有问题，但是紧随其后的第二个逻辑就有了一些问题。也就是对ParamIsApp不满足条件的处理，由上图我们可以看出在执行的文件没有参数的情况下，我们是没办法绕过smartscreen的，可是我们通过url又没法给file路径带参数。

但是当我们调试exp的时候发现，exp调用的是Wscript执行，这种就不满足ParamIsApp的处理。

这种行为也许是可以理解的，因为如果我们通过`file:`去下载执行远程文件的时候，确实是无法带参数执行。但是微软确实没有考虑到如果解压到本地路径后再调用系统应用启动的情况。  

在补丁中，微软也是不出所料的在第二个逻辑下添加了CheckSmartScreenWithAltFile验证。