[[183464]]

0x00 前言

在兩周前，來自Windows攻擊安全研究團隊(OSR)發(fā)布的關(guān)于加固Windows 10對抗內(nèi)核利用：https://blogs.technet.microsoft.com/mmpc/2017/01/13/hardening-windows-10-with-zero-day-exploit-mitigations/https://blogs.technet.microsoft.com/mmpc/2017/01/13/hardening-windows-10-with-zero-day-exploit-mitigations/

Windows上的內(nèi)核利用幾乎總是需要原始內(nèi)核讀或?qū)?。因此OSR報告了Windows 10周年版更新如何加固來緩解原始操作的使用。問題來自與tagWND對象，在內(nèi)核中表示一個窗口。讀了這個博文，我想起了我去年10月份做的一些研究。大約在Black Hat Europe 2016之前兩周，我在Windows10周年版更新上面查找利用tagWND對象來原始讀寫。但是在我準備寫些關(guān)于我發(fā)現(xiàn)的東西之前，在Black Hat Europe上通過窗口攻擊窗口的討論就發(fā)表了：https://www.blackhat.com/docs/eu-16/materials/eu-16-Liang-Attacking-Windows-By-Windows.pdf

因此我停止了寫作的想法，因為我的發(fā)現(xiàn)基本上和他們相同。然而在讀了OSR發(fā)布的博文后，來自Yin Liang 和 Zhou Li的演講只能在1511版本上面演示，這個版本不存在新的緩解措施。然而我做我的研究時發(fā)現(xiàn)了一些煩人的指針驗證，但是發(fā)現(xiàn)了一個繞過他們的方式，在當時并沒有想到它?，F(xiàn)在我確認了這個指針驗證就是OSR發(fā)布的加固措施，并且他們非常容易繞過，重新帶回原始讀寫功能。

本文將瀏覽加固的過程，和它的問題，且如何繞過它。下面的分析是在2016年更新的Windows 10版本研究的。

0x01 原始PoC

我將復(fù)用來自Black Hat Europe的演講內(nèi)容，因此如果你還沒有閱讀，我建議你現(xiàn)在看一下它。這個演講的本質(zhì)是一個write-what-where漏洞的情況，結(jié)構(gòu)體tagWND的cbwndExtra字段可能增長并且允許覆蓋內(nèi)存。因此如果兩個tagWND對象緊挨著存放，覆蓋第一個tagWND對象的cbwndExtra字段可能允許利用來修改下一個tagWND對象的字段。這些當中有strName，包含了一個窗口標題位置的指針，修改這個能被利用來在內(nèi)核內(nèi)存中讀寫。下面的代碼片段展示了如何使用SetWindowLongPtr和NtUserDefSetText來做到這點：

這個創(chuàng)建了一個新的LargeUnicodeString對象和試圖在任意地址寫入內(nèi)容。調(diào)用SetWindowLongPtr被用來改變窗口名字的指針，并且然后再次恢復(fù)它。這個在周年版之前的所有版本可以有效，現(xiàn)在會引起相面的bugcheck：

這個確實在OSR發(fā)布的博文中有描述。

0x02 深入挖掘

為了理解為什么會引起bugcheck，我開始調(diào)試函數(shù)DefSetText的流程。當進入這個函數(shù)，我們已經(jīng)有了RCX存放的tagWND對象的地址和RDX存放的指向新的LargeUnicodeString對象的指針。第一部分的驗證如下：

這個僅僅確保tagWND對象和新的LargeUnicodeString對象格式正確。一點點深入函數(shù)：

DesktopVerifyHeapLargeUnicodeString是新的加固函數(shù)。它使用LargeUnicodeString地址為參數(shù)，這個包含了我們通過調(diào)用SetWindowLongPtr改變的指針。并且針對Desktop的tagWND對象的一個指向tagDESKTOP結(jié)構(gòu)體的指針被使用。新函數(shù)的第一部分是驗證字符串的長度是不是正確的格式，并且不還有原始長度，因為他們應(yīng)該是Unicode字符串：

然后校驗確保LargeUnicodeString的長度不是負數(shù)：

然后以指向tagDESKTOP的指針為參數(shù)調(diào)用DesktopVerifyHeapPointer，記住RDX已經(jīng)包含了緩沖區(qū)地址。接下來發(fā)生的是觸發(fā)bugcheck。在結(jié)構(gòu)體tagDESKTOP對象的偏移0x78和0x80處解引用了，這是桌面的堆和大小，比較地址我們試圖寫操作LargeUnicodeString。如果那個地址不在桌面堆中，則會引起bugcheck。OSR說的加固措施如下：

非常清晰，原始寫不再有效，除非在桌面堆中使用，但是被限制了。

0x03 新的希望

不是所有的都丟了，桌面堆的地址和它的大小都來自tagDESKTOP對象。然而沒有驗證指向tagDESKTOP對象的指針是否正確。因此如果我們創(chuàng)建一個假的tagDESKTOP對象，并且替換原始的，然后我們能控制0x78和0x80偏移。因為指向tagDESKTOP的指針被tagWND使用，我們也能使用SetWindowLongPtr修改它。下面是更新的函數(shù)：

g_fakeDesktop被分配的用戶層地址是0x2a000000。因為Windows10不采用SMAP所以這是可能的，然而如果這么做，我們能將它放到桌面堆上，因為仍然允許在哪里寫。運行更新的PoC來確保校驗通過了，并且回到下面的代碼片段：

因此另一個調(diào)用來做相同的校驗，還是tagDESKTOP作為第一個參數(shù)，現(xiàn)在緩沖區(qū)指針加上最大字符串的長度減1是第二個參數(shù)，而不是字符串緩沖區(qū)的開始。校驗將通過并執(zhí)行到DefSetText。

當我們繼續(xù)執(zhí)行，我們還會引起一個新的bugcheck：

這是因為下面的指令：

因為R9包含了0x1111111111111111，非常清楚是由假的tagDESKTOP對象填充的。使用IDA我們發(fā)現(xiàn)：

證實了R9的內(nèi)容確實來自tagDESKTOP指針，并且是第二個QWORD。因此我們能更新代碼來設(shè)置這個值。如果設(shè)置為0，解引用被繞過。運行新的代碼不會導(dǎo)致崩潰，任意覆蓋如下：

0x04 總結(jié)

總結(jié)下OSR確實做了加固措施，但是還不夠。相同的方式也能通過使用InternalGetWindowText來作為原始讀。

代碼如下：https://github.com/MortenSchenk/tagWnd-Hardening-Bypass