IoT 设备通信安全讨论

时间：2017-12-17 17:00:29 阅读：201 评论：0 收藏：0 [点我收藏+]

标签：这一处理器用户名 open images tla 通信 body 单元

IoT 设备通信安全讨论

作者：360CERT

0x00 序言

IoT 设备日益增多的今天，以及智能家居这一话题愈发火热，智能家居市场正在飞速的壮大和发展，无数 IoT 设备正在从影片中不断的走向用户的身边。但是这其中却拥有着大量的安全问题和隐患。

此次以结合实际案例的方式来谈一谈目前国内 IoT 市场中普遍存在的安全问题。

0x01 历史回顾

在过去的一段时间内也曾暴露出了很多很多的 IoT 设备的安全问题。

可以看到自15年开始就频繁受到广大的黑/白帽子的关注了：

技术分享图片

Mirai

而在去年2016年9月-10月期间Mirai在全球范围内爆发。

技术分享图片

Mirai 的感染模式

感染初始设备
初始设备在网段内进行扫描，并做尝试，将有漏洞的设备 IP，PORT 等信息上传至 Loader 服务器
Loader 服务器对新的设备进行控制并下发控制程序
循环往复
受控设备足够多后，控制设备对 Victim 发起 DDoS

技术分享图片

直到2016年10月26日，我们通过 Mirai 特征搜索 shodan 发现，当前全球感染 Mirai 的设备已经超过100万台，其中美国感染设备有418,592台，中国大陆有145,778台，澳大利亚94,912台，日本和中国香港分别为47,198和44,386台。

IoT reaper

而最近则是 IoT reaper，从2017-09-13开始，360NetLab捕获到了一个新型的针对 IoT 设备的恶意样本

样本中集成了9个 IoT 漏洞 IoT_reaper 完全放弃了 mirai 中利用弱口令猜测的方式，转为利用 IoT 设备的漏洞植入，当前样本中集成了了9个 IoT 设备漏洞。最近十天以来，攻击者正在积极的将漏洞利用集成进入样本中，其中一个漏洞在公开后仅2天就被集成。

IoT_reaper 感染流程图

技术分享图片

IoTroop 是 IoT_reaper Botnet 在网络攻击活动中第一阶段使用的主要 payloads，该恶意软件借用了 mirai 的源代码，但是在几个关键行为上显著区别于 mirai，包括：

C&C 服务器已经完全被重新设计，并使用了新的后台。另外，IoTroop 的 C&C 服务器是用PHP编写的，而原来的 Mirai C&C 服务器是用 GO 编写的。
随着 C&C 后台的变化，C&C 通信协议也发生了变化，IoTroop 恶意软件使用了全新的 C&C 通信方式。
IoTroop 恶意软件不再使用弱口令猜测、而是使用 IoT 设备漏洞，扫描效率大大提高。
IoTroop 恶意软件不包含任何 DDoS 功能，实际上我们也没有观察到与该恶意软件有关的任何 DDoS 攻击，但所有与 DDoS 相关的功能都由 C&C 后台进行协调和管理，并作为单独的模块下载。

IoT_reaper 包含的一些漏洞

技术分享图片

可以看到的是，IoT 设备的安全问题正在日益突出，并日益严重。

虽然厂商心中已经有了一定的警戒，并采取了一定的措施但是还远远不够。

0x02 现状

攻击中最复杂的部分是取得与相关设备的连接问题，只要能够连接上能够与之通信,可以说被控制被劫持都只是一些相对较小的问题了。

在连接上的安全措施往往是难以做到尽善尽美的，那么我们就着重来看看目前国内市场上IoT设备在连接上存在的诸多问题。

在 iot 设备领域存在一个是否致命的问题，就是产品更迭周期，在此领域因为涵盖着硬件设备，在升级上往往难以针对某些领域的问题进行修复。

目前在国内的形式大多数是采用的多方合作，而杂合而成的一个十分混乱的 iot 生态。

A厂商从B厂商处采购主控芯片和开发套件，然后自己由这个主控芯片和开发套件对一些传感器进行集成连接，进行一些简单的包装。
A厂商和C厂商进行深度合作在A厂商的APP中集成C厂商的控制程序，从而实现A厂商具有更为广大的智能家居生态。
A厂商完成了硬件上的设计生产，而APP方面则采取外包方式获取。
为了照顾设备的网络情况以及性能情况作出的妥协。

在国内上述三种情况是十分普遍的，这种树状甚至是叉装的生态环境势必会产生无数的安全问题。

反过来回顾世界前列的互联网公司里 Apple，是唯一的一家最接近垂直生态公司，即使是这样，每年也有大量的漏洞被发现，就更何况国内的这些公司了。

0x03 分析

与上面的点一一对应

1.由于采用采购和使用开发套件的方式,势必会有大部分的逻辑是和供应商所提供的运行模式和设计理念是一致的,从这里入手就很容易看到对应的A厂商的设备的大致工作模式

