物联网温控器的安全性研究

Riscue的安全专家Kevin Valk研究了他的连接设备——云控制温控器的安全性，并发现了一系列令人担忧的问题。这篇文章展示了如何破坏现代物联网设备，以及如何提高安全性。最后，Kevin向连接设备的开发人员提出建议以改善他们抵御潜在的网络攻击的能力，这些网络攻击可能导致拒绝服务，知识产权被（去掉）窃取和客户（用户）数据泄露。

我的名字是Kevin Valk，是一名Riscure的（移动）安全分析师，（e.g. 支付，HCE，MOPS等）。不久前，我购买了一个名为“Anna from Plugwis”的IoT温控器使我能够更好的调节屋内的温度。当设置Anna的时候，你需要访问web接口来配置设备。我记得在指定的设置页面上，我收到了包含完整的Lua堆栈回溯的状态码为500的页面。你可以想象，当我意识到这个设备可能是我的安全防线中潜在的安全漏洞时，这使我毛骨悚然。

为了让我放心，我进行了一次小小的安全测试来验证我家里的Anna是足够安全的...然而我发现我错的是多么离谱...

探索

对于任何具有基本电子知识的有安全意识的人来说，PCB就像一个宝库；所有都清楚的标记，并有一些调试头部来启动。你可以清晰的看到主微控制器，RAM和Flash。而且，跟踪5-pin引脚标头表明这是一个UART调试接口。当然，这被在产品中被禁用了？！
'''

• U-Boot 1.1.4 (Mar 15 2016, 17:25:41) *

AP121 (AR9331) U-Boot R03 for AME (redacted)

DRAM: 64 MB DDR2 16-bit
FLASH: Winbond W25Q128 (16 MB)
CLOCKS: 400/400/200/33 MHz (CPU/RAM/AHB/SPI)

LED on during eth initialization...

Hit any key to stop autobooting: 0

Booting image at: 0x9F050000

Image name: MIPS OpenWrt Linux-3.7.9
Created: 2018-03-07 12:24:17 UTC
Image type: MIPS Linux Kernel Image (lzma compressed)
Data size: 1000748 Bytes = 977.3 kB
Load address: 0x80060000
Entry point: 0x80060000

Uncompressing kernel image... OK!
Starting kernel...
'''

唉，将UART电缆连接到UART并按下一个键即可停止自动启动(autobooting)进程后,我们获得了对Anna的运行时控制。U-Boot暴露的CLI接口可以以多种方式使用，包括读取flash闪存。这引起了我的兴趣，我想进一步的了解，为此，我需要dump出整个文件系统。

深入了解

可以使用现成的工具直接读取闪存IC（winbond 25Q128FV）从而获得文件系统。然而，我们已经可以访问U-Boot shell，为什么不是用它？

'''
for x in range(0, 2):
base_address = 0x9F000000
size = 1024 1024 16
blocksize = 1024 * 4
print('Starting dumping')
with open('dump{0:d}_{1:08X}.bin'.format(x, base_address), 'wb') as f:
for j in range (0, size // block_size):
com.write('md.b {offset:x} {block_size:x}\n'.format(
offset=base_address + j * block_size,
block_size=block_size).encode('ascii')
)
com.readline()

        for i in range (0, block_size//16):
            r = com.readline()[10:57].decode('ascii').replace(' ', '')
            if len(r) != 32:
                print('Panic, not received all bytes!')
            f.write(binascii.unhexlify(r))

        if 'uboot> ' not in com.readline().decode('utf-8'):
            print('Panic, desynced!!!!')
        print('{0:d} of {1:d} (address {2:08X})'.format(
            j,
            size // block_size, base_address + j * block_size)
        )

'''
一小段Python脚本和两个转储之后，我们成功获得了完整flash IC的正确转储。从最初的U-Boot shell开始，我们已经知道在这个设备上使用了自定义版本的OpenWrt。这意味着我们会有一个只读root文件系统的SquashFS分区和所有用户数据的JFFS2分区。

记得Lua堆栈回溯吗？

根文件系统事实上是一个自定义的OpenWrt，其显著不同的是，这是一个巨大的Lua程序。Lua)是一种脚本语言，通常会在文本编译器中打开文件便可直接看到源代码。然而，出于性能原因，Lua脚本可以编译成字节码，这样可以直接被Lua 虚拟机执行。就像大多数字节码编译语言，同样也存在着名为LuaDec的Lua反编译器，我希望能够轻松获得原始代码...我再一次错的离谱...

当打开文件系统上的一些Lua文件时，我看到了以下数据：

它看起来当然不像文本，但它也不像正常的字节码。进一步的研究表明这是一种Plugwise自定义的加密方案，其所有产品用它来保护知识产权（IP）。
一些逆向一段时间后，我们发现一个简单的Python脚本能够解密被加密的字节码和源代码。加密密钥被放在了Lua解释器中，因此可以通过静态分析轻松获得。
'''
import sys, sys, binascii, struct, lzma, tempfile
from Crypto.Cipher import AES

KEY = binascii.unhexlify('00000000000000000000000000000000') # REDACTED
HEADER_1 = b'\x1clUZ'
HEADER_2 = b'\x1bLuz'

with open(sys.argv[1], 'rb') as f:
header = f.read(4)

if header == HEADER_1 or header == HEADER_2:
    xz = tempfile.TemporaryFile()

    # Check if this is encrypted bytecode or source code
    if header == HEADER_1:
        print('Lua encrypted')
        prefix = b''
    elif header == HEADER_2:
        print('Lua encrypted bytecode')
        prefix = b'\x1bLua' + f.read(12)

    # Setup main cipher
    cipher = AES.new(KEY, AES.MODE_ECB)
    iv = cipher.decrypt(f.read(16))
    counter = 1

    # Read the complete file
    while True:
        block = f.read(16)
        if block is None or len(block) <= 0: break # Support for the custom IV block_iv = iv[:-4] + struct.pack('>I', struct.unpack('>I', iv[-4:])[0] ^ counter)
        block_iv = cipher.encrypt(block_iv)
        xz.write(bytes([block[i] ^ block_iv[i] for i in range(0, len(block))]))

        counter += 1

    # Now unpack the decrypted (but compressed) file
    xz.seek(0)
    with open(sys.argv[1] + 'dec.lua', 'wb') as fo:
        fo.write(prefix)
        fo.write(lzma.open(xz).read())
    xz.close()
else:
    print('File not supported!')

'''
解密所有的文件后，我们最终得到了原始源代码（包括注释和TODO's）和字节码。可以进行进一步的分析通过特别构造的HTTP请求找到其他的可能危害系统的方式。这是非常有趣的攻击向量，因为web界面运行在root用户权限。

