微软SMBv3 Client/Server远程代码执行漏洞分析(CVE-2020-0796)
微软SMBv3 Client/Server远程代码执行漏洞分析(CVE-2020-0796)
前言
北京时间2020.03.11日,互联网中泄漏了关于CVE-2020-0796的相关信息。在此前的微软3月份例行补丁日更新中,无意中泄漏了该漏洞的存在。该漏洞影响组件为SMBv3,在Windows 10 1903和Windows Server 1903之后的版本中存在,影响范围较广。目前尚未发现可利用EXP,但已有crash的PoC,需要积极应对。此外,该漏洞具有蠕虫传播特性,可以轻松进行蠕虫传播,需要高度重视。
一、SMBv3组件介绍
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进行压缩数据的传输。此次漏洞触发点就位于压缩数据的过程中。
二、漏洞信息和描述
1. 漏洞文件
漏洞存在于srv2.sys文件中
2. 漏洞函数
该漏洞涉及到了多个函数:
Srv2DecompressMessageAsync
Srv2DecompressData
Smb2GetHonorCompressionAlgOrder
Smb2SelectCompressionAlgorithm
Smb2ValidateCompressionCapabilities
三、漏洞分析
1. 基础数据结构
这里主要看一下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的验证特征。
然后,对以上各字段做简要说明:
字段 | 含义 |
---|---|
ProtocolId (4 bytes) | 协议标识符。该值必须设置为0x424D53FC,也以网络顺序表示为0xFC,“ S”,“ M”和“ B”。 |
OriginalCompressedSegmentSize (4 bytes) | 未压缩数据段的大小(以字节为单位)。 |
CompressionAlgorithm (2 bytes) | 此字段务必包含CompressionAlgorithms字段中指定的用于压缩SMB2消息的算法之一,“ NONE”除外。 |
Flags (2 bytes) | 必须为2个特定值之一 |
Offset/Length (4 bytes) | 如果在Flags字段中设置了SMB2_COMPRESSION_FLAG_CHAINED,则该字段必须解释为长度,压缩有效payload的长度(以字节为单位);否则,该字段必须解释为偏移。 从此结构的末尾到压缩数据段开始的偏移量(以字节为单位)。 |
CompressionAlgorithms字段中指定的算法:
Flags字段可选的固定值:
了解了以上数据结构,可以方便PoC构造和观察流量特征。
2. 静态分析
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导致缓冲区溢出。
3. crash的PoC复现
首先是靶机只是开机,未登录的状态:
直接执行PoC,可以成功执行:
正常登录后的执行,只是正常登录,并未进行任何文件或文件夹的共享设置:
同样可以造成蓝屏:
所以,不管存在漏洞的系统是否登录、是否开启了共享,都可以正常执行PoC。联想到EXP,只要可以获取到受影响系统的IP地址,即可进行漏洞攻击。
4. PoC代码分析
考虑到PoC尚未大范围传播,此处不放出完整代码,只对关键代码进行解释:
|
|
其中主要的是要OriginalCompressedSegmentSize + Offset/Length 可以产生溢出,所以这两个字段的值可以更改,最终使用的是两个字段的和。
5. 更新后的srv2.sys文件
主要是对Srv2DecompressData函数进行了更新,添加了一些数据长度的检查。
6. 流量分析
使用两个不同的PoC造成的蓝屏的流量截图如下:
-
设置Offset/Length字段为ffffffff
-
设置OriginalCompressedSegmentSize字段为ffffffff:
7. 漏洞防御策略
熟悉了漏洞原理后,可以在流量测进行防御,比如使用Snort的byte_math关键字判断两个字段的和是否会发生整数溢出,发生了证明可能存在恶意流量。
四、缓解措施及安全更新
-
缓解措施:使用以下PowerShell命令禁用SMBv3压缩功能
1
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 1 -Force
使用下面的命令解禁用SMBv3压缩功能
1
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 0 -Force
-
考虑到该漏洞影响较广,且crash的PoC已经公开,强烈建议及时安装官方安全补丁,补丁链接如下:
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0618
五、备注
网上看到一些大佬的分析,定位到了压缩算法里的漏洞,本人能力有限,可能没有分析足够透彻,望包涵。
六、参考链接
http://blogs.360.cn/post/CVE-2020-0796.html
https://www.synacktiv.com/posts/exploit/im-smbghost-daba-dee-daba-da.html