一個簡單的VBScript足以讓用戶獲得管理權限並完全繞過Windows 10上的UAC。
在普華永道英國安全研究人員Wietze Beukema的最新報告中，我們了解到將近300個Windows 10可執行文件容易受到DLL劫持的攻擊。
在普華永道英國安全研究人員Wietze Beukema的最新報告中，我們了解到將近300個Windows 10可執行文件容易受到DLL劫持的攻擊。
「事實證明，System32文件夾中的近300個可執行文件容易受到相對路徑DLL劫持的攻擊。您知道嗎，使用一個簡單的VBScript，其中一些EXE可以用於提升此類執行，而完全繞開UAC？」Beukema解釋說。
此處提到的漏洞是相對路徑DLL劫持，這是當攻擊者可能導致合法Windows可執行文件加載攻擊者選擇的任意DLL時，很可能是出於惡意目的。
DLL劫持攻擊可以證明對熟練的攻擊者有用，因為它們可以授予諸如任意代碼執行，特權提升和目標系統持久性之類的功能。
Beukema博客文章中涵蓋了DLL劫持的各種技術，包括DLL替換，DLL代理，DLL搜索順序劫持，Phantom DLL劫持，DLL重定向，WinSxS DLL替換以及相對路徑DLL劫持。
一個有效的例子
為了在實踐中演示相對路徑DLL劫持，Beukema著重研究了Windows 10（v1909）計算機上「 C：\ Windows \ System32」文件夾中存在的庫。
他將合法的winstat.exe進程複製到了系統上的downloads文件夾中。然後，他運行了進程監視工具procmon，以更好地了解EXE在執行過程中查找的DLL。
「這使我們能夠識別每個應用程式查詢的所有DLL，這將是所有潛在的可劫持DLL候選對象。但是並不能自動得出所有這些也都已加載（並因此執行）的結果。」研究人員解釋說。
「找出正確加載了哪些DLL的最可靠方法是編譯我們自己的DLL版本，並在成功加載後將其寫入唯一文件。如果我們隨後對所有目標可執行文件和DLL重複上述方法，則將導致文件收集，這些文件告訴我們已確認哪些DLL容易受到DLL劫持。」
但是，對攻擊者構成挑戰的是編譯一個可以由可執行文件啟動的自定義版本的DLL，而不會出現任何問題。為了獲得對合法DLL結構的可靠了解，Beukema建議使用DLL Export Viewer之類的工具進行分析。
該工具通過枚舉所有外部函數名稱來深入了解我們試圖重新編譯的DLL結構，這些名稱隨後將在DLL Hijacking漏洞中重複使用。
研究人員提供了一個完整的庫列表，這些庫是劫持攻擊的理想選擇。
他補充說：「這些不僅僅是理論上的目標，這些已經過測試並證實是有效的。該列表包括287個可執行文件和263個唯一的DLL。」
通過github.com/wietze/windows-dll-hijacking/提供了包含這些庫的完整列表的CSV。
一些限制
研究人員針對此示例攻擊所解釋的一些警告包括：
1）僅運行不需要任何參數的可執行文件
2）避免使用具有高級GUI和錯誤報告功能的應用程式
3）避免使用C ++編寫的DLL。
研究人員已經在Windows 10 64位（作業系統內部版本18362.476）上進行了測試，但表示：「某些[DLL]在[32位Windows]上將無法使用。您可以使用32位GCC編譯C文件，然後將可以正常使用。」
請注意，如Twitter線程中突出顯示的那樣，此處說明的攻擊可能不適用於所有Windows版本。
繞過UAC
Windows用戶帳戶控制（UAC）是Windows Vista及更高版本中添加的一項安全功能，該功能詢問用戶是否打算在執行高風險應用程式之前將其運行。
從Windows 7開始，由於一再要求用戶授權合法的過程（可能很快變得煩人），Microsoft在UAC框架內引入了內置的「例外」。有效地，這使受信任的系統DLL可以「自動提升」特權，而不必使用UAC提示來打擾用戶。
「考慮到這一點，您可以嘗試通過使用標記為自動提升的可執行文件來嘗試以提升的特權運行任意代碼，該可執行文件也容易受到DLL劫持的影響。如上一節所述，大約有35種這樣的可執行文件。」 Beukema解釋說。
如果成功利用了已執行的惡意DLL，則可以將其用於創建提升權限的命令提示符，從而以管理特權對計算機進行完全訪問。
不過，這裡有一個障礙。在期望任何DLL的「自動提升」特權之前，作業系統希望這些DLL存在於受信任的目錄中，該目錄不是用戶可寫的。
「要解決的問題是受信任目錄的問題：自動提升的可執行文件和自定義DLL都必須位於受信任目錄中，但是這些都不是用戶可寫的。」
此處提供了一些方便的模仿技術，例如創建一個模擬的「 C：\ windows \ system32」目錄（在Windows之後緊跟一個空格）。這個名稱異常的文件夾可能會誘使可執行文件將攻擊者創建的目錄視為「受信任位置」。
是否能夠創建這樣的目錄應被視為安全漏洞尚有爭議，因為它為攻擊者提供了利用DLL劫持漏洞的途徑。
「這是否是適當的安全漏洞尚待商--微軟認為不是，但至少是一個缺陷，因為大多數（非企業）Windows計算機默認使用的是「管理員帳戶」。無論哪種方式，這都為我們提供了一種出色的手段，通過它可以使DLL劫持更加強大。」研究人員說。
但是為什麼使用 VBScript？
作者建議使用VBScript的原因之一是因為創建名稱包含尾隨空格的Windows目錄不是通過「傳統方式」可以實現的。
「您可以像原始研究人員一樣，編譯一些C語言來完成此操作，但是事實證明，VBScript實際上也可以為我們做到這一點。以下概念驗證表明，僅需幾行代碼，您就可以使它起作用：」
當受到用戶質疑時，Beukema解釋了為什麼他在利用容易受到DLL劫持的可執行文件時選擇了VBScript。
「我知道……這只是因為PowerShell不允許您這樣做，而VBScript卻可以。而且由於它是VBScript，因此您無需帶上自己的編譯二進位文件即可使用此技巧，這意味著，除了自定義DLL之外，您還可以使用Living of the Land +腳本來完成所有工作。」
檢測和預防技術
Beukema提出了一些預防方法，可以用來阻止此類攻擊，例如，如果您的計算機上存在模擬Windows 文件夾中的活動，則可以對其進行查找。同樣，如果最終用戶足夠了解要執行的操作，則將UAC設置調整為「始終通知」可以幫助防止此類攻擊。
另一個策略是監視DLL創建和從意外文件路徑加載的實例：
「您可以從意外路徑中尋找前面提到的任何DLL的創建或加載，特別是在諸如％appdata％之類的臨時位置。畢竟，可以更改加載DLL的（合法）應用程式的名稱，但DLL的文件名始終是固定的。」
Beukema建議，在構建應用程式時，開發人員應強制使用絕對而非相對路徑來加載DLL，以及其他幾種技術。這些都不是足夠簡單的。
但是，如果適當地結合使用，預防措施（如研究人員所解釋的那樣）可以長期阻止DLL劫持攻擊。