介紹

• 該漏洞編號(hào)為CVE-2021-21974，由 OpenSLP 服務(wù)中的堆溢出問題引起，未經(jīng)身份驗(yàn)證的攻擊者可以此進(jìn)行低復(fù)雜度攻擊。
• 該漏洞主要影響6.x 版和 6.7、7.0版本之前的 ESXi 管理程序，2021年2月23日 ，VMware曾發(fā)布補(bǔ)丁修復(fù)了該漏洞。（在此之后發(fā)布的版本不影響）
• 該漏洞啟動(dòng)之后，主要破壞行為為停止所有虛擬機(jī)，并加密所有數(shù)據(jù)文件。
• 因?yàn)椴粫?huì)加密大文件，所以有很大可能性進(jìn)行恢復(fù)操作。

具體影響版本

大于以下版本則不受影響

• ESXi versions 7.x prior to ESXi70U1c-17325551
• ESXi versions 6.7.x prior to ESXi670-202102401-SG
• ESXi versions 6.5.x prior to ESXi650-202102101-SG

被攻擊之后的訪問管理界面示例

漏洞成因

服務(wù)定位協(xié)議

服務(wù)定位協(xié)議是一種服務(wù)發(fā)現(xiàn)協(xié)議，它允許連接設(shè)備通過查詢目錄服務(wù)器來識(shí)別局域網(wǎng)內(nèi)可用的服務(wù)。這類似于一個(gè)人走進(jìn)購(gòu)物中心并查看目錄列表以查看商場(chǎng)中有哪些商店。為了保持簡(jiǎn)短，設(shè)備可以通過發(fā)出“服務(wù)請(qǐng)求”并指定要使用 URL 查找的服務(wù)類型來查詢服務(wù)及其位置。

例如，要從目錄服務(wù)器查找 VMInfrastructure 服務(wù)，設(shè)備將使用“service：VMwareInfrastructure”作為 URL 發(fā)出請(qǐng)求。服務(wù)器將回復(fù)類似“service：VMwareInfrastructure：//localhost.localdomain”的內(nèi)容。

設(shè)備還可以通過發(fā)出提供相同 URL 的“屬性請(qǐng)求”來收集有關(guān)服務(wù)的其他屬性和元數(shù)據(jù)。要添加到目錄中的設(shè)備可以提交“服務(wù)注冊(cè)”。此請(qǐng)求將包括發(fā)布公告的設(shè)備的 IP、服務(wù)類型以及要共享的任何元數(shù)據(jù)等信息。SLP 可以執(zhí)行更多功能，但我感興趣的最后一個(gè)消息類型是“目錄代理通告”，因?yàn)檫@是漏洞所在。“目錄代理通告”是由服務(wù)器發(fā)送的廣播消息，讓網(wǎng)絡(luò)上的設(shè)備知道如果他們想要查詢服務(wù)及其位置，應(yīng)該聯(lián)系誰(shuí)。要了解有關(guān) SLP 的更多信息，請(qǐng)參閱此處和該內(nèi)容。

SLP 數(shù)據(jù)包結(jié)構(gòu)

雖然不同 SLP 消息類型之間的 SLP 結(jié)構(gòu)布局略有不同，但它們通常遵循標(biāo)頭 + 正文格式。

“服務(wù)請(qǐng)求”數(shù)據(jù)包如下所示：

“屬性請(qǐng)求”數(shù)據(jù)包如下所示：

“服務(wù)注冊(cè)”數(shù)據(jù)包如下所示：

最后，“目錄代理通告”數(shù)據(jù)包如下所示：

漏洞點(diǎn)

該問題出在“SLPParseSrvURL”函數(shù)中，該函數(shù)在處理“目錄代理通告”消息時(shí)被調(diào)用。

在第 18 行，URL 的長(zhǎng)度與數(shù)字相加 0x1d 以形成從內(nèi)存中“calloc”的最終大小。在第 22 行，調(diào)用 'strstr' 函數(shù)來查找子字符串 “：/” 的位置在網(wǎng)址中。在第 28 行，子字符串“：/”之前的 URL 內(nèi)容將從第 18 行復(fù)制到新的 ‘calloced’內(nèi)存中。

另一件需要注意的事情是，如果子字符串“：/”，'strstr'函數(shù)將返回0不存在或函數(shù)命中空字符。

