如何使用D-Link高端路由器構建殭屍網路

譯者：興趣使然的小胃

預估稿費：200RMB

投稿方式：發送郵件至linwei#http://360.cn，或登陸網頁版在線投稿

一、前言

在本文中，我會向大家介紹D-Link高端路由器中存在的一些漏洞，受影響的路由器型號包括：

DIR890L

DIR885L

DIR895L

其他DIR8xx型號的D-Link路由器

這些設備使用了相同的代碼，這就給攻擊者提供了絕佳的機會，可以將這些設備一起納入殭屍網路中。此外，我們稍微修改了Mirai的編譯腳本，成功將Mirai移植到這些設備上。

本文也會順便說一下我們與開發者的交流過程（然而沒有取得任何進展，這些漏洞依然沒被修復）。這3個漏洞中，有2個漏洞與cgibin有關（cgibin是負責生成路由管理頁面的主CGI文件），另一個漏洞與系統恢復有關。

二、竊取登錄名及密碼

一句話概括：只需一個HTTP請求，攻擊者就能獲取登錄名及密碼。

我們發現的第一個漏洞位於phpcgi中。Phpcgi是cgibin的符號鏈接，負責處理對.php、.asp以及.txt頁面的請求。Phpcgi可以解析通過URL、HTTP頭或者POST請求正文（body）發送的那些數據。Phpcgi會創建一個長字元串，該字元串隨後會分解為若干組鍵值對（key-value），包括$GET、$POST、$SERVER字典以及其他php腳本變數都包含在這些鍵值對中。完成請求分析過程後，該符號鏈會檢查用戶的授權狀態。如果用戶未經授權，符號鏈會往字元串中添加值為-1的一個AUTHORIZED_GROUP變數。

從安全形度來看，這種解析過程存在一些問題。每個鍵值對（key-value）的編碼形式為：TYPEKEY=VALUE，其中TYPE指代的是GET、POST、SERVER或其他值。編碼完成後，鍵值對後會跟上換行符
。

通過POST請求，我們可以使用SomeValue%3dAUTHORIZED_GROUP=1這個字元串實現添加值的目的。這個字元串會被設備解析為_GET_SomeKey=SomeValue
AUTHORIZED_GROUP=1，通過這種方式，我們可以使用已授權用戶身份運行腳本（儘管可運行腳本的數量有限）。

向地址發送請求並添加SERVICES=DEVICE.ACOUNT鍵值對後，我們可以調用/htdocs/webinc/getcfg/DEVICE.ACCOUNT.xml.php

從設備代碼中我們可以看出，攻擊者可以運行位於/htdocs/webinc/getcfg目錄中的腳本。這個目錄中還包含一個DEVICE.ACCOUNT.xml.php腳本，可以為攻擊者提供大量敏感信息，如設備的登錄名及密碼等信息。

換句話說，如果攻擊者往

http://192.168.0.1/getcfg.php

發送請求，同時添加SERVICES=DEVICE.ACOUNT鍵值對，那麼設備在響應頁面中就會包含相應的登錄名及密碼信息。

對攻擊者而言，獲得這些信息已經足夠，比如，攻擊者可以使用登錄憑證將自製的惡意固件刷到設備中。

讀者可以訪問此鏈接了解完整的PoC代碼。

三、獲取設備的超級用戶許可權（從RCE到Root）

一句話概括：只需一個HTTP請求，攻擊者就能獲得設備的root shell。

第二個漏洞是個棧溢出漏洞，與HNAP（Home Network Administration Protocol，家庭網路管理協議）的執行錯誤有關。

如果想要使用該協議來發送消息，攻擊者需要向

http:?/192.168.0.1/HNAP1/

頁面發送請求，並在SOAPACTION頭部中指定請求的類型。設備對授權請求的處理過程存在漏洞。設備會使用

http:?/purenetworks.com/HNAP1/Login

值來調用授權函數。攻擊者可以在請求正文（body）中指定其他鍵值對（key-value），如Action、Username、LoginPassword以及Captcha（請求正文中事先已經包含一組預定義的值）。隨後設備會使用html標籤對這些值進行編碼，編碼結果如：<key>value</key>。

這裡最主要的問題出現在提取鍵值對的那個函數上，設備在棧上使用了一個大小為0x400位元組的緩衝區用於提取鍵值對，然而，攻擊者可以使用strncpy函數發送高達0x10000位元組的數據，這樣一來就會導致巨大的棧溢出問題。精心構造後，strncpy不僅會溢出當前的棧，也會溢出調用函數棧，因為「dest」變數最多能存儲0x80個位元組的數據，而攻擊者輸入的值可達0x400個位元組。

