初學Windows內核漏洞利用（三）：竊取訪問憑證

最近我剛剛開始學習Windows內核漏洞利用，因此決定以博客的形式分享一些我的學習心得。

現在我們將接觸熟悉用於許可權提升的載荷。

本部分我所用到的工具環境如下：

• 在（1）和（2）中所描述的環境；

• nasm工具（下載網址： ）；

• HxD工具（下載網址： ）。

回顧一下，我們的攻擊目標是存在漏洞的驅動程序，我們將從用戶層向其提交一段緩衝區數據。上一部分中，我們通過提交畸形的輸入數據，成功觸發了一些崩潰場景；然而我們的目標並不是破壞執行流程，而是通過精心構造輸入來控制執行流程重定向到我們的代碼中。

通常，傳輸載荷被用於提升攻擊者應用程序的許可權；而這可以通過竊取擁有更高許可權的應用程序的訪問憑證（關於訪問憑證的具體含義，可參考相關維基百科，網址：https://en.wikipedia.org/wiki/Access_token）來實現。

查看訪問憑證

系統中運行的每個進程都有其對應的EPROCESS數據結構，其中封裝了所有與之相關的數據。該結構的完整定義，詳見網址（EPROCESS數據結構在Windows操作系統的不同版本之間會有細微差別，更多信息參見網址 ）。EPROCESS結構的某些成員，比如PEB（Process Environment Block，進程環境塊，具體含義可參考維基百科，網址：），用戶模式下即可訪問；而另一些，比如所提到的訪問憑證，只能在內核模式下訪問。我們可以通過如下命令，使用WinDbg調試器查看EPROCESS結構的所有域成員，結果如下圖所示。

dt nt!_EPROCESS

可見，結構起始位置到域成員Token的偏移為0xF8。

通過使用如下命令，讓我們查看憑證中所包含類型的細節，結果如下圖所示。

dt nt!_EX_FAST_REF

憑證存儲於一個聯合結構體_EX_FAST_REF中，其有兩個域成員：RefCnt（引用計數）和Value。我們只對替代Value感興趣；出於應用程序的穩定性考慮，最好不要改變引用計數。

現在，讓我們查看被調試方主機上運行的某些應用程序的憑證。我們可以使用如下命令來列舉進程：

!dml_proc

示例

結果如下圖所示。

圖中所示的第一列，是對應於特定進程的EPROCESS結構首地址。

現在，使用圖中的地址，我們可以通過如下命令來發現更多選定進程相關的細節：

!process [address of EPROCESS]

在如下圖所示的各個域成員之中，我們可以看到訪問憑證。

通過如下命令，我們還可以在更低層次上查看憑證的具體內容：

dt nt!_EX_FAST_REF [address of EPROCESS] + [offset to the Token field]

命令執行結果如下圖所示。

或者使用如下命令：

dd [address of EPROCESS] + [offset to the Token field]

結果如下圖所示。

從上面的結果我們可以看出，!process命令會自動應用掩碼，並從顯示信息中過濾引用計數；我們可以通過使用最右3比特置零的掩碼，在如下表達式求值的幫助下，人工實現相同的功能：

?[token] & 0xFFFFFFF8

結果如下圖所示。

通過WinDbg調試器竊取訪問憑證

作為練習，我們將在被調試方主機運行cmd.exe，並在調試方主機使用WinDbg調試器來提升其許可權。

首先，列舉所有進程；然後，顯示查看選定進程System和cmd的訪問憑證；之後，將System進程的訪問憑證複製到cmd進程內，在這個過程中為了保持引用計數不變我們需要使用相應的掩碼；最終，cmd.exe提權成功。

竊取憑證的載荷

現在我們需要通過注入代碼來重現以上過程；當然這並不簡單，因為我們不能再藉助WinDbg調試器了。

在官方的HEVD知識庫中，提供了一些用於竊取憑證的載荷的完整例子，作為漏洞利用代碼的一部分（網址： ）。

代碼中所包含的所有載荷的目的是相同的，即竊取訪問憑證；然而我們可以看到，為了適應特定的漏洞，它們之間有一點差別。它們的代碼大部分是相同的，只有結尾不同（該部分被稱之為「內核恢復樁程序」）；這部分代碼被用於進行必要的清理工作，以便在載荷部分執行完成返回之後，應用程序不會崩潰。

接著，我們看一個通用版本（網址：https://github.com/hacksysteam/HackSysExtremeVulnerableDriver/blob/master/Exploit/Payloads.c#L186 ），具體代碼如下圖所示。

