作者：yyjb
原文链接：http://noahblog.360.cn/cve-2021-1675/
背景
本月的微软更新包含一个spool的打印机服务本地提权漏洞，自从去年cve-2020-1048被公开以来，似乎许多人开始关注到这一模块的漏洞。鉴于此这个漏洞刚公布出来时，并没有太仔细关注。直到后面关注到绿盟的微信公众号的演示视频，显示这个漏洞可能在域环境特定情况下执行任意代码。所以认为有必要对其原理以及适用范围情况进行分析。
补丁分析
通过补丁对比，可以确定该漏洞触发原理应该是一个在添加打印机驱动的过程中RpcAddPrinterDriverEx()绕过某些检查的漏洞。
根据API文档，RpcAddPrinterDriverEx API用于在打印机服务器上安装打印机驱动；第三个参数为dwFileCopyFlags，指定了服务器在拷贝驱动文件时的行为。文档给出了标志的可能值，结合补丁，我们发现了这样一个标志：APD_INSTALL_WARNED_DRIVER（0x8000），此标志允许服务器安装警告的打印机驱动，也就是说，如果在flag中设置了APD_INSTALL_WARNED_DRIVER，那么我们可以无视警告安装打印机驱动。这刚好是微软补丁试图限制的标志位。
本地提权
我们分析了添加驱动的内部实现（位于localspl.dll的InternalAddPrinterDriver函数），添加驱动的过程如下：
-
检查驱动签名
-
建立驱动文件列表
-
检查驱动兼容性
-
拷贝驱动文件
如果能够绕过其中的限制，将自己编写的dll复制到驱动目录并加载，就可以完成本地提权。
绕过对驱动文件签名的检查
绕过驱动签名检查的关键函数为ValidateDriverInfo()。分析该函数，我们发现，如果标志位设置了APD_INSTALL_WARNED_DRIVER(0x8000)，那么函数会跳过驱动路径和驱动签名的检查。
绕过建立驱动文件目录函数
CreateInternalDriverFileArray()函数根据文件操作标志来决定是否检查spool驱动目录。如果a5 flag被标志为False，驱动加载函数只会检查用户目录中是否包含要拷贝的驱动文件；否则，函数会尝试到spool驱动目录寻找目标驱动，在本地提权场景下，这将导致列表建立失败。
通过简单分析可以发现，在FileCopyFlags中设置APD_COPY_FROM_DIRECTORY（0x10），即可跳过spool目录检查。
绕过驱动文件版本检查
后续的检查包括对需要添加的驱动的兼容性检查，这里主要是检查我们需要添加的驱动版本信息（这里主要是指版本号的第二位，我后面所描述的版本号都特指第二位）：
下面是用来被当去打印驱动加载的我们自己生成的一个dll文件，
修改dll文件版本号绕过驱动文件兼容性检查：
驱动加载函数InternalAddPrinterDriver中的检查限制了驱动版号只能为0，1，3.
而兼容性检查的内部函数实现（ntprint.dll的PSetupIsCompatibleDriver函数）又限制了该版本号必须大于2。因此，可以修改待加载驱动或dll文件的版本号为3，从而绕过驱动兼容性检查。
驱动文件的复制加载
驱动文件拷贝函数（CopyFileToFinalDirectory）对参数没有额外的限制。函数执行完成后，我们的驱动文件以及依赖就被复制到驱动目录了，复制后的驱动文件会被自动加载。
自动加载驱动：
尝试远程执行代码。
目前，我们已经可以从本地指定的用户目录加载我们自定义的打印机驱动文件到spool驱动目录。之前我们对AddPrinterDriverExW函数的调用第一个参数为空，用来在本地加载。如果直接设置该参数为指定服务器地址，目标会返回我们需要登陆到目标设备的权限的错误。作为测试，我们先通过IPC连接到目标设备，之后再通过我们的驱动添加调用，使远程目标设备从其本地的指定目录复制驱动文件到spool驱动目录并加载。
但这里有一个问题，这个操作仅仅是让目标服务器从本地磁盘复制并加载驱动，在此之前，我们还要使我们自己的驱动文件从攻击机设备的目录上分发到目标设备上。
这里就必须要求目标开启对应的集群后台打印处理程序，之后再次调用AddPrinterDriverExW修改标志为APD_COPY_TO_ALL_SPOOLERS，将本地的驱动文件分发到目标设备磁盘上。
远程加载驱动
最后，我这里并没有使用实际的集群打印服务器的环境。作为测试，我预先复制了驱动文件到目标服务器的指定路径。调用AddPrinterDriverExW使远程目标服务器完成了复制用户目录驱动文件到驱动目录并以system权限加载的过程。
思路验证视频：
漏洞总结
该漏洞的核心是允许普通用户绕过检查，将一个任意未签名dll复制到驱动目录并以系统管理员权限加载起来。而该漏洞可以达到远程触发的效果，则是由于集群打印服务间可以远程分发接收打印驱动文件的特性。
所以就目前的漏洞验证结果来看，该漏洞的危害似乎可能比他的漏洞原理表现出来的要影响更多一点。除了作为本地提权的利用方式之外，如果在一些内部隔离办公环境，启用了这种集群打印服务又没有及时更新系统补丁，该漏洞的作用还是比较有威胁性的。
对 PrintNightmare 0day POC的补充说明
通过最近一两天其他研究人员的证明，目前公开的cube0x0/PrintNightmare poc可以对最新的补丁起作用。鉴于此，我们后续验证了这个原因。
通过分析，补丁函数中对调用来源做了检查，查询当前调用者token失败时，会强制删除掉APD_INSTALL_WARNED_DRIVER(0x8000)的驱动添加标志。从而导致验证不通过。
但是，当我们从远程调用到这个接口，至少目前证实的通过IPC连接到目标后，这里的调用者已经继承了所需要的token，从而绕过检查。
从某种意义上讲，该漏洞修复方案只针对本地提权场景进行了限制，而没有考虑到远程调用对漏洞的影响。
参考
https://mp.weixin.qq.com/s/MjLPFuFJobkDxaIowvta7A
https://github.com/cube0x0/CVE-2021-1675
本文由 Seebug Paper 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/1699/