养猫之后,家里架起了两台监控摄像头,以供我上下班无缝赏猫。
摄像头本身有ddns功能,但想想看自家的监控摄像头可以被整个网络直接访问到,纵使有密码保护,心里还是觉得很恶心的。所以我在公司都是用vpn连回家里,在家庭内网环境中访问摄像头。
事实上两台摄像头中有一台是几年前买来看家用的,另一台是为了看猫最近新买的高分辨率版。两台摄像头并不是同一厂家出品,外形也很不相同,但神奇的是网页端管理界面竟然迷之相似,我一度以为这是同一集团不同分公司的产品。
后来经过我反复调查,发现这应该是某种现成的套件,各家厂商都在用罢了。
这个网页版管理界面做的可以说非常之 low。不说他杂乱的前端源代码,充满学生气息的界面设计,就连最重要的功能上都是严重缺失的。一个监控摄像头,竟然只有在IE下下载安装插件才能观看有声的实时直播,用 chrome 和手机浏览器都只能接收一张张的截图拼成一个幻灯片来看,声音更是甭想了。
我知道由于浏览器功能或者说 HTML 规则的限制,仅靠前端无法实现接收和播放 rtsp 直播流,但问题是服务器端也是你自家的啊,你做个 flv 直播流,做个 hls 直播流,怎么样都好,现成的库那么多,想让浏览器看个视频直播有什么难的= =
chrome 也真是讨厌,推翻 npapi 插件,又放弃了自家的 nacl 插件,跑去投奔一个不支持 socket 的 webassembly,导致我想自己写一个接收摄像头 rtsp 直播流的 chrome 插件都做不到了。虽然我也可以先写一个代理服务器,把 rtsp 流翻译成 flv 流或 hls 流,再用浏览器插件播放,可那很花功夫啊!我虽然喜欢写代码,但也会嫌麻烦的!
吐槽先放一放,说回到标题来。
从买到监控摄像头的第一天起,我就一直在担心摄像头被黑的问题。虽然我已经层层设防了,但每次进入摄像头的拍摄范围时还是时刻小心。没办法,我就是防人之心很重的人= =
想摄像头不被黑,先得知道摄像头会怎么被黑,然后才有办法防御嘛。再加上网络入侵本来就是一件对小青年很有吸引力的事,所以我开始好奇能不能入侵自己的网络摄像头。
参考这篇文章,我nmap了一下我的两台摄像头,发现并没有像作者遇到的情况那样简单的暴露出telnet端口或其他可疑端口。虽然证明我的摄像头更安全更不容易被人拿去搞ddos,但也让我更难入侵了…
直接登录不成,就从暴露出来的 http 服务器上找找线索吧。于是继续回来研究这个网页版后台。
大概看了一下,发现可能有多个服务器端程序在服务 http 请求:
看 response header 可知,服务器端的静态文件和 asp 脚本是跑在一个 http/1.0 服务器上的,返回的 server header 是厂商自定义的 “IPCamera-Web”。
另一方面,请求服务器上的 cgi 脚本或当请求返回 404 时,返回的 response 表明他的服务器使用 http/1.1 协议,此时返回的 server header 依然是厂商自定义的 “IPCamera-Web”。这个 1.1 的服务器的 200 response 总是会返回 “connection: close” header, 可见人家真的是 http/1.1 的服务器端呢。最后,当服务器请求失败返回 404 或 500 时,response 中不会携带 “connection: close” header,加上没有 content-length,也没有 chunked transfer encoding,仅从传输内容上已经无法判断这个 response 应该从何处结束了。不过从浏览器能正常访问后台页面这一点来看,1.1 的服务器端可能是发送 response 后直接断开了 connection,帮助客户端判断出了 response 的结束。不管怎么说,这最后一点使这个 1.1 服务器的实现显得很业余。业余好啊,说明代码中可能存在的安全隐患多,有助于我入侵系统。