Smb

作者： k0shl 作者博客： http://whereisk0shl.top 前言 我是菜鸟，大牛轻喷…… 这个SMBv3漏洞是由lgandx爆出的一个未被微软修复的漏洞（暂未发布补丁），漏洞出来后我进行了一定的分析，花了很多时间，这个漏洞有一些意思，但是对于SMB的整个协议通信过程非常庞大，所以没有进行非常细致的跟踪，包括一些不透明的结构体让我感到晕头转向，但到最后还是有了一些结果。 这个SMB漏洞可以看作是被动的，需要用户主动去访问445端口才可以触发，而不像ms08067一样主动攻击别人，所以需要运行漏洞脚本在操作系统上。 终于赶在元宵节这天完成了这个任务，也在这里，祝大家元宵节快乐（不知道文章发布的时候过没过元宵节23333）！ 这个漏洞在twitter爆出来之后，很多老外也在微博下面问是否可以RCE，包括国内的预警中也有人问到。 http://bobao.360.cn/learning/detail/3451.html http://www.freebuf.com/vuls/126100.html 那么很多人看到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函数的处理逻辑，从而引发漏洞。 ...