此外，當函數退出時，R0寄存器中存在一個指向該字元串的指針。因此，攻擊者可以指定一組sh命令，將返回地址修改為「system」函數。經過這些步驟，設備已處於攻擊者的掌控之下，任攻擊者宰割。

讀者可以訪問此鏈接了解完整的PoC代碼。

四、在恢復（Recovery）模式中更新固件

一句話概括：只需一次重啟，你就擁有root許可權。

第三個漏洞在於，當路由器啟動時，會啟動一個用於恢復模式的web伺服器，持續幾秒鐘。如果未授權的攻擊者通過乙太網線連接到設備上，他們就可以抓住這個機會，利用該伺服器更新設備固件。

為了利用這個漏洞，攻擊者唯一要做的就是重啟目標設備，重啟設備的方法有很多，攻擊者可以使用上面提到的漏洞完成重啟，也可以往jcpd服務發送「EXEC REBOOT SYSTEM」命令完成重啟。jcpd服務通過19541埠向本地網路提供服務，攻擊者無需經過認證即可訪問該服務，並且設備沒有提供關閉該服務的任何選項，是非常完美的操作目標。為了完全控制目標設備，攻擊者需要將自製的固件上傳到設備中。

讀者可以訪問此鏈接了解完整的PoC代碼。

五、時間線

這裡我想提一下我們跟D-Link安全團隊的溝通過程，時間線如下：

04/26/2017： 我們將hnap協議漏洞通知開發者。

04/28/2017： D-Link員工回復說他們已經在beta版的固件中修復了這個漏洞，我們可以從http://support.dlink.com下載相應固件。（註：D-Link主頁上沒有固件下載這一欄）

04/28/2017 – 05/03/2017：我們分析了D-Link在回復中提到的那個固件版本，發現我們通知開發者的某個漏洞仍然沒有被修復。

05/03/2017 – 05/09/2017：我們發現了固件中的另一個漏洞，通知D-Link並詢問前一個漏洞的修復情況。他們回復稱漏洞的檢測、修復以及評估需要一段時間。

06/01/2017：我們將漏洞信息通知CERT，收到的回復如下：

「向您問候並誠摯感謝您提交的漏洞報告。經過審查後，我們決定不處理該漏洞報告。我們建議您繼續跟廠商溝通，再公開這些漏洞信息。」

06/02/2017：D-Link沉默了將近一個月，因此我們決定採取一些行動。我們警告D-Link，如果他們對這些漏洞放任不管，我們會向公眾披露這些漏洞。

06/06/2017：D-Link在回復中提到了他們的漏洞響應過程，發送了一個beta版固件，在固件中修復了phpcgi漏洞。然而之前提交給D-Link的另一個漏洞仍然被開發者忽視了（可能D-Link安全團隊仍然堅信他們已經在beta版固件中修復了這個漏洞）。

我們再一次就未修復的漏洞聯繫D-Link。果不其然，我們沒有得到任何回復。我們從開發者那邊得到的最後一條回復如下：

「首先向您問候，我們的研發團隊正在研究您的漏洞報告。在理清漏洞來源、提供解決方案及確定問題範圍（我們需要確定漏洞影響的具體型號）之前，我們通常不會討論具體的進展情況。本周初我們應該會發布一些更新包。關於您的研究工作我無法提供任何進展信息。一旦我們修復漏洞後，我們會在support.dlink.com上公布經過第三方認證的具體信息。正如您看到的那樣，通常情況下，漏洞的修復周期為好幾個星期。經過驗證後，我們會以beta版形式向公眾提供固件，在公布RC版之前，我們還需要經過較長的質檢周期。完整的發布周期通常需要90天。如果您選擇早點公布漏洞報告，請向我們提供具體的URL地址。因為如果你希望該漏洞得到一個CVE編號，我們需要具體的報告作為參考。」

8月中旬，我們訪問support.dlink.com，發現開發者上傳了同一個beta版固件，該固件中仍有2個未修復。

因此，我們的結論為：

D-Link只在DIR890L路由器中修復了一個漏洞，其他設備仍然處於不安全狀態。

開發者完全忽視了其他兩個漏洞。

我只能說，幹得漂亮，D-Link！