SolarWinds發(fā)布安全公告，修復(fù)了Serv-U中存在的遠程代碼執(zhí)行漏洞（CVE-2021-35211），該漏洞為微軟發(fā)現(xiàn)在野利用后向SolarWinds報告，并提供了漏洞利用的概念證明。未經(jīng)身份驗證的遠程攻擊者利用此漏洞可在受影響的服務(wù)器上以特殊權(quán)限執(zhí)行任意代碼，請相關(guān)用戶盡快采取措施進行防護。

該漏洞存在于SSH協(xié)議中，與 SUNBURST 供應(yīng)鏈攻擊無關(guān)，僅影響SolarWinds Serv-U Managed File Transfer和Serv-U Secure FTP。使用Serv-U管理控制臺向?qū)?chuàng)建域時會默認(rèn)選擇啟用SSH，若Serv-U環(huán)境中未啟用SSH則不受此漏洞影響。

通過枚舉ssh-字符串在Serv-U中發(fā)現(xiàn)了SSH實現(xiàn)。SSH實例如圖1所示：

圖 1. SSH-字符串

研究人員在上述代碼中設(shè)置斷點，并嘗試用SSH客戶端連接到Serv-U確認(rèn)這一假設(shè)：

圖 2. 圖1中代碼中設(shè)置的斷點的調(diào)用棧

此時，研究人員發(fā)現(xiàn)Serv-U.dll和RhinoNET.dll都禁用了ASLR支持。研究人員逆向Serv-U.dll和RhinoNET.dll中相關(guān)的代碼后發(fā)現(xiàn)可以追蹤SSH消息的路徑。為處理進入的SSH連接，Serv-U.dll從RhinoNET!CRhinoSocket 類創(chuàng)建了CSUSSHSocket對象。CSUSSHSocket 對象的lifetime是TCP連接的長度。底層的CRhinoSocket 為socket提供了緩存的接口，因此單個TCP包可能含有許多字節(jié)。這表明單個包也可能包含任意數(shù)量的SSH消息以及部分SSH消息。CSUSSHSocket::ProcessRecvBuffer函數(shù)負(fù)責(zé)處理來自緩存socket數(shù)據(jù)的SSH消息。

CSUSSHSocket::ProcessRecvBuffer首先用ParseBanner檢查SSH版本。如果ParseBanner成功從banner獲得SSH版本，ProcessRecvBuffer就會循環(huán)處理ParseMessage，會從socket數(shù)據(jù)中獲取當(dāng)前消息的指針，并從消息中提出msg_id和length域。

圖 3. CSUSSHSocket::ProcessRecvBuffer處理循環(huán)部分代碼

消息數(shù)據(jù)包含在payload緩存中，其中第一個字節(jié)就是msg_id：

然后，ProcessRecvBuffer會根據(jù)msg_id來處理消息。部分消息會直接經(jīng)消息處理循環(huán)，其他消息會傳遞給ssh_pkt_others，ssh_pkt_others會發(fā)布消息給隊列為另一個線程來處理。

圖 4. CSUSSHSocket::ProcessRecvBuffer中的預(yù)認(rèn)證處理

如果msg_id委托給另一個線程，CSSHSession::OnSSHMessage就會負(fù)責(zé)處理。該函數(shù)主要處理需要與Serv-U管理用戶簡介數(shù)據(jù)和UI更新交互的消息。由于CSSHSession::OnSSHMessage需要先成功進行用戶交互，所以也沒有發(fā)現(xiàn)漏洞。

在對Serv-U進行模糊測試時，很明顯應(yīng)用發(fā)現(xiàn)一些包含異常，比如日志記錄錯誤、系統(tǒng)奔潰等。這些行為可以改善文件服務(wù)器應(yīng)用的運行時間，還是引發(fā)可能的內(nèi)容奔潰。攻擊者可以利用這一機會來發(fā)起暴力破解等攻擊。

在測試過程中，研究人員發(fā)現(xiàn)了一些讀寫訪問違背等異常情況，這些可以引發(fā)奔潰：

圖 5. WinDbg表明模糊測試生成的SSH消息引發(fā)的奔潰

如上所述，libeay32.dll中的CRYPTO_ctr128_encrypt嘗試調(diào)用無效的地址。使用的OpenSSL版本是1.0.2u，下面是相關(guān)的OpenSSL函數(shù)：

同時，下面是處理的結(jié)構(gòu)：

奔潰函數(shù)是通過以下路徑從OpenSSL API獲得的：

EVP_EncryptUpdate -> evp_EncryptDecryptUpdate -> aes_ctr_cipher -> CRYPTO_ctr128_encrypt

進一步分析調(diào)用棧，發(fā)現(xiàn)Serv-U會從CSUSSHSocket::ParseMessage 調(diào)用EVP_EncryptUpdate，如下所示：

圖 6. 調(diào)用OpenSSL的位置，攻擊者控制的函數(shù)指針可能會被調(diào)用

此時，研究人員通過測試操作了最小化的TCP包緩存以小到觸發(fā)奔潰所需的最小SSH消息。

研究人員發(fā)現(xiàn)該問題產(chǎn)生的根本原因是Serv-U創(chuàng)建了OpenSSL AES128-CTR代碼，如下所示：

用NULL key或空IV來調(diào)用EVP_EncryptInit_ex，Serv-U這么做是因為在處理 KEXINIT 消息時創(chuàng)建了上下文。但AES密鑰擴展在密鑰設(shè)置之前不會執(zhí)行，并且ctx->cipher_data數(shù)據(jù)在密鑰擴展執(zhí)行前仍然保持未初始化狀態(tài)。因此，研究人員推測消息的序列在密鑰初始化之前就會引發(fā)enc_algo_client_to_server->decrypt被調(diào)用。Serv-U KEXINIT handler在消息中的所有參數(shù)創(chuàng)建對象。但對應(yīng)的對象在NEWKEYS消息被處理簽不會被新創(chuàng)建的對象替換。客戶端會在發(fā)布NEWKEYS消息之前在正常的SSH連接過程中完成密鑰交換過程。不輪是連接狀態(tài)還是密鑰交換，Serv-U會處理NEWKEYS。

總結(jié)

以上是生活随笔為你收集整理的CVE-2021-35211： SolarWinds Serv-U SSH 漏洞分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。