实例：

技术分享图片

根据上面的文档可以看出这里设计出了一种工作模式，在智能硬件中会有一份主体固件 user1.bin，然后在后期可以通过 user2.bin 的方式对设备进行一定程度的更新。

为什么要说一定程度呢？首先，这里采用这种模式就肯定是为了减少更新完整固件包所带来的更新时间和下载内容大小，也从而被获得后直接逆向出完整设备工作流程的危害。

iot设备大多采用低成本的处理控制单元和极小的板载存储flash芯片,已经极小的内存容量,如果采取互联网全量更新,首先是机器本身无法存储,处理器,和内存也无法胜任此工作
iot设备为了长期稳定的工作,肯定无法去更新核心部分的工作,只会以修复一些细小的功能性问题而更新

那这里从实际的案例出发对这个现象的论证就是

在2015年的A厂商在通信过程中使用的AES加密,但在APK中由于开发没有良好的安全意识,导致被轻易的提取出了AES的密钥,而在我们进行分析的今天,该厂商的密钥也没有更换,亦可以在网上搜索得到这串长期没有更换的密钥进行通信消息的解密

而在今天厂商也仅仅只是将其放在了一个动态链接库中稍加混淆

技术分享图片

就这样一个问题,在一个厂商长发2年都没有一个良好的解决方案足以说明问题的严重性

2.在厂商与厂商的合作之间势必会相互开放sdk或者api接口以及通信密钥,一系列相关资源,这就导致了,但凡有一家合作厂商的安全做的不够出色这就会导致短板效应的出现而导致拉低了众多厂商的安全等级

A厂商和C厂商的合作使得A厂商几乎只承担的了集成SDK的成本就获得了一项智能家居产品，而C厂商也仅仅是提供了SDK就拓宽了自己的销售渠道，这样的合作模式肯定受到双方欢迎的，但是这之间的安全问题是值得关注的。

通信的密钥
身份TOKEN
完整的设备信息
完整的控制请求

根据上述的问题,再结合一定的分析往往就能很容易的得出一份令人满意的漏洞

实例:

技术分享图片

可以很清晰的看到,拥有SDK的TOKEN,完整的控制函数

技术分享图片

可以看到通信的地址,以及通讯认证的详细过程

技术分享图片

可以看到另一家合作厂商的密钥位置

技术分享图片

3. APP的编写,这明显不是传统的硬件厂商所擅长的,而外包基本成了主要解决办法

然而厂商也自身没有太高的安全意识在验收成果的时候,主要着力于功能的完善情况,以及界面交互是否有效上面这就会导致许多隐患

通信模型设计不当
验证认证流程存在绕过,或极不完善
查询接口权限认证粗糙
涉及服务器敏感信息泄露

这诸多问题都是一个个良好的突破口和值得关注的点

实例:

技术分享图片

从这里可以看到从 apk 中加载了通信使用的证书，故可以从 apk 中提取出来，也涉及了服务器的通信地址和端口

技术分享图片

可以看到另一处TCP直接通信的地址和端口

技术分享图片

这里可以看到，单凭一个手机号就获取了大量设备关键信息,包括密码等

技术分享图片

这里可以看到，以任意设备mac来获取对应的用户手机号的操作

技术分享图片

再根据已掌握的信息，进行设备控制指令的生成也是十分简单

4. 在结合国内的平均网络质量在全球排名处于中下游水平的情况下,并且要照顾多地区的复杂网络环境

在与智能硬件的通信过程中势必会有很多的妥协,因为产品的第一点是务必满足有良好的用户体验

进而就会产生

与服务器通信认证手段单一
身份识别过程简单
消息内容格式化程度高
分两套通信手段,一套局域网,一套互联网
服务器通信内容不认证用户身份

实例:

A厂商在为了解决远程控制这一问题上

互联网层面远程控制由XMPP协议进行通信

但国内的厂商在使用上仅仅着手于XMPP协议的及时性和开放性,对于一些必要的安全措施并没有进行良好的设计

A厂商的XMPP的设计模式下,受控端设备,以及控制端设备全凭MAC地址或是UUID作为登录凭据,并且在密码设计上采用与用户名一样的方式.这就导致可以使用遍历MAC地址的方式将该厂商所有设备踢下线,使其无法正常通信或是响应命令.或是在APP端注册一个账号,然后获得UUID便可以向任意在网设备发送控制指令,这对于智能产品来说危害是巨大的,也会导致用户无法获得正常的体验

A厂商该特意设计了一个控制服务器,来接受和记录设备的绑定以及设备状态查询的服务,该服务器没有任何权限设置,亦无token之类的校验,可以抓包后任意重放,来获得任意设备mac所绑定的用户手机号,同时,还有一个逻辑错误,以及一个重大的安全错误