我的翻譯--一個針對TP-Link調試協議（TDDP）漏洞挖掘的故事

標籤：網上   wifi   不能   包含   串口   coder   劫持   按鈕   training   

前言

我寫這篇文章原本是為了簡化WiFi滲透測試研究工作。我們想使用去年由Core Security發布的WIWO，它可以在電腦網路介面和WiFi路由器之間建立一個透明的通道。

研究的第一步，就是選取一個合適的工具， 在此研究中，我會首先選擇一個適當的路由器進行改造。

經過一段時間的考察，我選擇了TP-Link的TL-WA5210g無線路由器，它允許安全自訂韌體，（這樣我就能安裝之前提到的工具），同時，他也是一個室外路由器（最初的設計就是如此）。

我首先發現了一個問題，我所購買的路由器的硬體版本（2.0版本）和可以自訂韌體的版本不符，這樣安裝WIWO的時候可能就會有麻煩。我也讀了一些部落格，有時候雖然硬體版本不同，但是韌體可以相同。不幸的是，我手裡的裝置不可以。裝置的硬體和韌體版本是配套的，我也沒發現降級韌體的辦法，（TL-WA5210G_V2_140523）當我嘗試使用Web介面降級的時候，發生了錯誤。

 

使用串口

我暫時放下了最開始的目標，轉而，我試圖發現一種方法來控制裝置，安裝我所需要的軟體。我的第一個方法是使用UART串口通訊的方法，我把UART的引腳焊接上排針，使用Bus Pirate（我的選擇）或類似的東西把他串連到電腦，看看我能做什麼。（這一步需要拆開外殼，在綠色的電路板上操作）

串連到UART串口之後，我發現了一個可以運行有限命令的控制台，它的一些選項被禁用了，比如第一個和第二個。

source: https://forum.openwrt.org/viewtopic.php?id=17252&p=6

我嘗試了其他不同的數字和字母，希望找到隱藏功能，雖然我發現了一些，但是沒發現對我有用的。

第二種方法是分析web程式，我發現很多UART控制台也可以從web介面的菜單中進入，這在OpenWRT的wiki中有介紹。對於我手中的裝置，我發現了隱藏的菜單：

http://192.168.1.254/userRpm/NatDebugRpm26525557.htm

 

發現漏洞

在上一步發現的隱藏菜單中，有很多按鈕，他們顯示了裝置很多有趣的資訊。有一個預設開啟的UDP連接埠引起了我的注意。

做了一些研究之後，我瞭解到了這個UDP連接埠上啟動並執行協議：

https://www.google.com/patents/CN102096654A?cl=en

TDDP是一個用於調試的簡單協議，這個協議使用一個資料包，在載荷中使用不同的訊息類型來完成請求或者命令的傳遞。下面的圖片是TDDP的資料包資訊。

我還發現文檔中記錄了其他一些訊息類型。如果想從裝置中獲得一些有關裝置狀態的資訊，調試資訊是十分有用的。我想知道我到底可以做什麼，於是我從TP-Link的官網下載了它的韌體。

下載完成之後，我使用IDA 開始搜尋有關於與實現協議的代碼，來確定文檔中的協議是如何在韌體中實現的。我已經找到了第二版協議的說明，但是，通過逆向我發現他和第一版是有差別的。

由於沒有第一版協議的說明，我決定逆向協議處理部分的程式，瞭解二者的主要差異。雖然包的結構相似，但是，我還是發現了一些重要區別：第一版不支援身分識別驗證和對資料包載荷的加密，而第二版要求身分識別驗證和加密。

分析V1版的處理常式，我發現V2的一些處理常式也出現在V1裡，他們是set_configuration, get_configuration 和 set_macaddr。

1.set_configuration用來設施裝置配置

2.get_configuration用來擷取裝置配置

基於我目前所知道的，我已經準備好寫一個實現TDDP V1協議最小功能的Python指令碼，我首先將注意力集中在get_configuration請求上，希望可以收集我所需要的資訊。

使用指令碼發送資料包之後，硬體的返回看似關索引值設定檔。閱讀這個檔案，我們竟然發現了帳號和密碼。（我們在讀取配置資訊的時候沒有要求身分識別驗證）

雖然很有趣，但是我們還只是拿到了裝置的設定檔。我們依然離我們的目標——安裝一個自訂的韌體相去甚遠，而這才是我真正想做的。再次閱讀文檔，我想一個旨在調試的協議很可能有很多問題出現。我繼續逆向處理常式的其他部分，幾個小時後，當我在深入研究set_configuration的時候，我發現了一個類strcpy風格的函數，導致了一個簡單的溢出漏洞。

經過初步的分析，我發現利用這個漏洞的shellcoder有一些限制，例如，不能出現0或者空格。

通過這個漏洞，我可以劫持TDDP服務的執行流，指向自己的代碼，然後在更新功能上打上補丁，允許安裝我自己需要的韌體（包括舊版本）。

影響工作的主要問題就是裝置中沒有調試器，由於某些奇怪的原因，UART引腳也不工作了，我也不知道是為什麼>_>。我可以從裝置中獲得的唯一資訊就是PC寄存器的值和SP寄存器的值，他們在之前發現的web隱藏功能中。

下面的圖片顯示了進程列表是什麼樣子的，可以清楚的看見PC和SP的值。

我準備使用“跳轉調試”的方法寫一個漏洞利用指令碼，執行成功或者失敗，jmp指令就會使PC跳轉到不同的位置。

