前日，Akamai研究人員在微軟Windows RPC服務(wù)中發(fā)現(xiàn)了兩個重要漏洞：嚴(yán)重程度分值為4.3的CVE-2022-38034，以及分值為8.8的CVE-2022-38045。這些漏洞可以利用設(shè)計上的瑕疵，通過緩存機(jī)制繞過MS-RPC安全回調(diào)。我們已經(jīng)確認(rèn)，所有未安裝補(bǔ)丁的Windows 10和Windows 11計算機(jī)都會受到影響。

面對無處不在的安全威脅，就讓 Akamai 安全解決方案為你豎起“防護(hù)盾牌”！

延伸閱讀，了解Akamai強(qiáng)大的安全解決方案！

隨時隨地，幫助您捕捉每一個安全風(fēng)險！

這些漏洞已經(jīng)披露給微軟，而微軟也在10月的“周二補(bǔ)丁日”通過補(bǔ)丁修補(bǔ)了相關(guān)問題。漏洞的發(fā)現(xiàn)過程得到了Akamai研究人員開發(fā)的自動化工具和方法論支持，本文將介紹該漏洞的一些情況以及我們在研究過程中使用的工具（RPC工具包代碼庫）。

背景介紹

MS-RPC 是Windows操作系統(tǒng)的基石之一，自從二十世紀(jì)九十年代誕生以來，已經(jīng)深深扎根在系統(tǒng)的很多功能和組件中。服務(wù)管理器？離不開RPC！Lsass？需要RPC！COM？也依賴RPC！甚至針對域控制器執(zhí)行的一些域操作同樣需要用到RPC。RPC已經(jīng)如此普遍，很多人都覺得這項技術(shù)一定已經(jīng)進(jìn)行了大量檢查、記錄和研究。

其實并不然。雖然微軟圍繞RPC的使用提供了很多不錯的文檔，但有關(guān)本次漏洞相關(guān)主題的內(nèi)容卻并不多，研究人員對RPC，尤其是其安全性的關(guān)注也嚴(yán)重不足。這可能是因為RPC（不僅是MS-RPC，但微軟無疑也牽涉其中）實在是太復(fù)雜，因此也就更加難以研究和理解。

但我們總是樂于接受挑戰(zhàn)的，因此決定一頭扎進(jìn)MS-RPC的深海。不光是因為這是個有趣的研究課題，而且因為它會對安全性產(chǎn)生影響，畢竟哪怕到現(xiàn)在，也有很多常見的攻擊技術(shù)用到了RPC（簡單列舉幾個，例如通過MS-COM發(fā)起的T1021.003、通過MS-TSCH發(fā)起的T1053.005，以及通過MS-SCMR發(fā)起的T1543.003）。MS-RPC雖然內(nèi)建了安全機(jī)制，但如果存在可被輕松繞過或濫用的漏洞呢？如果能濫用暴露的RPC服務(wù)以非用戶希望的方式影響計算機(jī)呢？

實際上，我們就發(fā)現(xiàn)了一種可以通過緩存繞過某個安全機(jī)制的方法，并借此發(fā)現(xiàn)了可以濫用的服務(wù)，從而能在遠(yuǎn)程服務(wù)器上提升自己的特權(quán)，并且完全不需要滿足其他必要條件（下文將詳細(xì)分析）。目前我們可以分享有關(guān)這些潛在利用方式的兩個例子：WksSvc和SrvSvc。當(dāng)披露流程全部結(jié)束后，我們還將公布其他漏洞信息的詳情。

本文將專注于RPC服務(wù)器的安全回調(diào)機(jī)制，通過緩存繞過該機(jī)制的方法，以及我們?nèi)绾瓮ㄟ^自動化研究方法將Windows服務(wù)標(biāo)記為存在潛在漏洞的。我們的自動化工具以及原始輸出結(jié)果可參閱我們的RPC工具包，這些信息已經(jīng)發(fā)布到GitHub代碼庫中。這個代碼庫還提供了指向其他實用參考資源以及我們所依賴的其他研究成果的鏈接。

