2021年7月13日，美國微軟威脅情報中心發布安全公告[1]，文中指出黑客利用Serv-U 0day對極少數美國軍工部門成功進行了攻擊，同日Serv-U母公司solarwinds也發布安全公告[2]，并針對最新大版本發布了補丁[3]。

（注意：目前發布的補丁隻針對最新的15.2.3大版本，且隻能是付費用戶才能下載安裝補丁，非付費用戶目前無法從官方渠道獲取有效補丁。）

根據補丁比較和fuzzer，甯靜之盾安全團隊成功複現了該遠程溢出漏洞，并能在實戰環境下成功利用。

截至9月10日，互聯網上未發現任何有關該漏洞的技術分析和POC發布，也未發現更多新聞細節公布。

該漏洞是2003年Serv-U mdtm漏洞修補後出現的第一個RCE漏洞。

為了感謝廣大讀者夥伴的支持，準備了以下福利給到大家：

[一>關注我，私信回複“資料”獲取<一]

1、200多本網絡安全系列電子書（該有的都有了）

2、全套工具包（最全中文版，想用哪個用哪個）

3、100份src源碼技術文檔（項目學習不停，實踐得真知）

4、網絡安全基礎入門、Linux、web安全、攻防方面的視頻（2021最新版）

6、 網絡安全學習路線（告别不入流的學習）

7、ctf奪旗賽解析（題目解析實戰操作）[一>關注我，私信回複“資料”獲取<一]

該軟件是全球流行的商業閉源ftp服務器端軟件，官方資料顯示該軟件全球有超過10W用戶，軟件默認支持ftp(21端口)/sftp(22端口)等，出于安全性考慮現在大部分使用的是sftp端口(流量使用非對稱算法加密)，主要運行在windows平台，新版本為X64程序，該軟件22端口默認banner信息含有詳細版本号，通過zoomeye搜索顯示近一年IP量為13000個（全量為6.7W多）。

其中15.2.3大版本有1100台，最新補丁版本15.2.3.742有900台，該漏洞影響範圍是Serv-U 版本 < 15.2.3 HF2（即15.2.3.742）。按照近一年存活13000台，已安裝此漏洞補丁900台計算，也就是說現在全網至少有90%的Serv-U處于受此漏洞威脅狀态（Serv-U母公司應該是出于商業考慮未對大量存在的老版本發布補丁，老版本升級到最新版本需要再次付費）。

Banner信息

該漏洞是一個遠程内存破壞漏洞（可以穩定控制虛函數指針），針對WINDOWS版Serv-U SFTP(22端口)進行攻擊，該漏洞無需任何賬号和密碼，輸入IP和端口即可成功攻擊，隻要版本低于15.2.3.742，成功率接近100%（單次成功率達不到100%，但可以立即再次攻擊），利用成功獲取SYSTEM權限SHELL。

下載最新版本742和上一版本723，補丁包文件如下

> 15.2.3.723 hf1 5/14/2021 > > Serv-U crashes due to incorrect OpenSSL API usage > > <Serv-U-InstallDir>\Serv-U.dll > > <Serv-U-InstallDir>\RhinoNET.dll > > 15.2.3.742 hf2 7/12/2021 > > * Unauthenticated Remote Code Execution in SSH protocol > > * <Serv-U-InstallDir>\Serv-U-RES.dll > > * <Serv-U-InstallDir>\Serv-U-Tray.exe > > * <Serv-U-InstallDir>\Serv-U.dll > > * <Serv-U-InstallDir>\Serv-U.exe

可以看到主要修改了4個文件，使用Bindiff依次對這4個文件進行比較，最終可以排除掉Serv-U.exe、Serv-U-Tray.exe和Serv-U-RES.dll，因為這三個文件改動非常小，基本上不可能存在漏洞。

同時結合官方的報告，APT攻擊中利用該漏洞可能會報如下錯誤：

> EXCEPTION: C0000005; > > CSUSSHSocket::ProcessReceive(); > > Type: 30; > > puchPayLoad = 0x041ec066; > > nPacketLength = 76; > > nBytesReceived = 80; > > nBytesUncompressed = 156; > > uchPaddingLength = 5

基本可以判斷該漏洞是一個SSH相關的内存型漏洞。使用BINDIFF和IDA對主DLL的補丁情況比較如下：

左邊為未補丁變化的函數地址，右邊為補丁後的函數地址

對Serv-U.dll中的十餘個有變化的函數逐個分析，排除掉4個比較錯誤的函數，一共有9個函數發生變化，發現補丁為某些函數添加了硬編碼的判斷與賦值，比如，判斷某個值198h是否為0、1、2、3、4或5等，或者給198h賦值為0、1、2、3、4或5等。

此時，需要配合IDA嘗試理解這些值的含義，首先定位到該值存儲的位置，可以看到該值被存儲到a1[0x198]。

然後二進制搜索0x198，找到該值被讀寫的所有位置。

