北京时间2020.03.11日，互联网中泄漏了关于CVE-2020-0796的相关信息。在此前的微软3月份例行补丁日更新中，无意中泄漏了该漏洞的存在。该漏洞影响组件为SMBv3，在Windows 10 1903和Windows Server 1903之后的版本中存在，影响范围较广。目前尚未发现可利用EXP，但已有crash的PoC，需要积极应对。此外，该漏洞具有蠕虫传播特性，可以轻松进行蠕虫传播，需要高度重视。

SMB，服务器消息块，是一个网络通信协议，用于提供共享访问到文件、打印机和串行端口的节点之间的网络上。它还提供了经过身份验证的进程间通信机制。SMB的大多数用法涉及运行Microsoft Windows的计算机，在引入Active Directory之前被称为“ Microsoft Windows网络” 。相应的Windows服务是用于服务器组件的LAN Manager服务器和用于客户端组件的LAN Manager工作站。

Windows 10和Windows Server 2016引入了SMB 3.1.1 。除了在SMB3中添加的AES-128 CCM加密外，该版本还支持AES-128 GCM加密，并使用SHA-512哈希实现预认证完整性检查。当使用SMB 2.x和更高版本连接到客户端时，SMB 3.1.1还添加了必须进行的安全协商步骤。

在SMBv3中，有一项数据压缩功能，可以通过SMB进行压缩数据的传输。此次漏洞触发点就位于压缩数据的过程中。

漏洞存在于srv2.sys文件中

该漏洞涉及到了多个函数：

这里主要看一下SMB2 COMPRESSION_TRANSFORM_HEADER结构：

首先，说明了结构使用的场景：客户端或服务器在发送压缩消息时使用SMB2 COMPRESSION_TRANSFORM_HEADER。此可选标头仅对SMB 3.1.1 dialect有效。

可以通过以下链接查看SMB 3.1.1 dialect

也就是说，在进行压缩数据传输时，底层使用的是SMB2的COMPRESSION_TRANSFORM_HEADER，但是会有SMB 3.1.1 dialect的验证特征。

然后，对以上各字段做简要说明：

CompressionAlgorithms字段中指定的算法：

Flags字段可选的固定值：

了解了以上数据结构，可以方便PoC构造和观察流量特征。

srv2.sys文件拖入IDA，先观察函数实现：

SMB首先调用srv2!Srv2ReceiveHandler函数接收数据包，并根据ProtocolId设置对应的处理函数：

如果判断数据包中为压缩的数据（ProtocolID = 0xfc4d5342），则调用处置函数--Srv2DecompressMessageAsync函数。

srv2!Srv2DecompressMessageAsync函数会继续调用 Srv2DecompressData函数：

Srv2DecompressMessageAsync函数并不是实际处理压缩数据的函数，而是继续调用了Srv2DecompressData函数，跟进查看Srv2DecompressData函数：

在Srv2DecompressData函数中可以看到数据处理的部分：在进行buffer分配时，会调用

SrvNetAllocateBuffer进行分配。但是在调用时，并未对OriginalCompressedSegmentSize和Offset/Length的长度进行任何检查，对二者相加的和也未进行安全检查。此处就存在一个整数溢出，如果二者的和为一个特别大的值，会超出内存存储范围，值会变成一个很小的值。

srv2!Srv2DecompressData函数调用SmbCompressionDecompress函数，进而调用nt!RtlDecompressBufferXpressLz函数进行实际的数据解压过程。nt!RtlDecompressBufferXpressLz函数位于ntoskrnl.exe中，该函数实际进行的处理就是：

由上面的代码可以看到在进行数据解压缩时，首先进行smb compress协议数据包的解析，获取其中包含的需要解压缩的数据的大小，并和之前通过SrvNetAllocateBuffer分配的buffer的OriginalCompressedSegmentSize值进行比较，确认其大小不大于OriginalCompressedSegmentSize，然后进行内存拷贝。若v21大于OriginalCompressedSegmentSize，则返回0xC0000242错误。因为在2中进行内存分配时没有做长度检查，所以如果传入一个很大的OriginalCompressedSegmentSize值触发整数溢出，此时v21就可以设置一个极大值，但可以通过对decompress size的判断，最终调用qmemcpy拷贝一个极大的size导致缓冲区溢出。

首先是靶机只是开机，未登录的状态：

直接执行PoC，可以成功执行：

正常登录后的执行，只是正常登录，并未进行任何文件或文件夹的共享设置：

同样可以造成蓝屏：

所以，不管存在漏洞的系统是否登录、是否开启了共享，都可以正常执行PoC。联想到EXP，只要可以获取到受影响系统的IP地址，即可进行漏洞攻击。

考虑到PoC尚未大范围传播，此处不放出完整代码，只对关键代码进行解释：

其中主要的是要OriginalCompressedSegmentSize + Offset/Length 可以产生溢出，所以这两个字段的值可以更改，最终使用的是两个字段的和。

主要是对Srv2DecompressData函数进行了更新，添加了一些数据长度的检查。

使用两个不同的PoC造成的蓝屏的流量截图如下：

设置Offset/Length字段为ffffffff

设置OriginalCompressedSegmentSize字段为ffffffff：

熟悉了漏洞原理后，可以在流量测进行防御，针对已公开的poc，可以比如使用Snort的byte_math关键字判断两个字段的和是否会发生整数溢出，发生了证明可能存在恶意流量。但目前来看，这种防御策略是可以被绕过的。

缓解措施：使用以下PowerShell命令禁用SMBv3压缩功能

使用下面的命令解禁用SMBv3压缩功能

考虑到该漏洞影响较广，且crash的PoC已经公开，强烈建议及时安装官方安全补丁，补丁链接如下：

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0618

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！