RPC漏洞挖掘案例研究（上）

2018年8月底，一名自稱「沙盒逃脫者」(SandboxEscaper)的女性研究人員發布了一個Windows本地許可權升級0 day漏洞。另外，還附上一個概念性驗證攻擊程序，允許黑客讀取系統中未經授權的區域，不過目前她的GitHub帳號已被封了。這是因為從該漏洞被公開發布到攻擊者使用這一漏洞進行攻擊，不到兩周的時間，這讓網路安全機構根本來不及應對。

安全研究人員相信，了解這種漏洞攻擊的運行原理將極大的幫助他們找到類似SandboxEscaper在Windows任務計劃程序（Windows Task Scheduler）中發現的漏洞。在這篇文章中，我們將討論通過SandboxEscaper通過濫用RPC伺服器上的符號鏈接來發現許可權升級漏洞的方法。

繼今年8月及10月之後， SandboxEscaper在12月又第三次公開披露了Windows的0 day漏洞了，儘管前兩次都招致批評，且本月她還收到Google的警告通知，指出她已被FBI盯上，但SandboxEscaper似乎不為所動，依然不理會安全社群的「責任披露」原則，持續直接對外公開披露安全漏洞。

原來，Windows任務計劃程序在其通過RPC伺服器公開的遠程過程調用（RPC）應用程序編程介面（API）中存在漏洞。事實上，大多數RPC伺服器由運行本地系統許可權的系統進程託管，並且允許具有較低許可權的RPC客戶端與它們交互。與其他軟體一樣，這些RPC伺服器可能容易受到拒絕服務、內存損壞和邏輯漏洞等軟體漏洞的影響。換句話說，攻擊者可以利用RPC伺服器中可能存在的任何漏洞發起攻擊。

0 day漏洞如此迅速流行的原因之一是潛在的漏洞非常容易被利用，它是由程序邏輯漏洞引起的，只要使用正確的工具和技術，程序邏輯漏洞就很容易被發現。這種特殊類型的許可權升級漏洞通常使用偽符號鏈接來升級文件或文件夾，進而導致普通用戶的許可權升級。對於感興趣的人，網上有有大量關於符號鏈接攻擊的資源。

如何在動態條件和靜態條件下發現RPC伺服器的漏洞

對於研究人員來說，在進行一個新的研究主題時，都會查看一下是否有可用的開源工具。幸運的是，Microsoft RPC是一個眾所周知的協議，在過去的幾十年中，研究人員對它進行了很好的逆向工程。比如，研究人員已經開源了一個名為RpcView的工具，它是識別運行在Windows操作系統上的RPC服務的一個非常方便的工具。這絕對是我最喜歡的RPC工具之一，具有許多高效實用的功能，例如搜索RPC介面通用惟一標識符(UUID)、RPC介面名稱等。

但是，我們本文的目的不是將所有RPC信息反編譯並導出到文本文件中。幸運的是，在閱讀源代碼時，我們發現其中已經包含了我們需要的功能，但是默認情況下它不會被啟用，只能在調試模式下使用特定的命令行參數被觸發。由於此限制，我們在啟用該功能時，會將現有的DecompileAllInterfaces函數調整為RpcView GUI。如果你對使用這個功能感興趣，可以在Github存儲庫中使用我們自定義的RpcView工具。我們現在可以在下一節中討論「反編譯所有介面」 功能的好處時，詳細談到。

RpcView會反編譯所有介面

在分析RPC伺服器的行為時，我們總是通過RPC介面調用API。通過RPC客戶端向伺服器發送RPC請求，然後使用SysInternals中的Process Monitor工具觀察其行為，進而實現與感興趣的RPC伺服器的這種交互。在我看來，最方便的方法是通過腳本而不是重新編寫需要程序編譯的C / C ++ RPC客戶端，編寫很費時間。

