Windows Print Spooler服务最新漏洞CVE-2021-34527详解

本文阅读 5 分钟
首页 Linux,系统 正文

.text:0000000180085F64 loc_180085F64: ; CODE XREF: SplAddPrinterDriverEx+98↑j .text:0000000180085F64 ; SplAddPrinterDriverEx+BE↑j .text:0000000180085F64 and [rsp+58h+var_20], 0 .text:0000000180085F6A mov r9d, esi .text:0000000180085F6D mov eax, [rsp+58h+arg_28] .text:0000000180085F74 mov r8, r14 .text:0000000180085F77 mov [rsp+58h+var_28], ebx .text:0000000180085F7B mov edx, r15d .text:0000000180085F7E mov [rsp+58h+var_30], eax .text:0000000180085F82 mov rcx, rdi .text:0000000180085F85 mov [rsp+58h+var_38], rbp .text:0000000180085F8A call InternalAddPrinterDriverEx

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29

其中esi为dwFileCopyFlags,是一个调用者可控的参数,bt esi,0xf将esi中偏移0xf的比特位保存到CF标志位,即CF标志位与esi的0x10比特位相同,dwFileCopyFlags=0x8014时CF=1。cmovnb ebx, [rsp+58h+arg_30]即mov if not below,cmovnb会检测CF标志位是否为0且当CF为0时进行移位操作,此时[rsp+0x90]=1,CF=1不会将ebx赋值为1。调试现场如下

img

由于ebx=0,jz short loc_180085F64会跳转到InternalAddPrinterDriverEx处执行后续复制并加载驱动的操作,跳过了0x180085F57处ValidateObjectAccess的检测。

调用到localspl!SplAddPrinterDriverEx时的栈回溯如下

0:009> k

Child-SP RetAddr Call Site

00 0000001f7f83e938 00007ffcfb225852 localspl!SplAddPrinterDriverEx

01 0000001f7f83e940 00007ff66c23ba9f localspl!LocalAddPrinterDriverEx+0xa2

02 0000001f7f83e990 00007ff66c215ffe spoolsv!AddPrinterDriverExW+0x6f

03 0000001f7f83e9d0 00007ff66c212c71 spoolsv!YAddPrinterDriverEx+0x2ce

04 0000001f7f83ea10 00007ffd027184a3 spoolsv!RpcAddPrinterDriverEx+0x181

2021-6的补丁中在spoolsv!RpcAddPrinterDriverEx中调用YAddPrinterDriverEx加载驱动前加了几处校验,如下右为补丁后的spoolsv.exe。补丁后YIsElevated、RunningAsLUA分别校验了当前用户的token和LUA权限,这两处校验在RCE中可以通过IPC被绕过;YIsElevationRequired检验了HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindows NTPrintersPointAndPrintNoWarningNoElevationOnInstall的注册表项,但是笔者在2021-6全补丁的Windows server和Windows10系统上均未发现有该注册表项,所以这个缓解在目前来看也是无效的。(这两处缓解可能是针对Yunhai Zhang和ZhiPeng Huo提供的CVE-2021-1675的poc)

img

随后由于spoolsv!AddPrinterDriverExW调用到localspl!LocalAddPrinterDriverEx处的回调,又由于上述分析的localspl!SplAddPrinterDriverEx中验证无效进入localspl!InternalAddPrinterDriverEx的流程。

localspl!InternalAddPrinterDriverEx主要进行了如下操作,其中%spooler%=C:WindowsSystem32spool\

1.ValidateDriverInfo进行驱动签名等的检查

2.CreateInternalDriverFileArray创建spooler目录下的驱动文件,即%spooler%driversx64

3.GetPrintDriverVersion、CheckFilePlatform检查驱动版本和驱动运行平台

4.SplIsCompatibleDriver进行驱动版本和驱动兼容性检查,驱动版本号只能为3