安全回調(diào)

在討論漏洞本身之前，首先有必要對MS-RPC所實現(xiàn)的最基本的安全機(jī)制之一進(jìn)行一個簡單的說明：安全回調(diào)（Security callback）。安全回調(diào)可以讓RPC服務(wù)器開發(fā)者對RPC接口的訪問加以限制，從而應(yīng)用開發(fā)者自己的邏輯來允許特定用戶訪問，強(qiáng)制實施身份驗證或設(shè)置傳輸類型，以及阻止對特定Opnum（服務(wù)器所暴露的函數(shù)可以用Opnum來代表，即“操作編號”）的訪問。

每當(dāng)客戶端調(diào)用服務(wù)器暴露出的函數(shù)時，RPC運(yùn)行時都會發(fā)出這樣的回調(diào)。

RPC安全回調(diào)

我們的研究主要專注于遠(yuǎn)程客戶端-服務(wù)器交互。特別提到這一點是因為，RPC運(yùn)行時在服務(wù)器端的代碼實現(xiàn)與ALPC端點和遠(yuǎn)程端點（如命名管道）的代碼實現(xiàn)有所差異。

緩存機(jī)制

為改善性能并提高利用率，RPC運(yùn)行時會對安全回調(diào)的結(jié)果實現(xiàn)緩存。基本上，這意味著在每次調(diào)用安全回調(diào)之前，運(yùn)行時會嘗試著先使用緩存的項。讓我們深入了解一下具體的實現(xiàn)吧。

在RPC_INTERFACE::DoSyncSecurityCallback調(diào)用安全回調(diào)前，首先會檢查是否存在緩存項。為此需要調(diào)用OSF_SCALL::FindOrCreateCacheEntry。

OSF_SCALL::FindOrCreateCacheEntry會執(zhí)行下列操作：

1. 從SCALL（一種代表客戶端調(diào)用的對象）獲取客戶端的安全上下文。
2. 從客戶端的安全上下文中獲取緩存字典。
3. 使用接口指針作為字典的鍵，并使用緩存項作為值。
4. 如果不存在緩存項，則會創(chuàng)建一個。

RPC運(yùn)行時內(nèi)部的緩存過程

每個緩存項都有三個重要字段：接口中的過程（Procedure）數(shù)量、一個位圖，以及接口代系（Generation）。

在RPC服務(wù)器生命周期內(nèi)，接口可能會被改變，例如服務(wù)器針對現(xiàn)有接口調(diào)用RpcServerRegisterIf3后。這又會導(dǎo)致隨后調(diào)用RPC_INTERFACE::UpdateRpcInterfaceInformation，從而更新接口并增大接口的代系。這樣，緩存就知道自己需要“重置”，因為緩存項可能來自原先的接口。

緩存機(jī)制可以工作在兩種模式下：基于接口（這是默認(rèn)行為）的模式，以及基于調(diào)用的模式。

• 基于接口的緩存

在該模式下，緩存以接口為基礎(chǔ)運(yùn)行。這意味著從緩存的視角來看，只要位于同一個接口上，對兩個不同函數(shù)的兩個調(diào)用就沒有任何區(qū)別。

為了知道是否可以使用緩存項還是需要調(diào)用安全回調(diào)，RPC運(yùn)行時會將緩存項中保存的接口代系與實際的接口代系進(jìn)行對比。由于緩存項的初始化過程會讓接口代系歸零，因此在首次進(jìn)行對比時，接口代系必然是不同的，因而總是會調(diào)用安全回調(diào)。如果回調(diào)成功返回，RPC運(yùn)行時就會更新緩存項的接口代系（從而將其“標(biāo)記”為一個成功的緩存項，隨后無需再次調(diào)用安全回調(diào)就可以訪問接口了）。客戶端下次調(diào)用相同接口上的函數(shù)時將使用緩存項。

