如何攻擊 IP 攝像頭並搭建分析環境？

我寫這文章是為了分享我對 Edimax 生產的 IC-3116W IP 攝像頭的分析經驗。本文聚焦於如何開始分析 IP 攝像頭，當然本文提到的工具同樣適用於分析其他的設備。首先，我會介紹如何獲取目標固件，並利用固件來收集信息；然後，會講解如何進入系統；最後，會講如何在設備上面安裝 gdbserver。不過，本文不會去分析那些相對複雜的漏洞，而只專註於那些有助於我們分析設備漏洞的部分，包括後面會提及的一個管理界面遠程代碼執行漏洞(當然這個漏洞早已提交給了相關廠商)。

分析設備

這章開始，我們將會在一個已經搭建好的攝像頭測試環境中介紹分析的步驟，當然這個測試環境與一般的 Web 應用滲透測試環境沒什麼太大的區別。在最初的階段，我們需要通過一些外部資源(例如廠商網站或者谷歌)來收集攝像頭的信息，然後利用適當的工具(Burp Suite，nmap等等)掃描攝像頭可能暴露的服務(特別是管理界面)。隨後就是利用階段，我們需要拿到進入攝像頭的許可權，最後就是後利用階段了，此時我們就可以適當的在攝像頭上部署調試分析工具。

步驟1：收集信息

在分析設備前最關鍵的步驟就是儘可能多的收集相關信息，幸運的是，Edimax 官方網上提供了大量攝像頭的信息，如數據表，操作手冊，固件和構建工具(包括構建鏡像的文件)，但是一些涉及敏感信息的二進位文件源碼沒有公開。

固件可以提供對攝像頭最初的認識，通過使用 binwalk 分析固件，可以提取出攝像頭的文件系統。

$ binwalk -e IC3116W_v2.10.binnnnDECIMAL HEX DESCRIPTIONn-------------------------------------------------------------------------------------------------------n605 0x25D LZMA compressed data, properties: 0x88, dictionary size: 1048576 bytes, uncompressed size: 65535 bytesn10392 0x2898 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 3735204 bytesn1245312 0x130080 Squashfs filesystem, little endian, version 4.0, compression: lzma, size: 4072088 bytes, 907 inodes, blocksize: 131072 bytes, created: Mon Feb 22 11:50:40 2038n

從上面信息可以得知，開發人員使用了 SquashFS 文件系統，為了瀏覽文件系統，我使用帶有 LZMA 支持的 unsquashfs：

$ unsquashfs -d filesystem 130080.squashfn

這樣我們就獲得解壓過後的文件系統(存儲在filesystem文件夾下面)

$ ls -a filesystemnnn. .. bin dev etc home init lib mnt proc sys test tmp usr var web wwwn

在提取出文件系統後，我們就可以來瀏覽攝像頭的相關文件了。這個文件系統里包含一些有趣的二進位文件，如：telnetd，wget，FTP等等，但是通過使用 Nmap 掃描得知，telnet 守護進程默認情況下沒有運行。

$ nmap -sS -p0- --reason -v -T3 -Pn 192.168.2.3nnn[...]nNmap scan report for 192.168.2.3nHost is up, received arp-response (0.00065s latency).nNot shown: 65534 closed portsnReason: 65534 resetsnPORT STATE SERVICE REASONn80/tcp open http syn-ackn554/tcp open rtsp syn-acknMAC Address: 74:DA:38:34:AA:75 (Unknown)n[...]n

Web 服務的根目錄位於 www 下面，在這裡我發現了一些無需身份認證直接就能訪問的 CGI 文件：

/www/camera-cgi/public/anonymous.cgin/www/camera-cgi/public/getSysteminfo.cgin/www/camera-cgi/public/supportiPhoneAppVersion.cgin

其中，anonymous.cgi 和 getSysteminfo.cgi 透露了很多 IP 攝像頭的安裝信息(包括內部IP地址，固件版本等等)。

