微软“WebDAV”提权漏洞（cve-2016-0051）初探
*原创作者：gongmo（聚锋实验室）
注意：本分析一切结果均在win7 x86 sp1中尝试。
1.关于cve-2016-0051
在微软的官方描述中如下：
如果 Microsoft Web 分布式创作和版本管理 (WebDAV) 客户端验证输入不当，那么其中就会存在特权提升漏洞。成功利用此漏洞的攻击者可以使用提升的特权执行任意代码。
若要利用此漏洞，攻击者首先必须登录系统。然后，攻击者可以运行一个为利用此漏洞而经特殊设计的应用程序，从而控制受影响的系统。
工作站和服务器最易受此攻击威胁。此安全更新程序通过更正 WebDAV 验证输入的方式来修复这个漏洞。
通过微软的介绍，此漏洞是一个限定系统的提权漏洞，因为此漏洞在win8或者更高的系统上是触发BSOD，而在win7及以下的系统中才能提权成功。所以微软设定此漏洞的安全等级为：中。虽然如此，我们还是应该引起重视，毕竟，可以获得管理员权限的漏洞危害性依然很大。
本文通过基础性的研究，大概的探究下了漏洞的修补前后和执行的过程，供大家参考。
2.分析验证
在2016年2月9日发布的补丁中，微软修复了此问题。补丁名称为：Windows6.1-KB3124280-x86。后来通过对比这个补丁前后，发现微软在mrxdav.sys中增添了MRxDavIsCallerPrivileged函数并且修改了DAVFastIoDeviceControl和DAVDevFcbXXXControlfile的执行过程。
下图是对比补丁前后marxdav.sys执行的过程图。（红框为补丁版本）
1 ）MRxDavIsCallerPrivileged函数主要通过调用SeAccessCheck函数验证进程的访问权限进行作用。这样任何通过fastio分发的函数和文件控制块控制的文件，都需要经过权限的验证，是否有足够的管理员权限执行，如若没有，则MRxDavIsCallerPrivileged函数返回false,然后调用失败的路线。
2 ）其次在调用的历程函数中，MrxDAVEfsControl函数增加了对传入的device_object是否为null的验证。见下图红框所示缩略图：
放大图如下：
根据IDA的分析：
上图是补丁中通过验证MRX_SRV_OPEN+0×18对象结构体否为空，若不是NULL；则验证其MRX_SRV_OPEN+0×18+0xC对象，若文件对象正常，则验证其设备对象。如若出现一个为NULL；则转入失败，最后调用RxReleaseFcbResourceInMRx释放MrxFCB。
从整个函数推导来看：传入iofcalldriver函数的device_object来自：
Device_object=rx_context+0×38+0×18+0×10 （win7 sp1x86系统）
由于windbg中并没有找到此结构体，但是在windws driver kits中发现了此结构，在rxcontx.h头文件中，我们可以看到rx_context的结构体；以下是个人推导（仅对win7 sp1 x86来讲）：
MRX_SRV_OPEN=rx_context+0×38;
MRX_FCB=MRX_SRV_OPEN+0×10;
暂用AAA表示此结构= MRX_SRV_OPEN+0×18;
DEVICE_OBJECT=AAA+0×10;
猜测为FILE_OBJECT=AAA+0x0C
通过windbg；我们查看到验证判断的过程device_object的过程;esi的值为rx_context结构体。 MRX_SRV_OPEN是bc4381f8；结构AAA为：9920f508；如下图：请依次对应。
验证判断过程如下图所示：首先去验证AAA结构是否为空，然后依次验证AAA+0x0C;最后验证AAA+0×10,即为： DEVICE_OBJECT。
3.关于漏洞程序
在微软公布修补补丁的同时，黑客大神koczkatamas公布了漏洞源码程序。
漏洞原理：
在rdbss调用mrxdav的时候，利用rdbss!RxCreateRxContext创建了一个rx_context结构体的参数，而结构体rx_context默认的一个device_object对象初始化是null。而在内存中，null可以为0×00000000；所以只要作者精心构造一个以地址0×00000000为开头的device_object结构体，填充好MajorFunction对应函数的地址（用户的函数地址）。但是想要执行，还是需要调用IoCallDriver分发函数，而想调用到IoCallDriver分发函数，作者这里使用了NtFsControlFile作为触发进入mrxdav!MrxDAVEfsControl的条件从而调用到IoCallDriver。
所以在作者公布的源码中，申请了一块以0×00000000开头的内存；并且通过Marshal.Copy函数填写完整了device_object的结构体。如下图：
通过windbg；我们可以看到71c91150处就是shellcode的地址了。也是需要执行的地方。如下图：
例如：原函数IofCallDriver执行方式为：
driverObject->MajorFunction[irpSp->MajorFunction](DeviceObject,Irp );修改后的函数执行为：
driverObject->shellcode(DeviceObject,Irp );下图红框就是执行r3程序的地方。（调试的次数不一样，执行shellcode的函数地址也不同,下图shellcode的地址是：6ae91150。）这样，就从内核执行了任意r3的函数，成功将系统的Token赋值给应用程序eprocess的Token，达到提权的目的。
4.总结
通过初步漏洞分析，才发现windows的博大精深。本漏洞没有通过覆盖，溢出等方法寻找突破点，而是利用了内存中NULL可以理解为0×00000000的方式，去构造漏洞。同时应对漏洞问题时候，如何以最小的改动来换取最大的安全。微软做的这点值得我们去学习思考。
*原创作者： gongmo（聚锋实验室），转载请注明来自FreeBuf黑客与极客（FreeBuf.COM）
正文到此结束
热门推荐
相关文章
近期评论
-
666
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