• 基于調(diào)用的緩存

當(dāng)RPC接口使用RPC_IF_SEC_CACHE_PER_PROC標(biāo)志注冊時將使用此模式。在該模式下，緩存會通過一個位圖來追蹤安全回調(diào)可以訪問哪些過程。因此，如果客戶端調(diào)用Foo函數(shù)并且安全回調(diào)成功返回，我們就針對Foo有了一個緩存項；如果客戶端調(diào)用Bar函數(shù)，則將再次調(diào)用安全回調(diào)。

基于調(diào)用的緩存和基于接口的緩存

緩存的相關(guān)要求

那么需要滿足哪些條件才能讓緩存正常工作？首先需要澄清一些術(shù)語。MS-RPC代表客戶端和服務(wù)器之間使用綁定句柄（Binding handle）建立的邏輯連接，客戶端和服務(wù)器都可以使用指定的函數(shù)來操作綁定數(shù)據(jù)。

綁定可以進(jìn)行身份驗證。當(dāng)服務(wù)器（通過調(diào)用RpcServerRegisterAuthInfo）注冊身份驗證信息時就會發(fā)生這種操作，隨后客戶端可以在綁定上設(shè)置身份驗證信息。借此，服務(wù)器可以獲得有關(guān)客戶端身份的信息。該身份驗證過程將輸出一個為客戶端創(chuàng)建的安全上下文對象。

整個緩存機(jī)制均基于這個安全上下文。這意味著如果綁定未經(jīng)身份驗證，將無法為客戶端創(chuàng)建安全上下文，因而將無法使用緩存。為了讓緩存正常工作，服務(wù)器和客戶端都需要注冊并設(shè)置身份驗證信息。

但如果服務(wù)器不注冊身份驗證信息會怎樣？能否依然使用緩存？這就涉及到多路復(fù)用（Multiplexing）。

多路復(fù)用

在Windows 10的1703版之前，一個服務(wù)可以與其他服務(wù)共用同一個Svchost進(jìn)程。這種行為對MS-RPC的安全性產(chǎn)生了一定影響，因為一些RPC運(yùn)行時對象是在所有實例之間共享的。例如，在注冊一個端點（如TCP端口7777）后，該端點將可用于訪問同一個進(jìn)程中運(yùn)行的所有接口。因此其他本應(yīng)只進(jìn)行本地訪問的服務(wù)，現(xiàn)在也將可以遠(yuǎn)程訪問。微軟也在這里描述了這種行為。

端點能被復(fù)用，雖然這一事實已被很多人所了解并有了相關(guān)文檔記載，但我們想說的是另一種非常類似的行為：SSPI多路復(fù)用。作為身份驗證信息注冊過程的一部分，服務(wù)器必須指定要使用的身份驗證服務(wù)。身份驗證服務(wù)是一種Security Support Provider（SSP），作為一個軟件包，它可以處理從客戶端收到的身份驗證信息。大部分情況下將會使用NTLM SSP、Kerberos SSP或Microsoft Negotiate SSP，從而在Kerberos和NTLM之間選擇最佳選項。

RPC運(yùn)行時會將身份驗證信息以全局的方式保存。這意味著，如果兩個RPC服務(wù)器共用同一個進(jìn)程，并且其中一個服務(wù)器注冊了身份驗證信息，那么另一個服務(wù)器也將獲得這些身份驗證信息。這樣，客戶端在訪問任何一個服務(wù)器時，就可以對綁定進(jìn)行身份驗證。從安全的角度來看，如果一個服務(wù)器沒有注冊身份驗證信息，此時就不會期待客戶端對綁定進(jìn)行身份驗證，也不應(yīng)該進(jìn)行緩存。然而事實并非如此。

CVE-2022-38045 — Srvsvc