我推測(cè)VMware測(cè)試用例只嘗試長(zhǎng)度小于256的“范圍”。如果我們查看以下“目錄代理通告”布局代碼段，我們會(huì)看到示例 1 的“范圍”長(zhǎng)度包含一個(gè)空字節(jié)。這個(gè)空字節(jié)意外地充當(dāng)了“URL”的字符串終止符，因?yàn)樗o隨其后。如果 'scopes' 的長(zhǎng)度高于 256，則長(zhǎng)度的十六進(jìn)制表示形式將沒有空字節(jié)（如示例 2 所示），因此 'strstr' 函數(shù)將讀取傳遞的 'URL' 并繼續(xù)查找子字符串 “：/”在“范圍”中。

因此，“memcpy”調(diào)用將導(dǎo)致堆溢出，因?yàn)樵窗瑏碜?ldquo;URL”的內(nèi)容+“范圍”的一部分，而目標(biāo)只有空格來容納“URL”。

SLP 對(duì)象

在這里，我將介紹相關(guān)的 SLP 組件，因?yàn)樗鼈兪抢玫臉?gòu)建塊。

_SLPDSocket

連接到“slpd”守護(hù)程序的所有客戶端都將在堆上創(chuàng)建一個(gè)“slpd-socket”對(duì)象。此對(duì)象包含有關(guān)連接的當(dāng)前狀態(tài)的信息，例如它是處于讀取狀態(tài)還是寫入狀態(tài)。此對(duì)象中存儲(chǔ)的其他重要信息包括客戶端的 IP 地址、用于連接的套接字文件描述符、指向此特定連接的“recv-buffer”和“send-buffer”的指針，以及指向從先前和將來建立的連接創(chuàng)建的“slpd-socket”對(duì)象的指針。此對(duì)象的大小固定為 0xd0，無(wú)法更改。

來自O(shè)penSLP源代碼的_SLPDSocket結(jié)構(gòu)

_SLPDSocket對(duì)象的內(nèi)存布局

_SLPBuffer

從服務(wù)器接收的所有 SLP 消息類型將創(chuàng)建至少兩個(gè) SLPBuffer 對(duì)象。一個(gè)稱為“recv-buffer”，它存儲(chǔ)服務(wù)器從客戶端接收的數(shù)據(jù)。由于我可以控制從客戶端發(fā)送的數(shù)據(jù)的大小，因此我可以控制“recv-buffer”的大小。另一個(gè)SLPBuffer對(duì)象稱為“send-buffer”。此緩沖區(qū)存儲(chǔ)將從服務(wù)器發(fā)送到客戶端的數(shù)據(jù)。“發(fā)送緩沖區(qū)”具有固定的0x598大小，我無(wú)法控制其大小。此外，SLPBuffer 具有元數(shù)據(jù)屬性，指向所述數(shù)據(jù)的起始位置、當(dāng)前位置和結(jié)束位置。

從 OpenSLP 源代碼_SLPBuffer

_SLPBuffer對(duì)象的內(nèi)存布局

SLP 套接字狀態(tài)

SLP 套接字狀態(tài)定義特定連接的狀態(tài)。狀態(tài)值在_SLPSocket對(duì)象中設(shè)置。連接將調(diào)用“recv”或“發(fā)送”，具體取決于套接字的狀態(tài)。

OpenSLP 源代碼中定義的套接字狀態(tài)常量

了解_SLPSocket、_SLPBuffer和套接字狀態(tài)的屬性非常重要，因?yàn)槔眠^程需要修改這些值。

利用步驟

