前言

最近整理了一些奇安信&華為&深信服大佬的課件資料+大廠面試課題，想要的可以私信自取，無償贈送給粉絲朋友~

這些問題的根本原因來自常見的系統(tǒng)配置錯誤，這使得識別和利用這些問題非常可靠。相比之下，傳統(tǒng)的基于內(nèi)存損壞的本地權(quán)限提升漏洞通常需要固定偏移量，具體取決于目標使用的操作系統(tǒng)版本或系統(tǒng)構(gòu)建。

可寫系統(tǒng)路徑目錄漏洞

可寫路徑本地權(quán)限提升漏洞源于系統(tǒng)管理員或應用程序安裝程序修改系統(tǒng)路徑環(huán)境變量以包含非特權(quán)用戶可寫目錄的情況。

此問題的典型根本原因是應用程序安裝程序或管理員在適當目錄（例如“程序文件”）之外安裝應用程序，然后隨后修改系統(tǒng)路徑環(huán)境變量以指向已安裝目錄。結(jié)果，創(chuàng)建的目錄從父目錄繼承了危險的權(quán)限。

這方面的一個例子是在“C:\Program Files”目錄中創(chuàng)建的目錄與“C:\”目錄中創(chuàng)建的目錄的繼承權(quán)限之間的明顯差異。如下圖所示，“Authenticated Users”組可以在“C:\”目錄中創(chuàng)建文件和文件夾。此外，此權(quán)限是可繼承的，這意味著它適用于所有未明確拒絕的已創(chuàng)建目錄。

相比之下，“Program Files”目錄默認不包含此權(quán)限，“Program Files”中創(chuàng)建的文件夾默認阻止非特權(quán)用戶寫入，如下圖所示。

通過執(zhí)行一個簡單的實驗，我們可以確認預期的行為。作為管理員，在 C:\Program Files\test 和 C:\test 中創(chuàng)建兩個名為“test”的文件夾。接下來，創(chuàng)建一個非特權(quán)用戶并嘗試寫入這兩個目錄。請注意，非管理員用戶可以寫入 C:\test\ 但不能寫入 C:\Program Files\test\，如下圖所示。

可寫路徑問題的利用

用可寫路徑漏洞的最直接方法是識別以 NT AUTHORITY\SYSTEM 運行的應用程序服務，該服務嘗試加載不存在的動態(tài)鏈接庫 (DLL) 或嘗試執(zhí)行不存在的可執(zhí)行文件。例如，服務可能會嘗試加載僅存在于桌面操作系統(tǒng)上的 DLL 文件。由于該文件在服務器操作系統(tǒng)上不存在，它最終會遍歷系統(tǒng)路徑，尋找該文件。從操作的角度來看，攻擊者的最佳方案是非特權(quán)用戶可以觸發(fā)此操作而無需重新啟動目標系統(tǒng)。

NetMan 服務，它允許非特權(quán)用戶通過公開的 COM 接口 [1] 與其交互。一個重要的注意事項是，根據(jù)微軟的說法，這種行為并不構(gòu)成 Windows 中的漏洞，因為系統(tǒng)正在執(zhí)行適當?shù)牟僮鱽硭阉髀窂?[3]。但是，如果第三方應用程序安裝程序在安裝過程中修改了系統(tǒng)路徑環(huán)境變量并引入了可寫路徑權(quán)限問題，則這很可能符合應用程序安裝程序中的漏洞/CVE。

但是，從利用的角度來看，事情要復雜得多，因為易受攻擊的服務可能會根據(jù)目標系統(tǒng)所利用的操作系統(tǒng)版本而有所不同。在下表中，我們概述了可用于通過 DLL 植入來提升權(quán)限的三個獨立服務以及該技術(shù)可行的相應操作系統(tǒng)版本。

