探究?？低晹z像機中的重大漏洞

該漏洞并未在現(xiàn)場得到利用，因此不會對?？低暱蛻粼斐扇魏尉唧w的隱私侵犯或安全威脅。?？低晥F隊迅速采取了行動，修補了此漏洞，并將其他易受攻擊的產(chǎn)品也安裝了補丁。

技術(shù)概述

攝像機運行Linux操作系統(tǒng)。davinci進程包括攝像機的許多功能，比如Web服務(wù)器，并以使用者ID 0特權(quán)運行（用戶ID名為“admin”，當使用者ID為0時，它有效地賦予了root特權(quán)）。攝像頭的Web界面基于Embedthis appweb 3 Web服務(wù)器，?？低暈槠涮砑恿艘恍┐a。

?？低曁砑恿薟eb服務(wù)器的一些特殊頁面來控制攝像機的設(shè)置，通常這些特殊頁面僅在HTTP身份驗證通過后運行，但是其中一些頁面不需要身份驗證。

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

技術(shù)挑戰(zhàn)

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

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

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

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

通過查看相關(guān)功能，可以找到?？低晹z像機分配給maxUrl的值：

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

當使用GET變量從0x400中減去URI的長度時，我們得到了可以在變量的值中使用的有效負載的限制。我們?nèi)匀恍枰獜脑撝抵袦p去一個字節(jié)，因為還檢查了URI的長度是否相等。現(xiàn)在，我們可以檢查可用字節(jié)可以做什么。

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

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

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

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

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

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

給設(shè)備制造商的建議

攻擊者很容易發(fā)現(xiàn)并利用相機中的不良體系結(jié)構(gòu)導(dǎo)致的漏洞，因此制造商應(yīng)該檢查其設(shè)備研發(fā)過程中是否存在以下問題：

1.使用不安全的函數(shù)。sscanf是一個潛在的不安全函數(shù)，尤其是與％s或％［］一起使用時?？梢栽谥С值腁PI中用sscanf_s替換sscanf，或者可以通過添加長度說明符來安全使用sscanf（需要確保長度小于緩沖區(qū)長度，應(yīng)謹慎使用）。

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

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

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

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

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

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

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

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

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

編輯：jq