遺憾的是，即使知道了補丁補的位置與代碼，也很難揣測補丁的最終意圖。于是另辟蹊徑，從打過補丁的函數一直向上回溯，依次記錄分析，發現函數sub_180145070會引用所有打過補丁的函數。

其它幾個變化的函數主要是該函數的switch case分支裡調用的函數，下面我們具體分析該函數，該函數其實是RhinoNET!CRhinoSocket::ProcessReceiveBuffer，通過命名可以猜到是用于處理收到的數據BUF，在該函數入口點下斷：

180145070的調用棧如下：

RhinoNET!CRhinoSocket::OnReceive 0x170

mfc140u!CWnd::OnWndMsg 0xba9

mfc140u!CWnd::WindowProc 0x3f

mfc140u!AfxCallWndProc 0x123

mfc140u!AfxWndProc 0x54

mfc140u!AfxWndProcBase 0x49

USER32!UserCallWinProcCheckWow 0x1ad

USER32!DispatchMessageWorke 0x3b5

Serv_U_180000000!CUPnPNotifyEvent::SetTimeout 0x30d85

Serv_U_180000000!CUPnPNotifyEvent::SetTimeout 0x30dfd

ucrtbase!crt_at_quick_exit 0x7d

kernel32!BaseThreadInitThunk 0xd

ntdll!RtlUserThreadStart 0x1d

仔細觀察該函數的結構，一個外部大循環加内部的switch…case，明顯是某種協議的實現，配合關鍵字符串SSH_MSG_IGNORE，不難得出結論：函數sub_180145070實現了部分或完整的SSH握手協議。

通過調試可知，該函數主要用于處理SSH消息，依次處理的MSG消息如下：

> 180145070依次處理的MSG(10進制) > > 20 SSH_MSG_KEXINIT > > 30 SSH_MSG_ECDH key exchange init ! CASE 28 > > 21 SSH_MSG_NEWKEYS > > 5 SSH_MSG_SERVICE_REQUEST > > 50 SSH_MSG_USERAUTH_REQUEST > > 90 SSH_MSG_CHANNEL_OPEN > > 98 SSH_MSG_CHANNEL_REQUEST > > 94 SSH_MSG_CHANNEL_DATA

比如上圖中：switch(v21)中v21就是SSH協議中的消息碼，标識了消息類型。

通過此文檔可查到相關SFTP協議的規範

補丁後的程序，主要修補了20,30,21三個MSG，其中在這些MSG中處理CLIENT支持的SSH加密算法處多調用了SSH庫578,530和538函數做檢查(EVP_aes_128_ctr,EVP_EncryptInit_ex和EVP_DecryptInit_ex)

同時通過調試可知，修補後的程序，對MSG序列的順序做了限制！

補丁比較後基本判斷該漏洞是一個SSH協議握手階段的邏輯處理出錯，進而造成的内存處理出錯，那麼通過補丁比較就找不到傳統内存溢出型漏洞補丁一般會對COPY長度做限制的地方，要複現這個漏洞就需要對Serv-U的SSH握手過程進行FUZZER。

3.2 FUZZER SSH握手過程

有了上述的信息，便可以寫一個發包FUZZ腳本（不斷生成消息碼去測試），通過模拟SSH握手階段的數據交換來模糊測試Serv-U服務器15.2.3.723。

腳本運行一段時間後，得到了一個崩潰，通過分析該崩潰可以确認我們發送完20号消息後，不發送30号MSG，直接發送21号消息，是造成Serv-U崩潰的原因，打上補丁後不會産生該問題。那麼說明很可能找到了漏洞點。

同時該漏洞大概率能夠利用，因為Serv-U.dll沒有開啟ASLR，而我們擁有控制EIP的能力，所以配合ROP便可以遠程執行代碼了。

如下圖，可以看到被調用的函數指針被覆蓋為了AAAAAA……，也就是我們可以利用可控的數據覆蓋一個虛函數指針，從而控制函數執行流程以執行我們的ShellCode。

崩潰時的調用棧如下：

崩潰的最終位置并不在Serv-U.dll裡，而是在libeay32.dll，這個動态鍊接庫是OpenSSL用于加解密的一個組件。通過跟蹤調試，發現握手數據AAAAAA…的最後8字節數據被libeay32.dll錯誤地當作函數指針來調用，從而觸發了崩潰。

定位崩潰時發送的數據包，發現該數據包打亂了SSH正常的通信過程（握手包亂序），所以補丁中的硬編碼值0、1、2、3、4、5等是為限制了數據包的發送順序，即發送了包MSG 20之後隻能發包MSG 30，以此緩解該漏洞。

3.3 漏洞利用

通過分析發包流程和Serv-U的SSH通信處理過程便得知，該**漏洞的成因為Serv-U的SSH通信處理流程亂序導緻的内存未初始化漏洞。**通過網絡數據包列舉漏洞觸發原理及過程如下：

• SSH通信正常的處理過程為

密鑰交換初始化（申請N字節内存，每個版本可能不同）;

