Group of Software Security In Progress

GoSSIP @ LoCCS.Shanghai Jiao Tong University

Your IoTs Are (Not) Mine: On the Remote Binding Between IoT Devices and Users

作者:Jiongyi Chen, Chaoshun Zuo, Wenrui Diao, Shuaike Dong, Qingchuan Zhao, Menghan Sun, Zhiqiang Lin, Yinqian Zhang, and Kehuan Zhang

单位:The Chinese University of Hong Kong, The Ohio State University, Shangdong University, Jinan University

会议:DSN’19

链接:http://web.cse.ohio-state.edu/~lin.3021/file/DSN19.pdf


物联网云架构包含三个部分:物联网设备,用户,云。

在一个用户可以远程访问他的设备之前,他们之间的通信通过云来引导。

在这篇文章中,作者系统的分析了IoT远程绑定过程,评估了十种真实的远程绑定方案,发现了一些在认证授权机制设计过程中产生的问题,包括不正确的device ID 的使用、弱设备认证、弱云端访问控制,以及这些问题的影响,包括用户敏感数据泄漏、拒绝服务、连接中断,甚至设备控制。

1 Introduction

A. IoT 通信架构

IoT通信环境通常包含三个部分:IoT设备、用户、云。

在IoT系统中,用户与设备有两种连接模式:本地连接和远程连接。

  • Local connection:用户与设备在本地网络中通信,家庭路由器作为传输信息的本地。
  • Remote connection:用户的手机和IoT设备不在同一LAN,因此云端需要传输用户和设备之间的消息。

B. 远程绑定过程

作者将其分为如下几个阶段:

  • User authentication

    IoT制造商通常部署password-based的策略来认证用户,包括两个步骤:首先用户在云端登录;然后云端返回一个用户token作为接下来的凭证。

  • Local configuration

    设置IoT设备可以访问LAN (Wi-Fi) 并且向云端进行认证,同时与用户IoT App配对。

    • Network provisioning

    • Device authentication

      一旦设备可以联网,它向云端发送包含设备信息的认证token来进行认证。同时,向云端报告设备的状态、属性,例如firmware版本等。

    • Local binding

      当App和设备连接同一本地网络,在一些方案中,使用服务发现协议(例如SSDP)来广播描述信息,并且在设备和App之间交换信息;一些制造商在设备上添加包含设备信息的标签(device ID),并要求用户输入在App中输入相应的信息,App将广播包含这样的信息的消息来实现与设备进行本地绑定。

  • Binding creation

    当云传输特定设备和特定用户之间的消息,云上需要维护一个设备和用户之间的绑定关系。这样,一个包含设备信息和用户信息的绑定消息将通过App发送到云,或者通过没备。当绑定关系建立,App和设备就可以进行远程通信。

  • Binding revocation

    当用户重置设备或删除App上设备的信息,云上的绑定关系将会被撤销。在这种情况下,为了通知云,设备或 App会发送一个解绑消息。

2 Preliminaries

分解

基本的安全需求:云需要对用户和设备进行认证,维护认证用户与认证设备之间的关系。

这篇文章仅讨论一个用户与一个设备之间的关系。

作者使用设备状态机模型对远程绑定功能进行建模,该模型包含四种状态,接收三种类型的消息。

设备影子的四种状态如下:

  • 初始状态lnitial State —— 设备离线且未绑定。

  • 在线状态Online State —— 设备在线且未绑定。

    设备通过了云的认证,但没有与任何用户绑定。该状态发生在设备绑定之前或解绑之后。

  • 控制状态Control State —— 设备在线且已绑定

    设备已经通过了云的认证并与用户绑定,这是唯一一个允许用户控制设备的阶段。

  • 绑定状态Bound State —— 设备离线且已绑定。

    当设备断电或网络连接中断,或当绑定关系已在云中创建但设备还未在线。

图2显示远程绑定过程状态转移图,云接收来自用户或设备三种类型的消息:

  • Status:status message

    可能是registration消息或是heartbeat消息,在本文的模型中他们用于改变设备影子的在线/离线状态。在云中接收这样一个消息意味着真实设备处于在线状态,如果消息没有在一个确定的时间段内接收,则该设备认为离线。此外,该消息仅从设备发送。

  • Bind:binding message

    在这个消息中,指定哪个用户与设备绑定。当云中收到这样的消息,则在云中建立一个绑定。这个消息可以由用户或者设备发送。

  • Unbind:unbinding message

    这个消息撤销云中一对设备和用户的绑定关系,可以由用户或者设备发送。

注意除了这三种消息还有其他控制消息,在本文不考虑。

3 现有的方案设计

作者选取了排名前10种具有代表性的设备,他们是由来自中国和美国的主流制造商提供的畅销产品。此外,作者还参考了来自物联网解决方案提供商的远程绑定方案,例如AWS、Google、IBM等。

A Device Authentication