在了解了有關(guān)RPC安全回調(diào)和緩存的基礎(chǔ)知識后，我們可以看看是否能在真實世界中濫用這一機(jī)制。我們選擇了Srvsvc，過去我們已經(jīng)在其中發(fā)現(xiàn)了一個被逐步擊破的漏洞。

Srvsvc暴露了MS-SRVS接口。Server服務(wù)（也叫做LanmanServer）是Windows中一項負(fù)責(zé)管理SMB共享的服務(wù)。共享也是一種資源（文件、打印機(jī)、目錄樹），可通過Common Internet File System（CIFS）服務(wù)器進(jìn)行網(wǎng)絡(luò)訪問。本質(zhì)上來看，網(wǎng)絡(luò)共享可以讓用戶利用網(wǎng)絡(luò)上的其他設(shè)備執(zhí)行日常任務(wù)。

在研究Srvsvc的安全回調(diào)時，我們注意到除了已經(jīng)發(fā)現(xiàn)的漏洞外，該函數(shù)可能包含其他漏洞。一起看看安全回調(diào)的邏輯：

Srvsvc的安全回調(diào)邏輯

如上所示，Srvsvc的安全回調(diào)包含下列邏輯：

1. 如果遠(yuǎn)程客戶端試圖訪問介于64-73（含）范圍內(nèi)的函數(shù)——拒絕訪問。
2. 如果非集群賬戶的遠(yuǎn)程客戶端試圖訪問介于58-63（含）范圍內(nèi)的函數(shù)——拒絕訪問。

因此從本質(zhì)上來看，遠(yuǎn)程客戶端被禁止訪問接口上的特定函數(shù)。從這個范圍檢查可知，受限制的函數(shù)都是敏感函數(shù)，只能被預(yù)期的（本地）進(jìn)程所調(diào)用。

盡管這個檢查試圖阻止對這些函數(shù)的遠(yuǎn)程訪問，但遠(yuǎn)程攻擊者只要濫用緩存即可繞過這一限制。首先，遠(yuǎn)程攻擊者可以調(diào)用一個不在該范圍內(nèi)的函數(shù)，即可以遠(yuǎn)程使用的函數(shù)。由于安全回調(diào)函數(shù)會返回RPC_S_OK，RPC運(yùn)行時即可將結(jié)果成功緩存。又因為該接口并未使用RPC_IF_SEC_CACHE_PER_PROC標(biāo)記注冊，因此將使用基于接口的緩存。所以，攻擊者下一次調(diào)用相同接口上的任意函數(shù)時，將直接使用緩存項，進(jìn)而允許訪問。這意味著攻擊者現(xiàn)在將可以調(diào)用自己本不應(yīng)能訪問的本地函數(shù)，這一過程中完全不會調(diào)用安全回調(diào)。

RPC安全回調(diào)的緩存繞路過程

Srvsvc并不注冊身份驗證信息，因此正常情況下，客戶端將無法對綁定進(jìn)行身份驗證，進(jìn)而無法啟用緩存。但事實證明，當(dāng)服務(wù)器計算機(jī)內(nèi)存數(shù)少于3.5GB時，Srvsvc將與其他服務(wù)共用同一個Svchost進(jìn)程。AD Harvest Sites and Subnets Service和Remote Desktop Configuration Service這兩個服務(wù)會注冊身份驗證信息，因此Srvsvc此時就容易受到緩存攻擊了。

在這種特定情況下，攻擊者可以使用Opnum 58–74訪問受限制的函數(shù)，而攻擊者利用這些函數(shù)的方式之一就是脅迫遠(yuǎn)程計算機(jī)進(jìn)行身份驗證。

開始尋寶吧

在了解到濫用安全回調(diào)的緩存機(jī)制會產(chǎn)生實際的漏洞后，我們決定找出其他可能受到緩存攻擊影響的接口。但如果要手工查找所有接口，這將是一項漫長而艱巨的任務(wù)，于是我們打算用自動化的方式來完成。