本文，我們將使用的是PythonForWindows工具。它以Python化的方式提供了一些Windows功能的抽象，這在很大程度上依賴於Python的ctypes 模塊。它還包含一個RPC庫，該庫提供了一些方便的包裝函數，節省了我們編寫RPC客戶端時的時間。例如，典型的RPC客戶端二進位文件需要定義介面定義語言，你需要手動實現綁定操作，這通常涉及一些c++代碼，具體的請參見下面的代碼段1和代碼段2，它們演示了如何使用最少的漏洞處理代碼編寫RPC客戶端腳本和編程之間的差異。

import sys

import ctypes

import windows.rpc

import windows.generated_def as gdef

from windows.rpc import ndr

StorSvc_UUID = r"BE7F785E-0E3A-4AB7-91DE-7E46E443BE29"

class SvcSetStorageSettingsParameters(ndr.NdrParameters):

MEMBERS = [ndr.NdrShort, ndr.NdrLong, ndr.NdrShort, ndr.NdrLong]

def SvcSetStorageSettings():

print "[+] Connecting...."

client = windows.rpc.find_alpc_endpoint_and_connect(StorSvc_UUID, (0,0))

print "[+] Binding...."

iid = client.bind(StorSvc_UUID, (0,0))

params = SvcSetStorageSettingsParameters.pack([0, 1, 2, 0x77])

print "[+] Calling SvcSetStorageSettings"

result = client.call(iid, 0xb, params)

if len(str(result)) > 0:

print " [*] Call executed successfully!"

stream = ndr.NdrStream(result)

res = ndr.NdrLong.unpack(stream)

if res == 0:

print " [*] Success"

else:

print " [*] Failed"

if __name__ == "__main__":

SvcSetStorageSettings()

代碼段1:使用PythonForWindows RPC客戶端的SvcSetStorageSettings

RPC_STATUS CreateBindingHandle(RPC_BINDING_HANDLE *binding_handle)

{

RPC_STATUS status;

RPC_BINDING_HANDLE v5;

RPC_SECURITY_QOS SecurityQOS = {};

RPC_WSTR StringBinding = nullptr;

RPC_BINDING_HANDLE Binding;

StringBinding = 0;

Binding = 0;

status = RpcStringBindingComposeW(L"BE7F785E-0E3A-4AB7-91DE-7E46E443BE29", L"ncalrpc", nullptr, nullptr, nullptr, &StringBinding);

if (status == RPC_S_OK)

{

status = RpcBindingFromStringBindingW(StringBinding, &Binding);

RpcStringFreeW(&StringBinding);

if (!status)

{

SecurityQOS.Version = 1;

SecurityQOS.ImpersonationType = RPC_C_IMP_LEVEL_IMPERSONATE;

SecurityQOS.Capabilities = RPC_C_QOS_CAPABILITIES_DEFAULT;

SecurityQOS.IdentityTracking = RPC_C_QOS_IDENTITY_STATIC;

status = RpcBindingSetAuthInfoExW(Binding, 0, 6u, 0xAu, 0, 0, (RPC_SECURITY_QOS*)&SecurityQOS);

if (!status)

{

v5 = Binding;

Binding = 0;

*binding_handle = v5;

}

}

}

if (Binding)

RpcBindingFree(&Binding);

return status;

}

VOID RpcSetStorageSettings()