當這些服務之一加載攻擊者提供的 DLL 時，Windows 加載程序?qū)⒄{(diào)用 DllMain 函數(shù)，而不管目標服務調(diào)用了哪些導出的函數(shù)。執(zhí)行 DllMain 后，攻擊者可以將自己添加到本地管理員組中。雖然這對于概念驗證漏洞利用通常很好，但從操作安全的角度來看，它通常并不理想。修改本地管理員的組成員身份可以創(chuàng)建事件日志條目，這些條目可以通過安全工具發(fā)出警報。一種更有效的方法是在特權(quán)服務上下文中執(zhí)行遠程管理工具，例如 Cobalt Strike 的信標有效負載。

在某些情況下，嘗試將信標加載到被劫持的進程中可能會導致死鎖。操作員犯的一個常見錯誤是在 DllMain 中的被劫持進程的上下文中調(diào)用反射加載程序。因為 Windows 加載程序在 DllMain 執(zhí)行期間持有加載程序鎖，所以當反射加載程序還調(diào)用 LoadLibrary 并等待加載程序鎖被釋放時，從 DllMain 調(diào)用反射加載程序會導致進程死鎖。解決此問題的最直接方法是等待服務調(diào)用與被劫持的 DLL 關(guān)聯(lián)的導出，此時加載程序鎖未激活。攻擊者可以對相應的服務可執(zhí)行文件執(zhí)行逆向工程，以揭示受害服務利用了哪些導出。

使用 Windows 任務計劃程序進行利用

一種通過針對 Windows 任務計劃程序服務來利用可寫路徑漏洞的方法。Gregory 發(fā)現(xiàn)此服務通過調(diào)用 LoadLibrary 函數(shù)在啟動時嘗試加載 WptsExtensions.dll 文件。利用此方法的缺點是觸發(fā)目標服務的行為需要重新啟動系統(tǒng)，因為該服務僅在系統(tǒng)啟動時嘗試加載 DLL。

利用此向量的開發(fā)相對簡單。攻擊者只需將惡意 DLL 放入可寫路徑目錄，然后等待或觸發(fā)系統(tǒng)重啟。但是，在 Windows Server 操作系統(tǒng)上，非管理用戶無權(quán)執(zhí)行關(guān)機或重新啟動操作。此外，重新啟動生產(chǎn)系統(tǒng)通常是不明智的，并且可能對紅隊的運營安全產(chǎn)生不利影響。

使用 NetMan 服務進行開發(fā)

通過使用公開的 COM 接口枚舉連接屬性，Labro 可以觸發(fā)對 LoadLibrary 的調(diào)用以加載“wlanapi.dll”文件 。雖然默認情況下任何支持的 Windows Server 操作系統(tǒng)上都不存在“wlanapi.dll”文件，但它確實存在于 Windows 10 上，這使得該技術(shù)僅在針對 Windows Server 執(zhí)行權(quán)限提升時才可行。但是，即使在服務不能直接用于通過此向量進行本地特權(quán)升級的情況下，攻擊者仍然可以使用該服務執(zhí)行橫向移動或建立持久性。

在這種情況下，利用相對簡單，只需將攻擊者“wlanapi.dll”文件復制到可寫路徑目錄即可。在 Windows Server 2012 R2 上，該服務將嘗試加載名為“wlanhlp.dll” 的文件；但是，Praetorian 的測試表明該服務現(xiàn)在嘗試加載“wlanapi.dll”。接下來，攻擊者需要利用 Labro 提供的代碼來枚舉 COM 上的網(wǎng)絡適配器，從而觸發(fā) DLL 加載嘗試 。

IKEEXT 服務的奇特案例

在一篇題為“分類 DLL 植入漏洞”的文章中，Microsoft 安全響應中心 (MSRC) 團隊描述了他們在分類各種類型的 DLL 植入問題時遵循的流程。MSRC 聲明“屬于 PATH 目錄 DLL 種植類別的 DLL 種植問題被視為‘無法修復’?！?[3] 在 IKEEXT 服務的案例中，Microsoft 似乎偏離了這一既定政策的一個有趣案例。

在這種情況下，微軟似乎已經(jīng)通過修改 LoadLibrary 調(diào)用來解決 IKEEXT 服務 DLL 劫持問題，改為調(diào)用 LoadLibraryEx，并將 LOAD_LIBRARY_SEARCH_System32 標志設置為僅在 System32 目錄中搜索“wlbsctrl.dll”文件。

但是，由于該服務在啟動時仍嘗試加載不存在的 DLL，因此該服務對于利用任意寫入問題或執(zhí)行橫向移動仍然有用。

替代開發(fā)技術(shù)

之前我們說過，利用可寫路徑漏洞最簡單的方法是識別以“NT AUTHORITY\SYSTEM”運行的服務，該服務試圖通過遍歷系統(tǒng)路徑來加載不存在的DLL。但是，確實存在另一種方法來利用此問題，方法是執(zhí)行相同的攻擊，但針對以“NT AUTHORITY\NETWORK SERVICE”或“NT AUTHORITY\LOCAL SERVICE”運行的服務。默認情況下，Windows 服務被賦予 SeImpersonatePrivilege 權(quán)限。

其中記錄了他們發(fā)現(xiàn) Windows 傳真服務在啟動時嘗試加載不存在的 DLL。此外，Windows 傳真服務的配置使得任何用戶都可以觸發(fā)服務的啟動。

因為默認情況下 Windows 傳真服務被授予 SeImpersonatePrivilege 權(quán)限，所以可以首先創(chuàng)建一個命名管道，然后誘導更多特權(quán)服務訪問命名管道以模擬客戶端服務。在這篇文章中，作者利用了 James Foreshaw 在他的帖子“Sharing a Logon Session a Little Too Much”中記錄的一種技術(shù)。該技術(shù)涉及創(chuàng)建命名管道并使用 \\localhost\ 路徑通過它進行連接，這會觸發(fā)來自 SMB 網(wǎng)絡重定向器的身份驗證。

然后，作者利用模擬來訪問與 RpcSs 服務關(guān)聯(lián)的訪問令牌，打開與 RpcSs 進程關(guān)聯(lián)的服務的句柄，并掃描句柄表以識別與“NT AUTHORITY\SYSTEM”用戶關(guān)聯(lián)的訪問令牌。在識別此令牌后，該令牌被復制以獲得系統(tǒng)權(quán)限。

此外，Clément Labro 在其題為“PrintSpoofer – 在 Windows 10 和 Server 2019 上濫用模擬特權(quán)”的博文中概述了從 SeImpersonatePrivilege 轉(zhuǎn)移到“NT AUTHORITY\SYSTEM”的另一種方法，以及用于操作該技術(shù)的開源工具。

不幸的是，當 Windows 傳真服務嘗試加載不存在的“ualapi.dll”文件時，它通過調(diào)用帶有 LOAD_LIBRARY_SEARCH_SYSTEM32 標志的 LoadLibraryExW 函數(shù)來加載，這意味著在這種情況下服務不會遍歷系統(tǒng)路徑環(huán)境變量嘗試加載 DLL 時。相反，該服務將僅檢查“C:\Windows\System32\”目錄中的 DLL 文件。雖然這對橫向移動和持久性都有用，但在我們希望利用這種情況下的可寫路徑目錄漏洞的情況下，它就沒有用了。

開發(fā)后操作指南

從操作的角度來看，本地權(quán)限提升的最理想目標之一是多用戶系統(tǒng)，這些系統(tǒng)易于訪問并被多個部門或用戶的管理層廣泛使用。

Citrix 是這種設計模式的完美示例。在許多組織中，我們注意到當連接來自內(nèi)部網(wǎng)絡時，訪問 Citrix 不需要多重身份驗證。此外，組織內(nèi)的任何員工通常都可以訪問 Citrix，并且使用往往跨越多個部門。此外，Citrix 主機通常安裝了大量應用程序，因此我們經(jīng)常觀察到這些主機上的可寫路徑權(quán)限提升問題。

在獲得內(nèi)部立足點后，我們可以嘗試通過 SOCKS 代理 Citrix 接收器桌面應用程序以繞過多因素身份驗證，從而從內(nèi)部角度連接到 Citrix。以這種方式訪問 Citrix 通常提供了一種快速簡便的方法，可以在風險最小的環(huán)境中實現(xiàn)初始橫向移動。一旦實現(xiàn)對 Citrix 的訪問，我們通?？梢酝ㄟ^利用與路徑中可寫目錄相關(guān)的配置問題來提升權(quán)限。

使用 NT AUTHORITY\SYSTEM 級別訪問權(quán)限，我們可以安裝惡意安全支持提供程序，以記錄對環(huán)境中的任何 Citrix 主機進行身份驗證的所有用戶的明文憑據(jù)。通常，這為我們提供了足夠的訪問權(quán)限來實現(xiàn)參與的目標。

當針對具有成熟檢測和響應能力的環(huán)境時，針對這些類型的共享用戶系統(tǒng)特別有益。在這些類型的環(huán)境中，標準的紅隊攻擊和橫向移動技術(shù)將很快被檢測到并導致驅(qū)逐。

整治指導

可寫路徑問題的修復相對容易，因為只需要修改可寫目錄的權(quán)限。如果應用程序安裝程序通過修改系統(tǒng)路徑引入了可寫路徑漏洞，請考慮將問題報告給應用程序供應商，以便可以為所有客戶修復問題。例如，CVE-2020-15264 涵蓋了 Boxstarter 應用程序安裝程序修改系統(tǒng)路徑以在程序文件中包含可寫目錄的情況。

從架構(gòu)的角度來看，操作系統(tǒng)級別的用戶之間的安全邊界通常比虛擬機管理程序級別的虛擬機之間實施的安全邊界要弱。因此，我們通常建議盡可能避免使用單系統(tǒng)多用戶設計模式，尤其是在多層用戶或部門訪問系統(tǒng)的場景中。

文章來源公眾號：Khan安全攻防實驗室

好了，這篇文章的內(nèi)容發(fā)貨聯(lián)盟就和大家分享到這里，如果大家網(wǎng)絡推廣引流創(chuàng)業(yè)感興趣，可以添加微信：80709525  備注：發(fā)貨聯(lián)盟引流學習； 我拉你進直播課程學習群，每周135晚上都是有實戰(zhàn)干貨的推廣引流技術(shù)課程免費分享！