记一次电子猫眼的安全测试过程
引言
最近家里新买了一个电子猫眼，每次开门前，再也不用眯着眼睛从传统猫眼里往外看，而是通过一块屏幕直接看到门外的情况了。还可以通过手机远程连接猫眼，查看信息，或者进行实时通话。着实比较方便。
不过，这玩意儿的安全性到底如何呢？我反正是不信厂商的广告词，唯有经过一番安全测试才能让我有点安全感。于是乎，我抱着复杂的心情开始了针对这款电子猫眼的安全测试。一边盼着发现什么重大安全问题，同时一边又不希望真的发现严重安全问题，毕竟我自己也可能是受害者。
测试思路
麻雀虽小，五脏俱全。虽然只是个电子猫眼，但严格来讲也算是一个物联网系统。猫眼是物联网设备，通过Wifi接入互联网和IoT平台进行通信，同时还有一个移动端App允许用户在手机上查看猫眼中的数据、和猫眼实时通信。
在我看来，如果说物联网安全就是各种边缘设备本身的物理、固件安全，那么未免过于局限或狭隘。物联网安全应该涵盖由边缘设备、IoT平台或后端服务、移动端应用或Web应用所共同组成的整套系统的安全。
针对物联网系统的安全测试思路有很多，一种方式是先整体分析物联网系统的组成，随后对于各个组成部分依次进行扫描、测试，寻找安全漏洞留下的蛛丝马迹。而此次我选择的是另一种方式：在分析完系统组成后，先提出一个假设，假设这个系统存在某个破坏力十足的安全问题，随后到系统里进行测试，验证这个假设是否成立。与此同时，在这个过程中留意是否还有其他安全问题。
具体来说，对于电子猫眼而言，若权限控制失误进而导致数据泄露，显然是一个非常具有破坏力的安全问题。由于从移动端App上可以查看猫眼中以图片形式保存的访客记录、报警记录，还可以进行各种远程操作，因此若是权限控制有问题，那么攻击者就能查看、控制其他人的数据。
此外，用户之所以能在移动App上查看到他自己的猫眼数据，是因为设备绑定到了他的账号上。如果绑定流程存在权限控制问题，那么攻击者就有可能利用这个漏洞去绑定其他人的猫眼，从而查看、控制其他人的数据。
最终我选择先从移动端App和云平台之间的通信作为开始，之后再检查猫眼的绑定流程，看其是否存在安全问题。
安全测试场景1：移动端API接口权限控制
检查移动端App和云平台之间的交互API接口是否存在权限控制缺失或不足，从而通过修改或构造请求中的某些参数来达到越权访问其他人数据的目的。
我用BurpSuite进行网络抓包，打开移动端App之后，在Burp里看到发生了大量的网络请求：
图1：启动App后发送的大量网络请求
逐个对这些请求和响应进行分析后，并没有发现有什么可疑的地方。
此时就需要在App上进行一些操作，然后检查App发送出去的请求以及服务器返回的响应内容，判断其是否存在潜在安全问题。
App功能虽然不多，但每个操作的测试过程大体相似，因此下面只以“查看报警记录”为例进行说明。在手机上点击“查看报警记录”后，观察到发送出去的请求和响应如下：
图2：查看报警记录的请求和响应
从上面的截图可以看到，这个请求仅仅只是从服务器端获取到报警记录的一些基本信息，最重要的内容是每个报警记录的唯一标识符（图中fid字段）。在接下来的查看某个具体报警记录的请求中，将会用到这个ID：
图3：查看某个具体报警的请求和响应
一个经典的权限控制问题是，API请求中的用于标识用户、数据记录或者设备等等受保护资源的ID参数被修改，从而达到越权访问的效果。从以上几个截图可以看到，请求中出现了几个关键参数：token、fid和devid，这几个参数正好是几个标识符，让我们修改一下参数值看看能否达到攻击效果。
首先是token参数，从参数名来看应该是用户唯一标识符，确切的说应该是当前用户的有效session id，而且看上去没有什么规律，我修改了token值之后再发送请求，会收404服务器响应，看上去修改token行不通：
图4：修改token
其次是fid，这个参数值在前面提到过，在查看报警记录列表里会出现。当我把fid改为我自己的猫眼设备中的另一个fid后，服务器正常返回，而当我伪造一个fid时，服务器返回的则是404响应，看上去这条路也行不通：
图5：修改fid
至于devid，应该是猫眼设备ID，同样也是没有变化规律，而且修改它的值之后并不会对响应造成任何影响，因此也是一个无关紧要的参数。
经过进一步测试后发现，凡是发送给服务器的请求都必须带上token，有些请求必须包含fid或类似参数，而这些参数均无变化规律，修改后服务器也都会拒绝访问。从这个现象来看，移动端API接口的基本权限控制是没有问题的。
安全测试场景2：绑定流程
检查猫眼绑定手机账号的流程，强行绑定其他人的猫眼到我自己的账号。
要在手机上控制猫眼，需要先绑定设备。绑定流程是：
- 在移动App上登陆账号，并点击“添加设备”，输入猫眼要接入的Wifi密码，随后App将会生成一个二维码；
- 长按猫眼上的Home键，之后把二维码展示给猫眼的摄像头；
- 等待大约10秒后，手机App提示设备绑定成功。
表面上看，绑定过程很简单，但背后至少会完成以下两件事情：
- 通过二维码告诉猫眼如何接入Wifi；
- 猫眼接入网络后，告诉IoT平台应该把自己和哪个账号关联起来；
仔细分析就会发现，二维码在这个绑定流程里起到了非常重要的作用，它承载了Wifi信息、用户账号、猫眼设备信息等关键数据。解析App生成的二维码之后，更是进一步印证了这个结论：
图6：解析后的二维码
从上图可以看到，这是以分号为分隔符的几组数据，里面除了Wifi信息外，还有一个是用户账号ID，且看上去是以一个有变化规律的数字为后缀。如果我把这个ID更改为其他数值，理论上讲应该也能完成绑定，只是会把我的猫眼绑定到别人的账号下去，这和我的初衷可就背道而驰了，搞到最后把自己变成了受害者……
意外发现
在针对越权漏洞进行分析的过程中，还发现了一个小的安全问题。服务器端返回的响应里，在Header部分出现了Web服务器版本号信息。
图7：Web服务器版本号泄露
虽然算不上能直接造成危害的大问题，不过有经验的攻击者必然会依次为线索，寻找该版本的Web服务器是否存在已知安全漏洞，甚至是0 day漏洞，从而进行渗透。
未完待续
在上面第二个测试场景里，我只是分析了修改手机账号ID的可能性，有一个小的测试场景没有提到，那就是猫眼在接受了二维码信息后，会主动向IoT平台发送请求，告诉服务器端应该把自己和刚才二维码里的账号关联起来。
从逻辑推理上来讲，猫眼发送的这个请求里必然会带上自己的device id一类的数据，而如果这个请求可以被伪造，让我发起一个绑定设备的请求给服务器，其中写上我自己的账号ID和受害者的device id，那么就能达到绑定他人猫眼的效果。
不过以上只是逻辑上的推理，事实究竟如何呢？这背后有没有安全问题呢？敬请期待下回分解。
网友评论