2018年10月7日，來自全球知名高科技網路安全公司Tenable的安全研究人員Jacob Baines針對CVE-2018-14847[2]釋出了一段新的概念驗證（PoC）程式碼[1]，實現了在受漏洞影響的MikroTik路由器上的遠端程式碼執行。我們第一時間對PoC進行了研究，目前我們對漏洞利用的部分改進已經合入了Tenable的Github倉庫[7]。本文將對CVE-2018-14847目錄穿越漏洞成因進行分析，同時闡述我們的一些發現，如何通過受此漏洞影響的Winbox指令進行任意檔案上傳，從而實現一些更有趣的利用方式。我們能夠利用CVE-2018-14847在RouterOS 6.42中觸發後門shell，或在其他漏洞的配合下，通過在LD_LIBRARY_PATH中注入動態連結庫的方法，對存在漏洞的可執行檔案進行熱補丁修復。我們還將在文章中介紹一種“修改”只讀檔案系統修復漏洞的方法。

漏洞分析

環境簡介

MikroTik RouterOS是一個基於Linux開發的網路裝置作業系統，相容x86、ARM、MIPS等多種CPU架構，因此RouterOS也可以安裝在PC上將其作為軟路由，提供防火牆、VPN、無線網路等多種功能與服務。

RouterOS提供了多種途徑對其進行管理與配置，包括SSH、Telnet、Web介面（Webfig）與客戶端軟體（Winbox）等。本文討論的漏洞，位於RouterOS與客戶端軟體Winbox通訊過程中所使用的Winbox私有協議中。

RouterOS官網提供了針對多種CPU架構的ISO安裝映象，我們下載6.41.3版本的ISO映象並安裝一個虛擬機器。

在虛擬機器中配置好IP等基本設定後，我們對各個配置項進行探索，可以總結出一些基本認知。

1.    RouterOS可以通過Web（80埠）、SSH（22埠）、Winbox（8291埠）、Telnet（23埠）進行遠端訪問，使用相同的使用者名稱與密碼進行身份驗證。

2.    命令列方式訪問（SSH、Telnet）會登入到一個廠商定製的shell介面，只能執行廠商實現的管理功能，無法執行Linux命令。

3.    通過Webfig途徑登入後，與伺服器的互動全部通過一個名為master-min-xxxxx.js的指令碼進行加密傳輸。這個加密協議我們下文將稱之為JSProxy。

4.    Webfig與Winbox途徑提供的配置選項幾乎完全相同，根據Tenable與Talos等前人的研究，二者在傳輸層的編碼方式上有些許差異，但在應用層的指令編號、指令引數等保持一致。

協議分析

在上節我們提到，使用GUI管理RouterOS的兩個方式Webfig網頁端與Winbox客戶端，分別採用JSProxy與Winbox協議與RouterOS進行通訊，下面我們將分別分析兩種協議的通訊格式。

在JSProxy通訊過程中，瀏覽器與伺服器通訊採用變種的MS-CHAP-2方式生成會話金鑰，並用於全程的資料加解密，在此我們不作深入講解，通過JSProxy我們能夠略窺RouterOS控制所需要的指令格式與指令對映關係。

對JSProxy的payload進行解密後，我們得到一條條JSON編碼的資料。基本格式如下：

JSON資料中的每個鍵值對包含了三種資訊：欄位型別、欄位名、欄位值。JSON鍵的第一個字母（上圖藍色部分）代表欄位型別，包括字串、整型、布林值、陣列等。JSON鍵的剩下6個十六進位制位（上圖紅色部分）代表欄位名，通常是一個編號，表示資料值的含義，我們下文稱之為key ID。JSON值（上圖黃色部分）就是這個欄位的資料值。

到這裡我們可以瞭解到，RouterOS管理頁面的通訊方式是通過鍵值對的請求與回覆實現的，鍵值對的編碼方式在JSProxy與Winbox中不盡相同，但資料含義是相同的。我們對 master-min-xxxxx.js進行分析，一個好訊息是，我們可以在其中找到所有key ID。