這種情況下，可以通過兩種方式來查找RPC接口：通過當(dāng)前正在運(yùn)行的進(jìn)程，或通過文件系統(tǒng)。

對于正在運(yùn)行的進(jìn)程，我們可以查看已經(jīng)載入內(nèi)存的RPC服務(wù)器，為此或者在遠(yuǎn)程服務(wù)器上查詢遠(yuǎn)程端點映射器（例如使用Impacket的rpcmap或rpcdump工具），或者在本地進(jìn)行（使用RpcView或RpcEnum等工具）。不過這種方式會遇到一個問題：會漏掉所有當(dāng)前尚未加載的端口，并起我們無法查看客戶端端口，因為它們還沒注冊。

或者也可以搜索Windows文件系統(tǒng)，在其中查找文件中編譯的RPC接口。對于每個接口，我們通過分析傳遞給RpcServerRegisterIf的參數(shù)來找出注冊信息。這有些類似RpcEnum的做法，但我們查找的是文件系統(tǒng)而非內(nèi)存。

為了涵蓋并未載入內(nèi)存的接口，我們的研究最終選擇了文件系統(tǒng)的方法。我們編寫了多個腳本和工具將這一過程自動實現(xiàn)，相關(guān)內(nèi)容均已發(fā)布至RPC工具包代碼庫。

為了找到啟用緩存的接口，我們其實并不需要解析RPC接口本身，所需的全部信息都能從RPC服務(wù)器的注冊調(diào)用中提取。注冊函數(shù)可接受RPC接口結(jié)構(gòu)、注冊標(biāo)記以及安全回調(diào)指針。盡管如此，解析RPC接口結(jié)構(gòu)也能提供很多實用信息，例如接口暴露的函數(shù)，接口被客戶端還是服務(wù)器使用等。雖然我們最關(guān)注的是RPC服務(wù)器（其中可能存在漏洞），但RPC客戶端也對服務(wù)器的調(diào)用提供了可供參考的寶貴見解。

RPC服務(wù)器接口結(jié)構(gòu)請參閱該文檔，借此我們就不必猜測各種字段了。另外，大小字段和傳輸語法是不變的（實際上可能的傳輸語法有兩種：DCE NDR和NDR64，但我們只是意外發(fā)現(xiàn)了DCE NDR）。

PE文件中保存的RPC接口結(jié)構(gòu)代碼片段截圖，框出的內(nèi)容為大小和傳輸語法

通過（使用Yara或正則表達(dá)式）尋找這兩個常量，我們可以很簡單地找到所有RPC接口結(jié)構(gòu)。一旦找到后，即可借助解釋器信息字段來了解服務(wù)器到底實現(xiàn)了哪些功能。

清理后的輸出內(nèi)容范例

但我們還是缺乏有關(guān)接口安全回調(diào)的信息（如果存在這些信息的話），同時也不知道接口是否會被緩存。為此，我們必須求助可信賴的朋友：反匯編器。每個稱職的反匯編器都會提供xref功能，借此可以在RPC服務(wù)器中輕松找到所有接口注冊函數(shù)調(diào)用。這樣，我們就只需要解析函數(shù)調(diào)用參數(shù)并借此提取接口結(jié)構(gòu)地址（以便將其與我們收集到的RPC服務(wù)器數(shù)據(jù)交叉引用），以及安全回調(diào)地址（如果存在）和RPC接口標(biāo)記。

RPC服務(wù)注冊反匯編

我們所公布的清理腳本可以實現(xiàn)上述這一系列操作。您可以在RPC工具包中獲取該腳本，以及在Windows Server 2012和Server 2022上的輸出結(jié)果。

到底能有效果嗎？

這些方法和理論聽起來都挺不錯，但真的能獲得結(jié)果嗎？

