Your IoTs Are (Not) Mine On the Remote BindingBetween IoT Devices and Users.md

https://securitygossip.com/blog/2019/10/16/your-iots-are-not-mine-on-the-remote-binding-between-iot-devices-and-users/
物联网云架构包含三个部分：物联网设备，用户，云。
在一个用户可以远程访问他的设备之前，他们之间的通信通过云来引导。
在这篇文章中，作者系统的分析了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进行认证。
用户和设备的绑定涉及到用户在云端访问设备的授权。正确的机制应当在绑定中实施适当的访问机制。
撤销绑定的正确实现。云端应当检查消息的发送者是否有权力撤销绑定关系（绑定设备的用户）。
用户的敏感信息在远程绑定时不应当被传输到设备。
后续的研究：
文章的研究仅限于三方通信架构，在未来将其推广到涉及四方通信架构。
本文采用手工分析的方式揭示远程绑定的一些攻击面，今后可以探索自动化方法。
探索在不存在物理设备的情况下自动发现远程绑定的威胁。