在查看攝像頭文件系統中的文件後，下一步就是利用自動化工具結合手動測試來發現攝像頭內部服務是如何運行的了。如之前 Nmap 的掃描結果，有一個運行在 80 埠的 Web 服務，通過查看相機背面的說明信息，得知其默認賬號密碼是 admin:1234。

有了這個賬號密碼我們就可以進行下一步獲取系統訪問許可權的內容了。

步驟2：獲取系統訪問

在通過自動化掃描和手工測試後，我在攝像頭的 Web 界面中發現了 System Log 允許遠程命令執行。通過輸入 telnetd 的路徑，攝像頭的 telnet 服務就被開啟了。

這樣，我們就可能通過 telnet 進入攝像頭了：

$ telnet 192.168.2.3nTrying 192.168.2.3...nConnected to 192.168.2.3.nEscape character is ^].nnnIC-34AA75 login: adminnPassword: nRLX Linux version 2.0n _ _ _n | | | ||_| n _ _ | | _ _ | | _ ____ _ _ _ _ n | |/ || | / / | || | _ | | | | / /n | |_/ | |/ | || | | | | |_| |/ n |_| |_|_/_/ |_||_|_| |_|____|_/_/nnnFor further information check:nhttp://processor.realtek.com/nnnnBusyBox v1.13.4 (2015-02-25 18:14:22 CST) built-in shell (ash)nEnter help for a list of built-in commands.nnn# cat /etc/passwdnadmin:$1$yAn92Ld/$u5nHFH9nLds0naDaLuK1d/:0:0:System Administrator,,,:/:/bin/shn

telnet 的用戶憑證跟 Web 管理界面是一樣的，從 /etc/passwd 文件發現只有一個賬戶 admin(uid 0，gid 0) 存在於系統之中，這就意味著我們直接就有了系統的 root 許可權了。

當然，我們也還可以通過 UART 埠來獲得系統 Shell，埠可以在下圖中看到：

步驟3：建立研究環境

在攝像頭上有許多工具可以幫助我們分析運行的進程，但不幸的是，在攝像頭上沒有調試器或編譯器，而我的目標是在攝像頭上面運行調試器，具體點是，我想在攝像頭上面運行 gdbserver，然後在本地的 x86 機器上面運行 gdb。

在攝像頭上面運行 gdbserver 有這麼幾個優勢。首先，gdbserver 的二進位文件大小比 gdb 的要小不少，鑒於嵌入攝像頭的磁碟通常比較小，經常 gdbserver 會是我們調試唯一的選擇；其次，gdbserver 的依賴項也比 gdb 少不少，而且更加容易編譯。當然，gdbserver 也有它的缺點，例如，如果主機系統(運行 gdb 的系統)與目標系統(運行 gdbserver 的系統)位數不同就可能出現問題，這也就是為什麼我讓 gdb 運行在 x86 的機器上。

為了將安裝文件上傳到攝像頭文件系統當中，我選擇使用 wget，需要注意的是 squashfs 文件系統是只讀的，但是我已經將快閃記憶體掛載到了 /var 目錄下面，所以我們可以把文件寫入這裡。想要從攝像頭傳輸文件出來，可以使用 lighttpd，這個是攝像頭自帶的 Web 伺服器，只需要在啟動伺服器另一個實例並將根目錄設置為 "/" 即可。

在建立了本機與攝像頭文件傳輸的通道後，是時候在攝像頭上編譯 gdbserver 了。在此之前，我們需要先知道攝像頭使用的處理器：

# cat /proc/cpuinfonsystem type : RTL819xDnprocessor : 0ncpu model : 56322nBogoMIPS : 658.63ntlb_entries : 32nmips16 implemented : yesn

從上面的輸出我們得知使用的是 RTL819xD，這是一個基於 MIPS 的處理器。因此，我首先嘗試使用標準的 MIPS 交叉編譯。交叉編譯的源碼來自於 Aboriginal Linux 網站，他們不僅提供大量交叉編譯器，還提供了用於構建環境使用的腳本。