两种设备认证方式:设备token和设备ID,存在于status message中。

  • Status: DevToken

    物联网App从云中请求一个设备token,然后在本地配置的过程中,将其传输给设备;然后设备向云端发送token用于认证。

  • Status: DevId

    有些制造商为设备创建唯一设备ID用于认证,ID可以是设备MAC地址或者设备序列号,至少有四种设备使用这种设计。这种设计对用户十分友好:如果用户拥有这样一个ID,即使设备与App不在同一网络,设备认证仍可以完成。但是在这种情况下,存在设备ID被泄漏的风险。

除了以上两种方式,大多数物联网供应商还提供一些基于公钥的认证方案,例如AWS IoT、IBM Waston IoT、Google IoT。在这些方案中,在制造过程中会产生一对密钥对,公钥被存放在云端,私钥被嵌入到设备中。这种方式可以让云端安全的认证来自设备的消息,但是由于需要硬件支持来存放私钥,开销大且影响效率,很少被使用。

作者认为折中的方式是使用动态的认证token。

B Binding Creation

当云端收到绑定消息,它会在设备和相应的用户账户之间创建一个绑定关系。

有两种类型的绑定机制:基于ACL的绑定和基于Capability的绑定。

(1)基于ACL的绑定 —— Binding: (DevId, UserToken)

很多设备在绑定消息中使用device ID和user token来实现绑定,绑定消息可以由App或者物联网设备发送。

  • App发起的绑定

    设备ID从设备得到,用户token从云端获得。向云端发送设备ID和用户token进行绑定。

  • 设备发起的绑定

    在本地设置时,用户凭证(例如用户名和密码)被发送给设备;然后设备发送一个包含用户凭证和设备ID的绑定消息到云端;在接受消息后,云端创建绑定关系。然而,如果设备存在风险,那么传输用户凭证给设备可能会对用户账户产生威胁。

(2)基于Capability的绑定 —— Binding: BindToken

在这个机制中,云端下发认证token到用户App,然后本地传输到设备;然后,设备提交token到云端,来确实和用户的绑定。这种机制保障了用户对设备的所有权:为了远程绑定设备,用户必须先本地与设备绑定。

作者认为基于Capability的绑定最佳,绑定仅能通过与设备本地通信实现,例如三星SmartThings。

C Binding Revocation

有三种解绑消息:

  • Unbind: (DevId, UserToken)

    用户或设备发送包含用户token和设备ID的解绑消息到云端。当收到消息,云端首先会确认用户token;然后根据提交的设备ID解除相应的绑定;此外,云端还需要检查是否已经与设备绑定。

  • Unbind: DevId

    设备发送解绑消息。当一个设备仅属于一个特定的用户时,解绑消息仅包含设备标识符就可以实现解绑功能。

    由于任何用户设备ID的人都能够伪造解绑消息来撤销绑定,所以存在安全风险。

  • Bind: (DevId, UserToken)

    作者发现有一种设备不支持解绑操作,用户只能使用新的绑定来替换云中之前的绑定。无论什么时候收到绑定消息,云端都会替换绑定用户i为新用户n。

4 安全漏洞

A 攻击模型

作者假设攻击者可以获得device ID,理由有二(1)推导device ID;(2)设备物理交互。

此外,假设攻击者不能访问用户本地网络,并且设备固件和IoT App没有受到攻击。

概述

作者列举了考虑三种消息被伪造并发送到云端的后果:

  • 当状态信息被伪造,攻击者可以假装成设备发送假的设备消息,并且用户数据可能被窃取。
  • 当绑定消息被伪造,攻击者可以在用户绑定之前创建一个和用户设备的绑定,这可以引起绑定拒绝服务攻击。或者当用户已经与设备绑定时,攻击者可以替换绑定关系,以使用户与设备连接中断或者控制用户的设备。
  • 当解绑消息被伪造,攻击者可以撤销用户的绑定,导致设备与用户解绑。

作者将这些攻击认为四类:数据窃取和注入,拒绝服务,设备解绑,设备劫持。

B 数据窃取和注入

当设备影子处于控制或者绑定状态时,攻击者可以通过设备ID来伪造状态消息。由此,攻击者可以注入传感器数据到云端和用户,同时也可以伪造设备以从云中检索用户隐私数据。

C 绑定拒绝服务

出现在当攻击者在用户绑定设备之前占据绑定用户设备的时候,伪造的绑定消息包括攻击者的token和用户设备ID。一旦攻击者成功登录绑定,用户就不能与他的设备绑定。然而,由于很多制造商使用顺序的设备ID,攻击者可以比较容易的枚举或者暴力破解出设备ID,甚至可能会导致制造商整个产品系列遭受大规模的拒绝服务攻击。

D 设备解绑

攻击者可以利用解绑消息、绑定消息或者状态消息来使用户与其设备解绑。

  • 对于解绑消息Unbind: DevId,利用设备ID能够撤销云中用户的绑定
  • 对于Unbind: (DevId, UserToken)消息,仅当云端不检查提交用户token是否是绑定用户时,攻击才能成功。
  • 对于Bind: (DevId, UserToken)解绑消息,如果绑定消息泄漏,则会导致用户解绑。在这种情况下,如果云端不检查设备是否已经绑定用户,攻击者可以发送一个绑定消息来替代用户的绑定,以使得用户与设备断连。