而Winbox協議的二進位制編碼格式，我們可以從Winbox客戶端中分析得到。我們尋找到了一個關鍵函式，功能是將Winbox訊息轉換成字串進行日誌輸出，四捨五入等於開源了。

Winbox協議二進位制格式的大致格式分為6位元組的訊息頭，與依次緊密排列的鍵值對，大於255位元組的訊息會插入兩位元組的長度資料作為訊息分片。

其中鍵值都是以小端序傳輸，同樣採取類似“資料型別-鍵-值”的格式。

藉助Cisco Talos實驗室開源的Winbox協議Wireshark解析外掛[9]。我們能非常直觀的看到資料中各個欄位與原始資料的對應關係。

當然這個外掛還有一些不足之處，無法解析所有型別的資料包，但對於我們，能夠對資料包進行過濾和簡單檢視一下對應關係就足夠了。

關鍵漏洞：目錄穿越、任意檔案讀寫（CVE-2018-14847）

CVE-2018-14847漏洞發生在漏洞上傳的位置。我們如何知道檔案上傳指令發給誰，檔案由誰接收，儲存到哪裡呢？我們需要先定位哪個程式在RouterOS上負責接收使用者上傳的檔案。

從Winbox訊息中，我們注意到不同指令會傳送給不同的目的元件，從JSProxy中我們能夠得知這個目的地位於SYS_TO欄位對應的欄位中。這個欄位是兩個int32組成的陣列，第一個數字對應了系統中的一個程式，第二個數字對應了這個程式的第幾個功能。Tenable對系統中儲存了這個對應關係的資料檔案/nova/etc/loader/system.x3進行了分析，並製作了一個名為parse_x3的小工具，我們可以在Tenable的Github倉庫中的parse_x3目錄找到。

根據這個對應關係，結合抓包我們能夠得知，檔案上傳請求的SYS_TO值為{0x02,0x02}，對應的二進位制檔案位於/nova/bin/mproxy。

我們從RouterOS的ISO檔案中提取出對應的二進位制檔案。檔案位於mikrotik-6.41.3.iso\system-6.41.3.npk\nova\bin\mproxy，直接用7-zip開啟iso和裡面的npk，拖出來即可（很多地方其實用不著binwalk）。

在對mproxy進行分析的過程中，Tenable通過功能（handler）實現對應的基類nv::Handler找到了每個程式裡面的所有功能的所有編號，並編寫了一個Binary Ninja指令碼尋找程式中的所有handler，從而快速定位功能對應的函式，這個小工具位於Github倉庫中的find_handlers目錄中，有興趣的同學可以嘗試一下。

我們嘗試找一個簡單點的方法，從另外一個角度定位對應的函式。我們在Winbox客戶端中正常上傳一個檔案，並尋找上傳的檔案所在的路徑。當然，假如現在是黑盒測試的話，我們可以用其他的方法獲得檔案系統的訪問權，例如利用其他漏洞進行提權、直接修改檔案系統植入shell等等。我注意到檔案系統根目錄下有很多的符號連結，其中有一些連結到可寫目錄中，所以我在這裡用find -follow跟隨符號連結確保我們能夠定位到檔案的所有可能的路徑。

通過這種方法獲得的路徑，與mproxy程式中出現的字串進行交叉比對，我們可以得到結論：mproxy程式中，某個負責檔案上傳的函式能夠上傳檔案至/var/pckg目錄中。

再通過這個字串的交叉引用，我們就能夠定位到我們所需的關鍵函式，我們命名為ked_handler。

對這個函式進行分析，我們可以得出ked_handler函式大致有7個功能，以傳入的第5個引數進行選擇，有以下7個取值（以IDA虛擬碼中出現順序排序）：

l  功能1：在/var/pckg目錄下建立檔案，返回一個用於寫入資料的session

l  功能3：開啟/var/pckg目錄下的一個檔案，返回一個用於讀取資料的session

