前言

虹科Vdoo的安全研究團隊對領先的物聯網產品和安全設備進行了大規模的安全研究，為了提高效率和透明度，此過程設備供應商也參與其中。

這項研究的一部分是研究人員在多家供應商的設備中發現了零日漏洞。這些漏洞我們已經負責任地以最佳方式向供應商披露，并將在披露期限結束后逐步分享。

我們發現易受攻擊設備的供應商之一是海康威視。研究團隊在海康威視安全攝像機中發現了一個漏洞。攻擊者利用該漏洞能成功獲取攝像機IP地址，并且使用攝像機的root特權（通過LAN或Internet）遠程執行代碼。虹科Vdoo負責任地披露了此漏洞（CVE-2018-6414），并與海康威視的安全團隊合作解決了此問題。

該漏洞并未在現場得到利用，因此不會對海康威視客戶造成任何具體的隱私侵犯或安全威脅。海康威視團隊迅速采取了行動，修補了此漏洞，并將其他易受攻擊的產品也安裝了補丁。

技術概述

攝像機運行Linux操作系統。davinci進程包括攝像機的許多功能，比如Web服務器，并以使用者ID 0特權運行（用戶ID名為“admin”，當使用者ID為0時，它有效地賦予了root特權）。攝像頭的Web界面基于Embedthis appweb 3 Web服務器，海康威視為其添加了一些代碼。

海康威視添加了Web服務器的一些特殊頁面來控制攝像機的設置，通常這些特殊頁面僅在HTTP身份驗證通過后運行，但是其中一些頁面不需要身份驗證。

在處理對不需要HTTP身份驗證的頁面的請求的代碼中，存在對sscanf的非安全調用，當使用特制請求時，該調用會導致緩沖區溢出，從而損壞內存和導致任意代碼執行或進程崩潰。

技術挑戰

此漏洞使攻擊者可以在相機的固件中執行他們選擇的一段代碼。當用戶使用登錄網頁登錄時，將發送一個POST請求，其中也可以包含GET參數。

在解析特定GET參數的代碼中，有一個對isoc99_sscanf的調用。該isoc99_sscanf函數類似于已知的scanf函數，但不是從stdin讀取它的輸入，而是從一個字符串輸入。在這種情況下，輸入的字符串包含請求查詢字符串：

函數的格式字符串由參數名稱組成，后面連接“ =％s”。這意味著函數期望字符串以參數名稱開頭，后面連接“ =”，然后將其后的任何字符串讀入上圖中名為“ s1”的堆棧變量中。這允許我們向堆棧中寫入任意數量的字節，％s沒有限制。唯一的限制是Web服務器應用于整個URI（包括查詢字符串）的限制。

在頁面背后的任何邏輯發生之前，首先應用Web服務器的限制，如appweb 3源代碼所示（可以在github上查找）：

通過查看相關功能，可以找到海康威視攝像機分配給maxUrl的值：

將偽代碼與原始代碼進行比較時，很容易理解“ v3 ［52］”代表conn-》 http-》 limits，并且該值的偏移量是48。當找到用于初始化值的函數時我們將看到該值設置為0x400（這與原始appweb 3源代碼中找到的值不同）：

當使用GET變量從0x400中減去URI的長度時，我們得到了可以在變量的值中使用的有效負載的限制。我們仍然需要從該值中減去一個字節，因為還檢查了URI的長度是否相等。現在，我們可以檢查可用字節可以做什么。

回到漏洞的函數，我們將觀察堆棧框架并檢查其中的“ s1”變量的偏移量。在此特定固件中，變量位于與堆棧起始位置足夠近的偏移量處，這意味著我們可能會溢出到堆棧幀的起始位置。但是，在我們檢查的某些其他固件版本中，該變量位于堆棧的較低地址，這不允許我們到達堆棧幀的起始位置。在這種情況下，如果通過覆蓋駐留在堆棧框架上的變量，漏洞可能仍會部分被利用。

由于調用函數的返回地址位于堆棧幀的起始位置，因此通過覆蓋它，我們可以控制接下來要運行的代碼（在函數返回時）。