密鑰協商算法交換參數，比如ECDH（填充N字節内存：在内存塊内填充函數地址等）;

加解密數據（調用N字節内存中的函數地址）

• 觸發漏洞的過程為

密鑰交換初始化（申請N字節内存）;

加解密數據（調用N字節内存中的函數地址）;

可以看到漏洞觸發過程省略了ECDH密鑰交換協商這一步。并且在第一步申請N字節時并未初始化内存。

• 漏洞觸發利用過程

發包占坑布局N字節内存空間，并釋放;

密鑰交換初始化（申請N字節内存，該内存内容已被提前布局）

加解密數據觸發漏洞**（由于缺少了密鑰協商設置N字節内存塊内函數指針這一步，所以會調用N字節内存中已被提前布局的函數地址）;**

• 漏洞補丁原理

漏洞補丁限制了SSH通信過程，所以不會再導緻内存中函數指針被攻擊者提前布局并利用的情況。

通過分析該崩潰，确定了該漏洞大概率能夠利用，因為Serv-U.dll并沒有開啟ASLR，為我們提供了用于布置ROP鍊的必要條件。除此之外，上述崩潰的位置在CALL指令處，這使得我們大概率可以控制EIP。當同時擁有以上兩種能力後，就可以控制程序跳轉到布置好的ROP鍊上執行預先指定的代碼。

雖然Serv-U.dll中沒有導入VirtualProtect函數，但是它導入了另外一個能夠執行代碼的函數ShellExecuteExW，所以目标就是構造ROP鍊傳入指定參數執行ShellExecuteExW。

首先使用capstone編寫小工具提取ROP，獲取所需指令的地址。

然後拼接這些指令，達到執行ShellExecuteExW的目标，具體步驟是：切換棧 布局參數 調用函數。

切換棧是第一步，但非常簡單，使用xchg、pop、mov以及lea等指令修改rsp即可。布局參數是整個過程中最難的，因為函數ShellExecuteExW隻有一個參數，該參數為一個結構體指針，而結構體内部的字符串指針才是執行命令的核心，所以這裡涉及到多級指針的布控。由于我們控制了整個棧，所以布置多級指針的也并不難，但步驟比較繁瑣，容易出錯，一定要耐心謹慎。

參數布置好之後，再次控制EIP跳轉到導入表内的函數指針執行。一旦函數ShellExecuteExW執行完畢，就代表着用戶指定的命令也已經執行完畢，但由于棧已經損壞，主程序将随之崩潰。

如果不利用ShellExecuteExW也可以利用下圖所示位置的代碼，自行獲得VirtualProtect函數地址：

（上圖地址DLL版本為15.2.3.723）

四、現有補丁說明

截止9月10日，發布的補丁情況如下：

| 版本号 | 發布時間 | 有無漏洞 || <15.2.3.717 | ---- | 有 || 15.2.3.717 | 2021/04/20 | 有 || 15.2.3.723 hf1 | 2021/05/14 | 有 || 15.2.3.742 hf2 | 2021/07/12 | 無(最新版) |

五、漏洞利用工具說明5.1 受影響軟件版本

SSH-2.0-Serv-U_15.1.6.25至SSH-2.0-Serv-U_15.2.3.723

備注：SSH-2.0-Serv-U_15.1.6.25版本為2017年發布，更早的版本肯定也受影響，隻不過當前測試的最早版本為2017年。SSH-2.0-Serv-U_15.2.3.723版本為最新的補丁版本的前一個版本。

5.2 遠程利用限制條件

Serv-U需要以服務方式啟動才能利用成功，不過Serv-U默認安裝本來就是以服務方式啟動的。如果以非服務方式啟動則無法利用成功。

5.3 遠程利用執行演示效果及特殊情況說明

利用成功後，目标機器的Serv-U.exe程序會執行我們的ShellCode代碼，并且啟動一個PowerShell子進程（父進程為Serv-U.exe），并通過PowerShell腳本回連我們設置的IP和端口，獲取的SHELL權限為SYSTEM權限;ShellCode代碼啟動的程序和執行的程序命令可以通過修改攻擊腳本自行設定;上述第2點提到的ShellCode執行的程序命令有長度限制，不能超過500個字節;如果利用成功，Serv-U.exe程序會崩潰并自動重啟（不會彈框，因為是服務方式啟動所以會自動重啟），所以可以無限次反複遠程利用;如果利用失敗，攻擊腳本執行完後稍等十秒再進行下一次攻擊，直到成功為止;每次的攻擊成功率大概在20-50%;單次攻擊發出的網絡數據包大小在2-3M左右，注意網絡情況;每個Serv-U版本需要有對應的ROP序列，所以每一個單獨的小版本的Serv-U都需要定制化開發對應的攻擊代碼（程序有DEP，但關鍵DLL無ASLR）。本文僅作安全技術分析，旨在為無法獲得補丁的用戶和安全研究人員提供此漏洞細節分析，所以不提供任何POC。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部