l  功能7：開啟/home/web/webcfg目錄下的一個檔案，返回一個用於讀取資料的session

l  功能2：向一個開啟檔案的session寫入資料

l  功能4：從一個開啟檔案的session讀取資料

l  功能5：中止一個session並刪除先前寫入的檔案

l  功能6：在/var/pckg目錄下新建一個目錄

通過對抓包資料進行分析，我們發現官方客戶端在讀取並下載檔案時呼叫的是3號功能，而Tenable的poc呼叫的是7號功能。

與這兩個功能相關的部分邏輯如下。

其中，tokenize函式對傳入的字串按 / 字元進行切分，返回一個字串陣列。ked_check_path函式採用類似狀態機的方式有限制的允許“..”字串，不允許穿越到父目錄中。但函式中沒有對“.”（即，當前目錄）進行驗證，所以我們可以構造類似“/./../”的payload，讓函式誤以為我們進入1級子目錄後返回了當前目錄，但實際我們進入了父目錄，成功實現目錄穿越。ked_check_path這個函式可以說是搬起石頭砸了自己的腳。

通過虛擬碼我們能看到這三個功能都沒有對輸入引數進行正確過濾，應該存在相同的目錄穿越漏洞。這兩個命令理論上都能利用來進行任意寫入，實際情況呢？

關鍵點在許可權上，對ked_handler進行呼叫回溯，我們能夠定位到mproxy的main函式中，向event loop註冊handler的程式碼片段。在新增handler前，程式呼叫了set_policy對7個命令進行了某種設定，據Tenable的深入研究，這幾條函式呼叫與handler中相關功能的呼叫許可權相關。第三個引數為0的時候，代表呼叫此功能無需登入。由以上程式碼可知，功能命令4、5、7的呼叫無須登入。

到這裡，我們已經實現了對系統根目錄的任意檔案讀寫。

關鍵漏洞：開發者後門（Tenable exp: bytheway）

下一個問題，有了許可權，我們能做什麼呢？當然是Getshell了！我們前面提到，即使我們有管理員賬號密碼，ssh登入進去依然是一個功能受限的shell，不能執行Linux指令。Tenable在報告中提出了一種利用廠商開發者後門進行提權的方法。這個後門與上文提到的目錄穿越漏洞，在RouterOS 6.42.1與6.40.8版本一併得到修復。

這個漏洞存在於ssh和telnet登入時執行的/nova/bin/login中。命令列登陸時，程式先正常向使用者請求輸入使用者名稱和密碼，然後根據兩個判斷條件：使用者名稱是否等於devel、hasOptionPackage返回是否為非0值，如果都符合則進入下一個程式碼塊。

其中，hasOptionPackage函式位於/lib/libumsg.so中，它的取值依據為/pckg/option檔案是否存在。

確認使用者名稱與OptionPackage後，程式將使用者名稱重置為admin，並設定一個標誌位，指示後門的啟用狀態。

處理一部分其他邏輯之後，程式再次檢查這個標誌位，如果後門啟用，則將shell執行的實際命令設定為bash。根據PATH環境變數的設定，最後命中並執行檔案系統中名為/bin/bash（實際是一個busybox）的互動式命令列。

這個後門的觸發邏輯在RouterOS的不同版本中略有不同。根據Tenable的研究，在RouterOS 6.40.9以下版本中，依據的檔案是/flash/nova/etc/devel-login，在6.41.1以下版本中，判斷的是/pckg/option，在6.42以上版本中，對/pckg/option檔案型別做了額外的驗證，但依然能夠通過修改檔案系統的方式進行觸發。

利用方式總結

根據上面的兩個漏洞的細節，我們已經可以總結出整個漏洞利用的過程：

1.    構造payload，呼叫功能7，開啟/flash/rw/store/user.dat檔案，獲得session id。

2.    呼叫功能4，用這個session id讀取檔案內容。

3.    用其他工具解密管理員賬戶的明文密碼。