此外,状态消息伪造也可以导致设备解绑。在这种情况下,云端将攻击者作为一个新设备,并且与真实设备断连。

E 设备劫持

对于这种攻击,攻击者可以完全控制设备,有三种方法可以实现设备劫持。

  • 攻击者可以将包含攻击者token和用户设备ID的绑定消息发送到云。在这种情况下,考虑设备影子处于两种状态:控制状态和在线状态。

    • 当处于控制状态时,如果云未检查消息发送者和绑定用户,则会发生攻击。产生的原因:

      (1)云直接操纵了现有绑定而没有进行检查;(2)可能是解除绑定的设计缺陷。

    • 当用户处于在线状态时,攻击者可以在用户设置设备的过程中利用时间间隙,从而先于用户绑定设备。

  • 另一方面,也可以通过组合两个漏洞来实现设备劫持。攻击者首先发送解除绑定消息以断开用户与设备的连接,这会将设备变成在线状态。接下来,攻击者可以发送绑定消息以与设备绑定并对其进行控制。

    但是,如果使用设备token用于设备身份验证,则上述设备劫持攻击将失败。

5 实验结果

A 实验过程

攻击环境:Ubuntu主机,8G RAM,Intel Core i7 2.81 GHz

Android手机(Samsung galaxy S5…),在每部手机安装设备对应的App,登录不同的账户(用户/攻击者)

操作步骤:

(1)识别用户设备的device ID。

在研究的10类设备中,有6类可以直接从设备上获取,有5类使用的是MAC地址(前三字节是设备制造商ID);其余的设备ID可以直接从传输过程中观察得到,或者可以通过对消息差异分析来获得。

(2)在目标消息中替换用户设备ID为攻击者设备ID。

作者先使用人工动态分析App的方式,识别出绑定和解绑消息,并使用现有工具来拦截修改请求。

为了能伪造设备消息,作者对firmware进行逆向,只能在三类设备上成功,包括动态分析(1)和静态分析(2)。

B 结果

  • 至少四类设备使用设备ID用于设备认证,有一类设备是由设备发送绑定消息,90%的设备使用App发送Unbind: (DevId, UserToken)来撤销绑定(设备3不支持解绑,而是使用绑定操作替换)。

  • 总体上,可以成功的攻击9台设备。

    • 设备10可以进行数据注入和窃取攻击(A1)。

      作者对其固件进行逆向,找到设备消息;然后通过重构消息,建立和云的连接,伪造相关消息。对于数据注入攻击,作者伪造消息来向用户报告虚假的电量消耗;对于数据窃取攻击,作者在App上设置一个策略来开关智能开关,攻击者能够成功的收到云上发来的策略。

    • 有6类设备可以受到绑定拒绝服务攻击(A2)。

      对于设备7,绑定由用户App发起,要求用户在30s内按下设备上的一个按钮;当按钮按下时,一条设备注册消息会被发送;然后云端比较设备请求的源IP地址与用户请求是否相同,如果不相同则绑定失败。

    • 由4类设备可以受到设备解绑攻击(A3)。

      由于设备3不支持撤销绑定,用户和设备之间的绑定可以被攻击者的新绑定替代。但是,攻击无法劫持设备,因为这种机制使用device token作为设备认证,攻击者不能发送一个有效的token到设备。

      对于设备8,作者伪造设备状态信息,这可能会导致设备与用户解绑,也可以伪造一个解绑消息Unbind: devId,这可以造成用户与设备的解绑。

    • 作者在3类设备上成功实施设备劫持攻击(A4)。

      设备9通过简单的发送一个新的绑定消息来替代用户在云端的绑定关系,就可以实现设备劫持。

      设备6是当处于在线状态并且未绑定时,能够被劫持。

      对于设备8,作者发送一个解绑消息来撤销和用户的绑定,然后伪造一个绑定消息来将其与攻击者绑定。

6 总结

作者发现了IoT远程绑定的一些安全问题:

  • 使用静态设备ID进行设备身份认证。设备通常先由用户配置,建议向用户请求动态的设备token进行认证。

  • 用户和设备的绑定涉及到用户在云端访问设备的授权。正确的机制应当在绑定中实施适当的访问机制。

  • 撤销绑定的正确实现。云端应当检查消息的发送者是否有权力撤销绑定关系(绑定设备的用户)。

  • 用户的敏感信息在远程绑定时不应当被传输到设备。

后续的研究:

  • 文章的研究仅限于三方通信架构,在未来将其推广到涉及四方通信架构。
  • 本文采用手工分析的方式揭示远程绑定的一些攻击面,今后可以探索自动化方法。
  • 探索在不存在物理设备的情况下自动发现远程绑定的威胁。