介紹

• 該漏洞編號為CVE-2021-21974，由 OpenSLP 服務(wù)中的堆溢出問題引起，未經(jīng)身份驗證的攻擊者可以此進行低復(fù)雜度攻擊。
• 該漏洞主要影響6.x 版和 6.7、7.0版本之前的 ESXi 管理程序，2021年2月23日 ，VMware曾發(fā)布補丁修復(fù)了該漏洞。（在此之后發(fā)布的版本不影響）
• 該漏洞啟動之后，主要破壞行為為停止所有虛擬機，并加密所有數(shù)據(jù)文件。
• 因為不會加密大文件，所以有很大可能性進行恢復(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ù)器來識別局域網(wǎng)內(nèi)可用的服務(wù)。這類似于一個人走進購物中心并查看目錄列表以查看商場中有哪些商店。為了保持簡短，設(shè)備可以通過發(fā)出“服務(wù)請求”并指定要使用 URL 查找的服務(wù)類型來查詢服務(wù)及其位置。

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

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

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

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

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

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

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

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

漏洞點

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

在第 18 行，URL 的長度與數(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ù)命中空字符。

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

因此，“memcpy”調(diào)用將導(dǎo)致堆溢出，因為源包含來自“URL”的內(nèi)容+“范圍”的一部分，而目標只有空格來容納“URL”。

SLP 對象

在這里，我將介紹相關(guān)的 SLP 組件，因為它們是利用的構(gòu)建塊。

_SLPDSocket

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

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

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

_SLPBuffer

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

從 OpenSLP 源代碼_SLPBuffer

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

SLP 套接字狀態(tài)

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

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

了解_SLPSocket、_SLPBuffer和套接字狀態(tài)的屬性非常重要，因為利用過程需要修改這些值。

利用步驟

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

最新評論