下面的圖片是使用這種方法操作pc指標的例子：

在這個例子中，檔案描述符（0xa）被載入了寄存器，之後jmp指令被執行，這證明了這個寄存器控制著我們所需要的值。

 

設計漏洞利用代碼

幾天之後，利用之前描述的細節，我已經可以使用ROP 技術通過gadgets控制PC寄存器了，但是，當我準備讓他運行我自己的代碼的時候（我考慮了前面提到的限制因素），卻失敗了。

我之前從來沒有寫過MIPS架構的漏洞利用代碼，在讀過一篇文章【1】之後，我知道了為什麼失敗了，原因是MIPS的cache沒有被重新整理(此處涉及MIPS架構中“緩衝一致性”處理---譯者注)，所以，寫入的shellcoder是不能使用的，部落格中所介紹的，解決該問題的辦法是調用sleep（）函數清除cache，但是在我的情況下，韌體沒有符號，識別sleep函數很難，為此，我開始學習MIPS的cache是如何工作的，我怎樣可以清除它。

閱讀這篇文章【2】讓我知道MIPS的cache是雙重的。

一個是資料cache（D-cache），另外一個是指令cache（I-cache），清除這兩個cache的過程是：首先，設定副處理器的TagLi和TagHi為0，之後調用指令 “cache   8, 0($a0)”（清除I-cache）和指令“cache   9, 0($a0)”（清除D-cache）。

查看整個韌體，我發現了一個函數的作用正是我想要的。（可能是用來初始化）

我發現這個代碼有一個小問題。

像韌體中其他函數返回時一樣，這個函數使用了jr $ra.作為結尾，$ra寄存器中的值是在這個函數被jalr調用時設定的，例如，你可以這樣調用foo函數：

$ra寄存器的作用是為了確定返回地址。在這個例子中，返回命令使用jr，因為，和jalr指令相反，jr指令不設定$ra寄存器。

通常的解決方案是使用ROP 鏈（或者對於MIPS架構來說，說成JOP更好），設定$ra寄存器的值（例如0x12345678），然後接下來調用函數跳轉到0x8016B910(cache清除函數)，這個函數會清除cache，接下來就可以調用自己的函數了（例如0x12345678）.

問題是$ra寄存器只會在函數結尾被設定，就像這樣。

前面的圖片就是函數結尾，在這裡，你可以看到，從棧中獲得數值後，$ra寄存器用來返回調用者，如果我把它設定為0x8016b910（清除cache），我會失去控制，因為這會形成一個無線迴圈。

那麼，怎麼辦？

我想到當I-cache被清除之後，新的指令會立刻被設定，這意味著我可以修改清除函數 (0x8016B910) 的結尾，用一下指令代替 “jr $ra ”  “jr $fp” (或者相似的)，使用這種方法，我可以清除cache並且跳轉進我的shellcoder。

下面顯示了函數指令在攻擊前後的變化;

最後，shellcoder的作用是在代碼中打上補丁，再調用指令啟用補丁，關閉韌體檢查。

和@_topo談話之後，他建議我讀關於MIPS的段布局，我之後發現可以使用kseg1 ，不適用kseg0，這樣的話，MIPS的cache就可以避開 (http://cdn.imgtec.com/mips-training/mips-basic-training-course/slides/Me...)。我沒有嘗試。

 

後記

首先是一個好訊息，這個服務不可能從廣域網路串連到，實際上，串連到wifi都無法訪問，所以需要使用有線串連。第二，這個韌體版本是2014年的。然而，在那時，這個韌體是這個裝置的最新版本。可悲的是，使用這個裝置的人很多都沒有升級。

對於其他TP-Link裝置有很多新的韌體，我們安裝了適配於TL-MR3020的最新韌體（2015年發布），這個服務依然存在，預設在監聽連接埠。第一版的協議代碼依然存在於這個韌體中，雖然第一版的部分指令被刪除（例如，擷取設定檔的代碼被刪除了），我們不能確定新版是否存在我們發現的漏洞。我們需要研究。雖然我們沒有裝置測試，但是，通過靜態分析2016年的韌體，相同的情況還是存在的。

根據攻擊的方案和裝置的配置（再說一遍，WiFi串連和公網上無法訪問這個服務），這個漏洞的最大作用可能就是允許攻擊者更改路由器韌體（可能包含持久性的後門），使他 可以從網路上擷取資訊。

 

結論

人們關注嵌入式安全已經有一段時間了，我們通常不會花很多時間關注所有常見的問題。

在無需身份確認的條件下，就可以訪問一個預設開啟的調試協議，是很糟糕的事情，廠家應該注意到這一點。通過上述的研究，我們可以發現，記憶體溢出漏洞很常見。成熟的安全防護方法也應該被應用於嵌入式中。例如，現在MIPS裝置支援XI(Execute Inhibit）技術，他就和英特爾的NX技術相似，作用是阻止執行使用者輸入的資料。實際上，開發中也應該採用正確的方法，例如源碼審計和滲透測試。

 

參考連結

【1】http://www.devttys0.com/2012/10/exploiting-a-mips-stack-overflow/

【2】http://cdn.imgtec.com/mips-training/mips-basic-training-course/slides/Caches.pdf

 

（發表於360安全客 http://bobao.360.cn/learning/detail/3221.html）

我的翻譯--一個針對TP-Link調試協議（TDDP）漏洞挖掘的故事