从危害角度来说，攻击者可以使用普通用户认证，以管理员权限远程执行任意代码。 就漏洞利用难度而言，该漏洞非常容易利用，因此危害极大。

从漏洞特征来说，34527 漏洞基于漏洞 CVE-2021-1675。 而 1675 漏洞是一个本地提权和远程代码执行漏洞，它和 34527 漏洞有着非常相似的地方。

在了解漏洞的工作原理之前，我们应该对 Windows 打印后台处理程序的体系架构有个大致的了解，这样能够方便我们理清漏洞涉及的各个模块之间的关系。

== CVE-2021-1675 调用流程

=== Windows 打印后台处理程序体系架构

spooler 体系架构可以用 <<spooler_arch>> 来表示：

[[spooler_arch]] .Print Spooler Architecture image::Print Spooler Architecture.png[]

具体来说，后台打印程序用于管理打印任务，它由以下部件组成：

winspool.drv:: 提供给用户的动态链接库文件。 该文件定义了 spooler 相关的 Win32 API 供用户调用。 里面的 API 均采用远程过程调用的形式来获取服务。

spoolsv.exe:: spoolsv.exe 担当体系中服务器的角色，作为第一个处理 API 调用的程序。 如此设计是为了让 print spooler 既能处理本地打印作业，又能无差别处理远程打印作业。

spoolsv.dll:: 路由程序。 它将 spoolsv.exe 接收的打印请求，向各个打印提供程序发起，并决定由哪个打印提供程序最终处理该请求。 它的作用就是区分打印任务是远程任务还是本地任务。 在远程机器上它就会将任务固定分配给本地打印提供程序。

localspl.dll:: 本地打印提供程序。 打印提供程序主要任务是解决打印任务管理的需求，绝大多数的 API 都是在这个模块内实现的。

根据上述理论来继续研究，举个例子，当我调用 AddPrinterDriverEx 函数时（CVE-2021-1675），会经过以下流程：

=== 函数版本选择

首先该函数实际上是个宏，会根据本地的编译环境选择 Unicode 版本（W）或 Ansi 版本（A），如 <>：

[[AddPrinterDriverEx]] .AddPrinterDriverEx image::AddPrinterDriverEx.png[]

但不管是宽字符还是窄字符版本，其实结果都没差，因为 Windows 内核的字符串是使用 Unicode 编码的，所以最终 Ansi 版本的调用都会转换成 Unicode 版本的调用，如 <>：

[[AnsiToUnicode]] .AnsiToUnicode image::AnsiToUnicode.png[]

当 Ansi 函数的参数均转换成 Unicode 版本后，就调用了一个函数（<>）：

[[AnsiCallUnicode]] .AnsiCallUnicode image::AnsiCallUnicode.png[]

而该函数实际上就是 Unicode 版本的 AddPrinterDriverEx（<>）：

[[GetUnicodeProcAddress]] .GetUnicodeProcAddress image::GetUnicodeProcAddress.png[]

=== API 函数发送 RPC 请求到 spooler 服务器上

进入 Unicode 版本的函数内部后，首先会根据 Level 的数值对函数参数类型做一个选择：

image::pDriverInfo.png[]

该漏洞中我们会设置 Level 为 2，也就是选择参数 pDriverInfo 的类型为 DRIVER_INFO_2 结构体。 然后接下来 Windows 就会对函数参数做一个处理，处理完成后会通过远程过程调用继续处理该 API：

image::set arguments.png[]

image::NdrClientCall3.png[]

=== MSRPC 机制

微软的远程过程调用机制基于 DCE 标准进行构建。 通俗来解释，远程过程调用就是在远程系统上运行进程，这些进程都是程序员或者系统预先定义好的。

RPC 的具体做法就是将想要远程调用的函数序列化，通过网络将它传送至远程系统上，远程系统再将之反序列化，并执行之。 在微软构建的体系中，TCP/IP 和 SMB 是通常被选择来传输 RPC 调用的协议。

想要使用 MSRPC，首先得定义调用的函数的 IDL 接口描述，然后使用 MIDL 工具生成客户端和服务端相应的序列化程序 stub。 而对一些 Win32 API 来说，它本身就定义好了服务端 stub，我们就可以只生成并使用客户端 stub 就够了。

MSRPC 使用 UUID 来标识某一类型的协议，如 MS-RPRN 就用来描述远程打印协议，所有跟远程打印相关的函数均属于该协议的一部分，MSPRC 使用 UUID 12345678-1234-ABCD-EF00-0123456789AB 来标识该协议（<<rprn_uuid>>）：

[[rprn_uuid]] .MS-RPRN UUID image::spoolss uuid.png[]

接着，可以继续在此连接基础上，使用 operator number 来标识协议内的函数，以此来远程调用，比如 AddPrinterDriverEx 就是使用 89 来标识自己（<<addPrinterDriverEx_opnum>>）：

[[addPrinterDriverEx_opnum]] .AddPrinterDriverEx Opnum image::AddPrinterDriverEx Opnum.png[]

在使用 MSRPC 的过程中，有两点需要值得注意：

[IMPORTANT]

• TCP/IP 连接使用的是动态端口，需要通过监听在 135 端口的 endpoint mapper 来获取到端口值。

"As you can see in your output, the scripts are trying to connect to port 135 (endpoint mapper) in order to get the TCP/IP port where the DCOM endpoint is listening (that is a dynamic port)." -- SecureAuthCorp/impacket issue #412

• 另外，一些 RPC 函数需要认证才能调用，因此本漏洞需要一个普通用户权限。 ====

=== spoolsv.exe 处理 API 请求

[[call_flow]] .RpcAddPrinterDriverEx Call Flow image::Function Calls.png[]

从 <<call_flow>> 中可以看出，spoolsv.exe 会调用这些函数，而从函数内部分析来看，该模块内除了初始化外并没有完成什么操作。 最后，该模块会调用 pLocalProvidor 指向的函数，也就是 localspl.dll 模块内的函数 LocalAddPrinterDriverEx。 localspl 作为一个本地打印提供程序，确实是实现 API 功能的模块。

=== 本地打印提供程序的函数实现逻辑

[[LocalAddPrinterDriverEx]] .LocalAddPrinterDriverEx image::LocalAddPrinterDriverEx.png[]

首先 <> 说明了该模块会验证 spooler 是否正常运行，然后就跳转到函数 SplAddPrinterDriverEx。

[[SplAddPrinterDriverEx]] .SplAddPrinterDriverEx image::SplAddPrinterDriverEx.png[]

<> 函数内部是判断 AddPrinterDriverEx 函数能否执行成功的重要位置。 前半部分不用看，因为 WPP 是跟日志相关的技术，暂且跳过。

后半部分微软定义了一个变量 v12，是个标志位来判断函数是继续执行还是直接退出。

[[bittest]] .bittest dwFileCopyFlags image::bittest in spl.png[]

从 <> 可以看出，继续执行的条件有两种：一是 v12 为 0 也就是 bittest 判断成功，二是 Validate 成功。 而 Validate 是对权限的校验，没有办法很好地绕过。 里面有一个 API 是 OpenProcessToken，表示需要在接下来的进程中提升权限，如果不是管理员身份是做不到这点的。

所以想要继续执行就只能绕过 bittest 的判断了，而被判断的数 a4——函数的第 4 个参数，就是在官网中有着说明的参数 <> ：