CVE-2020-0796 Windows SMBv3 LPE Exploit POC 分析
作者:SungLin@知道创宇404实验室
时间:2020年4月2日
英文版本:https://paper.seebug.org/1165/
0x00 漏洞背景
2020年3月12日微软确认在Windows 10最新版本中存在一个影响SMBv3协议的严重漏洞,并分配了CVE编号CVE-2020-0796,该漏洞可能允许攻击者在SMB服务器或客户端上远程执行代码,3月13日公布了可造成BSOD的poc,3月30日公布了可本地特权提升的poc, 这里我们来分析一下本地特权提升的poc。
0x01 漏洞利用原理
漏洞存在于在srv2.sys驱动中,由于SMB没有正确处理压缩的数据包,在解压数据包的时候调用函数Srv2DecompressData
处理压缩数据时候,对压缩数据头部压缩数据大小OriginalCompressedSegmentSize
和其偏移Offset
的没有检查其是否合法,导致其相加可分配较小的内存,后面调用SmbCompressionDecompress
进行数据处理时候使用这片较小的内存可导致拷贝溢出或越界访问,而在执行本地程序的时候,可通过获取当前本地程序的token+0x40
的偏移地址,通过发送压缩数据给SMB服务器,之后此偏移地址在解压缩数据时候拷贝的内核内存中,通过精心构造的内存布局在内核中修改token将权限提升。
0x02 获取Token
我们先来分析下代码,POC程序和smb建立连接后,首先会通过调用函数OpenProcessToken
获取本程序的Token,获得的Token偏移地址将通过压缩数据发送到SMB服务器中在内核驱动进行修改,而这个Token就是本进程的句柄的在内核中的偏移地址,Token是一种内核内存结构,用于描述进程的安全上下文,包含如进程令牌特权、登录ID、会话ID、令牌类型之类的信息。

以下是我测试获得的Token偏移地址:

0x03 压缩数据
接下来poc会调用RtCompressBuffer
来压缩一段数据,通过发送这段压缩数据到SMB服务器,SMB服务器将会在内核利用这个token偏移,而这段数据是'A'*0x1108+ (ktoken + 0x40)
。

而经压缩后的数据长度0x13,之后这段压缩数据除去压缩数据段头部外,发送出去的压缩数据前面将会连接两个相同的值0x1FF2FF00BC
,而这两个值将会是提权的关键。


0x04 调试
我们先来进行调试,首先因为这里是整数溢出漏洞,在srv2!Srv2DecompressData
函数这里将会因为加法0xffff ffff + 0x10 = 0xf
导致整数溢出,并且进入srvnet!SrvNetAllocateBuffer
分配一个较小的内存。

在进入了srvnet!SmbCompressionDecompress
然后进入nt!RtlDecompressBufferEx2
继续进行解压,最后进入函数nt!PoSetHiberRange
,再开始进行解压运算,通过OriginalSize= 0xffff ffff
与刚开始整数溢出分配的UnCompressBuffer
存储数据的内存地址相加得一个远远大于限制范围的地址,将会造成拷贝溢出。

但是我们最后需要复制的数据大小是0x1108,所以到底还是没有溢出,因为真正分配的数据大小是0x1278,通过srvnet!SrvNetAllocateBuffer
进入池内存分配的时候,最后进入srvnet!SrvNetAllocateBufferFromPool
调用nt!ExAllocatePoolWithTag
来分配池内存:

虽然拷贝没有溢出,但是却把这片内存的其他变量给覆盖了,包括srv2!Srv2DecompressDatade
的返回值, nt!ExAllocatePoolWithTag
分配了一个结构体来存储有关解压的信息与数据,存储解压数据的偏移相对于UnCompressBuffer_address
是固定的0x60
,而返回值相对于UnCompressBuffer_address
偏移是固定的0x1150
,也就是说存储UnCompressBuffer
的地址相对于返回值的偏移是0x10f0
,而存储offset
数据的地址是0x1168
,相对于存储解压数据地址的偏移是0x1108
。

有一个问题是为什么是固定的值,因为在这次传入的OriginalSize= 0xffff ffff
,offset=0x10
,乘法整数溢出为0xf
,而在srvnet! SrvNetAllocateBuffer
中,对于传入的大小0xf
做了判断,小于0x1100
的时候将会传入固定的值0x1100
作为后面结构体空间的内存分配值进行相应运算。

然后回到解压数据这里,需解压数据的大小是0x13
,解压将会正常进行,拷贝了0x1108
个'A'后,将会把8字节大小token+0x40
的偏移地址拷贝到'A'的后面。


解压完并复制解压数据到刚开始分配的地址后正常退出解压函数,接着就会调用memcpy
进行下一步的数据拷贝,关键的地方是现在rcx
变成了刚开始传入的本地程序的token+0x40
的地址!!

回顾一下解压缩后,内存数据的分布0x1100(‘A’)+Token=0x1108
,然后再调用了srvnet!SrvNetAllocateBuffer
函数后返回我们需要的内存地址,而v8的地址刚好是初始化内存偏移的0x10f0
,所以v8+0x18=0x1108
,拷贝的大小是可控的,为传入的offset
大小是0x10
,最后调用memcpy
将源地址就是压缩数据0x1FF2FF00BC
拷贝到目的地址是0xffff9b893fdc46f0(token+0x40)
的后16字节将被覆盖,成功修改Token的值。

0x05 提权
而覆盖的值是两个相同的0x1FF2FF00BC
,为什么用两个相同的值去覆盖token+0x40
的偏移呢,这就是在windows内核中操作Token提升权限的方法之一了,一般是两种方法:

第一种方法是直接覆盖Token,第二种方法是修改Token,这里采用的是修改Token。
在windbg中可运行kd> dt _token
的命令查看其结构体:

所以修改_SEP_TOKEN_PRIVILEGES
的值可以开启禁用, 同时修改Present
和Enabled
为SYSTEM
进程令牌具有的所有特权的值0x1FF2FF00BC
,之后权限设置为:

这里顺利在内核提升了权限,接下来通过注入常规的shellcode
到windows进程winlogon.exe
中执行任意代码:

如下所示执行了弹计算器的动作:

参考链接:
- https://github.com/eerykitty/CVE-2020-0796-PoC
- https://github.com/danigargu/CVE-2020-0796
- https://ired.team/miscellaneous-reversing-forensics/windows-kernel/how-kernel-exploits-abuse-tokens-for-privilege-escalation

本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/1164/