Group of Software Security In Progress

GoSSIP @ LoCCS.Shanghai Jiao Tong University

Fear and Logging in the Internet of Things

作者: Qi Wang, Wajih Ul Hassan, Adam Bates, Carl Gunter

出处: NDSS’18

单位: University of Illinois at Urbana-Champaign

原文: http://seclab.illinois.edu/wp-content/uploads/2017/12/wang2018fear.pdf

作者观察到IoT平台存在一种新的威胁，当多个app和多个智能设备绑定在一起时，我们很难定位某个设备被攻击或者配置错误的原因。那首先想到的方法就是查看日志，然而存在的日志只记录了设备在某事某刻发生了什么，但不能解释不同事件之间的因果关系，比如是谁通过何种途径触发了设备状态的改变。因此，本文以Samsung的SmartThings为例，使用数据溯源的技术，来追踪IoT事件发生的一连串因果关系。

背景

### IoT Platforms and Smart Home Platforms 截至2017年，大概有450个IoT平台

这些平台支持 * enable custom IoT applications * create a device abstraction * Device Handler (SmartThings) * Device Shadows (AWS IoT)

Smart Home可分为

  • cloud-centric (更流行)
  • hub-centric

新的安全威胁

  • 多个app与多个device对应
    • 访问敏感数据
    • 越权操作
  • 如何检测非预期事件产生的原因是个困难问题

Samsung SmartThings

  • the SmartThings cloud backend
    • SmartApps
      • 允许开发者创建自定义的automation
    • Device Handlers
      • 硬件抽象，虚拟设备
  • the hub
    • 与device交互并且转发云和device之间的通信
  • the SmartThings mobile app
    • 接收设备状态，远程控制设备

SmartApp

Device Handler

Data Provenance

数据溯源记录了一个数据对象从创建到现在的所有的行为，可以用来解释“数据是在什么环境下产生的”和“这个消息是来自于敏感数据“等问题。数据溯源可以让我们理清智能家居各组件之间的因果关系。

System Model

W3C PROV-DM

  • an Entity is a data object
  • an Activity is a process

  • an Agent is something bears responsibility for activities and entities

  • Dependency
    • which entity WasAttributedTo which agent
    • which activity was WasAssociatedWith which agent
    • which entity WasGeneratedBy which activity
    • which activity used which entity
    • which activity WasInformedBy which other activity
    • which entity WasDerivedFrom which other entity

威胁模型

  • API-level attacker可以访问并修改device的状态

这些能力来自于

  • Malicious Apps
  • Device Vulnerability
  • Proximity

假设

  • device is integrity
  • cloud is trusty

ProvThings

需求

  • Completeness
    • 事件的因果关系、数据的状态
    • 系统应该能够回答“睡眠传感器是如何产生的数据”等问题
  • Applicability
    • 通用
    • 兼容各种物联网平台
  • Minimality
    • 对原有系统的改动尽量小
    • 需要很少或不需要修改平台本身的语义

IoT Provenance Model

W3C PROV-DM模型

举个例子：智能设备产生设备消息(entities)并执行一个命令(activities), 使用DEVICE来区别AGENT的类型

有了这个模型，就可以定义source和sink

  • source是安全敏感的data object，比如门锁的状态
  • sink是安全敏感的method，比如开锁的命令

Provenance Management Framework

模块设计

  • Provenance Collectors 收集 provenance records
  • Provenance Collectors 合并 records 到 IoT provenance model
  • 构建provenance graphs 并且 存储到 database
  • policy monitor 分析 graphs 并采取行动
  • frontends 用来提供交互的 interfaces

Provenance Collectors

  • 根据不同的组件设计不同的provenance collectors
  • 利用程序插桩追踪data flow 和 method invocations
  • 这部分是平台相关的，可以使用不同的语言兼容不同的平台

Provenance Recorder

  • 把provenance records合并、过滤并导入IoT provenance model
  • 构建并存储provenance graphs

Policy Monitor

  • monitor 的输入是根据不同组件创建的 policies
  • 验证某个action是否和policy匹配

ProvThings Frontends

  • 为用户提供一个接口，定义query API
  • 创建配置文件，policies规则

配置文件可以是用户是否允许产生provenance records，以及如何收集和处理并存着这些records

Instrumentation-based Provenance Collection

插桩用来追踪data assignment和method invocation

  • 根据源码生成Abstract Syntax Tree (AST) 和 call graph
  • 根据AST进行control flow analysis 和 data flow analysis
  • 插桩，当插桩代码执行时把record发给ProvThings

为了识别哪些source和sink是安全敏感的

  • 对与每个method，首先检查他是不是sink，如果是就看entry point是否可到达这个sink
  • 如果这个method是entry point，就对这个method插桩
  • 对于每个method的分支，迭代检查是否可达到sink
  • 如果到达sink，则对sink的执行进行插桩
  • 如果sink使用的变量来自source，计算这个这个变量的sink的后向切片

