來源：安全客
原文鏈接：https://www.brokenbrowser.com/detecting-local-files-to-evade-analysts/
譯者：WisFree
前言
上個月，我們一直都在嘗試弄清楚攻擊者到底是如何通過檢測目標系統中應用程序的相關MIME類型來對用戶進行攻擊的。如果目標計算機中安裝了反病毒工具的話，惡意軟件將拒絕下載惡意代碼。這樣一來，攻擊者不僅可以保證惡意軟件不會被檢測工具所檢測到，而且還可以在目標主機中潛伏很長的時間。當然了，所有的這一切都發生在瀏覽器中。雖然廠商及時修復了相關的漏洞，但我們現在仍然可以繞過補丁來實施攻擊。
漏洞概述
今天我們要講解的是另外一個指紋漏洞，這個漏洞將允許攻擊者檢測目標主機中是否存在某些類型的文件。根據Proofpoint公司的安全研究專家所透露的信息，這個漏洞是一個信息泄露漏洞，此前有很多不同的惡意廣告活動和漏洞利用工具都利用了這個漏洞來實施攻擊。目前，微軟公司已經成功修復了這個漏洞。
在2015年10月至12月期間，Proofpoint公司的安全研究專家發現了至少兩個信息泄露漏洞（CVE-2016-3351和CVE-2016-3298），并且已經將漏洞細節提交給了微軟公司。微軟于2016年9月份修復了漏洞CVE-2016-3351，并且在2016年10月份修復了漏洞CVE-2016-3298。但不幸的是，黑客在不到一天的時間里就成功繞過了這兩個補丁。
利用漏洞CVE-2016-3298
我們可以加載目標文件的內部資源，并通過檢查類似onload/onreadystate/onerror這樣的事件是否發生來檢測主機中是否存在某些目標文件（exe、dll和cpl等等），這種方法也是目前攻擊者最為常用的方法。實際上，IE瀏覽器會使用內部資源來加載信息頁面、錯誤信息、以及某些插件圖標。雖然這些資源嵌入在二進制文件之中，但是我們也可以單獨加載這些資源。
最常見的一個例子就是當我們嘗試在IE瀏覽器中加載無效的URL資源時，IE瀏覽器會顯示一個錯誤頁面。比如說，當我們在瀏覽器地址欄中輸入網址“http://invalidsite ”之后，IE瀏覽器就會將如下圖所示的頁面顯示給我們：
我們看得懂這個URL地址，但是瀏覽器不一定看得懂，而這個頁面很明顯跟我們輸入的網址沒有任何關系。接下來，我們可以通過檢查該頁面的屬性來找出該頁面真正的URL地址：在頁面空白處點擊鼠標右鍵，然后在彈出的菜單中選擇“頁面屬性”，瀏覽器便會將關于該頁面的信息顯示出來：
加載資源
正如我們所看到的那樣，該頁面的內容來自于res://ieframe.dll/dnserror.htm#http://invalidsite/，其中“res:”表示的是資源，而這是IE瀏覽器用來從二進制文件中加載內部資源所用的方法。默認情況下，瀏覽器會假設資源文件存在于目錄“windows/system32”之中，但是我們也可以修改這個路徑。比如說，如果我們安裝了Fiddler，我們就可以輕易地找出其中的一個有效資源，并將其提供給IE瀏覽器。接下來，我們就可以通過檢測readystate事件來查看資源是否加載成功了。
如果你使用的是Resource Hacker這樣的免費工具，那么你就可以直接讀取到資源的名稱和內容，并將它們以圖片或者HTML文件的形式進行加載。為了進行簡單的演示，我們在Resource Hacker中打開并查看dnserror.htm的內容，具體如下圖所示：
實際上，我們根本不需要通過Resource Hacker來查找有效資源，因為二進制文件中的默認資源都有固定不變的值。比如說，所有二進制文件的“文件信息”都可以通過資源“/16/1（16 == RT_VERSION）”來查找。需要注意的是，我們完全不必檢索每一個需要進行測試的文件，因為我們可以直接通過加載默認資源來實現我們的目的。比如說，我們可以向Fiddler提供資源的默認信息，而下面這段指令將會觸發一個readystatechange事件。
res://c:\Program?Files?(x86)\Fiddler2\Fiddler.exe/16/1
安裝補丁之前的PoC
為了利用這個漏洞，我們應該在一個iFrame中加載資源，并且記錄下onreadystate事件被觸發的次數。如果該事件被觸發了一次，則說明目標文件存在；如果被觸發了兩次，則說明該文件不存在。
關鍵代碼如下所示，如果你愿意的話，你也可以直接下載一個可用的PoC
下載地址 - 密碼：infected。
<iframe src="res://c:\Program Files (x86)\Fiddler2\Fiddler.exe/16/1" onreadystatechange="count++"></iframe>
<script>
count = 0;
// This onload gives the iFrame a bit of time to load.
// But has nothing to do with the method itself
window.onload = function()
{
if (count == 1) alert("File exists!");
else alert("File does not exist");
}
</script>改進PoC
上面的這個PoC在上周之前還是可以正常工作的，但是因為微軟在上周修復了這個漏洞，所以我們現在就得通過其他的方法來利用這個漏洞了。首先，讓我們來看一看攻擊者是怎么實現的。關鍵代碼如下圖所示：
在這里，惡意軟件的作者使用了三種不同的技術來檢測某一本地文件是否存在，但是漏洞現在已經被微軟修復了。在上面這段代碼中，第一個引起我注意的就是“mhtml:file”，因為即使IE禁用了“file:protocol”，但是mhtml仍然可以正常工作。于是我腦海中閃現了一個念頭：雖然“mhtml:file”和“res://”已經無法使用了，但如果將mhtml和res配合使用的話，會不會產生意想不到的效果呢？
如果你正在使用IE瀏覽器的話，你可以直接在線體驗一下這個漏洞[傳送門]。關鍵代碼如下所示：
<iframe src="mhtml:res://c:\Program Files (x86)\Fiddler2\Fiddler.exe/16/1" onload="count++"></iframe>
<script>
count = 0;
window.onload = function()
{
if (count == 1) alert("File exists!");
else alert("File does not exist");
}
</script>
如果你想深入了解這個漏洞和相關的補丁程序，或者你想尋找其他繞過方法的話，我建議你下載免費版的IDA，然后嘗試一下我們在之前利用mimeType漏洞時所使用的方法[傳送門]，你也許可以從中得到一些啟發。
我們現在已經知道的是，IE瀏覽器會非常樂意去加載類似“res://ieframe.dll”這樣的東西，所以我們就可以找出這部分代碼，然后看看是否能夠利用這些代碼來做更多有意思的事情。我直接告訴你吧，我們所要尋找的函數名為“IsIEResourcePage”。
接下來，我們要修改iFrame的location，并且要與之前設置為“res://ieframe.dll”時的返回值進行對比。
如果你懶得對返回數據進行手動對比的話，你也可以使用JavaScript腳本來完成這個任務。我在這里要跟大家分享一個小秘訣：當你在研究的過程中，最好使用window.open方法來修改iframe的location，盡量不要使用iframe.location。如果我們使用常規的修改方法，例如location.href和location.replace等方法，那么IE瀏覽器很可能會拒絕加載資源，此時瀏覽器將會返回一個“about:blank”頁面。
關鍵代碼如下所示：
<iframe name="ifr"></iframe>
<script>
// No errors, about:blank loaded in iFrame, very slow.
ifr.location = "res://testing.dll";
// Access Denied, nothing changes in the iFrame, super-fast.
window.open("res://testing.dll", "ifr");
// This last option can be used with a try/catch creating
// a battery of tests that will immediately return
// the result.
</script>總結
沒錯，即使是官方發布了某一漏洞的修復補丁，也并不意味著這個漏洞就無法再被利用了。我之所以要撰寫這篇文章，其中一個原因就是我想要將我所發現的東西分享給大家，以供大家學習和參考。但是我最重要的一個目的就是為了讓微軟公司認識到這個漏洞的嚴重性，希望他們能夠更加重視這種類型的漏洞，并提升這類漏洞的威脅等級。
攻擊者就是這樣，當某個漏洞“被修復”之后，他們又會立刻嘗試去尋找新的漏洞利用方法。在信息安全這個領域內，這種“貓捉老鼠”的游戲幾乎是永無止境的。最后，安全客祝大家挖洞愉快！
本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/87/
暫無評論