• 客戶端 1 發(fā)送“目錄代理通告”請(qǐng)求，以準(zhǔn)備此特定請(qǐng)求可能發(fā)生的任何意外內(nèi)存分配。我觀察到當(dāng)“slpd”守護(hù)進(jìn)程在啟動(dòng)時(shí)運(yùn)行時(shí)運(yùn)行時(shí)，請(qǐng)求會(huì)進(jìn)行額外的內(nèi)存分配，但在通過 /etc/init.d/slpd start 運(yùn)行它時(shí)不會(huì)。任何意外的內(nèi)存分配最終都會(huì)被釋放并最終出現(xiàn)在自由列表中。假設(shè)這些獨(dú)特的釋放插槽將被未來的“目錄代理通告”消息再次使用，只要我沒有顯式分配會(huì)劫持它們的內(nèi)存。
• 客戶端 2–5 發(fā)出“服務(wù)請(qǐng)求”，每個(gè)接收緩沖區(qū)的大小為 0x40。這是為了填充自由列表中存在的一些初始釋放插槽。如果我不占用這些釋放的插槽，它將劫持未來的“URL”內(nèi)存分配，用于未來的“目錄代理通告”消息并破壞堆整理。
• 客戶端 6–10 設(shè)置客戶端 7 以向服務(wù)器發(fā)送“服務(wù)注冊(cè)”消息。服務(wù)器僅接受來自本地主機(jī)的“服務(wù)注冊(cè)”消息，因此需要覆蓋客戶端 7 的“slpd-socket”以更新其 IP 地址。發(fā)送消息后，客戶端 7 的套接字對(duì)象將再次更新，以保存?zhèn)陕犖募枋龇蕴幚砦磥淼膫魅脒B接。如果跳過此步驟，將來的客戶端將無(wú)法與服務(wù)器建立連接。
• 客戶端 11–21 通過覆蓋客戶端 15 的“發(fā)送緩沖區(qū)”位置指針來設(shè)置任意讀取基元。由于我不知道首先要泄漏哪些地址，因此我將使用空值對(duì)“start”位置指針的最后兩個(gè)有效字節(jié)執(zhí)行部分覆蓋。這需要將擴(kuò)展的空閑塊設(shè)置為標(biāo)記為“IS_MAPPED”，以避免被“calloc”調(diào)用歸零。更新的“發(fā)送緩沖區(qū)”屬于“屬性請(qǐng)求”消息。由于我無(wú)法了解將泄漏多少數(shù)據(jù)，因此我可以通過在步驟 3 中記錄的“服務(wù)注冊(cè)”消息中包含標(biāo)記值來大致了解泄漏的位置。如果泄漏的內(nèi)容包含標(biāo)記，我知道它正在從“屬性請(qǐng)求”“發(fā)送緩沖區(qū)”對(duì)象泄漏數(shù)據(jù)。這告訴我是時(shí)候停止從泄漏中讀取了。最后，我必須更新客戶端 15 的“slpd-socket”，使其狀態(tài)為“STREAM_WRITE”，這將向我的客戶端發(fā)出“發(fā)送”調(diào)用。
• 我能夠從泄漏中收集堆地址和libc地址，我可以得出其他所有內(nèi)容。我的目標(biāo)是用libc的系統(tǒng)地址覆蓋libc的__free_hook。我將需要一個(gè)小工具將我的堆棧放置在應(yīng)用程序不會(huì)更改的位置。我從 libc-2.17.so 中找到了一個(gè)小工具，它將堆棧提升堆棧地址0x100。
• 使用收集的libc地址，我可以計(jì)算存儲(chǔ)堆棧地址的libc環(huán)境地址。我使用客戶端 22–31 來設(shè)置任意讀取原語(yǔ)以泄漏堆棧地址。我必須在“slpd-socket”中更新客戶端 25 的文件描述符以保存?zhèn)陕犖募枋龇?/li>
• 客戶端 32–40 設(shè)置任意寫入基元。這需要覆蓋客戶端 33 的“recv-buffer”對(duì)象的位置指針。它首先將 shell 命令存儲(chǔ)到客戶端 15 的“發(fā)送緩沖區(qū)”對(duì)象中，這是我控制下的一大塊空間。然后，它會(huì)在執(zhí)行堆棧提升后將 libc 的系統(tǒng)地址、虛假返回地址和 shell 命令的地址寫入預(yù)測(cè)的堆棧位置。之后，它會(huì)覆蓋 libc 的__free_hook以保存堆棧提升小工具地址。最后，每次任意寫入都需要將相應(yīng)的“slpd-socket”對(duì)象狀態(tài)更新為“STREAM_READ”。如果跳過此步驟，服務(wù)器將不接受位置指針的覆蓋值。
• 完成上述所有步驟后，將執(zhí)行所需的 shell 命令。

參考鏈接：

我的 RCE PoC 演練 （CVE-2021–21974） VMware ESXi OpenSLP

https://github.com/straightblast/My-PoC-Exploits/blob/master/CVE-2021-21974.py

到此這篇關(guān)于VMware ESXi OpenSLP 堆溢出漏洞(CVE-2021–21974)的文章就介紹到這了,更多相關(guān)VMware ESXi OpenSLP 堆溢出漏洞內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論