答案是：能。共有超過120個接口同時具備安全回調(diào)和緩存，很多都缺乏文檔記載。這本身并不值得恐慌，因為大部分時候，安全回調(diào)并不會受到緩存機(jī)制如此大的影響。通常來說，安全回調(diào)所執(zhí)行的檢查都是針對不可緩存的值進(jìn)行的，例如傳輸協(xié)議序列（如TCP）或身份驗證級別。任何變更都需要一個新的安全上下文，因為此時需要建立新的連接，這就重置了緩存，并且讓任何可能的緩存繞路措施失效。

但我們通過這種研究方法也發(fā)現(xiàn)了一些漏洞。目前只能討論其中一個，因為其他漏洞還沒有走完披露過程。

WksSvc

• CVE-2022-38034 CVSS評分：4.3

WksSvc暴露了MS-WKST接口。該服務(wù)負(fù)責(zé)管理域成員關(guān)系、計算機(jī)名稱以及到SMB網(wǎng)絡(luò)重定向器（如SMB打印服務(wù)器）的連接。查看該接口的安全回調(diào)我們發(fā)現(xiàn)，少數(shù)函數(shù)的處理方式與其他函數(shù)有很大差異。

WksSvc安全回調(diào)的一部分，展示了不同函數(shù)和不同Opnum之間的差異

當(dāng)通過本地客戶端調(diào)用Opnum介于8-11之間的函數(shù)時，也需要進(jìn)行檢查，這意味著不允許對它們進(jìn)行遠(yuǎn)程調(diào)用。但因為使用了緩存，如果首先調(diào)用另一個允許遠(yuǎn)程調(diào)用的函數(shù)，然后調(diào)用這個受限制的函數(shù)，又會發(fā)生什么？

您猜對了：由于第一個調(diào)用所創(chuàng)建的緩存項，我們將可以用遠(yuǎn)程方式調(diào)用這個原本受到限制只能本地調(diào)用的函數(shù)。那么現(xiàn)在又產(chǎn)生了新問題：這些函數(shù)是否重要到需要保證它們受到限制，只能通過本地客戶端調(diào)用？

暴露的函數(shù)包括：NetrUseAdd、NetrUseGetInfo、NetrUseDel以及NetrUseEnum。也許您覺得熟悉，因為它們都能通過netapi32.dll訪問（例如可參閱NetUseAdd）。

這很好，因為我們從中獲得了一條線索，從而可以確定能通過這種攻擊做些什么。也就是說，我們可以將遠(yuǎn)程服務(wù)器連接到我們自己指定的網(wǎng)絡(luò)共享文件夾，甚至將其映射到我們選擇的邏輯驅(qū)動器盤符，這與net use的作用極為類似。（巧合？也許未必！）

這樣我們就可以指定兩種攻擊方案：

1.可以要求對我們的共享文件夾進(jìn)行身份驗證，隨后將其轉(zhuǎn)發(fā)至不同服務(wù)器以進(jìn)行NTML重播攻擊，或?qū)⒘钆拼鎯ζ饋硪员忝摍C(jī)破解密碼。

要求對我們的惡意文件服務(wù)器進(jìn)行身份驗證，隨后即可在驗證過程中竊取NT哈希

2.或者我們可以用一些有趣或?qū)嵱玫奈募窝b稱成現(xiàn)有的文件服務(wù)器（或假裝是全新文件服務(wù)器），由于這些文件都在我們控制之下，因此可以用我們認(rèn)為適合的方式將其變?yōu)槲淦鳎M(jìn)而感染目標(biāo)用戶。

將惡意Web服務(wù)器充當(dāng)中間人攻擊手段或釣魚服務(wù)器，向不夠警惕的用戶發(fā)送武器化的文檔或惡意軟件

上述兩個場景，以及以遠(yuǎn)程方式調(diào)用受到限制只能本地調(diào)用的函數(shù)的能力，足以讓微軟將這個漏洞歸類為EoP分類，并給出4.3分的評分。

但這還不是故事的全部，我們還有一些問題需要注意。

安全上下文

