前言

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

這些問題的根本原因來自常見的系統配置錯誤，這使得識別和利用這些問題非?？煽?。相比之下，傳統的基于內存損壞的本地權限提升漏洞通常需要固定偏移量，具體取決于目標使用的操作系統版本或系統構建。

可寫系統路徑目錄漏洞

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

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

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

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

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

可寫路徑問題的利用

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

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

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

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

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

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

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

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

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

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

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

IKEEXT 服務的奇特案例

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

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

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

替代開發(fā)技術

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

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

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

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

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

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

開發(fā)后操作指南

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

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

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

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

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

整治指導

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

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

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

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