首先，我們必須找到EPROCESS結構的起始位置。使用WinDbg調試器這輕而易舉，一條命令就可以顯示該信息；現在，我們需要從其他的域來順藤摸瓜，自己動手找到該結構的起始位置。

我們使用KPCR（Kernel Processor Control Region，內核處理器控制區域）結構作為起點，32位Windows操作系統上的FS寄存器（64位系統上則是GS寄存器）指向該結構。

上圖中所述的代碼利用了以下結構之間的關係：

KPCR（PrcbData）->KPRCB（CurrentThread）->KTHREAD（ApcState）->KAPC_STATE（Process）->KPROCESS

KPROCESS結構是EPROCESS結構的第一個域，如下圖所示；因此，通過找到它我們最終找到了EPROCESS結構的起始位置。

當前進程的EPROCESS結構找到之後，我們將利用其另一個域來找到SYSTEM進程的EPROCESS結構，如下圖所示。

LIST_ENTRY是雙向鏈表的一個成員類型，該表將所有正在運行的進程連接到一起。該結構的具體定義如下圖所示。

其域成員Flink指向另一個進程的LIST_ENTRY域；因此，通過該指針索引並替代域成員的偏移，我們可以得到指向另一個進程的EPROCESS結構的指針。

然後，我們需要獲取PID值（對應於域成員UniqueProcessId），並將其與System進程的特有PID進行比對；PID值在EPROCESS結構中的位置如圖所示。

漏洞利用中對應以上過程的代碼片段，如下圖所示。

在獲取我們的進程和System進程的EPROCESS結構之後，我們就可以將憑證從一方複製到另一方。在以下代碼中，引用計數並沒有保留（如下圖所示）。

dt nt!

例如：

dt nt!_KPCR

結果如下圖所示。

之後執行如下命令：

dt nt!_KPRCB

結果如下圖所示。

因此，計算可得_KTHREAD的偏移為 0x120 + 0x004 = 0x124。

代碼片段中給出上述偏移，如下圖所示。

正如HEVD中的漏洞利用代碼（網址：https://github.com/hacksysteam/HackSysExtremeVulnerableDriver/blob/master/Exploit/Payloads.c#L63 ）所演示的那樣，我們可以使用內嵌彙編（封裝於C/C++代碼之中）來編寫載荷代碼。

然而，在這種情況下，編譯器將對我們的代碼進行加工；如下圖所示，代碼前後添加了多餘的前綴和後綴。

這就是我們在執行返回之前，通過堆棧指針（ESP）加上12（0xC）位元組的方式，從堆棧中移除多餘的DWORD類型數據的原因，具體代碼（網址：https://github.com/hacksysteam/HackSysExtremeVulnerableDriver/blob/master/Exploit/Payloads.c#L94 ）如下圖所示。

如果想避免麻煩，我們可以將函數聲明為裸代碼類型（更多內容詳見網址： ）；這可以通過在函數之前添加一個特殊聲明來實現，例如如下代碼（網址：https://github.com/hasherezade/wke_exercises/blob/master/stackoverflow_expl/payload.h#L16 ）：

__declspec(naked) VOID TokenStealingPayloadWin7

另一個選擇是外部編譯其彙編代碼，例如使用NASM編譯器；之後，我們可以將編譯緩衝區內容導出為十六進位字元串。

作為練習，我們還將對上述載荷代碼加以細微的修改，使其能夠保持引用次數不變，具體代碼（網址： ）如下圖所示。

使用如下命令，編譯代碼：

nasm.exe shellc.asm

然後，我們使用十六進位編輯器打開編譯結果，並複製位元組；某些十六進位編輯器（比如HxD）甚至支持以特定編程語言的數組格式來複制數據，如下圖所示。

在我針對HEVD的棧溢出漏洞利用示例中，你可以找到內嵌和外部編譯兩個版本的載荷代碼，具體代碼網址：，編譯後代碼網址：https://drive.google.com/open?id=0Bzb5kQFOXkiSWTJOS2VZZ0JiU3c。

利用該漏洞的細節將在下一部分詳細介紹，也可以閱讀附錄中所提到的Osanda和Sam的文章。

本文由 看雪翻譯小組 木無聊偶 編譯，來源 hasherezade's 1001 nights

轉載請註明來自看雪論壇

如果你喜歡的話，不要忘記點個贊哦！

熱門閱讀文章：

商務合作：[email protected]