前言

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

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

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

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

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

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

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

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

可寫路徑問題的利用

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

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

但是，從利用的角度來看，事情要復(fù)雜得多，因?yàn)橐资芄舻姆?wù)可能會(huì)根據(jù)目標(biāo)系統(tǒng)所利用的操作系統(tǒng)版本而有所不同。在下表中，我們概述了可用于通過 DLL 植入來提升權(quán)限的三個(gè)獨(dú)立服務(wù)以及該技術(shù)可行的相應(yīng)操作系統(tǒng)版本。

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

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

使用 Windows 任務(wù)計(jì)劃程序進(jìn)行利用

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

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

使用 NetMan 服務(wù)進(jìn)行開發(fā)

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

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

IKEEXT 服務(wù)的奇特案例

在一篇題為“分類 DLL 植入漏洞”的文章中，Microsoft 安全響應(yīng)中心 (MSRC) 團(tuán)隊(duì)描述了他們?cè)诜诸惛鞣N類型的 DLL 植入問題時(shí)遵循的流程。MSRC 聲明“屬于 PATH 目錄 DLL 種植類別的 DLL 種植問題被視為‘無法修復(fù)’?！?[3] 在 IKEEXT 服務(wù)的案例中，Microsoft 似乎偏離了這一既定政策的一個(gè)有趣案例。

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

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

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

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

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

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

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

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

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

開發(fā)后操作指南

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

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

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

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

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

整治指導(dǎo)

可寫路徑問題的修復(fù)相對(duì)容易，因?yàn)橹恍枰薷目蓪懩夸浀臋?quán)限。如果應(yīng)用程序安裝程序通過修改系統(tǒng)路徑引入了可寫路徑漏洞，請(qǐng)考慮將問題報(bào)告給應(yīng)用程序供應(yīng)商，以便可以為所有客戶修復(fù)問題。例如，CVE-2020-15264 涵蓋了 Boxstarter 應(yīng)用程序安裝程序修改系統(tǒng)路徑以在程序文件中包含可寫目錄的情況。

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

文章來源公眾號(hào)：Khan安全攻防實(shí)驗(yàn)室

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