5.CreateVersionDirectory使用提供的驱动版本号,创建spooler目录下驱动版本号目录,由于驱动版本号只能为3,最终目录为%spooler%driversx643

6.CopyFilesToFinalDirectory创建%spooler%3目录下New、Old文件夹,创建New、Old目录下的临时目录,如%spooler%driversx643Old1、%spooler%driversx643Old2;并将上传的驱动移动到临时目录下

7.WaitRequiredForDriverUnload加载6中临时目录下的驱动,路径如%spooler%driversx643old1xx.dll

localspl!ValidateDriverInfo在如下代码会校验加载驱动的签名,可以使用0x8000的dwFileCopyFlags绕过,0x8000即RpcAddPrinterDriverEx 的API文档中提到的APD_INSTALL_WARNED_DRIVER,翻译过来即强制加载驱动。

img

localspl!CreateInternalDriverFileArray中会使用如下代码根据RpcAddPrinterDriverEx 的dwFileCopyFlags参数生成CreateFile的参数,a5=1会使用%spooler%目录下路径做为CreateFile的参数;RCE利用时我们上传的驱动此时是在一个UNC路径下,如笔者本地为\192.168.18.153sharerev.dll,所以这里需要构造dwFileCopyFlags&0x10=1使spooler使用我们的UNC路径。

img

其中a5参数从localspl!LocalAddPrinterDriverEx这里传入,

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IYu2mThc-1625827565106)(data:image/gif;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQImWNgYGBgAAAABQABh6FO1AAAAABJRU5ErkJggg==)]

img

其中v117会在localspl!InternalAddPrinterDriverEx这里校验两次,v117==2和v117>3都会导致驱动加载失败。

img

localspl!SplIsCompatibleDriver检查驱动兼容性时会调用到ntprint!PSetupIsCompatibleDriver,最终会调用到如下代码,其中a6=v117为驱动版本号,当v117<=2时返回0会导致驱动加载失败。

img

综上,当v117==2、v117>3、v117<=2时均会最终导致驱动加载失败,v117只能为3。

img

最终在localspl!CompleteDriverUpgrade里更新所加载驱动的信息并加载上述临时目录下的驱动。

据Zhiniang Peng (@edwardzpeng) & Xuefeng Li (@lxf02942370)在最初公开的exp README里描述,spooler的漏洞最初用于10年前的震网(Stuxnet)攻击,10年间spooler模块也被披露了许多漏洞,但不知是因为微软补丁修复的不彻底还是spooler模块本身实现起来的复杂性导致了CVE-2021-1675和CVE-2021-34527的出现。微软已于2021.7.7发布了一个紧急安全更新补丁,希望微软的这个补丁能使spooler更安全一些吧;p

https://github.com/cube0x0/CVE-2021-1675

https://github.com/afwu/PrintNightmare

天融信阿尔法实验室成立于2011年,一直以来,阿尔法实验室秉承“攻防一体”的理念,汇聚众多专业技术研究人员,从事攻防技术研究,在安全领域前瞻性技术研究方向上不断前行。作为天融信的安全产品和服务支撑团队,阿尔法实验室精湛的专业技术水平、丰富的排异经验,为天融信产品的研发和升级、承担国家重大安全项目和客户服务提供强有力的技术支撑。

img

img

天融信

阿尔法实验室

长按二维码关注我们

转载自https://mp.weixin.qq.com/s/8qDQUu6FNpNjX1tY1KrAoQ

</article>
本文为互联网自动采集或经作者授权后发布,本文观点不代表立场,若侵权下架请联系我们删帖处理!文章出自:https://blog.csdn.net/wangyuxiang946/article/details/121437530
-- 展开阅读全文 --
Redis底层数据结构--跳跃表
« 上一篇 04-28
BUUCTF Web [强网杯 2019]随便注
下一篇 » 06-24

发表评论

成为第一个评论的人

热门文章

标签TAG

最近回复