静态的插桩还支持检查运行时的逻辑

  • method execution代表activity, callee和caller的关系是WasInformedBy
  • method invocation和他的参数是Used的关系，返回值的关系是WasGeneratedBy
  • entities之间的数据依赖表示为WasDerived
  • 没有直接参与复制的数据标记为Implicit-Used

IoT Provenance Policy Specification

  • pattern定义了目标行为的模式
  • check定义了检查pattern是否存在
  • action定义了当check满足时应该采取什么action

当Front Door Lock触发setCode命令时提醒用户

  • 在sink被执行之前，插桩的代码向Policy Monitor发出请求， Policy Monitor返回是否允许sink的执行

Comparison to Other Information Flow Solutions

实现

  • 在SmartApps和Device Handlers被提交到SmartThings后端之前，在他们的代码中插桩。

  • 插桩代码收集数据记录，并把他们发给ProvThings的服务器，用来审计日志。

SmartApp Provenance Collector

  • 静态源码插桩
  • 运行时收集provenance

Static Source Code Instrumentation

  • 使用Groovy AST transformation生成SmartApp的抽象语法树

  • 通过SmartThings的开发者手册人工识别SmartApps的入口，source和sink

    • entry points
      • lifecycle methods
      • event handler methods
      • web service endpoints
    • sources
      • device states
      • device events
      • inputs
    • sinks
      • device control commands
      • SmartThings provided API

特别的

  • dynamic method invocation
  • global variables

Runtime Provenance Collection

  • entryMethod
    • 溯源entry point的调用
  • trackVarAssign
    • 变量赋值
  • trackSink
    • sink调用
  • special type
    • 动态方法调用
    • 状态

Device Handler Provenance Collector

  • entry points
    • lifecycle methods
    • device command methods
    • the parse method
    • web service endpoints

评估

  • ProvFull (PF), 对所有的指令进行插桩
  • ProvSave (PS), 用Selective Code Instrumentation算法有选择的插桩

Effectiveness

从调查中总结出26种可能的攻击。

  • 12个基于漏洞报告
  • 14个基于病毒分析

Instrumentation overhead

  • 236 SmartApps, 平均280行代码
  • 132 Device Handlers, 平均200行代码

Runtime Performance

  • ProvSave 20.6% overhead
  • ProvFull 40.4% overhead

Storage Overhead

168,000 events

  • ProvFull 产生 219 MB
  • ProvSave 产生 89 MB

Query performance

For graphs with 2 million nodes

  • ProvSave, 请求所有节点的平均时间是2 ms，请求所有sink activity的节点的平均时间是9 ms

  • ProvFull, 请求所有节点的平均时间是5 ms，请求所有sink activity的节点的平均时间是14 ms

使用场景

### Professionals #### Platform developers Alice

  • smart home customer

WhenEveryoneIsAway

  • 当家里没人时，设置mode为Away

LockItWhenLeave（malicious）

  • 订阅该mode的状态，当mode为Away时锁门并打开摄像头

当Alice回家时发现门是开着，要求Admin调查原因。。

当一个sink被动态方式调用，并且sink的值来自HTTP，会向Admin报告这个隐患。

Help Desk Staff

当一个顾客使用SmartThings打开厨房的灯，但是灯有时会突然关掉。她想知道是硬件问题还是软件的问题。

她会去检查日志，如果有off的记录，那么就是SmartApp的问题。否则就是硬件问题。

Techies

Bob

  • smart home user

LockManager

  • 允许用户更新或删除pin code

FaceDoor（malicious）

  • 允许用户通过面部识别解锁

假如SmartThings存在越权漏洞， FaceDoor可以订阅所有的事件，那么它就可以偷取敏感信息，比如LockManager的pin code

Typical Consumers

SmokeMonitor

  • 正常的程序
  • 监控smoke detector的状态
    • 打开fire sprinkler
    • 打开窗户
    • 触发报警器

SmartLight

  • 插入恶意payload
  • raise a fake physical device event for smoke detector
    • physical damage
    • 窃贼从窗户进来。。

生成provenace图，这里对与smoke handler来说，并不能区别event来源于smartLight还是smoke detector

这张图user可能看不懂，所以简化一下。。

WhyThis

  • 让用户决定是否允许未知行为的发生
  • open is a sink function
  • 查看行为的解释

如果用户选择了deny，之后会默认使用这条规则拒绝所有类似event

Privacy Considerations

  • 为了保护消费者的隐私，消费者可以选择provenance收集的粒度以及这些数据可以分享给谁。
  • 平台通过访问控制管理访问provenance的权限。

End