深度分析CVE-2017-0007是如何繞過防護措施的

簡而言之，設備用戶模塊代碼完整性防護措施是指阻止沒有授權的程序運行，除非他在windows當中經過了信任授權。當然這一防護措施只有windows當中存在，並且它存在於Powershell中防護語言模式(Contrainted Language mode)。當我研究開啟防護措施的機器上是如何執行腳本一段時間後，我最後找到了一種方法可以在開啟防護措施的系統中執行任意腳本。在向MSRC報告問題後，最終將該漏洞命名為CVE-2017-0007（MS17-012），並且已經修補。這個特定的錯誤只會影響PowerShell和Windows腳本主機，而不會影響編譯代碼。

這個漏洞是我第一個CVE，同時也是我第一次分析補丁。所以這篇文章不僅介紹了漏洞的生成，還將會逆向分析補丁如何工作。由於這是我第一次做這種工作，所以可能會有一些錯誤。如果在文章中出現了錯誤，請在下方評論告訴我，我加以改正。

當執行一個擁有簽名的程序時，wintrust.dll會驗證這個文件的簽名。這是文件執行後查看得知的。事實上，如果你使用有微軟簽名的腳本對這個程序進行修改，那麼這個程序的完整性就會受到破壞，並且簽名不會有效。此類驗證對於設備防護至關重要，它的唯一目的就是防止沒有簽名或者不受信任的代碼運行。

CVE-2017-0007就繞過了這種防護措施，允許你通過簡單地修改先前已經獲得批准的簽名的腳本來運行任何未簽名的代碼。這種情況，我們選擇有一個微軟簽名的腳本是為了能夠在開啟設備防護措施的機器上運行。舉個例子，如果我們嘗試在PowerShell中運行一個沒有簽名的腳本(可以是實例化網站的腳本)，會因為PowerShell處於防護語言模式(Constrained Language mode)導致執行失敗。通過部署代碼的完整性策略可以批准任何有簽名並且受信任的Powershell腳本在任何語言模式(Fulllanguage)下沒有任何限制的運行。在這種情況，我們的代碼並沒有簽名而且也不是受信任代碼，所以他在防護語言模式不會被執行成功。

像這樣具有簽名的腳本，它們往往在正文中被嵌入一個認證簽名。如果你修改了這個文件的任何內容，則這個文件的完整性就會破壞，那麼這個簽名就會無效。你可以簡單的從已經存在簽名文件中複製簽名到一個沒有簽名的文件中。

就像你看到的這樣，這個腳本的內容已經被我們自己的代碼替換了，並且sigcheck腳本給出「這個文件的簽名無效」的提示。這意味著文件的完整性已經遭到了破壞，並且代碼會被阻止運行，不過確實會這樣嗎？

如上圖所示，儘管我們的簽名是無效的，但是我們已經執行了我們的程序。微軟將這個漏洞命名為CVE-2017-0007,歸類為：MS17-012。這個漏洞根本原因是確保文件的完整性的代碼並沒有驗證成功，也就是驗證程序沒有對存在錯誤代碼的未簽名程序進行驗證，最後成功執行未簽名的腳本。

那麼，這個漏洞的是什麼造成的，並且應該如何修補這個漏洞呢？設備防護依賴於wintrust.dll去解決已簽名文件的驗證簽名以及完整性的問題。由於這個漏洞的根本原因，所以我找到了第一個漏洞發生的位置。使用bindiff比較打補丁前的wintrust.dll(10.0.14393.0)以及打補丁後的wintrust.dll(10.0.14393.953)，我發現新增了一個代碼塊。同時，還有一個變化，這個變化是在驗證簽名這一方面的唯一變化。因此，我猜出這一部分是漏洞的補丁：

進一步查看，你可以看到從"sub_18002D0F8"中刪去了一些代碼：

新添加的代碼塊叫做"sub_18002D104"，你可以從中發現它包含一些來自"sub_18002D0F8"的代碼同時一些補充。這些函數沒有特定的符號，所以我們必須用他們定義的名字。或許，你可以在IDA中對這些函數進行更有意義的命名。

上圖中的文字有點小，不過我會更深一層次的解釋上面代碼做了什麼。我不會詳細的介紹如何使用bindiff,但是如果你想了解更多，你可以查看使用手冊。有了漏洞發生的確切位置，我開始探索在執行未簽名程序時，到底發生了什麼。我們知道修復過程中，從"sub_18002D0F8"刪除了一些代碼，並且添加了新的代碼塊叫做"sub_18002D104"。所以這兩處變化是個不錯的起點。首先，我在IDA中打開了沒有打補丁之前的wintrust.dll(10.0.14393.0),跳轉到補丁中修補的地方，即：sub_18002D0F8。這個函數通過設置一些變數開始，然後他們調用:"SoftpubAuthenticode"

查看"SoftpubAuthenticode"發現接下來它調用了"CheckValidSignature"方法：

似乎"CheckValidSignature"這個方法會在程序執行之前驗證簽名或者完整性。查看這個方法的內容，可找到在返回值之前調用的最後一個方法：

通過在最後一個函數設置一個斷點，我們可以在eax寄存器中可以看到來自」CheckValidSignature」的錯誤代碼。如下圖黃色標記：

由於判斷我們腳本的簽名不正確的錯誤代碼已經不存在了，所以它現在處於認證狀態，並且已經被允許執行：

我們現在已經知道了這個漏洞是如何形成的，我們現在可以看看微軟是如何對漏洞進行修復的。為了去了解他的做法，我們需要下載安裝補丁KB4013429。通過查看新版本的wintrust.dll(10.0.14393.953),我們可以搜索"sub_18002D104"也就是之前提到的新添加的代碼塊。我們現在已經知道這個漏洞的原因是寄存器中的錯誤代碼被覆蓋而導致沒有被認證。我們可以看到這個補丁在」SoftPubAuthenticode」返回之後添加了一條新的調用：

在上圖中，你還可能注意到我們的錯誤代碼存放在了ecx寄存器中，並且覆蓋rcx寄存器的指令現在取決於一個跟隨"jump if zero"指令的測試指令。這就意味著我們存儲在"ecx"寄存器的錯誤代碼只有不遵循跳轉的情況進行重寫。在新引入的代碼中，你可以發現以下內容：

將「al」設置為「1」並返回到先前的方法後，我們可以看到這個錯誤是如何實際修補的：

將"al"設置為"1"時，這一方法又對"al"的值是否是0做了判斷。如果不是0,它會設置"r14b"寄存器為0(由於前一個測試指令中沒有設置ZF標誌)。最後判斷"r14b"寄存器中的值是不是0。如果它是0,那麼會跟隨跳轉，將重寫"rcx" 寄存器這一步驟跳過(留下ecx寄存器保留我們的錯誤代碼)。錯誤代碼最後被驗證，以及我們的腳本會在防護語言模塊被攔截，導致執行失敗。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！