当Windows后台智能传输服务(BITS)处理符号链接不当时,存在特权漏洞提升,即"Windows后台智能传输服务特权漏洞提升"。表现和烂土豆类似(ms16-075),都是令牌窃取,本质上是任意文件移动漏洞
NVD评分
![de3b30a508f9cc2995671d9768cb71d6.png](https://i-blog.csdnimg.cn/blog_migrate/d84d22bdd3251f90441fcd461ce8f98c.jpeg)
原理简介
原理涉及到逆向的知识,Background Intelligent Transfer Service(BITS,后台智能传输服务)
什么是bits?
程序员及系统管理人员可以使用BITS来下载文件,或者将文件上传至HTTP Web服务器及SMB文件共享。BITS在传输过程中会权衡传输成本以及网络使用情况,尽可能少影响用户前台工作。即使主机重启,BITS也可以处理网络中断、暂停并自动恢复传输。
![816213f196fa0fd768b4a5a03b6b28a6.png](https://i-blog.csdnimg.cn/blog_migrate/1caffffba486d5994ea0643301ba1e3d.jpeg)
该服务提供了多个COM对象,包括多个不同的"Control Class"(控制类)以及一个"Legacy Control Class"(旧版控制类),后者可以用来获取指向旧版IBackgroundCopyGroup接口的指针,该接口包含2个未公开的方法:QueryNewJobInterface()及SetNotificationPointer()。
如果用户调用IBackgroundCopyGroup接口(即旧版接口)的CreateJob()方法,就能得到指向旧版IBackgroundCopyJob1接口的一个指针。如果用户调用同一个接口的QueryNewJobInterface()方法,就能得到指向新IBackgroundCopyJob接口的一个指针。
这里的问题在于,目标服务在处理该调用时,并没有采用模拟(impersonation)方式。这意味着用户得到的IBackgroundCopyJob接口的指针位于NT AUTHORITYSYSTEM上下文中。目标服务在其他方法中实现了模拟。
当创建传输任务、文件被添加到队列中时,服务也会创建一个临时文件。当服务完成文件写入操作后,就会调用MoveFileEx()将该文件重命名为用户指定的文件名。这里的问题在于,当使用QueryNewJobInterface()返回接口指针时,最后执行的操作并没有采用模拟机制。
因此普通用户可以利用这一点,通过挂载点(mountpoint)、机会锁(oploick)及符号链接将任意文件移动到受限区域。服务不再模拟当前用户身份,着意味着文件移动操作会在NT AUTHORITYSYSTEM的上下文中执行。
以SYSTEM权限执行任意文件移动操作将导致本地提权(LPE)问题。普通用户可以将精心构造的一个DLL移动到System32目录,就有可能在NT AUTHORITYSYSTEM上下文中执行任意代码
具体分析可以跳到 https://itm4n.github.io/cve-2020-0787-windows-bits-eop/
然后是大家最关心的exp部分
github上已经有exp,不过是desktop形式的
链接地址:https://github.com/cbwang505/CVE-2020-0787-EXP-ALL-WINDOWS-VERSION
利用的话直接点开就好了
exp使用了任意的文件移动漏洞来在System32文件夹中创建WindowsCoreDeviceInfo.dll文件。然后,利用更新会话编排服务将DLL加载为系统权限。
提权成功会出现system权限的cmd如下图
![a7c3ab2b8ee8e4d74f41db6b51686841.png](https://i-blog.csdnimg.cn/blog_migrate/20214852f31c77a9cbc1366eb7680336.jpeg)
失败则是这样
![57489715a5d3d2eb930cd93ee26e098b.png](https://i-blog.csdnimg.cn/blog_migrate/dd554b328c0f2045468fb3cb4be1eb69.jpeg)
总得来说,这是个不错的提权漏洞,因为是全版本的,所以个人认为将会有"烂土豆"般的历史地位