一、 SMB Ghost简介
服务器消息块（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还使安全协商成为必需。
Smb2CompressedTransformHeader的具体格式如下图所示：
漏洞产生根本原因是在srv2.sys中,由于SMB没有正确处理压缩的数据包,在解压数据包的时候使用客户端传过来的长度进行解压时,并没有检查长度是否合法.最终导致整数溢出。具体细节将通过对以下几个POC分析进行详细阐述。
二、 测试环境
攻击机：192.168.19.138（kali 2021.2 x64位安装Metaploit工具）
靶机： 192.168.19.195（win10 x64 专业版，1909，防火墙关闭）
Wireshark版本:3.4.8
三、 漏洞原理分析
蓝屏攻击
- 攻击复现
POC：https://github.com/maxpl0it/Unauthenticated-CVE-2020-0796-PoC
执行方法：Python3 crash.py ipaddress
效果：触发蓝屏
- 原因分析
srv2.sys中处理SMBv3压缩数据包的解压函数Srv2DecompressData未严格校验数据包中OriginalCompressedSegmentSize和Offset/Length字段的合法性。而这两个字段影响了Srv2DecompressData中内存分配函数SrvNetAllocateBuffer的参数。如下图所示的Srv2DecompressData函数反编译代码，SrvNetAllocateBuffer实际的参数为OriginalCompressedSegmentSize+Offset。这两个参数都直接来源于数据包中SMB Compression Transform Header中的字段，而函数并未判断这两个字段是否合法，就直接将其相加后作为内存分配的参数(unsigned int类型）。
而crash.py恰好利用这一特点，在构造Smb2CompressedTransformHeader时OriginalCompressedSegmentSize是正常大小，而offset却被设置成0xffffffff,从而在两者相加时产生整型溢出。
如下图所示，在windbg中进行调试，rax对应的是OriginalCompressedSegmentSize，rcx对应的是offset，二者进行相加后rcx的值却变为0x31，明显发生溢出。
由于发生整型溢出，导致SrvNetAllocateBuffer分配了一块较小的UncompressedBuffer。随后又传到了SmbCompressionDecompress去处理。
如上图所示，Srv2DecompressData又调用了srvnet中的SmbCompressionDecompress最后调用RtlDecompressBufferLZNT1去处理压缩数据，而就在RtlDecompressBufferLZNT1+0x57处rsi的地址不存在导致此处的mov指令无法执行从而造成系统崩溃触发蓝屏。
本地提权（LPE）
- 攻击复现
POC：https://github.com/danigargu/CVE-2020-0796
- 原因分析
POC利用Srv2DecompressData存在的漏洞精心构造了一个数据包。最终通过修改自身进程的TOKEN来提权。
首先来对POC进行分析，下图为构造数据包的具体过程，其中可以看到OriginalComressedSegmentSize设置为0Xffffffff，而offset为0x10。另外在头部构造完成后在其后面添加了大小为0x10的数据（两个0x1ff2ffffbc）最后添加压缩数据。
对其抓包结果如下所示：
压缩数据的大小为0x1110，由0x1108字节的‘A’和_TOKEN+0x40处的地址组成。
整体格式如下图所示：
2.1动态调试
在函数srv2!Srv2DecompressData处下断点，由于OriginalComressedSegmentSize为0xffffffff，与Offset相加后，发生整型溢出后结果变小（0xf）。两者相加的和作为参数进入srvnet!SrvNetAllocateBuffer函数，申请一段内存空间。
根据实际情况，传入的参数位0xf，则使用SrvNetBufferLookasides分配内存，这个函数用于有效地为驱动程序保留一组可重用的、固定大小的缓冲区。而SrvNetBufferLookasides函数初始化在SrvNetCreateBufferLookasides中，而SrvNetCreateBufferLookasides又调用了SrvNetBufferLookasideAllocate分配内存，SrvNetBufferLookasideAllocate根据参数分配一些固定的内存空间，[‘0x1100’，‘0x2100’，‘0x4100’，‘0x8100’，‘0x10100’，‘0x20100’，‘0x40100’，‘0x80100’，‘0x100100’]。
最终SrvNetAllocateBuffer返回值为0xffffab055e1cb150,知道注意的是此处的返回值是指向申请缓冲区的起始地址。而是指明这个缓冲区的一个结构，这个结构偏移0x18处为这个缓冲区起始地址。
其结构如下图所示：
缓冲区申请完之后，开始调用SmbCompressionDecompress对SMB的压缩数据进行解压，这里需要注意的是SmbCompressionDecompress第四参数传入的是offset +
(_QWORD )(UnCompressBuffer + 0x18), 也就是说RtlDecompressBufferLZNT1解压缩完之后数据是在起始地址的偏移0x10开始写入，而压缩数据的大小为0x1110显然会造成缓冲区的溢出，会导致缓冲区的结构体的前0x20的数据被覆盖。结果如下所示：
解压后缓冲区的数据：
结构体前0x20的数据被覆盖为解压后的数据：
最后，Srv2DecompressData把SMB压缩数据包解压后会调用memcpy将其未压缩的数据（两个0x1ff2ffffbc）放置到0x10的空闲区，目的就是复原SMB数据包。但是，此时的结构体已经被覆盖，其v7+0x18指向的地址恰好是_TOKEN Privileges的地址。因此，当内存复制后，_TOKEN Privileges中的数据被修改，从而实现提权！
2.2token介绍
在Windows中运行的每个进程都与一个访问令牌相关联，该令牌决定允许进程做什么。令牌是一个复杂的数据结构，具有一个关键部分，它决定允许给定进程执行哪些操作.
这里使用的是修改令牌以提高权限，在windbg中查看结构：
通过修改_SEP_TOKEN_PRIVILEGES的值去提升权限，升级权限就是将Present和Enabled的值更改为SYSTEM进程令牌的所有权限0x1FF2FF00BC。
远程代码执行（RCE）
- 攻击复现
扫描：http://dl.qianxin.com/skylar6/CVE-2020-0796-Scanner.zip
POC：https://github.com/chompie1337/SMBGhost_RCE_PoC
首先，使用下面所示命令构造playload
msfvenom -p windows/x64/meterpreter/bind_tcp
LPORT=4444 -b '\x00' -i 1 -f python
成功执行会得到类似下图所示数据。
接着将生成的playload全部复制，去替换expoit.py中的USR_PLAYLOAD(注意改名)。
通过msf使用exploit/multi/handler模块开启监听
然后使用exp对靶机进行攻击：
四、 防护策略
445端口
禁用SMBv3.1.1压缩
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论