4.    呼叫{0x0d，0x04}號handler進行Winbox管理員登入（模擬Winbox客戶端登入，協議細節不再贅述），獲得管理員許可權session id。

5.    呼叫功能1，用管理員session在/pckg/option建立空檔案。

6.    用管理員明文密碼登入ssh/telnet，獲得root shell。

整個的利用過程已經被Tenable總結出了一個漏洞利用程式bytheway，在他們的Github中可以找到。

漏洞復現

我們在這裡使用的是基於Tenable的bytheway進行修改後的exploit。

互動過程如下：

根據RouterOS版本不同，觸發後門需要的檔案也不同，因此exploit裡面將兩個檔案都建立了，儘量相容更多的版本。

One More Thing

漏洞復現了就結束了？NO。我們在公網上部署了多臺測試環境對RouterOS漏洞的利用行為進行捕獲，從攻和守兩個角度都有一些新的發現。我們接下來將介紹一個幫我們“修復”漏洞的好心攻擊者與我們對其修復方法的復現，還有我們發現的另一種漏洞利用方法，同時介紹如何利用這種方法反過來修復這個漏洞。

“刪除”只讀rootfs系統檔案

挖礦、蠕蟲、殭屍網路等攻擊行為不再多說，都是常規操作。在其中一個裝置上，我們發現了一個好心的攻擊者幫助我們“修復”了後門shell。具體表現是，“修復”後的裝置能夠通過ssh登入管理介面，也能通過exp觸發後門，但卻無法登入devel使用者，輸入正確的密碼後卻被斷開連線。估計是某個病毒的作者想要防止其他攻擊者利用這個漏洞，所以好心幫我們“修復”了。可以說是滑天下之大稽。

通過對裝置檔案系統的分析和虛擬機器上的復現，我們猜測這個裝置上的/bin/bash檔案被“刪掉”了。但問題是，PATH變數是硬編碼的不可能修改，而/bin目錄所在的根檔案系統是隻讀掛載的squashfs，所以刪除系統檔案是怎麼實現的呢？

前面我提到了特殊意義的“刪掉”，是因為我們重新分析線上環境的檔案系統時，發現/bin/bash並沒有被刪，所以下面的這種漏洞“修復”方式僅是我們能夠復現的一種猜想。

首先我們想知道，在系統目錄中有哪些是可寫入的。

我們選擇/ram，並用隨便一種方式上傳一個完整版busybox進去（因為RouterOS自帶的mount進行bind mount時會報錯）。隨後，在可寫目錄中新建bin資料夾並將/bin目錄中的內容複製進去，並用mount將新目錄掛載到/bin目錄之上，實現“覆蓋”的效果。由下圖可見，我們斷開連線後再次登入，就會在登入成功後馬上斷開，提示訊息為Connection Closed而不是漏洞修復後提示的Permission denied。

用這種方式實現的修改，並沒有真實寫入檔案系統，在重啟之後，後門依然可以訪問。病毒作者可以說是用心良苦哇。

這個思路同樣可以用於一些敏感的生產環境系統，很多嵌入式裝置都採用squashfs或者其他用於Flash晶片的只讀檔案系統，如果對可用性有較高的要求，不能接受重啟、系統升級帶來的服務中斷的話，可以用類似的目錄掛載方式對系統進行熱修復。

CVE-2018-14847的其他用途

在對CVE-2018-14847漏洞進行分析的時候，我產生了一個疑問。既然功能1、3、7共享這個目錄穿越漏洞，那理論上我們可以在未授權的情況下向系統任意目錄寫入任意檔案。也許我們不需要開發者後門，也可以實現遠端程式碼執行。

我嘗試利用Tenable的協議庫winbox_message.hpp編寫一些poc，利用ked_handler中功能1提供的session寫入檔案，在可寫的路徑上傳busybox。但伺服器對上傳的功能2指令沒有任何響應。通過對Winbox客戶端上傳功能的分析，我發現Tenable的協議庫中對長度大於256位元組的message處理有一些小bug。

