做者:SungLin@知道创宇404实验室
时间:2020年4月2日
原文地址:https://paper.seebug.org/1164/
英文版本:https://paper.seebug.org/1165/git
2020年3月12日微软确认在Windows 10最新版本中存在一个影响SMBv3协议的严重漏洞,并分配了CVE编号CVE-2020-0796,该漏洞可能容许攻击者在SMB服务器或客户端上远程执行代码,3月13日公布了可形成BSOD的poc,3月30日公布了可本地特权提高的poc, 这里咱们来分析一下本地特权提高的poc。github
漏洞存在于在srv2.sys驱动中,因为SMB没有正确处理压缩的数据包,在解压数据包的时候调用函数Srv2DecompressData
处理压缩数据时候,对压缩数据头部压缩数据大小OriginalCompressedSegmentSize
和其偏移Offset
的没有检查其是否合法,致使其相加可分配较小的内存,后面调用SmbCompressionDecompress
进行数据处理时候使用这片较小的内存可致使拷贝溢出或越界访问,而在执行本地程序的时候,可经过获取当前本地程序的token+0x40
的偏移地址,经过发送压缩数据给SMB服务器,以后此偏移地址在解压缩数据时候拷贝的内核内存中,经过精心构造的内存布局在内核中修改token将权限提高。web
咱们先来分析下代码,POC程序和smb创建链接后,首先会经过调用函数OpenProcessToken
获取本程序的Token,得到的Token偏移地址将经过压缩数据发送到SMB服务器中在内核驱动进行修改,而这个Token就是本进程的句柄的在内核中的偏移地址,Token是一种内核内存结构,用于描述进程的安全上下文,包含如进程令牌特权、登陆ID、会话ID、令牌类型之类的信息。shell
如下是我测试得到的Token偏移地址:windows
接下来poc会调用RtCompressBuffer
来压缩一段数据,经过发送这段压缩数据到SMB服务器,SMB服务器将会在内核利用这个token偏移,而这段数据是'A'*0x1108+ (ktoken + 0x40)
。安全
而经压缩后的数据长度0x13,以后这段压缩数据除去压缩数据段头部外,发送出去的压缩数据前面将会链接两个相同的值0x1FF2FF00BC
,而这两个值将会是提权的关键。服务器
咱们先来进行调试,首先由于这里是整数溢出漏洞,在srv2!Srv2DecompressData
函数这里将会由于乘法0xffff ffff * 0x10 = 0xf
致使整数溢出,而且进入srvnet!SrvNetAllocateBuffer
分配一个较小的内存。svg
在进入了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的值。
而覆盖的值是两个相同的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