WksSvc下的RPC服務(wù)器本身并不進(jìn)行任何身份驗證注冊。如果該服務(wù)獨立運(yùn)行，將無法進(jìn)行任何客戶端身份驗證（這樣做會導(dǎo)致RPC_S_UNKNOWN_AUTHN_SERVICE錯誤）。因此我們需要讓該服務(wù)與其他服務(wù)一起運(yùn)行，以便同時濫用SSPI多路復(fù)用機(jī)制。這也使得受影響的Windows版本僅限Windows 10 1703之前的版本，或在內(nèi)存不足3.5GB的情況下運(yùn)行的更新版本的Windows。

登錄會話

另一個問題則和網(wǎng)絡(luò)映射文件夾的工作方式有關(guān)，這類文件夾始終會被限制在創(chuàng)建映射文件夾的用戶的登錄會話中。因為我們最開始需要登錄才能獲得安全綁定和緩存，這意味著我們在目標(biāo)計算機(jī)上將始終創(chuàng)建不同于現(xiàn)有（交互式）會話的另一個登錄會話。就所有意圖和目的而言，這意味著我們的漏洞并不會產(chǎn)生影響。我們所創(chuàng)建的網(wǎng)絡(luò)映射只存在于我們那短暫的登錄會話下，并不像普通用戶登錄計算機(jī)時創(chuàng)建的網(wǎng)絡(luò)映射，我們創(chuàng)建的映射根本不可見。

WinObj截圖，展示了所創(chuàng)建的邏輯盤符只存在于發(fā)起攻擊的登錄會話上下文中，并不會出現(xiàn)在交互式會話中

為了克服這個問題，我們又深入挖掘了NetrUseAdd的代碼。結(jié)果發(fā)現(xiàn)，我們可以向NetrUseAdd傳遞一些標(biāo)記，借此讓它在Global命名空間中創(chuàng)建映射，這將影響所有用戶。這些標(biāo)記甚至能在可用的頭文件LMUse.h中找到：

在LMUse.h中看到的全局映射標(biāo)記

借助這些標(biāo)記，我們的代碼已經(jīng)可以成功創(chuàng)建能影響交互式會話的全局映射，隨后就可以利用了。

WinObj和資源管理器的截圖片段，展示了對WksSvc的成功利用：在遠(yuǎn)程服務(wù)器上創(chuàng)建了一個全局驅(qū)動器映射，并使其在資源管理器中對已登錄用戶可見

總結(jié)

MS-RPC是一個龐大而復(fù)雜的協(xié)議，它也承擔(dān)了Windows的一些核心功能。雖然開發(fā)者可以利用一些安全功能保護(hù)自己的RPC服務(wù)器，但對安全研究人員來說，這依然是一個有趣的話題，這恰恰是因為它包含了一個可能產(chǎn)生安全影響的漏洞。

盡管如此，有關(guān)該話題的公開研究也并不多。本文我們探討了MS-RPC中的一個大型安全機(jī)制（安全回調(diào)），并發(fā)現(xiàn)了以回調(diào)結(jié)果緩存形式存在的繞過機(jī)制。我們還介紹了自己發(fā)現(xiàn)有漏洞RPC服務(wù)器所采用的研究方法，并通過漏洞的利用演示了我們的發(fā)現(xiàn)。

希望本文提供的內(nèi)容，以及我們的RPC工具包代碼庫能對其他人的研究工作起到一些幫助。

您還有在安全方面想要了解的其他問題嗎~如果有的話，讓我們把評論區(qū)留給您！同時歡迎您體驗 Akamai Linode 云計算平臺，助力您一站配置計算、存儲、網(wǎng)絡(luò)和容器，現(xiàn)在點擊體驗，還有送100美金用云額度↓↓↓

點擊咨詢，獲取一對一專屬解決方案

技術(shù)無邊界，互動零距離！如果您想查看和安全有關(guān)的更多話題的話，那就來關(guān)注 Akamai 吧~