下圖以一個檔案上傳資料包內容為例，以全0資料方便我們觀察原始資料格式。方框部分就是Tenable協議庫遺漏的部分，我們在winbox_session.cpp中，在每個訊息分片之前加入分片長度值與截斷標記，修復後的資料包就和Winbox客戶端傳送的協議格式完全相同了。

進行修復以後，呼叫mproxy的功能2能夠正常上傳檔案到指定位置，在修復之前，因為其他header的存在，最多隻能上傳209位元組的檔案，更大的檔案請求就會因為訊息分片格式的問題被mproxy丟棄。這個patch我們也提交到了Github上。現在，我們開啟了另一扇大門。

不依賴開發者後門的漏洞利用方法

最開始我的設想，直接利用上傳功能覆蓋一個系統可執行檔案，並觸發對應的功能。但後來發現有兩個難點。一是從未授權使用者的角度來看，能夠呼叫的程式就那麼幾個，/nova/bin/login與mproxy、telnet和ssh伺服器等，這些程式所在的掛載點都是隻讀的，root使用者也無法覆蓋。二是通過功能2建立的檔案預設許可權都是644，即可讀可寫不可執行，即使傳上去了也會因為許可權問題無法啟動。

不過對RouterOS有了更多的瞭解後，我有了一個設想。檢視shell登入以後的環境變數：

我們發現，LD_LIBRARY_PATH中包含了多個目錄，/lib在根檔案系統下，是隻讀的。/pckg是一個指向/ram/pckg的符號連結，/pckg/security/lib與/pckg/user-manager/lib只在安裝了對應的可選包才會出現，也都是隻讀的。/rw是一個指向/flash/rw的符號連結，這個目錄是可寫的。雖然/rw/lib目錄在預設配置下不存在，但我們可以通過上文的目錄穿越漏洞呼叫ked_handler的功能6進行建立，從而使這個漏洞的利用成為可能。

LD_LIBRARY_PATH是一個危險的東西。利用這個環境變數，我們可以實現在任何程式執行前對程式的行為進行修改，甚至在程式執行時實現程式注入。子程式可以繼承父程式的環境變數，而系統中絕大多數應用都是loader程式的子程式（下圖PID 276）。

因此，將payload封裝為so庫，放置在LD_LIBRARY_PATH中的可寫路徑/rw/lib下，即可實現對接下來任意啟動的程式進行注入並實現命令執行——比如我們在命令列登入時，就會啟動一個/nova/bin/login。

在RouterOS 6.42+植入後門shell

用這個思路，我們還可以在無法觸發後門的6.42版本中，使用老版本libumsg.so重新引入這個後門，對RouterOS“越獄”會有幫助。前面我們提到，

這個後門的觸發邏輯在RouterOS的不同版本中略有不同。根據Tenable的研究，在RouterOS 6.40.9以下版本中，依據的檔案是/flash/nova/etc/devel-login，在6.41.1以下版本中，判斷的是/pckg/option，在6.42以上版本中，對/pckg/option檔案型別做了額外的驗證，但依然能夠通過修改檔案系統的方式進行觸發。

RouterOS 6.42+中，遠端觸發開發者後門幾乎是不可能的，攻擊者更不可能跑到別人家裡去拆掉Flash晶片往裡塞後門。意味著即使攻擊者拿下了使用者名稱密碼，但他也僅僅能訪問GUI中有限的控制選項，不能植入payload利用裝置獲得更多的經濟利益。

我們前面分析過，與後門相關的控制邏輯，有一部分位於/lib/libumsg.so中，準確來講是nv::hasOptionPackage函式。既然我們已經能夠進行任意檔案上傳，同時我們能夠控制LD_LIBRARY_PATH，那麼我們簡單的將RouterOS 6.41.x中的libumsg.so複製出來，再在6.42.x的系統中利用目錄穿越漏洞呼叫ked_handler的功能6建立/rw/lib目錄並將libumsg.so上傳上去，因為LD_LIBRARY_PATH的函式載入優先順序高於PE檔案中定義的載入路徑[8]，我們用這種方式即可實現後門觸發，在6.42.x系統中啟用ssh shell。

