Akamai如何揪出微軟RPC服務(wù)中的漏洞?
前日，Akamai研究人員在微軟Windows RPC服務(wù)中發(fā)現(xiàn)了兩個(gè)重要漏洞：嚴(yán)重程度分值為4.3的CVE-2022-38034，以及分值為8.8的CVE-2022-38045。這些漏洞可以利用設(shè)計(jì)上的瑕疵，通過緩存機(jī)制繞過MS-RPC安全回調(diào)。我們已經(jīng)確認(rèn)，所有未安裝補(bǔ)丁的Windows 10和Windows 11計(jì)算機(jī)都會(huì)受到影響。
面對無處不在的安全威脅，就讓 Akamai 安全解決方案為你豎起“防護(hù)盾牌”！
延伸閱讀，了解Akamai強(qiáng)大的安全解決方案！
隨時(shí)隨地，幫助您捕捉每一個(gè)安全風(fēng)險(xiǎn)！
這些漏洞已經(jīng)披露給微軟，而微軟也在10月的“周二補(bǔ)丁日”通過補(bǔ)丁修補(bǔ)了相關(guān)問題。漏洞的發(fā)現(xiàn)過程得到了Akamai研究人員開發(fā)的自動(dòng)化工具和方法論支持，本文將介紹該漏洞的一些情況以及我們在研究過程中使用的工具（RPC工具包代碼庫）。
背景介紹
MS-RPC 是Windows操作系統(tǒng)的基石之一，自從二十世紀(jì)九十年代誕生以來，已經(jīng)深深扎根在系統(tǒng)的很多功能和組件中。服務(wù)管理器？離不開RPC！Lsass？需要RPC！COM？也依賴RPC！甚至針對域控制器執(zhí)行的一些域操作同樣需要用到RPC。RPC已經(jīng)如此普遍，很多人都覺得這項(xiàng)技術(shù)一定已經(jīng)進(jìn)行了大量檢查、記錄和研究。
其實(shí)并不然。雖然微軟圍繞RPC的使用提供了很多不錯(cuò)的文檔，但有關(guān)本次漏洞相關(guān)主題的內(nèi)容卻并不多，研究人員對RPC，尤其是其安全性的關(guān)注也嚴(yán)重不足。這可能是因?yàn)?/span>RPC（不僅是MS-RPC，但微軟無疑也牽涉其中）實(shí)在是太復(fù)雜，因此也就更加難以研究和理解。
但我們總是樂于接受挑戰(zhàn)的，因此決定一頭扎進(jìn)MS-RPC的深海。不光是因?yàn)檫@是個(gè)有趣的研究課題，而且因?yàn)樗鼤?huì)對安全性產(chǎn)生影響，畢竟哪怕到現(xiàn)在，也有很多常見的攻擊技術(shù)用到了RPC（簡單列舉幾個(gè)，例如通過MS-COM發(fā)起的T1021.003、通過MS-TSCH發(fā)起的T1053.005，以及通過MS-SCMR發(fā)起的T1543.003）。MS-RPC雖然內(nèi)建了安全機(jī)制，但如果存在可被輕松繞過或?yàn)E用的漏洞呢？如果能濫用暴露的RPC服務(wù)以非用戶希望的方式影響計(jì)算機(jī)呢？
實(shí)際上，我們就發(fā)現(xiàn)了一種可以通過緩存繞過某個(gè)安全機(jī)制的方法，并借此發(fā)現(xiàn)了可以濫用的服務(wù)，從而能在遠(yuǎn)程服務(wù)器上提升自己的特權(quán)，并且完全不需要滿足其他必要條件（下文將詳細(xì)分析）。目前我們可以分享有關(guān)這些潛在利用方式的兩個(gè)例子：WksSvc和SrvSvc。當(dāng)披露流程全部結(jié)束后，我們還將公布其他漏洞信息的詳情。
本文將專注于RPC服務(wù)器的安全回調(diào)機(jī)制，通過緩存繞過該機(jī)制的方法，以及我們?nèi)绾瓮ㄟ^自動(dòng)化研究方法將Windows服務(wù)標(biāo)記為存在潛在漏洞的。我們的自動(dòng)化工具以及原始輸出結(jié)果可參閱我們的RPC工具包，這些信息已經(jīng)發(fā)布到GitHub代碼庫中。這個(gè)代碼庫還提供了指向其他實(shí)用參考資源以及我們所依賴的其他研究成果的鏈接。
安全回調(diào)
在討論漏洞本身之前，首先有必要對MS-RPC所實(shí)現(xiàn)的最基本的安全機(jī)制之一進(jìn)行一個(gè)簡單的說明：安全回調(diào)（Security callback）。安全回調(diào)可以讓RPC服務(wù)器開發(fā)者對RPC接口的訪問加以限制，從而應(yīng)用開發(fā)者自己的邏輯來允許特定用戶訪問，強(qiáng)制實(shí)施身份驗(yàn)證或設(shè)置傳輸類型，以及阻止對特定Opnum（服務(wù)器所暴露的函數(shù)可以用Opnum來代表，即“操作編號”）的訪問。
每當(dāng)客戶端調(diào)用服務(wù)器暴露出的函數(shù)時(shí)，RPC運(yùn)行時(shí)都會(huì)發(fā)出這樣的回調(diào)。
RPC安全回調(diào)
我們的研究主要專注于遠(yuǎn)程客戶端-服務(wù)器交互。特別提到這一點(diǎn)是因?yàn)椋?/span>RPC運(yùn)行時(shí)在服務(wù)器端的代碼實(shí)現(xiàn)與ALPC端點(diǎn)和遠(yuǎn)程端點(diǎn)（如命名管道）的代碼實(shí)現(xiàn)有所差異。
緩存機(jī)制
為改善性能并提高利用率，RPC運(yùn)行時(shí)會(huì)對安全回調(diào)的結(jié)果實(shí)現(xiàn)緩存。基本上，這意味著在每次調(diào)用安全回調(diào)之前，運(yùn)行時(shí)會(huì)嘗試著先使用緩存的項(xiàng)。讓我們深入了解一下具體的實(shí)現(xiàn)吧。
在RPC_INTERFACE::DoSyncSecurityCallback調(diào)用安全回調(diào)前，首先會(huì)檢查是否存在緩存項(xiàng)。為此需要調(diào)用OSF_SCALL::FindOrCreateCacheEntry。
OSF_SCALL::FindOrCreateCacheEntry會(huì)執(zhí)行下列操作：
- 從SCALL（一種代表客戶端調(diào)用的對象）獲取客戶端的安全上下文。
- 從客戶端的安全上下文中獲取緩存字典。
- 使用接口指針作為字典的鍵，并使用緩存項(xiàng)作為值。
- 如果不存在緩存項(xiàng)，則會(huì)創(chuàng)建一個(gè)。
RPC運(yùn)行時(shí)內(nèi)部的緩存過程
每個(gè)緩存項(xiàng)都有三個(gè)重要字段：接口中的過程（Procedure）數(shù)量、一個(gè)位圖，以及接口代系（Generation）。
在RPC服務(wù)器生命周期內(nèi)，接口可能會(huì)被改變，例如服務(wù)器針對現(xiàn)有接口調(diào)用RpcServerRegisterIf3后。這又會(huì)導(dǎo)致隨后調(diào)用RPC_INTERFACE::UpdateRpcInterfaceInformation，從而更新接口并增大接口的代系。這樣，緩存就知道自己需要“重置”，因?yàn)榫彺骓?xiàng)可能來自原先的接口。
緩存機(jī)制可以工作在兩種模式下：基于接口（這是默認(rèn)行為）的模式，以及基于調(diào)用的模式。
- 基于接口的緩存
在該模式下，緩存以接口為基礎(chǔ)運(yùn)行。這意味著從緩存的視角來看，只要位于同一個(gè)接口上，對兩個(gè)不同函數(shù)的兩個(gè)調(diào)用就沒有任何區(qū)別。
為了知道是否可以使用緩存項(xiàng)還是需要調(diào)用安全回調(diào)，RPC運(yùn)行時(shí)會(huì)將緩存項(xiàng)中保存的接口代系與實(shí)際的接口代系進(jìn)行對比。由于緩存項(xiàng)的初始化過程會(huì)讓接口代系歸零，因此在首次進(jìn)行對比時(shí)，接口代系必然是不同的，因而總是會(huì)調(diào)用安全回調(diào)。如果回調(diào)成功返回，RPC運(yùn)行時(shí)就會(huì)更新緩存項(xiàng)的接口代系（從而將其“標(biāo)記”為一個(gè)成功的緩存項(xiàng)，隨后無需再次調(diào)用安全回調(diào)就可以訪問接口了）?？蛻舳讼麓握{(diào)用相同接口上的函數(shù)時(shí)將使用緩存項(xiàng)。
- 基于調(diào)用的緩存
當(dāng)RPC接口使用RPC_IF_SEC_CACHE_PER_PROC標(biāo)志注冊時(shí)將使用此模式。在該模式下，緩存會(huì)通過一個(gè)位圖來追蹤安全回調(diào)可以訪問哪些過程。因此，如果客戶端調(diào)用Foo函數(shù)并且安全回調(diào)成功返回，我們就針對Foo有了一個(gè)緩存項(xiàng)；如果客戶端調(diào)用Bar函數(shù)，則將再次調(diào)用安全回調(diào)。
基于調(diào)用的緩存和基于接口的緩存
緩存的相關(guān)要求
那么需要滿足哪些條件才能讓緩存正常工作？首先需要澄清一些術(shù)語。MS-RPC代表客戶端和服務(wù)器之間使用綁定句柄（Binding handle）建立的邏輯連接，客戶端和服務(wù)器都可以使用指定的函數(shù)來操作綁定數(shù)據(jù)。
綁定可以進(jìn)行身份驗(yàn)證。當(dāng)服務(wù)器（通過調(diào)用RpcServerRegisterAuthInfo）注冊身份驗(yàn)證信息時(shí)就會(huì)發(fā)生這種操作，隨后客戶端可以在綁定上設(shè)置身份驗(yàn)證信息。借此，服務(wù)器可以獲得有關(guān)客戶端身份的信息。該身份驗(yàn)證過程將輸出一個(gè)為客戶端創(chuàng)建的安全上下文對象。
整個(gè)緩存機(jī)制均基于這個(gè)安全上下文。這意味著如果綁定未經(jīng)身份驗(yàn)證，將無法為客戶端創(chuàng)建安全上下文，因而將無法使用緩存。為了讓緩存正常工作，服務(wù)器和客戶端都需要注冊并設(shè)置身份驗(yàn)證信息。
但如果服務(wù)器不注冊身份驗(yàn)證信息會(huì)怎樣？能否依然使用緩存？這就涉及到多路復(fù)用（Multiplexing）。
多路復(fù)用
在Windows 10的1703版之前，一個(gè)服務(wù)可以與其他服務(wù)共用同一個(gè)Svchost進(jìn)程。這種行為對MS-RPC的安全性產(chǎn)生了一定影響，因?yàn)橐恍?/span>RPC運(yùn)行時(shí)對象是在所有實(shí)例之間共享的。例如，在注冊一個(gè)端點(diǎn)（如TCP端口7777）后，該端點(diǎn)將可用于訪問同一個(gè)進(jìn)程中運(yùn)行的所有接口。因此其他本應(yīng)只進(jìn)行本地訪問的服務(wù)，現(xiàn)在也將可以遠(yuǎn)程訪問。微軟也在這里描述了這種行為。
端點(diǎn)能被復(fù)用，雖然這一事實(shí)已被很多人所了解并有了相關(guān)文檔記載，但我們想說的是另一種非常類似的行為：SSPI多路復(fù)用。作為身份驗(yàn)證信息注冊過程的一部分，服務(wù)器必須指定要使用的身份驗(yàn)證服務(wù)。身份驗(yàn)證服務(wù)是一種Security Support Provider（SSP），作為一個(gè)軟件包，它可以處理從客戶端收到的身份驗(yàn)證信息。大部分情況下將會(huì)使用NTLM SSP、Kerberos SSP或Microsoft Negotiate SSP，從而在Kerberos和NTLM之間選擇最佳選項(xiàng)。
RPC運(yùn)行時(shí)會(huì)將身份驗(yàn)證信息以全局的方式保存。這意味著，如果兩個(gè)RPC服務(wù)器共用同一個(gè)進(jìn)程，并且其中一個(gè)服務(wù)器注冊了身份驗(yàn)證信息，那么另一個(gè)服務(wù)器也將獲得這些身份驗(yàn)證信息。這樣，客戶端在訪問任何一個(gè)服務(wù)器時(shí)，就可以對綁定進(jìn)行身份驗(yàn)證。從安全的角度來看，如果一個(gè)服務(wù)器沒有注冊身份驗(yàn)證信息，此時(shí)就不會(huì)期待客戶端對綁定進(jìn)行身份驗(yàn)證，也不應(yīng)該進(jìn)行緩存。然而事實(shí)并非如此。
CVE-2022-38045 — Srvsvc
在了解了有關(guān)RPC安全回調(diào)和緩存的基礎(chǔ)知識(shí)后，我們可以看看是否能在真實(shí)世界中濫用這一機(jī)制。我們選擇了Srvsvc，過去我們已經(jīng)在其中發(fā)現(xiàn)了一個(gè)被逐步擊破的漏洞。
Srvsvc暴露了MS-SRVS接口。Server服務(wù)（也叫做LanmanServer）是Windows中一項(xiàng)負(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)時(shí)，我們注意到除了已經(jīng)發(fā)現(xiàn)的漏洞外，該函數(shù)可能包含其他漏洞。一起看看安全回調(diào)的邏輯：
Srvsvc的安全回調(diào)邏輯
如上所示，Srvsvc的安全回調(diào)包含下列邏輯：
- 如果遠(yuǎn)程客戶端試圖訪問介于64-73（含）范圍內(nèi)的函數(shù)——拒絕訪問。
- 如果非集群賬戶的遠(yuǎn)程客戶端試圖訪問介于58-63（含）范圍內(nèi)的函數(shù)——拒絕訪問。
因此從本質(zhì)上來看，遠(yuǎn)程客戶端被禁止訪問接口上的特定函數(shù)。從這個(gè)范圍檢查可知，受限制的函數(shù)都是敏感函數(shù)，只能被預(yù)期的（本地）進(jìn)程所調(diào)用。
盡管這個(gè)檢查試圖阻止對這些函數(shù)的遠(yuǎn)程訪問，但遠(yuǎn)程攻擊者只要濫用緩存即可繞過這一限制。首先，遠(yuǎn)程攻擊者可以調(diào)用一個(gè)不在該范圍內(nèi)的函數(shù)，即可以遠(yuǎn)程使用的函數(shù)。由于安全回調(diào)函數(shù)會(huì)返回RPC_S_OK，RPC運(yùn)行時(shí)即可將結(jié)果成功緩存。又因?yàn)樵摻涌诓⑽词褂?/span>RPC_IF_SEC_CACHE_PER_PROC標(biāo)記注冊，因此將使用基于接口的緩存。所以，攻擊者下一次調(diào)用相同接口上的任意函數(shù)時(shí)，將直接使用緩存項(xiàng)，進(jìn)而允許訪問。這意味著攻擊者現(xiàn)在將可以調(diào)用自己本不應(yīng)能訪問的本地函數(shù)，這一過程中完全不會(huì)調(diào)用安全回調(diào)。
RPC安全回調(diào)的緩存繞路過程
Srvsvc并不注冊身份驗(yàn)證信息，因此正常情況下，客戶端將無法對綁定進(jìn)行身份驗(yàn)證，進(jìn)而無法啟用緩存。但事實(shí)證明，當(dāng)服務(wù)器計(jì)算機(jī)內(nèi)存數(shù)少于3.5GB時(shí)，Srvsvc將與其他服務(wù)共用同一個(gè)Svchost進(jìn)程。AD Harvest Sites and Subnets Service和Remote Desktop Configuration Service這兩個(gè)服務(wù)會(huì)注冊身份驗(yàn)證信息，因此Srvsvc此時(shí)就容易受到緩存攻擊了。
在這種特定情況下，攻擊者可以使用Opnum 58–74訪問受限制的函數(shù)，而攻擊者利用這些函數(shù)的方式之一就是脅迫遠(yuǎn)程計(jì)算機(jī)進(jìn)行身份驗(yàn)證。
開始尋寶吧
在了解到濫用安全回調(diào)的緩存機(jī)制會(huì)產(chǎn)生實(shí)際的漏洞后，我們決定找出其他可能受到緩存攻擊影響的接口。但如果要手工查找所有接口，這將是一項(xiàng)漫長而艱巨的任務(wù)，于是我們打算用自動(dòng)化的方式來完成。
這種情況下，可以通過兩種方式來查找RPC接口：通過當(dāng)前正在運(yùn)行的進(jìn)程，或通過文件系統(tǒng)。
對于正在運(yùn)行的進(jìn)程，我們可以查看已經(jīng)載入內(nèi)存的RPC服務(wù)器，為此或者在遠(yuǎn)程服務(wù)器上查詢遠(yuǎn)程端點(diǎn)映射器（例如使用Impacket的rpcmap或rpcdump工具），或者在本地進(jìn)行（使用RpcView或RpcEnum等工具）。不過這種方式會(huì)遇到一個(gè)問題：會(huì)漏掉所有當(dāng)前尚未加載的端口，并起我們無法查看客戶端端口，因?yàn)樗鼈冞€沒注冊。
或者也可以搜索Windows文件系統(tǒng)，在其中查找文件中編譯的RPC接口。對于每個(gè)接口，我們通過分析傳遞給RpcServerRegisterIf的參數(shù)來找出注冊信息。這有些類似RpcEnum的做法，但我們查找的是文件系統(tǒng)而非內(nèi)存。
為了涵蓋并未載入內(nèi)存的接口，我們的研究最終選擇了文件系統(tǒng)的方法。我們編寫了多個(gè)腳本和工具將這一過程自動(dòng)實(shí)現(xiàn)，相關(guān)內(nèi)容均已發(fā)布至RPC工具包代碼庫。
為了找到啟用緩存的接口，我們其實(shí)并不需要解析RPC接口本身，所需的全部信息都能從RPC服務(wù)器的注冊調(diào)用中提取。注冊函數(shù)可接受RPC接口結(jié)構(gòu)、注冊標(biāo)記以及安全回調(diào)指針。盡管如此，解析RPC接口結(jié)構(gòu)也能提供很多實(shí)用信息，例如接口暴露的函數(shù)，接口被客戶端還是服務(wù)器使用等。雖然我們最關(guān)注的是RPC服務(wù)器（其中可能存在漏洞），但RPC客戶端也對服務(wù)器的調(diào)用提供了可供參考的寶貴見解。
RPC服務(wù)器接口結(jié)構(gòu)請參閱該文檔，借此我們就不必猜測各種字段了。另外，大小字段和傳輸語法是不變的（實(shí)際上可能的傳輸語法有兩種：DCE NDR和NDR64，但我們只是意外發(fā)現(xiàn)了DCE NDR）。
PE文件中保存的RPC接口結(jié)構(gòu)代碼片段截圖，框出的內(nèi)容為大小和傳輸語法
通過（使用Yara或正則表達(dá)式）尋找這兩個(gè)常量，我們可以很簡單地找到所有RPC接口結(jié)構(gòu)。一旦找到后，即可借助解釋器信息字段來了解服務(wù)器到底實(shí)現(xiàn)了哪些功能。
清理后的輸出內(nèi)容范例
但我們還是缺乏有關(guān)接口安全回調(diào)的信息（如果存在這些信息的話），同時(shí)也不知道接口是否會(huì)被緩存。為此，我們必須求助可信賴的朋友：反匯編器。每個(gè)稱職的反匯編器都會(huì)提供xref功能，借此可以在RPC服務(wù)器中輕松找到所有接口注冊函數(shù)調(diào)用。這樣，我們就只需要解析函數(shù)調(diào)用參數(shù)并借此提取接口結(jié)構(gòu)地址（以便將其與我們收集到的RPC服務(wù)器數(shù)據(jù)交叉引用），以及安全回調(diào)地址（如果存在）和RPC接口標(biāo)記。
RPC服務(wù)注冊反匯編
我們所公布的清理腳本可以實(shí)現(xiàn)上述這一系列操作。您可以在RPC工具包中獲取該腳本，以及在Windows Server 2012和Server 2022上的輸出結(jié)果。
到底能有效果嗎？
這些方法和理論聽起來都挺不錯(cuò)，但真的能獲得結(jié)果嗎？
答案是：能。共有超過120個(gè)接口同時(shí)具備安全回調(diào)和緩存，很多都缺乏文檔記載。這本身并不值得恐慌，因?yàn)榇蟛糠謺r(shí)候，安全回調(diào)并不會(huì)受到緩存機(jī)制如此大的影響。通常來說，安全回調(diào)所執(zhí)行的檢查都是針對不可緩存的值進(jìn)行的，例如傳輸協(xié)議序列（如TCP）或身份驗(yàn)證級別。任何變更都需要一個(gè)新的安全上下文，因?yàn)榇藭r(shí)需要建立新的連接，這就重置了緩存，并且讓任何可能的緩存繞路措施失效。
但我們通過這種研究方法也發(fā)現(xiàn)了一些漏洞。目前只能討論其中一個(gè)，因?yàn)槠渌┒催€沒有走完披露過程。
WksSvc
- CVE-2022-38034 CVSS評分：4.3
WksSvc暴露了MS-WKST接口。該服務(wù)負(fù)責(zé)管理域成員關(guān)系、計(jì)算機(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ù)時(shí)，也需要進(jìn)行檢查，這意味著不允許對它們進(jìn)行遠(yuǎn)程調(diào)用。但因?yàn)槭褂昧司彺妫绻紫日{(diào)用另一個(gè)允許遠(yuǎn)程調(diào)用的函數(shù)，然后調(diào)用這個(gè)受限制的函數(shù)，又會(huì)發(fā)生什么？
您猜對了：由于第一個(gè)調(diào)用所創(chuàng)建的緩存項(xiàng)，我們將可以用遠(yuǎn)程方式調(diào)用這個(gè)原本受到限制只能本地調(diào)用的函數(shù)。那么現(xiàn)在又產(chǎn)生了新問題：這些函數(shù)是否重要到需要保證它們受到限制，只能通過本地客戶端調(diào)用？
暴露的函數(shù)包括：NetrUseAdd、NetrUseGetInfo、NetrUseDel以及NetrUseEnum。也許您覺得熟悉，因?yàn)樗鼈兌寄芡ㄟ^netapi32.dll訪問（例如可參閱NetUseAdd）。
這很好，因?yàn)槲覀儚闹蝎@得了一條線索，從而可以確定能通過這種攻擊做些什么。也就是說，我們可以將遠(yuǎn)程服務(wù)器連接到我們自己指定的網(wǎng)絡(luò)共享文件夾，甚至將其映射到我們選擇的邏輯驅(qū)動(dòng)器盤符，這與net use的作用極為類似。（巧合？也許未必?。?/span>
這樣我們就可以指定兩種攻擊方案：
1.可以要求對我們的共享文件夾進(jìn)行身份驗(yàn)證，隨后將其轉(zhuǎn)發(fā)至不同服務(wù)器以進(jìn)行NTML重播攻擊，或?qū)⒘钆拼鎯?chǔ)起來以便脫機(jī)破解密碼。
要求對我們的惡意文件服務(wù)器進(jìn)行身份驗(yàn)證，隨后即可在驗(yàn)證過程中竊取NT哈希
2.或者我們可以用一些有趣或?qū)嵱玫奈募窝b稱成現(xiàn)有的文件服務(wù)器（或假裝是全新文件服務(wù)器），由于這些文件都在我們控制之下，因此可以用我們認(rèn)為適合的方式將其變?yōu)槲淦?，進(jìn)而感染目標(biāo)用戶。
將惡意Web服務(wù)器充當(dāng)中間人攻擊手段或釣魚服務(wù)器，向不夠警惕的用戶發(fā)送武器化的文檔或惡意軟件
上述兩個(gè)場景，以及以遠(yuǎn)程方式調(diào)用受到限制只能本地調(diào)用的函數(shù)的能力，足以讓微軟將這個(gè)漏洞歸類為EoP分類，并給出4.3分的評分。
但這還不是故事的全部，我們還有一些問題需要注意。
安全上下文
WksSvc下的RPC服務(wù)器本身并不進(jìn)行任何身份驗(yàn)證注冊。如果該服務(wù)獨(dú)立運(yùn)行，將無法進(jìn)行任何客戶端身份驗(yàn)證（這樣做會(huì)導(dǎo)致RPC_S_UNKNOWN_AUTHN_SERVICE錯(cuò)誤）。因此我們需要讓該服務(wù)與其他服務(wù)一起運(yùn)行，以便同時(shí)濫用SSPI多路復(fù)用機(jī)制。這也使得受影響的Windows版本僅限Windows 10 1703之前的版本，或在內(nèi)存不足3.5GB的情況下運(yùn)行的更新版本的Windows。
登錄會(huì)話
另一個(gè)問題則和網(wǎng)絡(luò)映射文件夾的工作方式有關(guān)，這類文件夾始終會(huì)被限制在創(chuàng)建映射文件夾的用戶的登錄會(huì)話中。因?yàn)槲覀冏铋_始需要登錄才能獲得安全綁定和緩存，這意味著我們在目標(biāo)計(jì)算機(jī)上將始終創(chuàng)建不同于現(xiàn)有（交互式）會(huì)話的另一個(gè)登錄會(huì)話。就所有意圖和目的而言，這意味著我們的漏洞并不會(huì)產(chǎn)生影響。我們所創(chuàng)建的網(wǎng)絡(luò)映射只存在于我們那短暫的登錄會(huì)話下，并不像普通用戶登錄計(jì)算機(jī)時(shí)創(chuàng)建的網(wǎng)絡(luò)映射，我們創(chuàng)建的映射根本不可見。
WinObj截圖，展示了所創(chuàng)建的邏輯盤符只存在于發(fā)起攻擊的登錄會(huì)話上下文中，并不會(huì)出現(xiàn)在交互式會(huì)話中
為了克服這個(gè)問題，我們又深入挖掘了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)建能影響交互式會(huì)話的全局映射，隨后就可以利用了。
WinObj和資源管理器的截圖片段，展示了對WksSvc的成功利用：在遠(yuǎn)程服務(wù)器上創(chuàng)建了一個(gè)全局驅(qū)動(dòng)器映射，并使其在資源管理器中對已登錄用戶可見
總結(jié)
MS-RPC是一個(gè)龐大而復(fù)雜的協(xié)議，它也承擔(dān)了Windows的一些核心功能。雖然開發(fā)者可以利用一些安全功能保護(hù)自己的RPC服務(wù)器，但對安全研究人員來說，這依然是一個(gè)有趣的話題，這恰恰是因?yàn)樗艘粋€(gè)可能產(chǎn)生安全影響的漏洞。
盡管如此，有關(guān)該話題的公開研究也并不多。本文我們探討了MS-RPC中的一個(gè)大型安全機(jī)制（安全回調(diào)），并發(fā)現(xiàn)了以回調(diào)結(jié)果緩存形式存在的繞過機(jī)制。我們還介紹了自己發(fā)現(xiàn)有漏洞RPC服務(wù)器所采用的研究方法，并通過漏洞的利用演示了我們的發(fā)現(xiàn)。
希望本文提供的內(nèi)容，以及我們的RPC工具包代碼庫能對其他人的研究工作起到一些幫助。
您還有在安全方面想要了解的其他問題嗎~如果有的話，讓我們把評論區(qū)留給您！同時(shí)歡迎您體驗(yàn) Akamai Linode 云計(jì)算平臺(tái)，助力您一站配置計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)和容器，現(xiàn)在點(diǎn)擊體驗(yàn)，還有送100美金用云額度↓↓↓
技術(shù)無邊界，互動(dòng)零距離！如果您想查看和安全有關(guān)的更多話題的話，那就來關(guān)注 Akamai 吧~
