CVE-2022-21882漏洞是Windows系统的一个本地提权漏洞,微软在2022年1月份安全更新中修补此漏洞。本文章对漏洞成因及利用程序进行了详细的分析。
CVE-2022-21882是对CVE-2021-1732漏洞的绕过,属于win32k驱动程序中的一个类型混淆漏洞。 攻击者可以在user_mode调用相关的GUI API进行内核调用,如xxxMenuWindowProc、xxxSBWndProc、xxxSwitchWndProc、xxxTooltipWndProc等,这些内核函数会触发回调xxxClientAllocWindowClassExtraBytes。攻击者可以通过hook KernelCallbackTable 中 xxxClientAllocWindowClassExtraBytes 拦截该回调,并使用 NtUserConsoleControl 方法设置 tagWNDK 对象的 ConsoleWindow 标志,从而修改窗口类型。 最终回调后,系统不检查窗口类型是否发生变化,由于类型混淆而引用了错误的数据。flag修改前后的区别在于,在设置flag之前,系统认为tagWNDK.pExtraBytes保存了一个user_mode指针;flag设置后,系统认为tagWNDK.pExtraBytes是内核桌面堆的偏移量,攻击者可以控制这个偏移量,从而导致越界R&W。 本篇文章分析了漏洞成因及漏洞利用手法分析,侧重动态调试及利用手法分析。
Windows 10 Version 21H2 for x64-based Systems Windows 10 Version 21H2 for ARM64-based Systems Windows 10 Version 21H2 for 32-bit Systems Windows 11 for ARM64-based Systems Windows 11 for x64-based Systems Windows Server, version 20H2 (Server Core Installation) Windows 10 Version 20H2 for ARM64-based Systems Windows 10 Version 20H2 for 32-bit Systems Windows 10 Version 21H1 for ARM64-based Systems Windows 10 Version 21H1 for x64-based Systems Windows 10 Version 1909 for x64-based Systems Windows 10 Version 1909 for 32-bit Systems Windows Server 2019 (Server Core installation) Windows Server 2019 Windows 10 Version 1809 for ARM64-based Systems Windows 10 Version 1809 for x64-based Systems Windows 10 Version 1809 for 32-bit Systems Windows 10 Version 20H2 for x64-based Systems Windows 10 Version 1909 for ARM64-based Systems Windows Server 2022 (Server Core installation) Windows Server 2022 Windows 10 Version 21H1 for 32-bit Systems
Windows 10 21H2 19044.1415 x64 Vmware 16.2.1 VirtualKD-Redux 2020.4.0.0 Windbg 10.0.22000.194
本节内容描述了创建窗口时需要用到的结构体及函数:
在xxxSetWindowLong函数中: 正常情况下cbWndServerExtra为0,157行如果index+4< cbWndServerExtra,那么修改的是窗口的保留属性,例如GWL_WNDPROC对应-4,含义为设置窗口的回调函数地址。我们需要设置的是窗口扩展内存,所以进入165行的代码区域。 在167行会判断dwExtraFlag属性是否包含0x800,如果包含,那么168行代码destAddress=pExtraBytes+index+内核桌面堆基址,此处pExtraBytes作为相对内核桌面堆基址的相对偏移量,*(QWORD*)(pTagWnd->field_18+128)为内核桌面堆基地址 ,对应的汇编代码为 在171行处,dwExtraFlag属性不包含0x800,此时destAddress=index+pExtraBytes,此处pExtraBytes作为用户态申请的一块内存区域地址。
dwExtraFlag的含义: dwExtraFlag&0x800 != 0时,代表当前窗口是控制台窗口。调用AllocConsole申请控制台窗口时,调用程序会与conhost程序通信,conhost去创建控制台窗口,调用栈如下: conhost获取到窗口句柄后,调用NtUserConsoleControl修改窗口为控制台类型,调用栈如下: dwExtraFlag&0x800 ==0时,代表当前窗口是GUI窗口,调用CreateWindow时窗口就是GUI窗口。
总结: (1) xxxSetWindowLong设置扩展内存数据时,有如下两种模式: 模式1:tagWND的dwExtraFlag属性包含0x800,使用间接寻址模式,基址为内核桌面堆基地址,pExtraBytes作为偏移量去读写内存。 模式2:tagWND的dwExtraFlag属性不包含0x800,使用直接寻址模式,pExtraBytes直接读写内存。 (2) xxxSetWindowLong会检查index,如果index+4超过cbWndExtra,那么返回索引越界错误。
此漏洞是对CVE-2021-1732漏洞的绕过,此处简要介绍下CVE-2021-1732漏洞: 用户调用CreateWindow时,在对应的内核态函数中检查到窗口的cbWndExtra不为0,通过xxxCreateWindowEx-> xxxClientAllocWindowClassExtraBytes->调用回调表第123项用户态函数申请用户态空间, 1027行会调用USER32!_xxxClientAllocWindowClassExtraBytes,EXP在回调函数中调用NtUserConsoleControl修改窗口的dwExtraFlag和pExtraBytes,修改窗口类型为控制台。 Windows修复代码在1039行,检查pExtraBytes是否被修改,此处查看汇编代码更为清晰 rdi+0x140-0x118 = rdi+0x28,得到tagWNDK,偏移0x128得到pExtraBytes,判断是否不等于0,如果不等于0,1045行代码会跳转,最终释放窗口,漏洞利用失败。 也就是说:CVE-2021-1732的修复方法是在调用xxxClientAllocWindowClassExtraBytes函数后,在父函数CreateWindowEx中判断漏洞是否被利用了,这个修补方法之前是没有问题的。 但是在后续代码更新后,有了新的路径来触发xxxClientAllocWindowClassExtraBytes函数: 在xxxSwitchWndProc函数中调用xxxClientAllocWindowClassExtraBytes后也有检查pExtraBytes是否为0,如果不为0,那么就复制pExtraBytes内存数据到新申请的内存地址中,没有检查dwExtraFlag是否被修改。
总结: 由于CVE-2021-1732漏洞修补时是在父函数中修复的,虽然当时没有问题,但是当多了xxxClientAllocWindowClassExtraBytes函数的触发路径后,同样的漏洞又存在了,而且 CVE-2021-1732漏洞触发路径是在xxxCreateWindowEx中,此时窗口句柄还未返回给用户态,漏洞利用时需要更多的技巧,此漏洞利用时已经返回了窗口句柄,利用起来更加简单。
本节介绍了漏洞触发的流程,并介绍了触发漏洞及利用漏洞需要的各个知识点。 漏洞触发利用的流程: 要利用这个漏洞,需要以下背景知识:
本节描述如何触发用户态回调,使内核回调到USER32!_xxxClientAllocWindowClassExtraBytes。
在IDA中查看xxxClientAllocWindowClassExtraBytes的引用,有多处地方调用到了此函数, 查看xxxSwitchWndProc代码如下: 98行代码有cbWndServerExtra变量赋值,而在调用SetWindowLong时会使用index-cbWndServerExtra,所以我们真正想设置内存区域偏移index位置的变量时,参数2应该传入index+cbWndServerExtra。 103行代码调用xxxClientAllocWindowClassExtraBytes返回值赋值给了v20变量。 111行代码检查原来的pExtraBytes是否为0,如果不为0,那么就复制内存的数据,还会释放原来的pExtraBytes。 117、123行代码都会将v20变量赋值给pExtraBytes。 而xxxSwitchWndProc函数是可以通过win32u! NtUserMessageCall函数来触发的,在用户态调用NtUserMessageCall函数会触发内核态函数xxxClientAllocWindowClassExtraBytes,函数调用栈如下:
在内核态的win32kfull!xxxClientAllocWindowClassExtraBytes函数中,会调用用户态的xxxClientAllocWindowClassExtraBytes函数。 win32kfull!xxxClientAllocWindowClassExtraBytes函数如下: KernelCallbackTable第123项对应_xxxClientAllocWindowClassExtraBytes函数,使用IDA查看函数内容: 此函数中调用RtlAllocateHeap函数来申请*(a1)大小的内存,内存地址保存在addr变量中,然后调用NtCallbackReturn函数返回到内核态,返回的数据为addr变量的地址,对应在上面win32kfull!xxxClientAllocWindowClassExtraBytes函数中的v7变量,v7为addr变量的地址,*v7即为上图中的addr。
总结: 触发回调函数的路径为: Win32u!NtUserMessageCall(用户态)->win32kfull!NtUserMessageCall(内核态)-> win32kfull!xxxSwitchWndProc(内核态)-> win32kfull!xxxClientAllocWindowClassExtraBytes(内核态)-> nt!KeUserModeCallback(内核态)-> USER32!_xxxClientAllocWindowClassExtraBytes(用户态,HOOK此函数) 本节讲了如何从用户态进入到内核,又回调到USER32!_xxxClientAllocWindowClassExtraBytes函数的方法。
上一小节讲了触发到USER32!_xxxClientAllocWindowClassExtraBytes函数的流程,我们还需要hook此回调函数,在回调函数中触发漏洞。下面代码可以将回调函数表项第123、124分别修改为MyxxxClientAllocWindowClassExtraBytes、MyxxxClientFreeWindowClassExtraBytes。
上一小节讲了如何进入到用户态自定义的函数,本节讲述在自定义的函数中通过用户态未公开函数NtUserConsoleControl修改窗口模式为模式1,本节对NtUserConsoleControl函数进行逆向分析。 函数win32u! NtUserConsoleControl可以设置模式为内核桌面堆相对寻址模式,此函数有三个参数,第一个参数为功能号,第二个参数为一个结构体的地址,结构体内存中第一个QWORD为窗口句柄,第三个参数为结构体的大小。 NtUserConsoleControl函数会调用到内核态win32kfull模块的NtUserConsoleControl函数,调用栈如下:
win32kfull模块NtUserConsoleControl判断参数,然后调用xxxConsoleControl如下: 17行判断参数index不大于6 22行判断参数length小于0x18 26行判断参数2指针不为空且length不为0 以上条件满足时会调用xxxConsoleControl函数,传入参数为index、变量的地址,传入数据的长度, xxxConsoleControl函数会对index及len进行判断: 110行代码可知,index必须为6,113行代码可知len必须为0x10,115行到119行代码可知,传入参数地址指向的第一个QWORD数据必须为一个合法的窗口句柄,否则此函数会返回。 134、136行判断是否包含0x800属性,如果包含,v23赋值为内核桌面堆基地址+偏移量pExtraBytes,得到的v23为内核地址。 140行代码,如果不包含0x800属性,那么调用DesktopAlloc申请一段cbWndExtra大小的内存保存在v23中。 149到156行代码判断原来的pExtraBytes指针不为空,就拷贝数据到刚申请的内存中,并调用xxxClientFreeWindowClassExtraBytes->USER32!_xxxClientFreeWindowClassExtraBy释放内存。 159、160行代码使用内核地址v23减去内核桌面堆基址得到偏移量v21,将v21赋值给pExtraBytes变量。 使用如下代码可以修改窗口模式为模式1:
总结: 在自定义回调函数中调用win32u!NtUserConsoleControl可以设置窗口模式为模式1,传入参数需要符合下列要求:
在_xxxClientAllocWindowClassExtraBytes 函数中调用NtCallBackReturn回调函数可以返回到内核态: 伪造一个合适的偏移量Offset,然后应该取Offset地址传给NtCallbackReturn函数,可以将offset赋值给pExtraBytes变量。 由于之前已经切换窗口为模式1,pExtraBytes含义为相对于内核桌面堆基址的偏移,再查看tagWNDK结构体,关注以下字段:
OffsetToDesktopHeap为窗口本身地址tagWNDK相对于内核桌面堆基址的偏移,可以使用如下方法来伪造合适的偏移量:
总结: 调用NtCallbackReturn可以返回到内核中,伪造偏移量为窗口0的OffsetToDesktopHeap,赋值给窗口2的pExtraBytes,当对窗口2调用SetWindowLong时即可修改到窗口0的tagWNDK结构体。 接下来我们需要获取窗口0的OffsetToDesktopHeap。
上一小节中我们在用户态中要返回窗口0的OffsetToDesktopHeap到内核态,OffsetToDesktopHeap是内核态的数据,要想获取这个数据还需要一些工作。 调用CreateWindow只能返回一个窗口句柄,用户态无法直接看到内核数据,但是系统把tagWNDK的数据在用户态映射了一份只读数据,只需要调用函数HMValidateHandle即可,动态库中没有导出此函数,需要通过IsMenu函数来定位: 定位USER32!HMValidateHandle的代码如下: 定位到USER32!HMValidateHandle函数地址后,传入hwnd即可获取tagWNDK数据地址。
通过上面的知识,我们可以通过窗口2修改窗口0的tagWNDK结构体数据,本节描述如何布局内存,构造写原语。 应该通过NtUserConsoleControl修改窗口0切换到模式1,这样对窗口0调用SetWindowLong即可修改内核数据,但是调用SetWindowLong时index有范围限制,所以通过窗口2将窗口0的tagWNDK. cbWndExtra修改为0xFFFFFFFF,扩大窗口0可读写的范围。 现在我们开始内存布局:
创建窗口0,窗口0切换到模式1,pExtraBytes为扩展内存相对内核桌面堆基址的偏移量 窗口2触发回调后,回调函数中对窗口2调用NtUserConsoleControl,所以窗口2也处于模式1,pExtraBytes为扩展内存相对内核桌面堆基址的偏移量。
回调函数中返回窗口0的OffsetToDesktopHeap,此时内存如下: 图中红色线条,此时窗口2的pExtraBytes为窗口0的OffsetToDesktopHeap,指向了窗口0的结构体地址,此时对窗口2调用SetWindowLong即可修改窗口0的内核数据结构
通过窗口2修改窗口0的cbWndExtra SetWindowsLong(窗口2句柄, 0xC8(此处还有一个偏移量),0xFFFFFFFF),即可修改窗口0的cbWndExtra为极大值,且此时窗口0处于模式1,如果传入一个较大的index且不大于0xFFFFFFFF,那么就可以越界修改到内存处于高地址处的其他窗口的数据。
再次创建一个窗口1,窗口1处于模式2,不用修改模式 窗口1刚开始pExtraBytes指向用户态地址,使用模式2直接寻址。 由于窗口0的pExtraBytes是相对于内核桌面堆基址的偏移量,窗口1的OffsetToDeskTopHeap是当前tagWNDK结构体与内核桌面堆基址的偏移量,所以这两个值可以计算一个差值,对窗口0调用SetWindowLong时传入这个差值即可写入到窗口1的结构体,再加上pExtraBytes相对于tagWNDK结构体的偏移即可设置窗口1的pExtraBytes为任意值。
由于此时窗口1处于模式1直接寻址,且我们可以设置窗口1扩展内存地址pExtraBytes为任意地址,所以对窗口1调用SetWindowLong即可向任意内核地址写入数据。
总结: 内存布局的关键在于窗口0的pExtraBytes必须小于窗口1和窗口2的OffsetToDesktopHeap,这样的话在绕过了窗口0的cbWndExtra过小的限制后,对窗口0调用SetWindowLong传入的第二个参数,传入一个较大值,即可向后越界写入到窗口1和窗口2的tagWNDK结构体。 我们来设想一下不满足内存布局的情况,假如窗口1的OffsetToDesktopHeap小于窗口0的pExtraBytes,即窗口1的tagWNDK位于低地址,窗口0的扩展内存位于高地址,那从窗口0越界往低地址写内容时,SetWindowLong的index必须传入一个64位的负数,但是SetWindowLong的第二个参数index是一个32位的值,调用函数时64位截断为32位数据,在内核中扩展到64位后高位为0还是个正数,所以窗口0无法越界写到低地址。
首先动态定位多个函数地址,接下来需要调用 创建窗口类:
调用函数RegisterClassEx创建两个窗口类: 类名为NormalClass的窗口,窗口的cbWndExtra大小为0x20。 类名为MagicClass的窗口,窗口的cbWndExtra大小为0x1337,使用MagicClass类创建的窗口会利用漏洞构造一个内核相对偏移量。 内存布局的代码如下: 第241行到244行,创建了菜单,之后创建窗口使用此菜单。 第245行到250行,使用NormalClass类名创建了50个窗口存放在g_hWnd数组中,然后销毁后面的48个窗口,这样是为了后面创建窗口时可以占用被销毁窗口的区域,缩短窗口之间的间距,此时g_hWnd[0]和g_hWnd[1]存放句柄,将这两个窗口称为窗口0和窗口1,其中247行调用HMValidateHandle函数传入句柄得到对应窗口在用户态映射的tagWNDK数据内存地址保存在g_pWndK数组中。 第245行到255行,调用NtUserConsoleControl函数设置窗口0由用户态直接寻址切换为内核态相对偏移寻址,并且窗口0的pExtraBytes是相对于内核桌面堆基址的偏移。 第257行到258行,使用MagicClass类名创建窗口2保存在g_hWnd[2]中,称为窗口2,然后调用HMValidateHandle获得窗口2的tagWNDK数据映射地址保存在g_pWndK[2]中。 第260和278行代码判断内存布局是否成功,此时窗口0处于内核模式,所以窗口0的pExtraBytes为申请的内核内存空间(不是窗口内核对象地址)相对于内核桌面堆基地址的偏移,窗口1和窗口2为用户态模式,OffsetToDesktopHeap为窗口内核对象地址相对于内核桌面堆基地址的偏移,内存布局必须满足: 窗口0的pExtraBytes小于窗口1的OffsetToDesktopHeap,计算差值extra_to_wnd1_offset,为正数。 窗口0的pExtraBytes小于窗口2的OffsetToDesktopHeap,计算差值extra_to_wnd2_offset,为正数。 如果布局失败,那就销毁窗口继续布局,如果最后一次布局失败,就退出。 布局完成后,程序运行到此处: 程序在虚拟机中运行到DebugBreak()函数时,如果有内核调试器,调试器会自动中断: 此时指令位于DebugBreak函数中,输入k,栈回溯只显示了地址,没有显示符号表,输入
.reload /user会自动加载用户态符号,pdb文件位于本地对应目录,再次输入k,显示栈回溯,可以看到显示正常。 我们先查看三个窗口的内核数据结构 使用命令 dt tagWNDK poi(CVE_2022_21882!g_pWndK+0)可以以结构体方式查看窗口0的tagWNDK结构,在内存布局时已经对窗口0切换了模式,如下: 在调用NtUserMessageCall之前,窗口0处于模式1,窗口1和2处于模式2。 接下来调用HookUserModeCallBack 来Hook回调函数,代码如下: 动态调试时查看KernelCallbackTable表:
查看KernelCallbackTable表项 我们需要查看123项的内容,如下: 调试运行HookUserModeCallBack函数后,再次查看: 在自定义的回调函数MyxxxClientAllocWindowClassExtraBytes中 接着下断点: 并且在MyxxxClientAllocWindowClassExtraBytes函数中下断点: 在调试器中输入g运行,现在运行到如下位置: 在运行NtUserConsoleControl前后分别查看窗口2的模式: 继续按g运行,中断在SetWindowLong函数前 此时窗口2处于模式1,并且pExtraBytes为窗口0的OffsetToDesktopHeap,再调用SetWindowLong函数: 这是第一次越界写,第一个参数为窗口2的句柄,第二个参数为index,为cbWndExtra相对tagWNDK结构体首地址的偏移量+cbWndServerExtra,由于窗口2调用了NtUserMessageCall,所以cbWndServerExtra为0x10,调用SetWindowLong时会使用index-cbWndServerExtra,所以此处要加上cbWndServerExtra来抵消,可参考前文SetWindowLong函数的分析。 单步运行后 可以看到窗口0的cbWndExtra变成了0xFFFFFFFF,接下来对窗口0调用SetWindowLong时传入index可以传入之前计算得到的extra_to_wnd1_offset和extra_to_wnd2_offset来分别修改窗口1和窗口2的窗口内核数据。 此时窗口1处于直接寻址模式,对窗口0调用SetWindowLongPtr修改窗口1的pExtraBytes为任意值,使用SetWindowLongPtr是因为此函数第三个参数可以传入64位数据,将窗口1的pExtraBytes设置为任意值,接下来对窗口1调用SetWindowLong即可实现任意地址写数据。
第一种为设置当前进程的token为system进程的token,将当前进程提升到system权限,这种需要读取进程的EPROCESS结构,再定位到token变量的地址,修改token,公开的EXP中使用GetMenuBarInfo函数来实现内核任意地址读原语。 我们先分析这种方式,先看下Menu内核结构体:
在EXP中先构造一个假的Menu 其中401行设置ppMenu偏移0x00处的值为spMenu,404、408、409设置spMenu结构体内部数据是为了绕过GetMenuBarInfo的验证,GetMenuBarInfo函数会调用内核中的NtUserGetMenuBarInfo,最终调用到xxxGetMenuBarInfo,GetMenuBarInfo对应有四个参数,对应xxxGetMenuBarInfo的四个参数,其中参数2为idObject,参数3为idItem。 xxxGetMenuBarInfo对参数有校验: 164行判断idObject!=-3如果满足,就不能触发到下面读内存的代码路径,所以idObject必须为-3。 316行代码判断dwStyle不能包含WS_CHILD属性。 322行代码从spMenu中偏移0x98取值,赋值给ppMenu。 325行代码判断idItem不能小于0。 328行代码判断idItem不能大于spMenu偏移0x28取值再偏移0x2c取值。 335行代码判断spMenu偏移0x40取值不为0并且偏移0x44取值不为0。 338行到344行,如果idItem不为0,可以让idItem为1,那么_readAddrSub40的值为spMenu偏移0x58取值。 接下来程序进入353行 v5是传入的第四个参数,用作保存读取到的数据。 在353、354行,可以读取传入地址的数据+窗口RECT的left坐标。 在357、358行,可以读取传入地址的数据+4+窗口RECT的top坐标。 所以只要我们可以绕过构造一个假的Menu,绕过上述限制,在Menu偏移0x58再偏移0x00的地址处存放想读取的地址-0x40,当GetMenuBarInfo返回时left和top中保存的就是目标地址处的8字节数据。 要想替换窗口的Menu为假的Menu,还是需要用到SetWindowLong函数,在内核态win32kfull!xxxSetWindowLong函数中会调用xxxSetWindowData函数: xxxSetWindowData函数如下: 134、136行,判断如果index为0xFFFFFFF4,为-12,对应为GWLP_ID。 138行判断如果dwStyle是否包含WS_CHILD属性。 140行取出原来的menu指针,赋值给retValue,最终会作为用户态SetWindowLong函数的返回值。 142行修改spMenu为SetWindowLong传入第三个参数newValue值。 所以我们需要如下步骤才能完成任意地址读:
第二种漏洞利用要修改token的变量Privileges,这种实现相对来说简单,不需要构造写原语,为当前进程添加SE_DEBUG权限并启用,遍历进程,过滤与当前进程位于同一session下的winlogon登录进程,此进程是system权限,打开此进程并注入代码执行。
背景知识: 要打开系统安全进程和服务进程,并且有写入数据权限,需要当前进程拥有SeDebugPrivilege权限,这个是调试进程会用到的权限,当一个进程启动后,正常情况下,是无法提升权限的,正向开发时使用的AdjustTokenPrivileges函数只能是启用某个权限或者禁用某个权限。 之前我们已经实现了任意地址写数据,窗口1本身为用户态直接寻址模式,通过设置窗口1的pExtraBytes值为任意值,调用SetWindowLongPtr时即可对任意地址写数据,上一种利用手法是调用SetWindowsLong来构造写原语,调用GetMenuBarInfo来构造读原语,然后通过EPROCESS的ActiveProcessLinks链遍历进程,当进程号为4时,认为是system进程,获取system的Token变量覆盖到当前进程的Token,当前进程就提权到了system级别。 漏洞利用思路为:使用OpenProcessToken打开当前进程调整权限的句柄,使用NtQuerySystemInformation函数泄露句柄在内核中的地址,泄露出的地址为进程Token在内核中的地址,然后偏移0x40:
在EPROCESS结构体中的token变量类型为nt!_EX_FAST_REF
其实这个结构体中Object才属于TOKEN结构体,但Object的值不是简单的对应TOKEN结构体,而是需要经过计算,上面的结构体中RefCnt也是位于偏移0x00,只占4位,这四位表示了Object对象的引用计数,这里我们使用上面第一种利用方法利用成功后的数据
Object为0xffffbe09`9a242744,RefCnt 为0y0100,需要经过如下换算才可以:
Windbg中查看: Token偏移0x40为Privileges,Privileges中Present和Enable分别表明进程当前是否可以启用对应权限和是否启用了对应权限,EnabledByDefault是默认启用了对应权限,EnabledByDefault这个变量不需要修改,都是8字节数据,如果将Present和Enable都修改为0xFFFFFFFFFFFFFFFF, 在windbg中可以看到位与权限对应关系如下: 其中2位到32位是有效数据,我们只需要启用第20位SeDebugPrivilege权限就可以打开winlogon进程,之后注入shellcode,运行shellcode启动一个system级别的cmd进程。 内存布局与之前的第一种利用方法一样,接着hook回调函数,对窗口2调用NtUserMessageCall,接下来就不一样了: 调用LeakEporcessKtoken泄露token的地址, LeakEporcessKtoken函数调用OpenProcessToken打开自身进程的token,第二个参数访问掩码设置为TOKEN_ADJUST_PRIVILEGES,为调整令牌权限,然后调用GetKernelPointer泄露token的内核地址: 其中结构体SYSTEM_HANDLE_TABLE_ENTRY_INFO和SYSTEM_HANDLE_INFORMATION在移植到64位版本时,笔者有对结构体内容进行一些修正,结构体中都多了一个变量ULONG xxxCDCDCD用来占位,保持8字节对齐。 泄露token地址后,token+0x40即可定位到Privileges变量地址, 313行通过窗口0越界写修改窗口1的pExtraBytes为token+0x40,定位到Privileges。 314到319行,设置新的权限值,其实只需要设置第20位,但是此处设置了第2到第36位都为1。 320行设置Present属性。 321行设置Enabled属性。 322行恢复窗口1的pExtraBytes值。 324行定位winlogon进程的pid,此处需要注意如果有多个用户登录那么存在多个winlogon进程,需要找到跟当前进程处于同一会话中的winlogon进程,否则最终启动的cmd当前用户无法看到。 325行写shellcode到winlogon进程中并执行。 328到331行是为了修复窗口内核数据。
总结两种漏洞利用方法的优劣: 第一种方法:对比第二种稍微有点复杂,要构造读写原语,优势在于不管是低权限进程还是中等权限进程都可以进行提权。 第二种方法:只需要构造一个写原语,然后开启各种权限,通过注入的方法来获取高权限,相对难度低点,但是要调用NtQuerySyetemInformation函数至少需要中等权限,对权限要求较高。
此漏洞对应的补丁为KB5009543,打补丁后调用NtUserMessageCall时触发到内核函数的调用栈如下:
在函数xxxClientAllocWindowClassExtraBytes中调用回调函数后,内核函数对窗口的dwExtraFlag属性校验: 43行判断dwExtraFlag是否包含0x800属性,如果包含,说明用户态函数被hook,当前函数返回值不使用用户态申请的空间,而是返回0,返回到xxxValidateClassAndSize函数后, 判断返回值为0,直接返回,不会再去修改pExtraBytes为用户伪造的值。
https://www.anquanke.com/post/id/241804#h3-12 https://bbs.pediy.com/thread-266362.htm https://www.4hou.com/posts/3KPr https://blog.l4ys.tw/2022/02/CVE-2021-21882/ https://googleprojectzero.github.io/0days-in-the-wild/0day-RCAs/2022/CVE-2022-21882.html
typedef struct tagWNDCLASSEXW {
UINT cbSize;
/
/
结构体的大小
…
UINT style;
/
/
窗口的风格
WNDPROC lpfnWndProc;
/
/
处理窗口消息的回调函数地址
int
cbClsExtra;
/
/
属于此类窗口所有实例共同占用的内存大小
int
cbWndExtra;
/
/
窗口实例扩展内存大小
LPCWSTR lpszClassName;
/
/
类名
…
} WNDCLASSEXW
typedef struct tagWNDCLASSEXW {
UINT cbSize;
/
/
结构体的大小
…
UINT style;
/
/
窗口的风格
WNDPROC lpfnWndProc;
/
/
处理窗口消息的回调函数地址
int
cbClsExtra;
/
/
属于此类窗口所有实例共同占用的内存大小
int
cbWndExtra;
/
/
窗口实例扩展内存大小
LPCWSTR lpszClassName;
/
/
类名
…
} WNDCLASSEXW
ptagWND
/
/
内核中调用ValidateHwnd传入用户态窗口句柄可返回此数据指针
0x18
unknown
0x80
kernel desktop heap base
/
/
内核桌面堆基址
0x28
ptagWNDk
/
/
需要重点关注这个结构体,结构体在下方:
0xA8
spMenu
ptagWND
/
/
内核中调用ValidateHwnd传入用户态窗口句柄可返回此数据指针
0x18
unknown
0x80
kernel desktop heap base
/
/
内核桌面堆基址
0x28
ptagWNDk
/
/
需要重点关注这个结构体,结构体在下方:
0xA8
spMenu
struct tagWNDK
{
ULONG64 hWnd;
/
/
+
0x00
ULONG64 OffsetToDesktopHeap;
/
/
+
0x08
tagWNDK相对桌面堆基址偏移
ULONG64 state;
/
/
+
0x10
DWORD dwExStyle;
/
/
+
0x18
DWORD dwStyle;
/
/
+
0x1C
BYTE gap[
0x38
];
DWORD rectBar_Left;
/
/
0x58
DWORD rectBar_Top;
/
/
0x5C
BYTE gap1[
0x68
];
ULONG64 cbWndExtra;
/
/
+
0xC8
窗口扩展内存的大小
BYTE gap2[
0x18
];
DWORD dwExtraFlag;
/
/
+
0xE8
决定SetWindowLong寻址模式
BYTE gap3[
0x10
];
/
/
+
0xEC
DWORD cbWndServerExtra;
/
/
+
0xFC
BYTE gap5[
0x28
];
ULONG64 pExtraBytes;
/
/
+
0x128
模式
1
:内核偏移量 模式
2
:用户态指针
};
struct tagWNDK
{
ULONG64 hWnd;
/
/
+
0x00
ULONG64 OffsetToDesktopHeap;
/
/
+
0x08
tagWNDK相对桌面堆基址偏移
ULONG64 state;
/
/
+
0x10
DWORD dwExStyle;
/
/
+
0x18
DWORD dwStyle;
/
/
+
0x1C
BYTE gap[
0x38
];
DWORD rectBar_Left;
/
/
0x58
DWORD rectBar_Top;
/
/
0x5C
BYTE gap1[
0x68
];
ULONG64 cbWndExtra;
/
/
+
0xC8
窗口扩展内存的大小
BYTE gap2[
0x18
];
DWORD dwExtraFlag;
/
/
+
0xE8
决定SetWindowLong寻址模式
BYTE gap3[
0x10
];
/
/
+
0xEC
DWORD cbWndServerExtra;
/
/
+
0xFC
BYTE gap5[
0x28
];
ULONG64 pExtraBytes;
/
/
+
0x128
模式
1
:内核偏移量 模式
2
:用户态指针
};
win32kfull!xxxSetWindowLong
win32kfull!NtUserSetWindowLong
+
0xc7
win32k!NtUserSetWindowLong
+
0x16
nt!KiSystemServiceCopyEnd
+
0x25
win32u!NtUserSetWindowLong
+
0x14
USER32!_SetWindowLong
+
0x6e
CVE_2022_21882!wmain
+
0x25d
win32kfull!xxxSetWindowLong
win32kfull!NtUserSetWindowLong
+
0xc7
win32k!NtUserSetWindowLong
+
0x16
nt!KiSystemServiceCopyEnd
+
0x25
win32u!NtUserSetWindowLong
+
0x14
USER32!_SetWindowLong
+
0x6e
CVE_2022_21882!wmain
+
0x25d
win32kfull!xxxClientAllocWindowClassExtraBytes
win32kfull!xxxSwitchWndProc
+
0x167
win32kfull!xxxWrapSwitchWndProc
+
0x3c
win32kfull!NtUserfnINLPCREATESTRUCT
+
0x1c4
win32kfull!NtUserMessageCall
+
0x11d
内核态
…
win32u! NtUserMessageCall 用户态
win32kfull!xxxClientAllocWindowClassExtraBytes
win32kfull!xxxSwitchWndProc
+
0x167
win32kfull!xxxWrapSwitchWndProc
+
0x3c
win32kfull!NtUserfnINLPCREATESTRUCT
+
0x1c4
win32kfull!NtUserMessageCall
+
0x11d
内核态
…
win32u! NtUserMessageCall 用户态
win32kfull!NtUserConsoleControl 内核态
win32k!NtUserConsoleControl
+
0x16
内核态
nt!KiSystemServiceCopyEnd
+
0x25
win32u!NtUserConsoleControl
+
0x14
用户态
CVE_2022_21882!wmain
+
0x3f4
用户态
win32kfull!NtUserConsoleControl 内核态
win32k!NtUserConsoleControl
+
0x16
内核态
nt!KiSystemServiceCopyEnd
+
0x25
win32u!NtUserConsoleControl
+
0x14
用户态
CVE_2022_21882!wmain
+
0x3f4
用户态
ULONG64 buff[
2
]
=
{hwnd};
NtUserConsoleControl(
6
, &buff, sizeof(buff));即可将hwnd对应的窗口模式设置为模式
1
。
ULONG64 buff[
2
]
=
{hwnd};
NtUserConsoleControl(
6
, &buff, sizeof(buff));即可将hwnd对应的窗口模式设置为模式
1
。
+
0x08
ULONG64 OffsetToDesktopHeap;
/
/
窗口tagWNDK相对桌面堆基址偏移
+
0xE8
DWORD dwExtraFlag;
/
/
包含
0x800
即为模式
1
+
0x128
ULONG64 pExtraBytes;
/
/
模式
1
:内核桌面堆偏移量 模式
2
:用户态指针
+
0x08
ULONG64 OffsetToDesktopHeap;
/
/
窗口tagWNDK相对桌面堆基址偏移
+
0xE8
DWORD dwExtraFlag;
/
/
包含
0x800
即为模式
1
+
0x128
ULONG64 pExtraBytes;
/
/
模式
1
:内核桌面堆偏移量 模式
2
:用户态指针
tagWNDK
*
p
=
HMValidateHandle(hwnd),通过tagWNDK指针即可获取到OffsetToDesktopHeap数据。
tagWNDK
*
p
=
HMValidateHandle(hwnd),通过tagWNDK指针即可获取到OffsetToDesktopHeap数据。
gu;.
reload
/
user
kd> !peb
PEB at
0000001eb0c75000
kd> dt ntdll!_PEB KernelCallbackTable
0000001eb0c75000
+
0x058
KernelCallbackTable :
0x00007ffe
`bc6f2070 Void
kd> !peb
PEB at
0000001eb0c75000
kd> dt ntdll!_PEB KernelCallbackTable
0000001eb0c75000
+
0x058
KernelCallbackTable :
0x00007ffe
`bc6f2070 Void
ptagWND
0x10
THREADINFO
0x1A0
PROCESSINFO
0x00
EPROCESS
0x18
unknown
0x80
kernel desktop heap base
0x28
ptagWNDk
0xA8
spMenu
0x28
obj28
0x2C
cItems(
for
check) 设置为
1
0x40
cxMenu(
for
check) 设置为
1
0x44
cyMenu(
for
check) 设置为
1
0x50
ptagWND
0x58
rgItems
0x00
unknown(
for
exploit)
/
/
要读的地址
-
0x40
0x98
ppMenu
0x00
pSelf
/
/
指向spMenu
ptagWND
0x10
THREADINFO
0x1A0
PROCESSINFO
0x00
EPROCESS
0x18
unknown
0x80
kernel desktop heap base
0x28
ptagWNDk
0xA8
spMenu
0x28
obj28
0x2C
cItems(
for
check) 设置为
1
0x40
cxMenu(
for
check) 设置为
1
0x44
cyMenu(
for
check) 设置为
1
0x50
ptagWND
0x58
rgItems
[培训]内核驱动高级班,冲击BAT一流互联网大厂工作,每周日13:00-18:00直播授课