IoT安全测试指北 – 作者:3unshine-安全小百科

物联网（The Internet of Things，简称IOT）是指通过各种信息传感器、射频识别技术、全球定位系统、红外感应器、激光扫描器等各种装置与技术，实时采集任何需要监控、连接、互动的物体或过程，采集其声、光、热、电、力学、化学、生物、位置等各种需要的信息，通过各类可能的网络接入，实现物与物、物与人的泛在连接，实现对物品和过程的智能化感知、识别和管理。

关于IoT安全测试的方法，网上也有一些资料，但感觉有用的分享并不多，且杂。关于IoT要学的东西也还有很多，肯定不是本文这些内容就能说完的，本文就个人已知的知识部分结合经验简单总结一下IoT如何进行安全测试。

IoT体系结构

作为安全人员，需要对测试目标进行充分了解后才能去思考目标可能会存在的问题，也是本质上的从信息收集开始做起。

首先需要清楚当前测试的目标的体系结构，此处引用前人总结过的分类

执行器：通过物理过程控制事物，如空调机组，门锁，窗帘
网关：用于收集传感器信息和控制中心
传感器：用于检测环境，例如光，运动，温度，湿度，水/电量
云：Web界面或API托管用于收集数据的云端web应用和大型数据集分析。一般来说，就是用来做信息与其他方资源共享
移动（app）：移动设备大多使用的，在设备上的应用程序，以实现手机端控制IoT环境来进行互动

IoT攻击面及测试思路

综合上文，笔者认为可以进行安全测试的攻击面有如下部分：

（没写的就是不会，会我就写了 (￣□￣｜｜) ）

1、协议

IoT目前所用到的协议有很多种，本文列举本人遇到的过的较为常见的几种，包括HTTP、TLS/SSL、S7Comm-plus、websocket、MQTT

HTTP

HTTP协议大概是安全人员最熟悉的协议之一了，在IoT情景中，简单分为两种情况，有web应用和没有web应用的。

先对有web应用的情景进行分析，常见的IoT设备有路由设备（TP-Link、D-Link等）、视频监控（海康威视、各种DVR等）、门禁考勤系统（Linear eMerge E3-Series）、智能网关（GPON Home Gateway）等。

这种其实不需要多作赘述，基本都是常规的web渗透一把梭，常见的问题有默认密码、弱口令、越权、RCE等。

对没有web应用的情景进行分析，这类设备就太多了，离生活较近的有打印机、智能烤箱和电饭煲、智能咖啡机、智能语音助手等。这一类设备大部分功能其实还是使用其他协议完成，但是总要一部分功能会需要用到HTTP协议，举个栗子，笔者家里有个智能电烤箱，能绑定后通过某语音助手来进行命令下发（开关机和设定烤箱温度时间等），需要扫描产品上方的二维码进行绑定，类似下图

而二维码其实解析出来是一段URL形如http://target.com/xx/?sid=xxx

经过测试sid为烤箱编号，能够进行遍历修改，也可以对烤箱进行解绑操作，不过自己家用的那款利用起来比较麻烦，绑定过程需要输入附近的WIFI密码使烤箱联网，因此并未达到直接绑定操作任意其他烤箱，但可以引为思路。

以上其实还是偏向于web安全测试，但是也有部分IoT设备能提供特别的环境，局域网。比如某智能音箱，通过wireshark等软件的抓包可以发现音乐点歌的功能是使用了HTTP请求的，那么这一点就存在三个可测试方案，一个是中间人攻击，在非安全的网络环境中，通过中间人的方式替换请求就能使音箱播放指定歌曲，比如无论用户点什么歌，最后播放的都是《今天是个好日子》，可能会对用户造成精神污染最后导致退货和投诉，对厂商还是有一定危害和影响的；再一个就是如果某些特定操作是通过HTTP请求来进行实现，例如智能咖啡机的咖啡制作功能（当然，大部分咖啡机都没有使用HTTP，此处只是举例）是通过一条HTTP请求完成，那么通过抓取数据包后进行重放攻击，就能不断获取新的咖啡，一杯给领导，一杯给女神，还有一杯自己喝；最后再举一个栗子，智能门禁系统，如果使用HTTP协议，将用户刷卡信息上传到服务器中，我们在内网可以通过嗅探等方式捕获这些数据，导致敏感信息泄露的问题。

