本文对iSmartAlarm厂商的iSmartAlarm Cube产品相关的五个漏洞做了演示。

原文链接:http://dojo.bullguard.com/blog/burglar-hacker-when-a-physical-security-is-compromised-by-iot-vulnerabilities/

关于文中实验的说明:由于编辑人员时间和资源的限制，暂时没有实际验证。如果后续有条件的话，会实际验证一下。
关于翻译的说明:遣词造句的功夫还欠缺火候，如有错误，烦请指出。

背景介绍

物联网是下一个趋势。数字化和可接入互联网的设备正在组成和构建一种新的网络和生态系统。据Gartner介绍，到2020年，将有208亿个物联网设备连接到世界各地。这些设备几乎可以随时随地用于家庭，汽车和可穿戴设备。随着市场的增长，网络威胁也在增加。每一个接入网络的设备都容易受到一些可能导致设备损坏和窃取隐私信息的攻击。许多研究表明，安全和隐私是消费者采用IoT设备进入日常生活的首要关注点。Dojo发现iSmartAlarm有多重漏洞，容易成为攻击目标。一旦攻击者渗透到家庭/商业网络并找到这样的设备，他们就能够完全控制这些设备。至于控制这些设备有什么危害，则不必多言了。本文打算详细介绍iSmartAlarm的漏洞细节及其影响。

概览

iSmartAlarm有多个能够导致设备被完全控制的漏洞。未授权的攻击者能够通过一些手段彻底破坏设备的功能，还有完整性和可靠性，从而长久地取得对iSmartAlarm设备的控制权限。例如，攻击者可以访问整个iSmartAlarm客户群，其用户的私人数据，用户的家庭地址，报警撤防以及“欢迎来到我的家庭标志”。

相关CVE总结:
|————-|——|———————————-|—————-|
|CVE-2017-7726|Remote|Missing SSL Certificate Validation|iSmartAlarm Cube|
|CVE-2017-7727|Remote|Server Side Request Forgery |iSmartAlarm |
|CVE-2017-7728|Remote|Authentication Bypass |iSmartAlarm Cube|
|CVE-2017-7729|Remote|Incorrect Access Control |iSmartAlarm Cube|
|CVE-2017-7730|Remote|Denial of Service |iSmartAlarm Cube|

前言

作为网络安全研究员，我真的想测试接入互联网报警系统，看看我能从中得到什么。研究过程中，我选择了iSmartAlarm厂商的产品，它占有很大的市场份额，还收到不少好评。iSmartAlarm收到的好评

iSmartAlarm是智能报警系统领域的领先的IoT制造商之一。它提供了一个完整的报警系统,由报警器、监察相机、锁构成。它除了具备常见的报警系统所具有的功能，还有网络设备必要的功能:可以通过app弹出警报和远程操控设备。很合适的研究对象。

SSL Certificate Validation Vulnerability

在搭建好实验环境，设备和程序正常运行之后，我找到了第一个漏洞。iSmartAlarm cube的证书校验漏洞。在设备开始运行的时候，iSmartAlarm cube会首先和运行在iSmartAlarm服务器上、监听端口为8443的程序建立连接。然而，cube在SSL握手阶段并不校验来自服务端的SSL证书的真伪。因此，在伪造的自签证书后，可以看到和控制来往的数据。

SSRF

iSmartAlarm的一个API包含重定向，这导致我尝试利用它。

令人惊讶的是它能正常执行！这是一个好的开始，但这不能满足我，我想控制任何人的报警系统。在检查iSmartAlarm的API时，我能够获取加密密钥。

Denial of service vulnerability

我想看看app和cube的通信过程，并找出是否可以在没有app的情况下远程控制报警系统。iSmartAlarm的app有两种模式。一种模式是cube和app在局域网中。另一种模式是当它们在不同的网络上时。当两者处于局域网中，能够嗅探到cube和app之间的加密流量，cube监听了12345端口。

因为cube和app通过局域网直接进行通信，所以我能够对cube进行Dos攻击，让它无法为正常用户提供服务。

在对cube进行DoS攻击的时候，不论app是运行在远程模式或者本地模式，正常用户将会失去对报警系统的控制权。

Authentication Bypass and Incorrect Access Control

分析协议花费了一些时间，这超出了本文的范围，但最终cube和app之间的协议如下所示:
首先app和cube通过复杂的4次握手进行身份验证:
App:ISAT\x01\x003\x01\x007

Cube:ISAT\x02\x003\x01\x003\x10\x00*3 + “Cube generated Secret Key”

加密算法:app利用Ipu(在SSRF小节处获得的密钥)和接收到的”Cube generated Secret Key”来做运算，从而获得一个新的密钥。iSmartAlarm使用XXTEA加密算法（尽管它们的实现被破解）。之后，反转XXTEA加密算法的输出就可以得到新的密钥:”new key”。所以一旦我们有Ipu，我们可以让alarm来做任何我们想要的事情。加密密钥”new key”的创建如下所示:
reverse(xxtea_encrypt(reversed(“secret_key”), reversed(“IPU_key”)))
该操作的结果作为最终的密钥，对发往cube的命令做签名。
接下来app发送如下数据继续身份验证过程:
App:ISAT\x03\x003\x01\x003\x10\x00*3 + “new key”

Cube:ISAT\x04\x003\x01\x003\x01\x003\x01
这会导致iSmartAlarm Cube的第三和第四个漏洞:Authentication Bypass and Incorrect Access Control
使用新创建的密钥，我们现在可以发送任何我们想要的命令到cube - disarm，arm或者panic。 DISARM ISATP\x003\x01\x003\x03\x003\x01\x002
ARM ISATP\x003\x01\x003\x03\x003\x01\x000 PANIC ISATP\x003\x01\x003\x03\x003\x01\x003

我决定深入研究应用程序，希望我能发现一些东西。幸运的是，我发现这个:

看起来是登陆iSmartAlarm某个内部网站。这是非常令人不安，所以我尝试了…
(原文后面还有一些关于上报厂商的说明，我就没有罗列出来了)