{

RPC_BINDING_HANDLE handle;

RPC_STATUS status = CreateBindingHandle(&handle);

if (status != RPC_S_OK)

{

_tprintf(TEXT("[-] Error creating handle %d
"), status);

return;

}

RpcTryExcept

{

if (!SUCCEEDED(SvcSetStorageSettings(0, 1, 2, 0x77))

{

_tprintf(TEXT("[-] Error calling RPC API
"));

return;

}

}

RpcExcept(1)

{

RpcStringFree(&instanceid);

}

RpcEndExcept

}

代碼段2:使用c++ RPC客戶端的SvcSetStorageSettings

RPC客戶端成功地執行了相應的RPC API之後，我們使用Process Monitor來監控其活動。流程監控器在動態分析中非常有用，因為它提供了基於事件的API運行時信息。Process Monitor是一款擁有功能強大的監控和過濾的高級WindowsProcess Monitor 工具，可實時顯示文件系統、註冊表、進程或線程的活動。它結合了兩個 Sysinternals 的舊版工具 Filemon 和 Regmon 的功能，並添加了一個包含豐富的和非破壞性的廣泛增強過濾功能列表，全面的事件屬性(例如會話 ID 和用戶名稱)，可靠的進程信息，每個操作的完整線程、堆棧與集成符號支持，同時記錄到一個文件中，以及更多。如圖2所示，它使你能夠跟蹤事件的API調用。

Process Monitor API調用堆棧

例如，在通過IDA Pro這樣的反彙編程序進行靜態分析時，我們可以使用地址和路徑信息精確地指出對應的模塊和函數常式。這很有用，因為有時你可能無法僅使用Process Monitor的輸出信息來發現潛在的符號鏈接攻擊模式。這就是為什麼通過反彙編程序進行靜態分析，以幫助我們發現競態條件漏洞，這些漏洞將在本系列博客的第二部分中詳細討論。

微軟通用遙測客戶端(Universal Telemetry Client,UTC)案例研究

你聽說過微軟正在Windows 10及以上版本上收集客戶信息、數據和文件啟動信息嗎?你有沒有想過其中的運行原理?如果你感興趣，可以在這篇關於UTC 的優秀文章中詳細了解到。

在開始分析之前，我們首先將所有RPC介面從RpcView GUI導出到文本文件。生成的文本文件包含可從RPC伺服器調用的所有RPC API。然後，我們從輸出文本文件中查找接受寬字元串作為輸入的RPC API，直到發現來自diagtrack.dll的一個更有趣的RPC介面。稍後，我們會確認此DLL組件負責UTC的功能是否實現，這可以通過Microsoft Windows Diagnostic Tracking的名稱判斷，以下是RpcView GUI中具體的描述信息。

RpcView顯示了UTC的DLL組件，其中一個RPC介面接受寬字元串作為輸入

由於我們的目標是找到可能接受最終導致許可權升級的輸入文件路徑的API，正如Windows任務計劃程序漏洞所示的那樣。但是僅這個漏洞就提供了16個可能的API，如圖3所示。顯然，我們需要過濾掉那些我們不感興趣的API。因此，我們必須使用IDA Pro並從靜態分析開始，找出應該深入研究的API。

我通常會首先找到RPC函數RpcServerRegisterIf，它通常用於在RPC伺服器上註冊介面規範。介面規範包含由特定RPC伺服器託管的RPC介面的定義。根據MSDN的說明，介面規範位於函數的第一個參數中，該參數由RPC_SERVER_INTERFACE數據結構表示，其定義如下所示:

struct _RPC_SERVER_INTERFACE

{

unsigned int Length;

RPC_SYNTAX_IDENTIFIER InterfaceId;

RPC_SYNTAX_IDENTIFIER TransferSyntax;

PRPC_DISPATCH_TABLE DispatchTable;

unsigned int RpcProtseqEndpointCount;

PRPC_PROTSEQ_ENDPOINT RpcProtseqEndpoint;

void *DefaultManagerEpv;

const void *InterpreterInfo;

unsigned int Flags;

};

介面規範的InterpreterInfo是指向MIDL_SERVER_INFO數據結構的指針，該數據結構由DispatchTable指針組成，該指針保存特定RPC介面支持的介面API的信息，這些信息正是我們正在查找的內容。

typedef struct _MIDL_SERVER_INFO_

{

PMIDL_STUB_DESC pStubDesc;

const SERVER_ROUTINE* DispatchTable;

PFORMAT_STRING ProcString;

const unsigned short* FmtStringOffset;

const STUB_THUNK* ThunkTable;

PRPC_SYNTAX_IDENTIFIER pTransferSyntax;

ULONG_PTR nCount;

PMIDL_SYNTAX_INFO pSyntaxInfo;

} MIDL_SERVER_INFO, *PMIDL_SERVER_INFO;

下圖是一個動圖，說明了我們如何遍歷導入地址表以確定IDA Pro中的DispatchTable。

通過在IDA Pro中遍歷IAT來確定RPC公開的API

在我們使用UtcAPI前綴確定UTC的介面API之後，如上圖所示，我們會嘗試確定這些介面API是否會導致訪問控制列表(ACL) API，例如SetNamedSecurityInfo和SetSecurityInfo。之所以我們對這些ACL API感興趣，是因為它們可以用於更改對象(無論是文件、目錄還是註冊表對象)的自主訪問控制(DACL)安全描述符。IDA Pro中另一個可能未得到充分利用的有用功能是它的鄰近視圖（proximity view），它會顯示一個函數常式的調用圖，該函數常式將以圖形的形式顯示。我們可以使用鄰近視圖來查找前面提到的ACL API引用或調用的函數常式。

IDA的鄰近視圖，它顯示了SetSecurityInfo和diag .dll中的函數常式之間的相關性

然而，當我們試圖查找SetSecurityInfo和UtcAPI之間的相關性時，IDA Pro里並沒有什麼有價值的線索。進一步深入研究後，我們發現UtcAPI將客戶端的RPC請求放置到將由非同步線程處理的運行項隊列中。如上圖所示，當Microsoft::Diagnostic::EscalationWorkItem::Execute被觸發時，SetSecurityInfo將會被執行。基本上，這是一個回調函數，負責執行RPC客戶端提交的運行項中保存的升級請求。

此時，我們需要弄清楚如何提交升級請求。在試過各種應用程序之後，我們遇到了Microsoft Feedback Hub， Feedback Hub是微軟在Windows 10系統上收集建議和反饋的官方應用，該應用除了用戶表達關注、報告漏洞等，還充當了調試報告診斷信息的重要工具，在Windows 10上是默認安裝的，是一個通用Windows平台（UWP）應用程序。有時候，你可能會發現調試UWP應用程序很有用。遺憾的是，你無法直接在WinDbg下打開或添加UWP應用程序，並期望它能神奇地運行。但是，你可以通過Windows 10 SDK中包含的窗口調試器（Window Debugger）附帶的PLMDebug工具來啟用UWP應用程序調試。我們可以先通過Powershell內置的cmdlet確定Feedback Hub的完整包系列名稱：

PS C:Users
esearcher> Get-AppxPackage | Select-String -pattern "Feedback"

Microsoft.WindowsFeedbackHub_1.1809.2971.0_x86__8wekyb3d8bbwe

PS C:Users
esearcher> cd "c:Program FilesWindows Kits10Debuggersx86"

PS C:Program FilesWindows Kits10Debuggersx86>

PS C:Program FilesWindows Kits10Debuggersx86> .plmdebug.exe /query

Microsoft.WindowsFeedbackHub_1.1809.2971.0_x86__8wekyb3d8bbwe

Package full name is Microsoft.WindowsFeedbackHub_1.1809.2971.0_x86__8wekyb3d8bbwe.

Package state: Unknown

SUCCEEDED

PS C:Program FilesWindows Kits10Debuggersx86>

獲得完整的包名稱後，我們再次使用PLMDebug為Feedback Hub啟用UWP調試。

c:Program FilesWindows Kits10Debuggersx86>plmdebug.exe /enabledebug Microsoft.WindowsFeedbackHub_1.1809.2971.0_x86__8wekyb3d8bbwe "c:program fileswindows kits10Debuggersx86windbg.exe"

Package full name is Microsoft.WindowsFeedbackHub_1.1809.2971.0_x86__8wekyb3d8bbwe.

Enable debug mode

SUCCEEDED

這樣在下次啟動Feedback Hub時，應用程序將自動執行並添加到WinDbg。

確定來自Process Monitor事件屬性的API調用的偏移量

啟動Feedback Hub後，我們將按照應用程序的屏幕說明進行操作，並開始在Process Monitor中查看活動。這是一個好兆頭，因為它意味著我們正在走上正軌。當我們查看突出顯示的SetSecurityFile事件的調用堆棧時，就可以在偏移量0x15A091處找到ACL API SetSecurityInfo的返回地址（diagtrack.dll的基地址可以在Event Properties的Process選項卡中找到）。如你所見，這個偏移位於Microsoft::Diagnostics::Utils::FileSystem::SetTokenAclOnFile常式中，該常式不但出現在上圖中的反彙編程序，並且也出現在圖5中所示的鄰近視圖中。這證明了我們可以使用Feedback Hub來找到我們想要的代碼路徑。

除此之外，我們通過查看Process Monitor的輸出內容還會發現，這個事件會試圖設置文件對象的DACL，但是通過執行代碼靜態分析來確定文件對象是如何生成的可能會非常耗時。幸運的是，我們可以將本地調試器添加到具有管理許可權的UTC服務的svchost.exe程序，因為該進程不受Protected Process Light（PPL）機制的保護，我們就可以靈活地動態調試UTC服務，以了解如何檢索文件路徑。

在後台，所有的反饋回來的詳細信息和附件將通過Feedback Hub提交後保存在格式為％DOCUMENTS％ FeedbackHub \ diagtracktempdir的臨時文件夾中。添加到diagtracktempdir的隨機十進位數是通過BCryptGenRandom API生成的，這意味著生成的十進位數是不可預測的。但是，進行符號鏈接攻擊最重要的條件之一是能夠預測文件或文件夾的名稱，因此，隨機diagtracktempdir名稱增加了利用符號鏈接漏洞的難度。所以，我們再想其他辦法去查找其他潛在的漏洞。

在我們試圖弄清楚如何設置diagtracktempdir安全描述符時，卻發現該文件夾使用的是顯式安全描述符字元串O:BAD:P(A;OICI;GA;; BA)(A;OICI;GA;; SY)創建的，這意味著對象的DACL將僅授予管理員和本地系統用戶訪問許可權。但是，如果相應地設置了以下註冊表項，則將忽略顯式安全描述符：

HKEY_LOCAL_MACHINESoftwareMicrosoftDiagnosticsDiagTaskTestHooksVolatile

「NoForceCopyOutputDirAcl」 = 1

簡而言之，當上面的註冊表項不存在時，diagtracktempdir將被強制使用顯式的安全描述符，否則默認的DACL將應用於可能引發某些安全問題的文件夾，因為在文件夾創建過程中沒有使用模擬令牌。不過，如果存在任意註冊表寫入漏洞，則可以將顯式安全描述符繞過此文件夾。但這並不是我們的目的，所以我們最好的選擇是再次調查Process Monitor。

設置DACL並重命名文件夾diagtracktempdir

基本上，我們可以將上圖中標誌的操作過程總結如下:

1.在本地系統許可權下，授予對diagtracktempdir上當前登錄用戶的訪問許可權；

2.將diagtracktempdir重命名為模擬環境下的GUI樣式的文件夾；

3.在模擬環境下撤消對diagtracktempdir上登錄的當前用戶的訪問許可權；

下面的代碼段對應於上圖所示的操作:

bQueryTokenSuccessful = UMgrQueryUserToken(hContext, v81, &hToken);

if ( hToken && hToken != -1 )

{

// This will GRANT access of the current logged in user to the directory in the specified handle

bResultCopyDir = Microsoft::Diagnostics::Utils::FileSystem::SetTokenAclOnFile(&hToken, hDir, Sid, GRANT_ACCESS)

if ( !ImpersonateLoggedOnUser(hToken) )

{

bResultCopyDir = 0x80070542;

}

}

// Rename diagtracktempdir to GUID-styled folder name

bResultCopyDir = Microsoft::Diagnostics::Utils::FileSystem::MoveFileByHandle(SecurityDescriptor, v65, Length);

if ( bResultCopyDir >= 0 )

{

boolRenamedSuccessful = 1;

// This will REVOKE access of the current logged in user to the directory in the specified handle

bSetAclSucessful = Microsoft::Diagnostics::Utils::FileSystem::SetTokenAclOnFile(&hToken, hDir, Sid, REVOKE_ACCESS) if (bSetAclSucessful)

{

// Cleanup and RevertToSelf

return;

}

}

else

{

lambda_efc665df8d0c0615e3786b44aaeabc48_::operator_RevertToSelf(&hTokenUser);

// Delete diagtracktempdir folder and its contents

lambda_8963aeee26028500c2a1af61363095b9_::operator_RecursiveDelete(&v83);

}

代碼段3:先授予diagtracktempdir訪問許可權，然後撤銷該訪問許可權

從代碼段3中，我們可以判斷文件重命名操作何時失敗。如果bResultCopyDir的值小於0，它將繼續調用RecursiveDelete函數。值得注意的是，在調用RecursiveDelete函數之前調用RevertToSelf函數來終止模擬，這意味著可以在本地系統許可權下刪除目標目錄及其內容，如果我們設法使用一個符號鏈接將diagtracktempdir重定向到任意文件夾中，就能夠實現任意文件刪除。幸運的是，微軟已經緩解了潛在的重解析點(reparse points)刪除漏洞。此RecursiveDelete函數已顯式跳過任何設置了FILE_ATTRIBUTE_REPARSE_POINT標誌的目錄或文件夾，該標誌通常是為一個連接文件夾設置的，所以我們可以確認這個遞歸刪除常式不會帶來任何安全風險。

由於我們無法在此演示任意文件刪除的過程，所以我們決定演示如何將任意文件寫入diagtracktempdir目錄。在查看代碼時，我們意識到在遞歸刪除常式完成後，UTC服務不會刪除當前登錄用戶的diagtracktempdir的安全描述符。這是有意為之的，因為你不需要將新的DACL強加到將要刪除的文件夾中，這是冗餘的運行。但是，這也為攻擊者提供了一個潛在的競態條件機會，可以通過在同一個目錄中創建具有獨佔文件句柄的文件來防止刪除升級的diagtracktempdir。嘗試使用獨佔文件句柄打開和刪除文件時，RecursiveDelete函數遇到共享衝突，然後正常退出操作。畢竟，攻擊者可以在受限制的目錄中刪除並執行升級的diagtracktetempdir中的文件，例如C:WINDOWSSystem32。

緊接著，我們會問文件重命名操作如何會失敗?深入研究Microsoft::Diagnostics::Utils::FileSystem: MoveFileByHandle的底層實現，我們發現它本質上是一個調用SetFileInformationByHandle API的包裝器函數。從這個API生成的底層內核函數似乎總是能夠獲得具有寫入訪問許可權的父目錄的文件句柄。例如，如果該句柄當前被引用到c:lahabc，它將嘗試以c: blah的寫入訪問許可權獲取文件句柄。但是，如果我們刪除一個當前登錄用戶的具有寫入訪問許可權的目錄，那麼Microsoft::Diagnostics::Utils::FileSystem::MoveFileByHandle可能無法正確執行。以下文件路徑就是一個很好的選擇，因為它們是不允許為普通用戶帳戶創建文件夾的受限文件夾:

C:WINDOWSSystem32

C:WINDOWS asks

由於某些升級請求會將一堆日誌文件寫入我們的受控diagtracktempdir並且它們將需要一些時間來刪除，因此這個競態條件不會有任何可以被利用的漏洞。因此，如果我們在目標目錄中成功創建了一個獨佔文件句柄，那麼在具有多個內核的現代系統中，競態條件下的漏洞是不會發生的。

接下來，我們需要找到使用UtcAPI所需的正確參數以編程方式觸發代碼路徑的方法。能夠調試並設置RPC函數上的斷點，Feedback Hub中的NdrClientCall確實使我們的運行更輕鬆。調試器會顯示方案ID以及我們應該發送到UtcApi的升級路徑。在本文的示例中，我們將使用方案ID ，因為它似乎總是在UtcAPI_EscalateScenarioAsync常式被觸發時顯示，並且它也會產生RPC伺服器上所需的代碼路徑。請注意，升級路徑還允許我們控制將創建diagtracktempdir的位置。

Breakpoint 0 hit

eax=0c2fe7b8 ebx=032ae620 ecx=0e8be030 edx=00000277 esi=0c2fe780 edi=0c2fe744

eip=66887154 esp=0c2fe728 ebp=0c2fe768 iopl=0 nv up ei pl nz na po nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202

Helper+0x37154:

66887154 ff15a8f08866 call dword ptr [Helper!DllGetActivationFactory+0x6d31 (6688f0a8)] ds:0023:6688f0a8=

0:027> dds esp l9

0c2fe728 66892398 Helper!DllGetActivationFactory+0xa021

0c2fe72c 66891dca Helper!DllGetActivationFactory+0x9a53

0c2fe730 0e8be030

0c2fe734 1881a45e // Scenario ID

0c2fe738 445201fd

0c2fe73c 234ae4ac

0c2fe740 e3666e66

0c2fe744 00000000

0c2fe748 032ae620 // Escalation path

0:027> du 032ae620

032ae620 "E:
esearcherDocumentsFeedback"

032ae660 "Hub"

因此，utcAPI_escalatescenoasync的原型如下所示:

long UtcApi_EscalateScenarioAsync (

[in] GUID SecnarioID,

[in] int16 unknown,

[in] wchar_t* wszEscalationPath

[in] long unknown2,

[in] long unknown3,

[in] long num_of_keyval_pairs,

[in] wchar_t **keys,

[in] wchar_t **values)

綜上所述，我們的概念證明(PoC)是這樣的:

1.創建一個監控目標目錄的無限線程，例如:C:WINDOWS SYSTEM32, 以便捕獲diagtracktempdir的文件夾名稱；

2.創建另一個無限線程，它將在C:WINDOWSSYSTEM32diagtracktempdirz中創建一個獨佔文件句柄；

3.調用UtcAPI_EscalateScenarioAsync(1881A45E-01FD-4452-ACE4-4A23666E66E3)來觸發Microsoft::Diagnostic::EscalationWorkItem::Execute；

4.成功地創建C:WINDOWSSYSTEM32 diagtracktempdir { random_decimal } z；

5.之後，攻擊者可以將任意文件寫入並在升級文件夾C:WINDOWSSYSTEM32 diagtracktempdir { random_decimal }執行，以繞過一直認為％SYSTEM32％目錄僅包含合法操作系統文件的合法程序；

PoC的結果演示了利用UTC服務在受限目錄下的靜態文件夾中創建任意文件和文件夾的可能方法。

PoC允許在diagtracktempdir中創建任意文件

重申一下，如果沒有能夠控制或重命名文件夾diagtracktempdir，這個PoC不會對Windows操作系統造成安全風險。然而，惡意軟體的開發者會經常使用不同的技術（如用戶帳戶控制（UAC）繞過）來將文件寫入Windows系統文件夾，以便繞過精巧的啟發式掃描技術檢測器。實際上，在探索PoC中使用的潛在文件路徑時，我們發現C:WINDOWSSYSTEM32Tasks包含普通用戶賬戶的寫入和執行許可權。但是維度沒有讀取許可權，這就是為什麼這個文件夾也是惡意軟體開發者用來存儲惡意文件的一個目標路徑。

總結

在本文，我們向你展示了如何使用不同的可用工具和在線資源在Windows RPC伺服器中發現潛在的安全風險。我們還演示了對RPC伺服器進行反向彙編所需的一些基本知識。我們堅信RPC伺服器中還有其他潛在的安全漏洞。在下一篇文章中，我們將繼續研究並改進強化Windows RPC伺服器的方法，以便發現其他RPC伺服器漏洞。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！