因為不想再寫程式碼了，為了從另一個角度驗證這個思路的可行性，我們在RouterOS 6.41.x上設計了下面的實驗。

在RouterOS 6.41.x上利用漏洞“修復”漏洞

我們現在有一個後門，我們還控制了LD_LIBRARY_PATH下可寫的目錄/rw/lib，同時能夠建立這個目錄並向其中寫入檔案。假如我現在的裝置就是一個骨幹路由，需要對漏洞進行緊急修復，我們現在來嘗試一下，在不更新、不重啟系統的情況下通過LD_LIBRARY_PATH預載入動態連結庫關掉這個後門。

首先，我們確認後門可以正常工作，並建立/rw/lib目錄。當然，我們也可以用漏洞來建立這個目錄，我只是懶得寫exp了（笑

接下來，我們從RouterOS 6.42的ISO中提取出libumsg.so，並利用CVE-2018-14847（或者用你能想到的其他方法）上傳到指定目錄中。我在這裡同時上傳了一個busybox。

上傳成功後，kill掉所有名為login和sshd的程式。

這樣一來，當前所有通過控制檯、Telnet與ssh登入的終端都會被關閉，再次連線就會啟動新程式，同時載入我們通過LD_LIBRARY_PATH植入的新版本libumsg.so，後門shell失效。

還記得我們在前面對開發者後門的分析嗎？如果libumsg.so中的後門函式hasOptionPackage返回true後，登入session的使用者名稱會被重置為admin，從而控制檯中顯示的登入成功、失敗的日誌中的使用者名稱都會因此被修改。但後門修復之後，這一段程式邏輯不復存在，因此對後門的登入嘗試也會在系統日誌中顯示出來。

再結合我們前面提到的，用mount掛載魔改只讀檔案系統的方式，我們還可以用新版本覆蓋根檔案系統的/nova/bin/mproxy，將目錄穿越漏洞一併修復掉。

我們再開個腦洞，整個漏洞修復過程分為三步：建立目錄、上傳修補程式、重啟服務，這個過程完全可以自動化，一個指令碼對全網存在漏洞的裝置進行掃描修復。真正做出來肯定也會非常有趣吧。

後記

攻與防的較量，就是正常程式猿與腦洞程式猿的較量。不知攻，焉知防？知己知彼，方能百戰不殆。

參考資料

[1]    Bug Hunting in RouterOS 視訊：https://youtu.be/ItclhUF6MnA 講稿：https://github.com/tenable/routeros/raw/master/slides/bug_hunting_in_routeros_derbycon_2018.pdf

[2]    MikroTik blog - CVE-2018-14847 winbox vulnerability https://blog.mikrotik.com/security/winbox-vulnerability.html

[3]    MikroTik RouterOS Authenticated Directory Traversal https://zh-cn.tenable.com/security/research/tra-2019-16

[4]    GitHub - tenable/routeros: RouterOS Security Research Tooling and Proof of Concepts https://github.com/tenable/routeros

[5]    深入分析MikroTik RouterOS CVE-2018-14847 & Get bash shell https://www.anquanke.com/post/id/162457

[6]    基於 CVE-2018-14847 的 Mikrotik RouterOS 安全事件分析 http://ith4cker.com/content/uploadfile/201811/aed91542039274.pdf

[7]    Fix message length issue with packet bigger than 256 bytes https://github.com/tenable/routeros/pull/7

[8]    What is the order that Linux's dynamic linker searches paths in? - Unix & Linux Stack Exchange https://unix.stackexchange.com/a/367682

[9]    GitHub - Cisco-Talos/Winbox_Protocol_Dissector https://github.com/Cisco-Talos/Winbox_Protocol_Dissector