郵件系統作為大部分企業主要的資訊交換方式，在戰略上佔有了舉足輕重的地位。掌控了郵件伺服器不僅可以竊聽郵件的內容，甚至許多重要文件都可以在郵件系統中找到，使得駭客能夠更進一步的滲透。本篇文章將介紹研究組在 Openfind Mail2000 這套軟體上發現的記憶體漏洞，以及利用這個漏洞的攻擊手法。
此漏洞為 2018 年時發現，當時已通報 Openfind 並且迅速被修補，同時也已協助相關用戶進行更新。
Openfind Mail2000
Mail2000 是一套由台灣廠商 Openfind 所開發，簡單易用的電子郵件系統，被廣泛使用於台灣的公家機關、教育機構，如台北市教育局、中科院，以及臺灣科技大學都有使用 Mail2000 作為主要的郵件伺服器。常見的入口介面如下：
這次的漏洞，便是從這個 Web 介面，利用 Binary 的手法，攻陷整台伺服器！
伺服器架構
Mail2000 提供了 Web 介面供管理員以及使用者操作，也就是所謂的 Webmail，而此處 Openfind 使用了 CGI (Common Gateway Interface) 的技術來實作。大多數 Web 伺服器實現 CGI 的方式如圖：
首先由 httpd 接受客戶端的請求後，根據對應的 CGI 路徑，執行相對應的 CGI 檔案。而大多數的開發者會根據需求，將常見的共用 function 撰寫成 library，供 CGI 呼叫。
往底層來看，其實可以發現，雖然稱為 Web 伺服器，仍有許多元件是建構於 binary 之上的！例如 httpd，為了效能，多是由 C/C++ 所撰寫，而其它像是 library、擴充的 module、各頁面的 CGI 也常是如此。因此，binary 相關的漏洞，便是我們這次的攻擊目標！
漏洞
這個漏洞位於 Openfind 實作的 library libm2kc中，此函式庫包含了各種 CGI 通用函式，如參數解析及檔案處理等等，而這個漏洞就發生在參數解析的部分。由於參數處理是很底層且基本的功能，因此影響的範圍非常的大，就連 Openfind 的其它產品也同樣受影響！
這個漏洞的觸發條件如下：
- 攻擊者使用 multipart 形式發送 HTTP POST 請求
- POST 傳送的資料內容超過 200 項
multipart 是 HTTP 協定中，用來處理多項檔案傳輸時的一種格式，舉例如下：
Content-Type: multipart/form-data; boundary=AaB03x
--AaB03x
Content-Disposition: form-data; name="files"; filename="file1.txt"
Content-Type: text/plain
... contents of file1.txt ...
--AaB03x--
而在 libm2kc 中，使用了陣列來儲存參數：
g_stCGIEnv.param_cnt=0;while(p=next_param()){g_stCGIEnv.param[param_cnt]=p;g_stCGIEnv.param_cnt++;}這個陣列為全域變數 g_stCGIEnv 中的 param，在存入 param 陣列時，並沒有檢查是否已超過宣告的陣列大小，就造成了越界寫入。
需要注意的是，param 陣列所儲存的結構為指向字串位置的指標，而非字串本身
structparam{char*key;char*value;intflag;};因此當觸發越界寫入時，寫入記憶體的值也是一個個指向字串的指標，而被指向的字串內容則是造成溢出的參數。
漏洞利用
要利用越界寫入的漏洞，就要先了解利用這個溢出可以做到什麼，發生溢出的全域變數結構如下：
00000000 CGIEnv struc ; (sizeof=0x6990, mappedto_95)
00000000 buf dd ? ; offset
00000004 length dd ?
00000008 field_8 dd 6144 dup(?) ; offset
00006008 param_arr param 200 dup(?)
00006968 file_vec dd ? ; offset
0000696C vec_len dd ?
00006970 vec_cur_len dd ?
00006974 arg_cnt dd ?
00006978 field_6978 dd ?
0000697C errcode dd ?
00006980 method dd ?
00006984 is_multipart dd ?
00006988 read_func dd ?
0000698C field_698C dd ?
00006990 CGIEnv ends
溢出的陣列為其中的param_arr，因此在其之後的變數皆可能被覆寫。包括post_files、vec_len、vec_cur_len、arg_cnt… 等等。其中最吸引我注意的是file_vec這個變數，這是一個用來管理 POST 上傳檔案的 vector，大部分的 vector結構像是這樣：
使用 size記錄陣列的總長度，end記錄目前用到哪裡，這樣就可以在容量不夠的時候進行擴充。我們若利用漏洞，使溢出的指標覆蓋 vector的指標，就有可能有效的利用！藉由覆蓋這個 vector指標，我們可以達到偽造一個 POST file，及其中所有相關變數的效果，而這個 POST file結構裡面就包含了各種常見的檔案相關變數，像是路徑、檔名，和 Linux 中用來管理檔案的 FILE結構，而 FILE結構便是這次的攻擊的關鍵！
FILE Structure Exploit
這次的攻擊使用了 FILE structure exploit 的手法，是近幾年較新發現的攻擊手法，由 angelboy 在 HITCON CMT 公開[1]：
FILE 結構是 Linux 中用來做檔案處理的結構，像是 STDIN、STDOUT、STDERR，或者是呼叫 fopen後回傳的結構都是 FILE。而這個結構之所以能成為漏洞利用的突破口主要原因就是它所包含的 vtable指標：
struct_IO_FILE_plus{FILEfile;conststruct_IO_jump_t*vtable;};vtable當中記錄了各種 function pointer，對應各種檔案處理相關的功能：
struct_IO_jump_t{JUMP_FIELD(size_t,__dummy);JUMP_FIELD(size_t,__dummy2);JUMP_FIELD(_IO_finish_t,__finish);/* ... */JUMP_FIELD(_IO_read_t,__read);JUMP_FIELD(_IO_write_t,__write);JUMP_FIELD(_IO_seek_t,__seek);JUMP_FIELD(_IO_close_t,__close);/* ... */};因此如果我們可以篡改、偽造這個 vtable的話，就可以在程式做檔案處理的時候，劫持程式流程！我們可以以此訂出以下的攻擊步驟：
- 建立連線，呼叫 CGI
- 使用大量參數，覆寫 vector 指標
- 偽造 POST file 當中的 FILE*，指向一塊偽造的 FILE 結構
- 在 CGI 流程中呼叫 FILE 相關的操作
- fread, fwrite, fclose, …
- 劫持程式流程
我們現在已經知道終點是呼叫一個 FILE 操作，那麼就可以開始往回找哪個 function是 CGI 常用的 FILE 操作，又有哪一些 CGI可以作為入口點，才能串出我們的攻擊鏈！我們首先對使用到 POST file 的相關函式做研究，並選定了目標 MCGI_VarClear()。MCGI_VarClear()在許多用到 FILE 的 CGI 中有被呼叫，它用於在程式結束前將 g_stCGIEnv清空，包括將動態配置的記憶體 free()掉，以及將所有 FILE 關閉，也就是呼叫 fclose()，也意味著是可以通過 vtable 被劫持的！我們可以使用這個越界寫入漏洞蓋掉 file_vec，而指向的內容就是 HTTP request 的參數，便可以偽造為 POST files！像是下面這個結構：
我們的最終目標就是將 FILE* 指向偽造的結構，藉由偽造的 vtable 劫持程式流程！這時候便出現了一個問題，我們需要將 FILE* 這個指標指向一個內容可控的位置，但是其實我們並不知道該指到哪裡去，會有這個問題是起因於 Linux 上的一個防禦機制 - ASLR。
Address Space Layout Randomization (ASLR)
ASLR 使得每次程式在執行並載入記憶體時，會隨機載入至不同的記憶體位置，我們可以嘗試使用 cat /proc/self/maps觀察每一次執行時的記憶體位置是否相同：
ASLR 在大部分的環境中都是預設開啟的，因此在撰寫 exploit 時，常遇到可以偽造指標，卻不知道該指到哪裡的窘境。
而這個機制在 CGI 的架構下會造成更大的阻礙，一般的伺服器的攻擊流程可能是這樣：
可以在一個連線當中 leak address 並用來做進一步的攻擊，但在 CGI 架構中卻是這樣：
在這個情況下，leak 得到的 address 是無法在後續攻擊中使用的！因為 CGI 執行完就結束了，下一個 request 又是全新的 CGI！
為了應對這個問題，我們最後寫了兩個 exploit，攻擊的手法根據 CGI binary 而有不同。
Post-Auth RCE - /cgi-bin/msg_read
第一個 exploit 的入口點是一個需要登入的頁面，這一隻程式較大、功能也較多。在這一個 exploit 中，我們使用了 heap spray 的手法來克服 ASLR，也就是在 heap 中填入大量重複的物件，如此一來我們就有很高的機率可以猜到它的位置。
而 spray 的內容就是大量偽造好的 FILE 結構，包含偽造的 vtable。從這隻 binary 中，我們找到了一個十分實用的 gadget，也就是小程式片段：
xchg eax, esp; ret
這個 gadget 的作用在於，我們可以改變 stack 的位置，而剛好此時的 eax指向內容是可控的，因此整個 stack 的內容都可以偽造，也就是說我們可以使用 ROP(Return-oriented programming) 來做利用！於是我們在偽造的 vtable 中設置了 stack 搬移的 gadget 以及後續利用的 ROP 攻擊鏈，進行 ROP 攻擊！
我們可以做 ROP，也就可以拿 shell 了對吧！你以為是這樣嗎？不，其實還有一個大問題，同樣導因於前面提到的防禦機制 ASLR – 我們沒有 system 的位置！這隻 binary 本身提供的 gadget 並不足以開啟一個 shell，因此我們希望可以直接利用 libc 當中的 system 來達成目的，但正如前面所提到的，記憶體位置每次載入都是隨機化的，我們並不知道 system 的確切位置！
經過我們仔細的觀察這支程式以後，我們發現了一件非常特別的事，這隻程式理論上是有打開 NX，也就是可寫段不可執行的保護機制
但是實際執行的時候，stack 的執行權限卻會被打開！
不論原因為何，這個設置對駭客來說是非常方便的，我們可以利用這個可執行段，將 shellcode 放上去執行，就可以成功得到 shell，達成 RCE！
然而，這個攻擊是需要登入的，對於追求完美的 DEVCORE 研究組來說，並不足夠！因此我們更進一步的研究了其它攻擊路徑！
Pre-Auth RCE - /cgi-bin/cgi_api
在搜索了所有 CGI 入口點以後，我們找到了一個不需要登入，同時又會呼叫 MCGI_VarClear()的 CGI – /cgi-bin/cgi_api。一如其名，它就是一隻呼叫 API 的接口，因此程式本身非常的小，幾乎是呼叫完 library 就結束了，也因此不再有 stack pivot 的 gadget 可以利用。
這時，由於我們已經得知 stack 是可執行的，因此其實我們是可以跳過 ROP 這個步驟，直接將 shellcode 放置在 stack 上的，這裡利用到一個 CGI 的特性 – HTTP 的相關變數會放在環境變數中，像是下列這些常見變數：
- HTTP_HOST
- REQUEST_METHOD
- QUERY_STRING
而環境變數事實上就是被放置在 stack 的最末端，也就是可執行段的位置，因此我們只要偽造 vtable 直接呼叫 shellcode 就可以了！
當然這時候同樣出現了一個問題：我們仍舊沒有 stack 的記憶體位置。這個時候有些人可能會陷入一個迷思，覺得攻擊就是要一次到位，像個狙擊手一樣一擊必殺，但實際上可能是這樣拿機關槍把敵人炸飛：
換個角度思考，這隻 binary 是 32 bits 的，因此這個位置有 1.5bytes 是隨機的，總共有 163個可能的組合，所以其實平均只要 4096 次請求就可以撞到一次！這對於現在的電腦、網路速度來說其實也就是幾分鐘之間的事情，因此直接做暴力破解也是可行的！於是我們最終的 exploit 流程就是：
- 發送 POST 請求至
cgi_api- QUERY_STRING 中放入 shellcode
- 觸發越界寫入，覆蓋
file_vec- 在越界的參數準備偽造的 FILE & vtable
cgi_api結束前呼叫MCGI_VarClear- 跳至 vtable 上的 shellcode 位置，建立 reverse shell
最後我們成功寫出了不用認證的 RCE 攻擊鏈，並且這個 exploit 是不會因為 binary 的版本不同而受影響的！而在實際遇到的案例中也證明了這個 exploit 的可行性，我們曾在一次的演練當中，藉由 Mail2000 的這個 1day 作為突破口，成功洩漏目標的 VPN 資料，進一步往內網滲透！
漏洞修復
此漏洞已在 2018/05/08 發布的 Mail2000 V7 Patch 050 版本中完成修復。Patch 編號為 OF-ISAC-18-002、OF-ISAC-18-003。
後記
最後想來談談對於這些漏洞，廠商該用什麼樣的心態去面對。作為一個提供產品的廠商，Openfind 在這一次的漏洞處理中有幾個關鍵值得學習：
- 心態開放
- 主動提供測試環境
- 積極修復漏洞
- 面對漏洞以積極正向的態度，迅速處理
- 修復完畢後，與提報者合作驗證
- 重視客戶安全
- 發布重大更新並主動通報客戶、協助更新
其實產品有漏洞是很正常也很難避免的事，而我們研究組是作為一個協助者的角色，期望能藉由回報漏洞幫助企業，提高資安意識並增進台灣的資安水平！希望廠商們也能以正向的態度來面對漏洞，而不是閃躲逃避，這樣只會令用戶們陷入更大的資安風險當中！
而對於使用各項設備的用戶，也應當掌握好屬於自己的資產，防火牆、伺服器等產品並不是購買來架設好以後就沒有問題了，做好資產盤點、追蹤廠商的安全性更新，才能確保產品不受到 1day 的攻擊！而定期進行滲透測試以及紅隊演練，更是可以幫助企業釐清自己是否有盲點、缺失，進而改善以降低企業資安風險。