简单总结下这一段，对没有web应用的设备进行安全测试，需要尽量找到设备的HTTP请求，在该请求的基础上，尝试中间人攻击、重放攻击、敏感数据获取。（除此之外其实也可以按照web渗透的方法进行测试，权限绕过、SQL注入等，毕竟各种IoT环境实在太多，本段只是举了三个个人认为比较通用一点的面。）

TLS/SSL

加密后的流量虽然可以被抓包工具捕获，但是一般都无法获取有效信息，因此针对使用了TLS协议的设备，首先需要将流量解密，关于解密方法，一种是通过该协议本身的漏洞进行解密，但这一块本人没有太多的研究，不进行深入，另一种是通过对设备固件进行分析，获取解密方法，这一块涉及逆向和二进制等方面，也无法进行过多深入。当然流量解密后，测试方法就参考上文所写HTTP协议部分即可。

S7Comm-plus

了解的不多，但是貌似用的不少，可以参考另一篇文章

西门子S7comm-plus通信过程及重放攻击分析

Websocket

websocket用的最多的地方还是即时通信，通常在工业互联网中用的毕竟多，比如需要实时监控某些信息的设备。

一般通过抓包可以看到

测试方法并不局限，就本人测试过的而言，主要问题是没有鉴权，很多时候直接请求接口就完事了，服务器正常接收并执行，这一点还是很危险的，不过使用websocket大部分还是用于实时数据传输，但是通过未鉴权的接口，我们除了能越权进行某些操作之外，其实还容易导致大量的敏感信息泄露。因此，对于websocket，测试接口鉴权和是否存在信息泄露。

MQTT

MQTT是一种机器对机器（M2M）的协议，它被广泛地用于IoT 。其在1999年由IBM发明，当时是为了创建一个协议，用于通过卫星连接连接石油管道的最小电池损耗和最小带宽。因为它的耗能非常低，所以被IoT生态系统广泛采用。目前几乎所有的IoT 云平台都支持通过MQTT 与几种不同实现的IoT 智能设备发送接收数据。

对此协议的测试其实还是感谢上一段在某车企的工作经历，因为车机中会使用较多的MQTT协议，而其实MQTT在物联网设备的应用场景十分之广

智能家居
温度湿度传感器
健身器材
血压测量仪
位置服务
医疗设备
…

先了解一下该协议，MQTT基于TCP协议默认端口为1883，主要功能就两个，发布（Publish）和订阅（Subscribe）。

关于MQTT的攻击面，个人觉得较为好用的是MITM、口令问题、权限问题。

1.MIMT

MQTT和HTTP一样都非常容易受到中间人攻击，具体思路参考上文。

2.口令问题

此部分也分为空口令、弱口令和暴力破解。

网上很多开放MQTT的设备均为空口令，使用mqtt连接工具可以直接连上

同样，对于安全方面的忽视，也存在不少弱口令，并且对于暴力破解没有很好的防御方式，因此口令问题是MQTT协议非常需要注意的方面。附暴力破解脚本https://github.com/zombiesam/joffrey

3.权限问题

MQTT 主题(Topic) 支持’+’, ‘#’的通配符，’+’通配一个层级，’#’通配多个层级(必须在末尾)。

也就是说如果我们的有两个个Topic分别为CMD/123/456 CMD/789/666那么我们可以订阅CMD/#来获取其CMD下的全部消息。在攻击中我们首先就可以利用其来监听所有不以$开头的Topic。对于以$开头的Topic我们可以使用$SYS/#来订阅（详见：https://github.com/mqtt/mqtt.github.io/wiki/SYS-Topics）

如下为没有权限控制的MQTT消息服务器，直接查看所有Topics

2、固件

设备固件分析的前提是需要获取到固件，提取固件的方法可以参考看雪大佬的文章https://bbs.pediy.com/thread-230095.htm

对于web出身的安全人员（也就是本人），较为实在的方法就是从官网寻找，或者联系产品售后获取，也可以通过软件升级抓包得到固件下载地址。

如下图，从官网直接搜索下载到指定版本固件。

