SMBv3远程拒绝服务(BSOD)漏洞分析，这个SMBv3漏洞是由lgandx爆出的一个未被微软修复的漏洞(暂未发布补丁)，漏洞出来后我进行了一定的分析，花了很多时间，这个漏洞有一些意思，但是对于SMB的整个协议通信过程非常庞大，所以没有进行非常细致的跟踪，包括一些不透明的结构体让我感到晕头转向，但到最后还是有了一些结果。
Image may be NSFW.
Clik here to view.
这个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
Image may be NSFW.
Clik here to view.
接下来我们在kali2.0里运行漏洞脚本。
Image may be NSFW.
Clik here to view.
随后执行"dir \ip\PATH"，漏洞触发，通过windbg双机联调，此时捕捉到了BSOD。
Image may be NSFW.
Clik here to view.
可以看到提示此时问题出现在mrxsmb20.sys中，问题函数是Smb2ValidateNegotiateInfo，来看一下触发位置的代码。
kd> p
mrxsmb20!Smb2ValidateNegotiateInfo+0x17:
fffff803`1869c7d7 66394114 cmp word ptr [rcx+14h],axkd> r rcx
rcx=0x00000000`00000000
此时rcx的值为0x0，是一处无效地址，因此这是由于空指针引用导致的BSOD，接下来继续执行可以看到Windows 10引发蓝屏。
Image may be NSFW.
Clik here to view.
回溯及数据包分析(important!)
我们来看一下mrxsmb20.sys关于Tree Connect特性的一些内容，代码逻辑相对简单。
Image may be NSFW.
Clik here to view.
可以看到执行到Smb2ValidateNegotiateInfo函数有两条逻辑调用，一个是Smb2TreeConnect_CopyData，一个是Smb2TreeConnect_Receive，这里我就把我回溯的结果和大家分享一下，首先，通过Smb2TreeConnect_Receive来接收smb的Tree Connect数据，这个是通过opcode来决定的。
正常情况下不会进入Smb2TreeConnect_CopyData，但一旦由不正常(后面会提到)数据包执行，则会在Receive之后进入CopyData函数的处理逻辑，从而引发漏洞。
这里数据包分析很关键，因为在漏洞触发过程中，就是由于数据包的问题导致的。