CVE-2020-0796 Windows SMBv3 LPE Exploit POC 分析

作者:SungLin@知道创宇404实验室 时间:2020年4月2日

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 ffffoffset=0x10 ,乘法整数溢出为 0xf ,而在 srvnet! SrvNetAllocateBuffer 中,对于传入的大小 0xf 做了判断,小于 0x1100 的时候将会传入固定的值 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 的值可以开启禁用, 同时修改 PresentEnabledSYSTEM 进程令牌具有的所有特权的值 0x1FF2FF00BC ,之后权限设置为:

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

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

参考链接:

  1. https://github.com/eerykitty/CVE-2020-0796-PoC

  2. https://github.com/danigargu/CVE-2020-0796

  3. https://ired.team/miscellaneous-reversing-forensics/windows-kernel/how-kernel-exploits-abuse-tokens-for-privilege-escalation

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章