FavoriteLoading
0

SMBv3远程拒绝服务(BSOD)漏洞分析


前言
我是菜鸟,大牛轻喷。
这个SMBv3漏洞是由lgandx爆出的一个未被微软修复的漏洞(暂未发布补丁),漏洞出来后我进行了一定的分析,花了很多时间,这个漏洞有一些意思,但是对于SMB的整个协议通信过程非常庞大,所以没有进行非常细致的跟踪,包括一些不透明的结构体让我感到晕头转向,但到最后还是有了一些结果。
这个SMB漏洞可以看作是被动的,需要用户主动去访问445端口才可以触发,而不像ms08067一样主动攻击别人,所以需要运行漏洞脚本在系统上。
终于赶在元宵节这天完成了这个任务,也在这里,祝大家元宵节快乐!
这个漏洞在twitter爆出来之后,很多老外也在微博下面问是否可以RCE,包括国内的预警中也有人问到。
那么很多人看到PoC中的关键部分,就会想:有填充数据,会不会是缓冲区溢出!
## Tree Connect
if data[16:18] == "\x03\x00":
head = SMBv2Header(Cmd="\x03\x00", MessageId=GrabMessageID(data), PID="\xff\xfe\x00\x00", TID="\x01\x00\x00\x00", CreditCharge=GrabCreditCharged(data), Credits=GrabCreditRequested(data), NTStatus="\x00\x00\x00\x00", SessionID=GrabSessionID(data))
t = SMB2TreeData(Data="C"*1500)#//BUG
packet1 = str(head)+str(t)
buffer1 = longueur(packet1)+packet1
print "[*]Triggering Bug; Tree Connect SMBv2 packet sent."
self.request.send(buffer1)
data = self.request.recv(1024)
答案是否定的,至少在我看来,大量的数据目的并非是为了填充缓冲区,而是为了绕过tcpip.sys的某处判断,从而进入漏洞出发的函数调用逻辑。
问题出现在smbv2后的一个特性Tree Connect,用来处理共享服务的特性,opcode:0x03,而整个问题,确是多个地方导致的。下面我们就一起来进入今天的旅程吧!
Github地址:https://github.com/lgandx/PoC/tree/master/SMBv3%20Tree%20Connect
漏洞复现
首先,网上关于这个漏洞的触发方法有很多,比较通用的是twitter中某老外提到的Powershell的方法,最为简单,首先我们调试的环境是:Windows 10 x64 build 1607

接下来我们在kali2.0里运行漏洞脚本。

随后执行"dir \ip\PATH",漏洞触发,通过windbg双机联调,此时捕捉到了BSOD。

可以看到提示此时问题出现在mrxsmb20.sys中,问题函数是Smb2ValidateNegotiateInfo,来看一下触发位置的代码。
kd> p
mrxsmb20!Smb2ValidateNegotiateInfo+0x17:
fffff803`1869c7d7 66394114        cmp     word ptr [rcx+14h],ax
kd> r rcx
rcx=0x00000000`00000000
此时rcx的值为0x0,是一处无效地址,因此这是由于空指针引用导致的BSOD,接下来继续执行可以看到Windows 10引发蓝屏。

回溯及数据包分析(important!)
我们来看一下mrxsmb20.sys关于Tree Connect特性的一些内容,代码逻辑相对简单。

可以看到执行到Smb2ValidateNegotiateInfo函数有两条逻辑调用,一个是Smb2TreeConnect_CopyData,一个是Smb2TreeConnect_Receive,这里我就把我回溯的结果和大家分享一下,首先,通过Smb2TreeConnect_Receive来接收smb的Tree Connect数据,这个是通过opcode来决定的。
正常情况下不会进入Smb2TreeConnect_CopyData,但一旦由不正常(后面会提到)数据包执行,则会在Receive之后进入CopyData函数的处理逻辑,从而引发漏洞。
这里数据包分析很关键,因为在漏洞触发过程中,就是由于数据包的问题导致的。
来看一下Smb最关键的这个数据包。

来看一下Smb头部的协议格式。

在协议格式中Opcode指示smb类型

注意数据包中对应位置,opcode值是0x03,就是tree connect的处理。同时这里在后面分析中我们要用到,注意Data数据之前的长度。其中包含了NetBIOS Session Service 4字节,和 SMB2 Header + Tree Connect Body 80字节,以及 Data n字节。这个非常重要,后续分析我们会用到。

分页阅读: 1 2 3 4 5
【声明】:8090安全小组门户(http://www.8090-sec.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱hack@ddos.kim,我们会在最短的时间内进行处理。