作者:SungLin@知道创宇404实验室
时间:2020年4月2日
原文地址:https://paper.seebug.org/1164/

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

创宇君
4 声望0 粉丝

一名喜欢摄影的码农