在提取固件后需要对固件进行分析，但是在此之前需要先判断固件是否被加密，通常使用binwalk先进行分析查看，此时如果出现如下图，那么该固件可能为加密固件

参考如何分析和解密已加密的路由器固件进行解密

未加密的固件通常如下图

可以通过命令

binwalk -e 固件名

来进行提取

提取后可以看到squashfs文件系统，然后在对其源码进行分析即可

3、云端

云对于IoT也是非常重要的一个环境，毕竟只有things能连接到Internet才算是IoT。

在实际测试中，获取云端地址是尤为重要的一个环节，通常来说使用wireshark等抓包工具就能直接看到设备云端地址，在简略的获取云端地址后，首先一定是对该云服务器进行一次常规完整的渗透，这部分主要是信息收集居多；然后根据实际情况进行测试，我遇到过的场景有，在针对一次车机系统的测试中，后端web管理端可以直接通过一条HTTP请求对车机下发命令，如软件升级更新、消息推送等，此时可以进行更改对应车机VIN码或未授权漏洞的尝试等；最后可以尝试对固件进行分析，筛选提取一些隐藏的接口，看是否存在可利用的点。

4、APP&C/S

APP和C/S客户端也是经常容易受到攻击的点，不考虑上文已经提过的攻击面，对于APP我们可以进行脱壳分析，除了常规的APP本身的问题如重打包、组件安全问题之外，最需要关注的点应该是信息泄露部分，如一些敏感的接口地址（测试越权和有无更深一层的信息泄露）以及某些功能服务的账号密钥（如oss服务器的secretkey、telnet或ftp服务的账号密码）等。

对于C/S客户端架构的安全测试，首先肯定是分析所用协议，常规抓包工具就能搞定，然后按照上文的根据协议的攻击面去进行测试，除此之外，客户端还可以测试逆向信息收集、DLL劫持等，这个测试的并不多，奉上大佬们的文章

CS-checklist

某云pc客户端命令执行挖掘过程

实战介绍Windows下的PC客户端常见漏洞挖掘

5、RFID

生活中用到RFID的地方其实还是很多的，最常见的有门禁刷卡、地铁公交刷卡、智能打印机刷卡打印等。

比较常见的利用场景有复制小区的门禁卡，修改学校水卡余额，以及修改电梯卡可刷楼层等。

这一类利用方式也比较简单，淘宝买个NFC设备基本都附送操作教程，复制操作就是一个解密然后重新写入的操作，不多赘述。修改余额和电梯楼层的操作可以参考文章

https://blog.csdn.net/TymonPaul/article/details/80425617

比对hex后推测出规律和需要修改的点，使用winhex等工具进行修改即可

那么除此之外，由于一次偶然的机会，我又有了一些新的思路。比如我司的智能打印机，需要先刷卡进行身份认证，然后才能打印你上传的文档。首先看一下正常第一次使用工卡刷卡，打印机给的反馈如下

然后我又拿我的小区门禁卡刷了一下，想不到也可以，反馈如下

那么测试思路就很明显了，通过比对分析，得到该打印机读取的数据段，然后进行修改，反向推断出其他同事的工号（当然其实可以直接借一个过来刷），然后修改成心仪女神的工号，这样就能看到女神天天在打印啥东西..了？（所以其实并没有太大的用处吗）

当然能做的也不止于此，假设读取的数据会进入数据库，是不是也可能存在SQL注入的问题，毕竟参数可控，假如能知道管理员的序号，是不是能直接刷卡成为打印机管理员，诸如此类。

思路说了这些，你问我为什么没有实践一下的话，因为笔者就买了个PN532再玩，买不起PM3和更高级的读卡器，而PN532能读取的卡类实在太少，所以总结没实践的原因，穷。

另外，蓝牙其实也算是RFID的一类，用到蓝牙的地方生活中其实也有很多，耳机、音箱、共享单车等。蓝牙协议是真的挺难研究学习的，但是也不妨碍提出一点小小的想法，一种是中间人攻击，通过中间人的方式修改或截取信息，参考文章[翻译]蓝牙中间人攻击代理工具，还有一种就是重放攻击，可以尝试用到共享单车的开锁，参考文章蓝牙抓包重放实例