通过对智能摄像头的网络结构和设备特性进行分析，总结了智能摄像头常见的几类攻击方式，并结合实际案例进行全面的安全分析。由于自己也是刚开始接触这方面知识，所以涉及的内容都比较浅显，大佬无视即可。
智能摄像头介绍
传统摄像头，一般指传统的只能存储监控画面的老实摄像头，如需及时发现画面中的异常，需长时间回看画面，比如之前一些警匪片中出现的几个人端着泡面守着电脑回滚监控视频。
而智能摄像头之所以称之为“智能”，就是由于智能摄像头可主动捕捉异常画面并自动发送警报，大大降低了用户精力的投入，方便、简单。智能摄像头的核心为物联网及云应用双剑合璧，缺一不可：要想实现即时且随时随地的监控，摄像头需要可通过手机 app 与手机相连，点开便可查看摄像头即时拍摄的画面；同时，当拍摄画面出现异常动态或声响时，摄像头除了可自动捕捉异常并启动云录像并自动上传，还可通过短信或手机 app 向用户发送警报信息，从而实现全天候智能监控。
智能摄像头网络结构
目前市面上的智能摄像头都包含了云端、手机端、摄像头设备端三部分。
摄像头设备终端：主要存放设备密码、与云端交互的信息、协议相关信息；
手机端：通过蓝牙、wifi 等方式管理智能设备、用户注册、密码修改、绑定设备、管理设备等；
云端：提供存储空间进行上传的视频存储、对用户进行管理、对 app 进行管理、提供 api 接口等。
智能摄像头常见攻击方法
根据网络结构中的三个部分云端、手机端、摄像头设备端以及通讯协议可分为四类攻击方法（部分内容参考了绿盟科技和白帽汇的物联网安全分析报告）。
针对摄像头设备的攻击
1、针对物理设备的攻击：调试接口暴露、固件提取、设备序列号篡改、篡改存储介质、获取普通用户权限、权限提升等；
2、针对固件的攻击：获取敏感数据、获取硬编码密码、逆向加密算法、获取敏感 api 接口、ftp 或 ssh 等服务攻击、固件降级等；
3、针对内存的攻击：获取内存中的敏感数据（如用户名、密码等）、获取加密 Key 等。
针对手机端的攻击
针对手机端 app 的攻击相对比较常见，而结合摄像头的特殊性，主要可以从以下几个方面入手。
1、静态反编译：对 APP 进行脱壳、使用反编译工具获取源码、本地敏感数据存储、logcat 日志、webview 风险测试等；
2、通信安全：中间人攻击、访问控制是否合理、数据加密强度等。
针对云端的攻击
云服务端面临的风险和常规的应用服务器类似，简单列举几个。
1、web 应用安全：用户注册的各种问题、任意用户注册、用户枚举、验证码缺陷、各种越权、密码复杂度、单点登录、密码修改等等。
2、服务安全：针对服务器开放的各种服务存在的缺陷进行攻击，如 ftp、ssh、mysql 等各种弱口令，针对操作系统的各种 Nday 和 0day 等；
3、其他：各种 C 段、子域名等等，还可以先打入摄像头公司内部办公网再觊觎服务器，DDOS 打乱对方部署也是一种思路。
针对协议的攻击
除了摄像头设备、手机端、云服这三个重要节点外，三者之间的通讯安全也非常关键。
1、APP 与云端一般通过 HTTP、HTTPS 通信，分析中应判断通信流量是否加密，可否抓包劫持通信数据;
2、设备与云端一般采用 MQTT、XMPP、CoAP 等协议通信，也会使用 HTTP、HTTPS 通信,部分厂家的设备会使用私有协议进行通讯，例如京东、小米、broadlink 等;
3、APP 与设备之间通信一般利用短距离无线网络进行通信，如 ZigBee、Wi-Fi 以及蓝牙等。
摄像头安全分析案例
情况简述
本案例是针对一互联网小型摄像头厂商，在测试前期已经和相关负责人进行了沟通并签署了授权和保密协议等，在测试后已经完全交付了测试结果，并在厂商整改后进行了复测确保所有风险均已修复。在时隔一年半后，已经确保该旧版摄像头已经基本退市，在征得厂商同意后才和大家分享一下本案例。由于部分加密算法和协议仍在使用，所以部分内容进行了脱敏和文字混淆。那时候也是刚开始接触这方面知识，所以涉及的内容都比较浅显，大佬勿喷。
本次分析主要包括摄像头设备、服务云端、数据通信三个方面，另外还涉及到部分手机端 APP、网站系统等。
固件升级包可被逆向
通过对 XX 官网提供的固件升级程序进行分析，发现大部分升级包均可被逆向出源文件，在固件包中可获取 ssh 和 ftp 登录账号和密码以及一些重要 api 接口和加密算法等，以 ssh 密码获取为例。
从其中下载了两个固件包为例进行测试，使用 Binwalk 对该固件进行分析。
从上图中可以看到固件中包含了 LZMA 压缩的数据和 Squashfs 文件系统以及其他系统信息，但 Binwalk 直接提取数据失败。
固件使用的是 squashfs 文件系统，它是一套供 Linux 核心使用的 GPL 开源只读压缩文件系统。squashfs 文件系统开始于 0×40040, 大小为 4605584 字节, 用 dd 命令提取该文件系统，再用 UnSquashfs 对 Squashfs 文件系统进行解包。
解压出来的系统文件：
可以查看系统文件信息：
可直接查看系统 passwd 文件：
使用暴力破解工具 john the ripper 可轻易破解该密码。
风险分析：
1、可根据 passwd 文档破解默认的摄像头 root 密码，通过该默认密码可直接登录暴露在内网中或互联网上的摄像头设备；
2、可根据系统内的文件逆向密码加密算法，破解摄像头和云端的通信数据。
加密算法可被逆向
通过对手机端 APK 的分析，发现虽然有的版本使用了加密和混淆，但通过解密和反编译后，大部分 APK 可直接被逆向出源程序。
使用 JD 可将 smali 反编译为 java 源码，更为直观的查看程序代码。
随后将 lib 目录下的 so 文件进行了逆向分析。
根据关键字定位到密码加密算法几个相关的函数。
由于逆向能力比较一般，于是又结合了上一节摄像头固件解包出的/progs/bin 目录下的 sctrl 文件进行逆向分析。
结合手机端 APK 和摄像头固件中的文件反编译分析，推导出了用户密码加密逻辑。用户密码使用了 MD5(unix)+SALT 的方式进行加密，SALT 使用了函数生成，但生成算法非常简单。
根据加密算法编写的解密算法如下：
使用该算法对密码 123456 进行加密：
该密文和用户在手机端 APK 登录时的加密后的密码完全一致。
这也证明了通过逆向加密算法而推导出的解密算法是正确的。
风险分析：
1、APK 未进行混淆、加壳或使用了较简单的加壳保护，很容易导致 APK 被反编译、重打包等；
2、较弱的 salt 生成算法可通过反编译还原出来解密算法，进而使用程序模拟用户登录。
用户密码可被批量破解
在用户使用手机端登录时，对数据进行抓包分析。
多次抓包分析后，可得到几个关键 TCP 数据包。
根据前面逆向编写出的解密算法，使用 socket 进行数据发包测试：
可以模拟 APK 进行用户登录，并能进行其他操作。如获取设备列表、添加设备、修改设备密码等。
分析发现，在用户密码正确和错误时，返回信息时不同的。
根据这种不同，可以设计字典对用户和密码进行破解。编写程序使用手机号字典进行用户枚举测试，简单测试后发现 150 多个手机号使用了 123456 做为手机端登录密码。
编写程序对手机云端 ID 号进行简单的枚举测试，经过十分钟测试便发现了在线且使用默认设备密码的手机云端 ID 号码有二三百个。
风险分析：
1、云端对 APK 发送的数据没有更多的校验，导致可编写程序批量破解用户名和密码，导致用户身份失窃。
2、通过通信数据的分析，可有针对性的编写程序进行批量添加设备，进行批量的破解设备密码。
3、理论上讲，使用该方法可遍历所有的用户、密码和手机端设备。
互联网设备可被探测发现
通过对摄像头设备的分析，发现摄像头在正常工作时默认开放了如下端口。
其中 80 端口为 web 管理端，11010 为数据转发端口。
而有些部署在互联网上的 XX 摄像头设备在开放一个 web 管理端外，也会开放 11010 端口进行录像机的管理。
使用 zmap 对全国 IP 进行扫描，发现中国境内 IP 开放了 11010 端口的服务器大约有 3.5W 个。
通过分析，在访问 web 管理时，服务器会返回如下信息，其中头信息 Server: thttpd/2.25b 29dec2003 可作为指纹进行摄像头识别：
通过 web 指纹对开放了 11010 端口的 IP 进行再次过滤，发现存在的主机有 3800 多个。
使用默认密码 admin/123456 对其中 IP 进了访问测试：
风险分析：
1、默认的、有特殊性的端口很容易被识别，导致设备被暴露在互联网上；
2、摄像头默认的弱口令比较方便用户记忆和管理，但也会给用户带来信息泄露的极大威胁。
设备可被未授权控制
在摄像头联网时，对摄像头和云端的通信数据进行抓包分析，发现摄像头会先请求手机端服务器 IP 地址。
得到服务器 IP 地址后，进行数据传输测试。
在选择好服务器后，随后的音视频的传输使用了 UDP 协议。
而通过几次分析，发现在该数据流中摄像头还会发送配置信息给云端服务器。
其中包括了云端 ID 号码、端口、SMTP 账号、密码等明文信息。在随后的修改密码测试时，通过手机端 APP 修改设备密码，发现了数据包格式为：
对 data 字符串进行分析：6a7ea9b5c000004a31b1add1515c000000860000000600000014000000000000000000000061646d696e0000000000000000000000000000003132333435360000000000000000000000000000b9dcc0edd4b1d5cabba700000000000000000000000000000000000000000000 发现 6a7ea9b5c000004a31b1add1 之后的字符为控制字段和密码字段。编写脚本模拟云端对设备进行密码修改。
可成功将密码修改为 123456789。随后的测试中，发现还可以控制摄像头重启或关机。
风险分析：
1、音视频流和控制数据流都使用了 UDP 进行传输，很容易实现中间人攻击，导致敏感信息泄露；
2、在监听到摄像头的通信数据后，很容易伪造数据进行摄像头密码修改、重启设备、控制云台；
3、在摄像头请求服务器 IP 地址的时候，发现系统使用了 DNS 解析域名，此时进行 DNS 欺骗可轻易劫持摄像头，进而对摄像头进行云台控制、关机、固件升级等非法控制管理。
多个 web 服务器存在漏洞
在对摄像头进行安全检测的同时，不可避免的接触到 web 服务器，虽未进行针对性的测试，但仍发现一些问题，在此仅列举一二。
手机端官网存在 s2-045 命令执行漏洞
测试中发现 IP 为 X.X.X.X 的服务器存在 Struts2-045 漏洞。 其中 xxx.com 和 xx.xxx.com 两个域名解析到该服务器上，在其中一个服务器上存在 struts2 命令执行漏洞。
http://xx.xxx.com/xxx.do?deviceGuid=xxx，使用 POC 程序可直接执行系统命令。
执行 whomai，使用了 root 用户。
查看 shadow 文件。
攻击者可以利用该漏洞轻易在远程服务器上执行任意系统命令，将会对受影响站点造成严重影响，引发数据泄露、网页篡改、植入后门、成为肉鸡等安全事件。
云端 ID 号码可进行枚举
在摄像头官网提供了一个云端 ID 号码查询的接口http://www.xxx.com/xxx/Support.jsp?id=S12923021
该接口可直接查询所有的云端 ID 号码，并显示是否在线。
当设备不存在时，返回值 rt=-1：
当设备离线时，返回 rt=1，dsls=0;当设备在线时，rt=1，dsls=1.
根据返回值的不同即可进行云端 ID 号码的暴力枚举，使用枚举到的在线手机端设备，可使用默认密码尝试添加查看。
管理后台存在越权漏洞
在进行 APK 测试时，发现 APK 广告管理平台存在越权。访问 URL:http://xx.xxx.com/Service/AdsList.do可查看所有广告信息。
通过该越权也可以轻易修改或删除广告信息，进而影响所有 APK 接收到的广告。另外一处经销商查询接口处，也存在越权。访问 URL 可直接查看所有供应商信息。
多个数据库使用了相同口令
通过 struts2 命令执行获取了一台服务器的权限，得到了其中数据库的密码，后来发现该公司多个云服务器上的数据库使用的都是相同密码，包括最重要的用户管理数据库和云 ID 号码管理数据库，也包括了两台重要的视频存储集群设备。
风险分析：
1、相比摄像头设备的漏洞，攻击者可能更擅长从 web 服务器入手，服务器一旦出现问题，那么所有的用户和设备信息都将受到威胁；
2、未授权访问可能导致供应商信息泄露、广告被恶意篡改，甚至管理员密码失窃等。
测试小结
通过测试，发现摄像头、云端、APP 之间的数据通信采用了一定的保护措施，但还是存在很多安全薄弱点。
1、算法可被逆向分析。私有算法的安全性取决于算法的不公开性，一旦算法逻辑可被逆向分析，那么在这之上建立的安全基础都将不复存在。
2、身份校验存在缺陷。在使用自发包控制摄像头或连通服务器时，摄像头和云端服务器没有对控制数据进行校验，导致可直接响应任意数据。
3、WEB 服务器存在的安全隐患较大。虽然本次测试并非针对 web 服务器，但测试中就已经发现中高危漏洞七八个之多，如果进行针对性 web 安全测试应该会有更多的问题。而且 web 服务器中保存着更多的用户数据和设备信息。
安全建议
1、平台安全性：采用安全隔离方式，把专网与公网从物理上隔离开，这是最切实有效的安全措施，防止摄像头在互联网上的暴露；
2、应有完善的授权机制，可以灵活地分配用户可以查看的摄像机、可执行的功能模块，可执行的具体功能等。因而用户只能查看权限范围内的摄像机和执行被授予的功能。
3、通信安全机制：在网络通信时，系统提供端到端（用户端-系统平台-设备固件）的 SSL 验证和数据加密。为防止视频流被非法用户截获，可以对视频文件进行加密传输，一般可以采用对称密钥体系进行加密，对每个视频流采用不同的密钥加密，只有有权观看此视频流的用户才拥有此密钥，可以对视频流进行解密，保障视频传输的安全性。
4、云服务器除了避免传统 web 漏洞外，对云端服务器的视频和文件进行备份和加密存储，防止因为服务器被贡献而导致用户数据泄露。
5、手机 APP 应该进行安全加固和代码混淆，防止 app 被逆向破解导致算法或业务逻辑泄露。
参考资料
https://www.zhihu.com/question/61252135 http://blog.nsfocus.net/handbook-safety-analysis-intelligent-equipment/ https://www.freebuf.com/column/202095.html https://iot-security.wiki/ https://nosec.org/home/detail/2113.html http://news.mydrivers.com/1/595/595362.htm https://ibotpeaches.github.io/Apktool/ https://zhuanlan.zhihu.com/p/30220669 https://security.tencent.com/index.php/blog/msg/92 https://www.jianshu.com/p/2bfde2ba8a99 http://www.freebuf.com/sectool/95426.html http://www.freebuf.com/articles/wireless/106298.html http://www.freebuf.com/news/88281.html http://www.freebuf.com/articles/wireless/106298.html https://blog.csdn.net/zhuangjitongxue/article/details/49337445 https://pan.baidu.com/s/1o6AbAqu https://www.cnblogs.com/aikm/p/5021220. html https://wenku.baidu.com/view/fb7271af941ea76e58fa04e7.html *本文作者：Tide 重剑无锋
评论