本環境是蛇矛實驗室基于"火天網演攻防演訓靶場"進行搭建，通過火天網演中的環境構建模塊，可以靈活的對目標網絡進行設計和配置，并且可以快速進行場景搭建和復現驗證工作。

自 2005年國際電信聯盟正式提出“物聯網（IoT）”這一概念以來，物聯網在全球范圍內迅速獲得認可，并成為信息產業革命第三次浪潮和第四次工業革命的核心支撐。同時，數以億計的設備接入物聯網，這些設備如今已滲透到我們生活的方方面面，從家居到工廠無處不在。一方面物聯網設備使我們的生活更加便捷，而另一方面物聯網安全事件頻發，全球物聯網安全支出不斷增加。

當前，大量物聯網設備及云服務端直接暴露于互聯網，這些設備和云服務端存在的漏洞一旦被利用，可導致設備被控制、用戶隱私泄露、云服務端數據被竊取等安全風險，甚至會對基礎通信網絡造成嚴重影響。從2018年全球統計數據來看，路由器、視頻監控設備暴漏數量占比較高。

路由器暴漏數量超過3000萬臺，視頻監控設備暴露數量超過1700萬臺，并且這些設備往后幾年會一年比一年多，物聯網安全的事件也會越來越多。由此，物聯網安全行業需要大力發展，物聯網安全人才的培養也刻不容緩。

蛇矛實驗室在后續將利用火天網境系列靶場中的相關目標仿真和環境構建的特性，將持續發布關于“物聯網安全-CVE實戰分析”系列的文章來幫助大家入門物聯網安全。

關于模糊測試

模糊測試（Fuzz Testing）是一種自動化的軟件測試技術，最初是由威斯康辛大學的Barton Miller于1989年開發的，通常用于識別程序中的潛在漏洞。其核心思想是自動或半自動的生成隨機數據輸入到一個程序中，并監視程序異常，如***，斷言 (assertion)失敗，以發現可能的程序錯誤，比如內存泄漏。

模糊測試常常用于檢測軟件或計算機系統的安全漏洞。Boofuzz是一個基于python生成的協議Fuzz工具，它通過python語言來描述協議的格式。Boofuzz對協議的模糊測試有著良好的支持，且其代碼開源，目前被廣泛使用，但Boofuzz無法直接獲取協議相關知識，需人工定義協議模型。這一小節，我們將使用Boofuzz實戰測試vivotek攝像頭棧溢出漏洞。

漏洞分析

下載好固件后，我們使用"binwalk 固件名"進行分析，發現固件并沒有加密，并且文件系統是squashfs格式，固件中的數據都經過了xz壓縮。

我們使用"binwalk -Me 固件名"遞歸提取里面的文件系統。

里面的目錄比較多，我們可以使用”find . -name ’squashfs-root‘ “，也可以使用tree命令快速預覽文件目錄分布情況。這里我使用"tree -d -L 5"命令，遞歸查看5層以內的目錄，然后就找到了"squashfs-root"文件目錄。

還是和前面小節的步驟相同，我們進入到文件系統的根目錄中，查看開機自啟"etc/init.d/rcS"文件。

開機自啟文件中，首先初始化系統，然后使用run-parts命令遍歷執行"/etc/rcS.d"目錄下的所有可執行腳本。

進入"etc/rcS.d/"目錄下后發現執行腳本均為軟連接文件，連接至"etc/init.d/"下的對應文件。我們在這里看到了httpd腳本，一般情況下路由器系統中的httpd為web服務程序，所以這里可能是啟動httpd服務的腳本。

我們查看"/etc/init.d/httpd"文件，發現httpd程序為 "/usr/sbin/httpd"程序，并且執行參數為"-c /etc/conf.d/boa -d"。確定了路由器的服務器程序，我們進行漏洞分析。

這一小節的漏洞信息以及POC已經在[exploit-db]中詳細的展示了出來。根據這里的漏洞詳情我們知道了vivotek攝像頭漏洞是棧溢出漏洞，觸發的具體位置為"Content-Length"頭。根據以上信息，我們將httpd程序放入IDA Pro進行分析。

IDA Pro分析完畢后，我們按"shift+F12"搜索Content-Length字符串，雙擊進入其存儲變量地址。

鼠標點擊"Content-Length"存儲變量，按“x”可以找到該變量的交叉引用。發現sub_17F80函數引用了該變量。進入函數進行分析

函數獲取由用戶"POST或PUT"方法請求包中的"Content-Length"頭位置并存入v33變量中。然后獲取" "的位置賦值給v34，獲取":"的位置賦值給v35變量。

隨后使用strncpy函數從":"后面+1位置的字節一直復制到“ "字符前面一字節的位置，將所有的字節復制到dest變量，dest變量為4字節的char型數組。

由于開發者沒有對“Content-Length”參數的值進行限制，導致攻擊者可以偽造"Content-Length"頭，寫入大量不為"x00"的垃圾數據就可以導致棧溢出。

知道了漏洞成因以及觸發位置，下面我們使用boofuzz進行fuzz測試，以下測試環境在ubuntu18.04中完成。

首先安裝boofuzz：

Boofuzz 官方要求 Python ≥ 3.5，并且推薦安裝方式為pip。那么我們先確保python和pip已經安裝。

sudo apt-getinstall python3python3-pip python3-dev

Boofuzz官方建議我們在虛擬環境 (venv)中設置 boofuzz 。那么我們需要安裝boofuzz的依賴

sudo apt-get installpython3-venv build-essential

創建boofuzz目錄，并在其目錄下啟動虛擬環境env，使其與其他包隔離

mkdirboofuzz && cdboofuzz
python3-mvenv env