其它的东西？

在研究文件系统和web界面期间，一个名为SSH中继的功能不断出现。通常，SSH中继通过设置反向隧道来绕过防火墙。Anna温控器安装在了位置网络中，SSH中继可以用于从外部访问设备。

通过进一步的研究，这正是Plugwis访问现场部署Anna后的做法。实现此功能可能有许多正当理由，但是如果没有安全的完成，它必然将在消费者家庭网络中造成巨大的安全漏洞。为此，我决定研究反向隧道是如何创建的。

开放Anna温控器给世界！

Pulgwise有一个复杂的动态HTTP API来让设备与后端连接。终端中的一个用来获取在后端登录的私钥，并设置反向隧道。如果远程服务器上的SSH用户没有被合理的保护，攻击者可以使用此私钥来获得后端的非特权shell。

尽管使用SSH反向隧道的架构不是最好的，但如果设置正确也没错。为了验证攻击者是否无法轻易破坏服务器，我执行了与Anna相同API的请求来获得一个私钥。使用私钥我可以尝试设置交互式SSH shell，期望尝试是失败的，因为（这样攻击）只需要隧道。

'''
Last login: Sat Jun 16 18:29:42 2018

   __|  __|_  )
   _|  (     /   Amazon Linux AMI
  ___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2014.03-release-notes/
59 package(s) needed for security, out of 336 available
Run "sudo yum update" to apply all updates.
Amazon Linux version 2018.03 is available.
[sshrelay_fc81b@ip-10-36-41-6 ~]$
'''
到我收到这条消息时，你可以理解我的恐惧。我立刻终止了SSH会话，并思考发生了什么。我们不仅获得了低权限的shell，而且系统运行着2014年的镜像。这意味着有许多权限提升漏洞可用于在此系统上来获取root权限。没人知道其他的服务器是如何连接的，以及中继服务器上的用户系统可以怎样通过Plugwise后端网络横向移动。在联系Plugwise之前，我只想确认一个最终问题。如果攻击者知道Plugwise中继服务器的IP，攻击者是否可以执行端口扫描并直接连接到部署到家庭网络中的设备？

最后的接触

在中继服务器上执行了简单的端口扫描，我看到了以下开放的端口列表

'''
Discovered open port 22/tcp on 18.202.0.0
Discovered open port 42371/tcp on 18.202.0.0
Discovered open port 42104/tcp on 18.202.0.0
...
Discovered open port 43690/tcp on 18.202.0.0
Discovered open port 43370/tcp on 18.202.0.0
'''

总计有205个反向SSH隧道直连在一些家庭网络中的Plugwise设备。幸运的是，设备中的SSH服务器只允许root用户使用SSH key登录。然而，事实是，这些设备穿过家庭网络防火墙并监听公开可访问的服务器是远非理想的。

协作披露

在2018-06-16 Riscure开始了它的协作披露程序并发送具有未发现问题的细节的最初邮件。Riscure和Plugwise在此后到写这篇博文前多次交流来解决最紧迫的问题。通过大量的环节措施，我们可以声明他们更新了所有的后端服务器并完全锁定了SSH中继用户。

建议

这个产品很有意思，因为它没有重要的安全对策，除了感觉不成比例的Lua应用程序。然而，定制的安全Lua解释器很容易被攻破因为它的安全性是含糊的。

在分析此设备时，我们发现了常见错误，Riscure希望分享一些常见的提升嵌入式和IoT设备安全性的方法。下面的列表还远未完成，但提供了强化IoT安全的基本指导。

• 硬件：
  • 锁定或禁止产品中的调试接口避免攻击者可以轻松了解内部系统。
  • 加密flash来组织攻击者直接获取明文flash内容。或者，使用集成了内存的Soc或隐藏引脚/走线/焊盘到flash IC使攻击者更难转储内存。
• 软件：
  • 通过将密钥移动到硬件或运行时来保护密钥，避免攻击者仅通过静态分析获得密钥。这将会显著提高攻击者的工作量（设备的运行时控制）。
  • 应用权限分离来增加一个分层的防御。在这种情况下，破坏了Web界面（如果可能的话）只会影响低权限用户。
• 后端：
  • 确保所有的后端服务器时刻保持最新（最好自动更新）。
  • 虽然中继服务器很有用，但从安全角度看，它通常不是最佳解决方案。在极少数使用中继服务器的情况下，请确保只有你可以访问反向/正向隧道。

原文地址：https://www.riscure.com/blog/on-the-security-or-lack-thereof-of-the-connected-iot-thermostat/

翻译：看雪翻译小组 sudozhange
校对：看雪翻译小组 wanring

[培训]《安卓高级研修班(网课)》月薪三万计划，掌握调试、分析还原ollvm、vmp的方法，定制art虚拟机自动化脱壳的方法