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作为后面结构体空间的内存分配值进行相应运算，而大于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中执行任意代码：

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

作者：SungLin@知道创宇404实验室 
时间：2020年4月2日 
英文版本：https://paper.seebug.org/1165/

参考链接:

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

如若转载，请注明原文地址：