但是底層的 Realtek CPU 使用的卻是改進的指令集，而純 MIPS 二進位文件通常無法直接在攝像頭上運行。但是正如之前提到的，Edimax 已經為我們準備好了一套用於構建的工具。通過使用 CentOS 7.3 和提供的工具，我建立了一個攝像頭的環境，關於構建環境的步驟都在官方提供工具的一個 pdf 說明文檔中，基本上就是如下步驟：

1. cd TARGET_DIRn2. bzip2 -cd rsdk-{VERSION}-{LIBRARY}-{PLATFORM}.tar.bz2 | tar xvf –n3. ln -s rsdk-{VERSION}/{PLATFORM}/{LIBRARY} rsdkn4. export PATH=TARGET_DIR/rsdk/bin:$PATHn

現在我可以通過 CentOS 系統來交叉編譯用於攝像頭的二進位文件了。例如交叉編譯 gdbserver 只需要如下命令：

$ cd gdbserver_srcn$ ./configure --host=mips-linux CC=rsdk-linux-gccn$ ./make CC=rsdk-linux-gcc AS=rsdk-linux-as LD=rsdk-linux-ldn

最後，我們獲得了可以運行在攝像頭上面的 gdbserver 二進位文件。相應的，我們可以通過相同的方法獲得 gdb 的二進位文件，不過幸運的是，官方提供了一個預編譯好的二進位文件。當然，如果你想要自己編譯也是可以的，只需要在編譯的時候使用不同參數：

$ cd gdb_srcn$ ./configure --target=mips-linuxn$ ./maken

在構建過程中，我們必須要制定目標系統，即 gdbserver 將要運行在哪個系統之上。另外，我測試了多個不同版本的 gdb/gdbserver 後，發現 gdb-6.8 可以運行在攝像頭上。

最後，我想要說明 gdb/gdbserver 是如何分析運行在攝像頭上二進位文件的。但請先將 gdbserver 二進位文件拷貝到 /var 目錄下面，並通過 chmod 給予執行許可權。然後我們就可以通過如下命令進行調試了：

# /var/gdbserver ip:port --attach pidn

這裡的 IP 是運行 gdb 主機的地址，而指定的埠 port 則會在目標系統上開放，隨後的 PID 是我們想要連接的進程 ID。當然，我們還可以在攝像頭中啟動一個新的進程，通過指定可執行文件的路徑來代替 –attach 參數。

一個在攝像頭上抓取 /bin/ipcam 二進位文件運行的實例如下：

# /var/gdbserver 192.168.2.10:1234 --attach 9266 nAttached; pid = 9266nListening on port 1234n

在執行了該命令後，gdbserver 就會在 1234 埠上等待連接，而在 x86 主機上，我們需要啟動 gdb 並使用如下命令連接到目標系統：

$ rsdk-mips-gdb -qn(gdb) target remote 192.168.2.3:1234 nnnRemote debugging using 192.168.2.3:1234n[New Thread 9266]n0x2ab6b89c in ?? ()nnn(gdb)n

然而，我們看到 gdb 沒有上下文，即它不知道當前的狀態。這是因為 gdb 載入的二進位文件符號表是在目標伺服器上進行調試的，因此，需要在本地使用 gdn 的文件命令在載入一次符號表。此外，在本地調試攝像頭文件系統中庫的副本時，需要保持和 gdb 同處於根目錄之下。

$ cd cam_root_dirn$ rsdk-mips-gdb -qn(gdb) file cam_root_dir/bin/ipcamnReading symbols from cam_root_dir/bin/ipcam...(no debugging symbols found)...done.n(gdb) target remote 192.168.2.3:1234 nRemote debugging using 192.168.2.3:1234n[New Thread 9266]n0x2aaa8a40 in _start() from cam_root_dir/lib/ld-uClibc.so.0n(gdb)n

至此，我們就可以像在攝像頭上原生使用 gdb 一樣進行調試了，例如設置斷點，分析寄存器等等。當我們擁有了這樣一個分析環境後，就可以進一步去分析攝像頭的其他服務了。

註：本文參考來源於insinuator

推薦閱讀：