這會在當前文件夾中創建一個新的虛擬環境 env。這里的虛擬環境中的 Python 版本是固定的，并且可以在創建時選擇。與全局安裝不同，虛擬環境中的虛擬環境python別名為 Python 版本。然后我們使用下面的命令來激活虛擬環境：

sourceenv/bin/activate

激活環境后，我們終端前面的標識多了一個"(env)"，這代表我們在虛擬環境中操作。

然后安裝最新版的pip和setuptools：

pip install-U pip setuptools

最后，安裝 boofuzz：

pip installboofuzz

安裝好以后，進入python3，測試導入boofuzz庫不報錯即為安裝成功。

安裝好boofuzz以后，我們就可以使用boofuzz框架進行fuzz測試了。我們需要編寫一個fuzz腳本，腳本如下：

fromboofuzz import*
IP = "127.0.0.1"
PORT = 80

defcheck_response(target,fuzz_data_logger,session,*args,**kwargs):
fuzz_data_logger.log_info("Checking for response ...")
try:
response = target.recv(512)
except:
fuzz_data_logger.log_fail("Unable to connect ...")
return
ifnotresponse:
fuzz_data_logger.log_fail("Empty response ...")
target.close()
return
fuzz_data_logger.log_info("Start checking ...
"+response.decode())
target.close()
return

defmain():
session = Session(
target=Target(connection=SocketConnection(IP,PORT,proto="tcp"),
),
post_test_case_callbacks=[check_response],
)
s_initialize(name="FUZZ")
withs_block("Request-Line"):
# Method
s_group("Method",["POST"])
s_delim(" ",fuzzable=False)
s_string("/cgi-bin/admin/upgrade.cgi ",fuzzable=False,name="URI")
s_static("HTTP/1.1",name="Version")
s_static("
",name="CRLF")
# Host
s_static("Host")
s_delim(": ",fuzzable=False)
s_string("127.0.0.1",fuzzable=False,name="IP")
s_static("
")
# Connection
s_static("Connection")
s_delim(": ",fuzzable=False)
s_string("Close",fuzzable=False,name="Active")
s_static("
")
# Content-Length
s_static("Content-Length")
s_delim(": ", fuzzable=False)
s_string("65", fuzzable=True)
# End
s_static("
")
s_static("
")

session.connect(s_get("FUZZ"))
session.fuzz()

if__name__=="__main__":
main()

上面的腳本***有倆個函數，一個main函數(腳本入口函數)，一個check_response函數(回調函數)。

main函數中，首先我們創建一個session，session可以設置一些基礎屬性，我們可以使用Target設置我們要fuzz的目標的ip地址和端口號以及協議類型(這里我們要fuzz的目標為httpd服務器，即tcp協議)。Target還可以使用post_test_case_callbacks指定回調函數。

當我們發送fuzz的請求包后，boofuzz需要判斷返回包的內容來確定是否具有漏洞特點，這里就需要用到回調函數。我們可以自己編寫回調函數，這里我們將回調函數指定為check_response函數，回調函數的參數'fuzz_data_logger'記錄測試檢查和通過/失敗。

boofuzz數據生成的特點為一個數據報文由Primitives和Blocks組成，多個Primitives可以組成Block，Blocks之間可以相互嵌套。所以我們需要初始化一個消息請求塊，這里我設置請求塊的名稱為FUZZ，然后通過s_block設置對應的http請求數據。然后我們可以指定對應的字段選擇fuzz，設置Content-Length參數的值為”fuzzable=True“。使用session.connect(s_get("FUZZ"))發送請求包裹，session.fuzz()開始驅動整個fuzz過程。

下面開始測試fuzz腳本，我們先模擬運行vivotek的httpd服務，訪問后發現服務正常。

運行我們的fuzz腳本，藍色字體的部分為腳本發送的request包數據，我們發現Content-Length參數后面的值確實是由boofuzz產生的fuzz數據。這里case 1中出現了紅色字體的報錯，為"Empty reponse ..."，也就是說沒有返回包。猜測服務器可能已經***，切換至模擬的路由器系統進行查看

果然，服務器已經***，說明我們的fuzz腳本是正確的，服務器不能正確處理Content-Length的垃圾數據，導致服務器***。

這時，我們可以訪問localhost:26000可以觀察boofuzz web服務中這次fuzz的詳細信息。

確定了確實是有棧溢出漏洞后，我們寫一個poc測試一下棧溢出偏移

正式運行路由器httpd服務，使用gdbserver進行attach，使用gdb-multiarch進行遠程調試。

我們在0x18538(strncpy函數)處下斷點，然后c運行，這時發送poc，程序斷在了strncpy處。pwndbg中顯示了strncpy函數執行時src和dest的地址。

拷貝到棧上時，0x7effeb4c處為返回地址，那么我們就算出了拷貝字符串到返回地址的偏移為0x34字節。下面我們開始寫exp

編寫exp的過程中，需要注意的點為strncpy復制時遇到"x00"停止，所以我們需要繞過"x00"找到可以用的rop gadget，然后通過已知的libc基地址找到system函數的地址運行命令。最終代碼如下

動態調試整個過程，下斷strncpy，沒拷貝前棧空間正常

strncpy拷貝完成后，我們觀察一下棧的空間分布

返回地址確實被我們覆蓋成了gadget的地址，說明我們前面的分析正確。

漏洞復現

啟動路由器后，運行我們的exp腳本

此時路由器系統中，已經運行了"nc -lp2222 -e /bin/sh"，我們使用nc連接后就可以獲得shell

使用nc連接2222端口后，隨意運行命令，命令成功執行，本次攻擊成功。

總結

這一小節，我們以vivotek攝像頭為例，簡短介紹了模糊測試框架Boofuzz，以及學習了如何利用該框架編寫腳本進行IoT設備服務進行fuzz。

審核編輯：劉清