由于攻擊是基于％s sscanf格式說明符的，因此我們不能在攻擊中使用任何空格，也不能使用NULL字符。這限制了我們，因為代碼部分中的所有地址都以NULL字節開頭。但是，我們使用了眾所周知的技術來克服此限制。

幫助利用此漏洞的一件重要的事是，雖然已將ASLR用于已加載的共享庫，但未將其用于固件的主要二進制文件。因此，可以準確知道代碼所在的位置，從而使我們可以跳至自己選擇的代碼段。我們還可以看到沒有使用stack canaries，因此我們可以安全地覆蓋堆棧的內容，而無需對其進行檢查。

完成所有操作后，我們需要選擇一個地址跳轉至該地址。例如，類似于Foscam PoC，我們選擇跳到一段代碼來重置設備的憑據，從而使我們能夠以管理員身份登錄設備。然后，作為設備管理員，我們可以控制任何設置，包括使用自定義固件升級設備的能力。

考慮到此漏洞帶來的風險，我們決定不發布PoC，以保護尚未升級其設備的用戶免受惡意攻擊。

給設備制造商的建議

攻擊者很容易發現并利用相機中的不良體系結構導致的漏洞，因此制造商應該檢查其設備研發過程中是否存在以下問題：

1.使用不安全的函數。sscanf是一個潛在的不安全函數，尤其是與％s或％［］一起使用時。可以在支持的API中用sscanf_s替換sscanf，或者可以通過添加長度說明符來安全使用sscanf（需要確保長度小于緩沖區長度，應謹慎使用）。

最佳操作是即使在特定情況下也不要使用任何不安全的功能版本，定期使用它們很危險。特別是，建議不要使用sscanf。固件中發現的其他可能不安全的功能包括strcpy（可以替換為strncpy），strcat（可以替換為strncat），sprintf（可以替換為snprintf）等等。

2.主二進制文件缺少ASLR。ASLR已在設備上運行的Linux OS中實現并打開，唯一要做的更改是通過在GCC上添加“ -pie-fPIE”標志來使其與主要二進制文件兼容。使用此功能，攻擊者無法猜測他想跳轉到的功能地址。

3.缺少stack canaries。這是一個非常簡單且重要的安全功能，可以通過在GCC中添加“ -fstack-protector-all”標志來啟用該功能，當可執行文件識別出堆棧受到破壞時將崩潰。這將導致短暫的拒絕服務，但至少它不允許攻擊者運行其選擇的代碼。

重要的是要注意此功能可能會導致性能下降，因為對每個功能都檢查了stack canaries。如果性能下降使其無法使用，則可以控制stack canaries的創建，并將其設置為僅放在極容易遭受基于堆棧的緩沖區攻擊的函數上。這可以通過將“ -fstack-protector”標志與“ --param ssp-buffer-size”一起使用來完成。

4.URL參數應該被清理為僅包含ASCII可打印字符。與ASLR結合使用，將降低該漏洞的利用率。

5.使用對稱加密對固件文件進行加密。這使攻擊者可以打開固件進行研究。

6.固件文件未經過數字簽名。這使攻擊者可以重新打包惡意固件，供應商應考慮簽署其固件，以防止受到這種威脅。

7.在我們研究的固件中，使用了appweb 3，特別是它的舊版本-長期未維護。如https://www.embedthis.com/appweb/download.html 所述，此版本以及一些較新的版本被稱為“壽命終止”，這意味著它將不會獲得任何安全補丁。

8.該設備的幾乎所有邏輯都包含在一個二進制文件中。當所有內容都在一個二進制文件中時，特權分離就會減少，這會增加攻擊面。例如，任何設備功能中可能存在的拒絕服務漏洞都將使主進程崩潰，并且許多設備功能也將遭受損失，而不僅僅是使負責特定邏輯的進程崩潰。將攝像機的邏輯劃分為不同的二進制文件可能還會使利用代碼執行漏洞變得更加困難，因為進程內存中的可用代碼更少，無法跳轉。

編輯：jq