[[183464]]

0x00 前言

在兩周前，來自Windows攻擊安全研究團(tuán)隊(duì)(OSR)發(fā)布的關(guān)于加固Windows 10對(duì)抗內(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報(bào)告了Windows 10周年版更新如何加固來緩解原始操作的使用。問題來自與tagWND對(duì)象，在內(nèi)核中表示一個(gè)窗口。讀了這個(gè)博文，我想起了我去年10月份做的一些研究。大約在Black Hat Europe 2016之前兩周，我在Windows10周年版更新上面查找利用tagWND對(duì)象來原始讀寫。但是在我準(zhǔn)備寫些關(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

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

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

0x01 原始PoC

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

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

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

0x02 深入挖掘

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

這個(gè)僅僅確保tagWND對(duì)象和新的LargeUnicodeString對(duì)象格式正確。一點(diǎn)點(diǎn)深入函數(shù)：

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

然后校驗(yàn)確保LargeUnicodeString的長(zhǎng)度不是負(fù)數(shù)：

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

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

0x03 新的希望

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

g_fakeDesktop被分配的用戶層地址是0x2a000000。因?yàn)閃indows10不采用SMAP所以這是可能的，然而如果這么做，我們能將它放到桌面堆上，因?yàn)槿匀辉试S在哪里寫。運(yùn)行更新的PoC來確保校驗(yàn)通過了，并且回到下面的代碼片段：

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

當(dāng)我們繼續(xù)執(zhí)行，我們還會(huì)引起一個(gè)新的bugcheck：

這是因?yàn)橄旅娴闹噶睿?/p>

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

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

0x04 總結(jié)

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

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