IoT简单的架构图如下,其中包含了移动端、设备端和云端,几个端之间涉及多种通信方式。
(引自freebuf)
以上只是一个粗略的架构,在实际测试过程中,我们需要更细致的架构图:
各个组件之间的通信,大致可以分为以下:
移动端会与云端、设备端进行通信:常见的通信方式包括HTTP、HTTPS、WS、WSS、TCP、UDP等;
硬件设备端会与云端、传感器、移动端进行通信:与云端通信常见方式包括HTTP、HTTPS、WS、WSS、TCP、UDP,甚至有的还有FTP等;与传感器通信常见方式包括ZigBee、BlueTooth、Zwave、RF433、WIFI、TCP、UDP等;
云端会与移动端、设备端及第三方云端进行通信:与第三方云端通信常见方式包括HTTP、HTTPS等;
云端和第三方云端之间的通信,一般不具备测试条件,其他几个组件之间的通信都有办法可以嗅探、截取。移动端与云端之间的通信测试,一般会采用Burpsuite或者Fiddler等代理工具进行截断测试,如果是HTTPS的还需要在移动端安装证书。但是设备端不一样,一般不允许我们在设备端配置代理、安装证书,那么对于设备端和云端之间的通信,我们怎么做呢,本文主要交流设备端和云端之间的通信测试方法。
配置设备端不可行,换个思路,能不能在设备的网关处进行拦截。
上面是我们测试设备与云端通信搭建的测试环境,下面简要说明:
网关直接用了kali系统,方便进行测试。
两块网卡,iInf用于连接互联网;wInf是wifi设备,配置为热点,供IoT设备连接。这样,IoT设备配网成功后就能直接联网了。
现在,我们只需要将IoT设备访问互联网的数据转发到代理端口就可以了,通过iptables很容易实现:
iptables -t nat -A PREROUTING -i $wInf -p tcp --dport 80 -j REDIRECT --to-ports 9999
iptables -t nat -A PREROUTING -i $wInf -p tcp --dport 443 -j REDIRECT --to-ports 9999我们开启Burpsuite,配置监听端口为9999,那么上面的命令会将IoT设备访问互联网的80、443端口的数据转发到Burpsuite。
Burpsuite很重要的一点,配置监听端口时需要启用invisible proxying,否则是看不到数据的,在Alert里面会有信息提示。
同时使用wireshark等抓包工具对网络流量进行嗅探,获取Burpsuite不能截断的流量数据。
以上过程可以脚本化,方便随时接入不同的新设备进行测试。
测试环境已经具备,现在我们拿到了一个新设备,该如何进行通信测试呢?我们能得到的信息可能就只有设备的使用说明书,除了内部团队,别人基本上拿不到产品系统架构、通信、api这种细致的文档。所以,上面只是具备了测试条件,实际进行通信测试需要一定的步骤、方法。
第一步:全面了解设备通信
拿到设备时,我们不了解设备与云端通信会使用哪些协议、哪些端口。
所以我们必须使用抓包工具,比如wireshark,全面了解设备与云端的通信。
我们也不了解设备与云端通信时的HTTP(S)、WS(S)等具体端口有哪些,所以我们需要把所有目的端口都重定向到代理工具:
iptables -t nat -A PREROUTING -i $wInf -p tcp --dport 1:65535 -j REDIRECT --to-ports 9999
这样,一方面我们能掌握设备与云端通信的HTTP(S)、WS(S)流量,同时又不会因为没有拦截某些端口导致放过某些流量。比如,测试某设备时发现设备升级时使用FTP,如果我们仅仅拦截了80、443等端口,虽然通过wireshark能看到FTP数据,但是因为没有拦截,这时候设备已经升级了。
第二步:正式测试
测试过程中,我们需要维护一张通信表,不用太细致,但是要大概描述出来某通信做什么用的,比如是ximalaya资源、还是home cloud等等。
对于IoT设备,有一些测试点需要考虑:
一般的安全测试,主要是涉及数据部分,这部分内容都很成熟了,不再赘述。
IoT设备涉及到设备控制功能部分的,比如控制灯光、颜色、声音、温度、运动等等等等可以与现实交互(想不出更好的词)的部分,可能更多的会采用UDP、TCP通信,需要重点测试,比如重放;
IoT设备一般都涉及升级更新,而且基本上厂商都不会开放升级包,那么最好把升级包截取下来做分析。
本文虽然主要讲设备与云端通信测试,但实际上我们基本都是通过移动端来对设备进行控制,所以测试过程中,应同时进行移动端通信测试。
移动端和设备端同时接入测试环境,代理监听在不同的端口,这样能同时观察到移动端和云端、设备端和云端交互的逻辑。
有些情况下,需要将移动端采用常规的配置代理方式,观察数据交互。