2345内核拒绝服务漏洞（1）

2018-07-08

概述

已经快2个月了吧，已经忘了是什么原因突然搞起了驱动漏洞，反正就是很有兴致地想挖掘一下驱动漏洞。

在网上了解了基本的驱动漏洞挖掘方法，主要是通过ioctl接口进行挖掘，已经有很多相关fuzz工具了，比如ioctlbf、kDriver-Fuzzer等等。

kDriver-Fuzzer的作者k0keoyo在2017年收获了100多个CVE，很牛逼啊，这个已经2018年了，再来挖此种类型的驱动是不是已经晚了啊，心中苦涩啊。

不过毕竟也写了几年驱动程序了，不搞搞怎么也说不过去啊，所以开始干！

初学者嘛，还是找软柿子捏捏，什么微软、卡巴、小红伞、360、管家先还是别想了，很巧的知道了2345安全软件（此处想笑，毕竟为我贡献了不少…），先啥也不管，IDA一番…

很不幸的，没多久2345就被我弄翻了，嗯，听说该公司年代也挺久了，咋这么…

经过俩周手工和工具的连番蹂躏，发现2345安全软件驱动共10多个内核拒绝服务漏洞（某些也许可提权），也第一次感受到了拿CVE的感觉（其实怎么感觉都有点waterwater的）…

好，前言胡扯差不多就到这里了，本系列将拿2345中几个典型的原因造成的安全漏洞进行一番分析，希望对和我一样的初学者有一定帮助。

哦，当然，在连番联系2345客服催促之后，2345终于修复了所有漏洞，所以我才等到这个时候分享文章，分析一些细节应该对他们没什么影响了吧（不过，我可没有所有的都重新验证一遍，申明一下，大家不要拿来干坏事，出事了我概不负责！）

漏洞概况

软件网址：http://safe.2345.cc/
版本：v3.7 X86

2345安全软件的驱动2345NetFirewall.sys在ioctl(0x00222014)接口处理中，对输入数据校验不严格，可构造数据中包含非法地址导致访问违例，然后bsod拒绝服务。

漏洞分析

在IRP_MJ_DEVICE_CONTROL处理函数中，对0x222014接口进行处理时如下所示：

InputBuf是应用层传入的输入缓存内容，校验InputBuf是否为空，长度是否超过8字节，然后在memcpy位置直接取InputBuf第一个字段(0偏移)作为目标地址拷贝内容进去，这里未校验第一个字段值作为内存地址的合法性。

看到这里是不是有什么邪恶的想法了，把该字段置0，那么memcpy(0, xx, xx)不就bsod了。嗯，有点想多了，2345还是受过一些伤害做过一些自我修复的。

看下面，该段代码有异常处理保护，so，0地址bsod不成了（确认该处在3.6版本时被人法克了的，所以补了一下）。

既然0不行，那么其他地址还是可以的嘛，比如某些内核地址0x80000000，或者nt!HalDispatchTable（某些提权方式使用的地址）。

用下面的poc代码尝试了一下，bsod！

ctlcode = 0x222014;
NETFW_IOCTL_222014 buf_222014 = {0};
buf_222014.size = 1;
buf_222014.ptr = (DWORD*)0x80000000; //非法内核地址
if(!DeviceIoControl(h, ctlcode, &buf_222014, sizeof(NETFW_IOCTL_222014), &buf_222014, sizeof(NETFW_IOCTL_222014), &BytesReturned, NULL)) {
	printf("[-] DeviceIoControl %x error: %d\n", ctlcode, GetLastError());
}

kd> dd 80000000
80000000  ???????? ???????? ???????? ????????
80000010  ???????? ???????? ???????? ????????

至此，该内核拒绝服务漏洞验证成功，替换未其他内核地址还是有希望提权的，这里不在深入研究。

结语

看完整篇，其实知道该漏洞真的很明显，很弱B是吧。但是基于某些原因（门槛？漏洞价值？），内核驱动这方面受到的关注较少，所以被虐的少了，开发人员重视程度也不够，所以对于参数的校验上就没那么认真严谨了！所以留下了这种弱X的洞洞被我捡漏。

当然，前面提到2345在3.6版本中已经被人干过，所以还是做了一定的工作的，除了加入了异常保护代码，对于ioctl接口调用也加入了一定的限制和校验。所以poc不是直接就调用接口就成功触发bsod的，而做了一定的前期工作来应对2345做的限制和保护。

这里不是重点，大致讲一下。在IRP_MJ_DEVICE_CONTROL处理函数中，首先会校验调用接口的进程是否在缓存的白名单进程中，但是呢2345又提供了ioctl接口来添加进程到白名单中，对该接口也没做什么其他的校验，所以很随意的调用成功，把自己的poc进程加入了白名单中，然后再调用漏洞接口触发bsod，完成！

另外，如果有兴趣也研究一些驱动此类漏洞的，并且对驱动编程不是很了解的，建议可以先简单学习一下简单驱动编写模板、ring3和ring0通信方式、驱动设备等等内容，推荐可以看看《Windows驱动开发技术详解》相关章节内容。

该系列后续会继续分析其他原因引起的漏洞，如有兴趣，敬请期待！

转载请注明出处：https://anhkgg.github.io/vul-2345-1/