图10：在tagWnd结构中设置了一个任意值
为了触发此漏洞，新创建的窗口的WS_CHILD属性必须被分配，并且GWLP_ID属性必须通过API函数NtSetWindowLongPtr()来进行设置。此外，最后一个障碍是如何触发xxxNextWindow。经过一番研究，我们发现可以通过按Alt + Tab的组合键或者用keybd_event API模拟按键来触发它。
漏洞复现和进一步分析
现在，我们已经从上层了解此漏洞的根本原因，下面就让我们来尝试复现此漏洞。我们将创建一个简单的窗口，并在其tagWND结构中填充一些值。
HWND hwnd = CreateWindowEx(0, L”TestWnd”, 0, WS_OVERLAPPEDWINDOW | WS_VISIBLE | WS_CHILD, 5, 5, 1, 1, hWndParent, 0/*hMenu */, h, 0);
SetWindowLongPtr(hwnd, GWLP_ID,/*0xfffffff4=GWLP_ID*/ 0x41414141);
图11：调试存在漏洞的函数xxxNextWindow
上面的截图显示了实时调试输出。这里ebx寄存器保存了指向tagWND结构的指针，并且写入违规将很快发生。正如下图所看到的，违规指令的目的地正是我们以前通过NtSetWindowLongPtr API传递的地址（加上0x14），这完美地证实了一次任意地址写入攻击。
图12：任意地址写入攻击的场景
让我们回到微软的补丁，它首先检查tagWND结构起偏移0x23后的值。 在补丁代码中，我们可以看到新引入的语句
(*(_BYTE *)(v8 + 0x23) & 0xC0) != 0x40
在打补丁后的函数中，ebx指向了tagWND结构
ebx + 0x23 = 0x54
0x54＆0xc0 = 0x40;
0x40！= 0x40;
现在这个语句变成false。 因此，程序跳过以下尝试修改内存的代码行，从而避免了程序崩溃（写入访问冲突）。
*（_ DWORD *）（*（_ DWORD *）（v30 + 0x78）+ 0x14）＆= 0xFFFFFFFB;
*（_ DWORD *）（*（_ DWORD *）（v8 + 0x78）+ 0x14）| = 4u;
如何利用此漏洞实现提权？与允许将任意值写入任意地址相比，此漏洞只能更改一个比特位; 也就是说，地址上的值将0x04（或其倍数）进行逻辑或运算，如下所示：
Value = Value | 0x04;
Value = Value | 0x0400;
Value = Value | 0x040000
Value = Value | 0x04000000
在这种情况下，如果攻击者可以在内核区域中找到某个对象数组，并使用此逻辑或原语扩大对象数组的索引（例如tagWnd-> cbWndExtra）从而导致越界访问，这样攻击者就能够从用户态（通过使用一些用户态API）获得任意地址读/写的能力。我们目前知道一些这种利用技能（指的是API），如GetBitmapbits /SetBitmapbits（首先由KeenTeam发现）SetWindowText/GetWindowText。
总结
如今，使用内核态漏洞的提权仍然是打破应用程序沙箱（Internet Explorer的EPM或Edge的AppContainer）的主载体。这个方式已经被我们所看到的针对Internet Explorer/Edge/Adobe Reader和Flash的大多数成功的漏洞利用证明了。对于当前使用多层防御的Windows版本，使用内核提权突破沙箱仍然是攻击者的第一选择。KeUsermodeCallback过去是一种非常流行的Windows内核漏洞，它可能导致内核模式的代码执行，我们在CVE-2014-4113和CVE-2015-0057中就可以看到。微软在解决内核漏洞和增加更多缓解安全特性方面的工作导致了这种类型的攻击下降。道高一尺魔高一丈，攻击者已经开始研究内核字体和GDI漏洞。Windows 10已经限制了Edge中的win32k调用，从而显著减少了攻击面。微软也已经修复了利用GDI共享句柄表的内核内存信息披露问题。毫无疑问，内核利用将变得越来越困难。然而，我们预见攻击者仍然会使用win32k作为主攻击面来利用内核实现代码执行或特权提升。对于攻击者和防御者双方战斗都将继续围绕这个热点持续蔓延。
发表评论