Security Analysis of Emerging Smart Home Applications Earlence - PowerPoint PPT Presentation

Security Analysis of Emerging Smart Home Applications Earlence Fernandes, Jaeyeon Jung, Atul Prakash IEEE Security and Privacy 24 May 2016

Smart Door Locks CO Sensors Connected Ovens Smart Plugs IP Cameras Emerging Smart Home Frameworks Smart TVs 2

Potential Security Risks Current Vulnerabilities Devices Protocols Remotely determine prime time for Flooding [1] OR Burglary [1,2] These attacks are device-specific, and require proximity to the home [1] Denning et al., Computer Security and the Modern Home, CACM’13 3 [2] FTC Internet of Things Report’15

In what ways are these emerging, programmable smart homes vulnerable to attacks, and what do those attacks entail? 4

Analysis of SmartThings Access Control • Why SmartThings? • Relatively Mature (2012) • 521 SmartApps • 132 device types Trigger-Action • Shares design principles with other existing, nascent frameworks Programming • Methodology • Examine security from 5 perspectives by constructing test apps to exercise SmartThings API • Empirical analysis of 499 apps to determine security issue prevalence • Proof of concept attacks that compose security flaws 5

Analysis of SmartThings – Results Overview Security Analysis Area Finding Overprivilege in Apps Two Types of Automatic Overprivilege Event System Security Event Snooping and Spoofing Third-party Integration Safety Incorrect OAuth Can Lead to Attacks External Input Sanitization Groovy Command Injection Attacks API Access Control No Access Control around SMS/Internet API > 40% of apps exhibit overprivilege of Empirical Analysis of 499 Apps atleast one type Pincode Injection and Snooping, Disabling Proof of Concept Attacks Vacation Mode, Fake Fire Alarms 6

SmartThings Primer SmartThings Cloud Platform Capability Groovy-Based Groovy-Based HTTPS System GET/PUT Sandbox Sandbox SmartDevice SmartApp [Cmd/Attr] Internet API [Events] SMS API WiFi Configure SmartThings Companion App Control ZWave 7

Capability System Send commands ZWave Lock SmartDevice Untrusted Read/set attributes SmartApp Receive events capability.lock capability.lockCodes capability.battery Capability Commands Attributes … capability.lock lock(), unlock() lock (lock status) capability.battery N/A battery (battery status) Security Ease of Development Usability Very Granular Capabilities Expressive Functionality Simpler Coarser Capabilities 8

SmartApps request Capabilities de defini nition (name: “DemoApp”, namespace: “com.testing”, category: “Utility”) //query the user for capabilities preference ces { sect ction (“Battery-Powered Devices”) { in input “dev”, “capability.battery”, title: “Select battery powered devices you wish to authorize”, multiple: true } } … Device Enumeration 9

Overprivilege in SmartApps SmartThings Cloud Platform Capability Groovy-Based Groovy-Based HTTPS System GET/PUT Sandbox Sandbox SmartDevice SmartApp [Cmd/Attr] Internet API [Events] SMS API WiFi Configure SmartThings Companion App Control ZWave 10

Overprivilege in SmartApps Coarse-Grained Capabilities Coarse SmartApp-SmartDevice Binding SmartApp input “dev”, “capability.battery” • “Auto-lock” app from app store • Only needs “lock” command, but SmartDevice1 SmartDevice2 [ZWave Lock] [Smoke Sensor] can also issue “unlock” capability.battery capability.battery capability.lock capability.smoke capability.refresh capability.refresh Overprivilege Increases Attack Surface of the Home Physical Lock Physical Smoke Sensor 11

Insufficient Event Data Protection SmartThings Cloud Platform Capability Groovy-Based Groovy-Based HTTPS System GET/PUT Sandbox Sandbox SmartDevice SmartApp [Cmd/Attr] Internet API [Events] SMS API WiFi Configure SmartThings Companion App Control ZWave 12

Insufficient Event Data Protection subscribe dev, “door.unlock”, handler ZWave Door Lock SmartApp 71c9344e-6bea-4ae8-993a-28a7817a7d9e handler(EventData: {unlocked, time: 9AM}) • Once a SmartApp gains any capability for a device, it can subscribe to any event that device generates • If a SmartApp acquires the 128-bit ID, then it can monitor all events of that device without gaining any of the capabilities the device supports • Using the 128-bit ID, a SmartApp can spoof physical device events 13

Insufficient Event Data Protection subscribe dev, “door.unlock”, handler ZWave Door Lock SmartApp 71c9344e-6bea-4ae8-993a-28a7817a7d9e handler(EventData: {unlocked, time: 9AM}) • Can lead to leakage of confidential information • Spoofed Events can lead to Apps/Devices taking incorrect actions 14

Other Potential Security Issues - OAuth SmartThings Cloud Platform Capability Groovy-Based Groovy-Based HTTPS System Sandbox Sandbox GET/PUT SmartDevice SmartApp [Cmd/Attr] Internet API [Events] SMS API • Insecurity of Third-Party Integration: SmartApps expose HTTP endpoints protected by OAuth; Incorrect implementation can lead to remote attacks [1] [1] Chen et al., OAuth Demystified for Mobile Application Developers, CCS’14 15

Other Potential Security Issues - OAuth SmartThings Cloud Platform Capability Groovy-Based Groovy-Based HTTPS System Sandbox Sandbox GET/PUT SmartDevice SmartApp [Cmd/Attr] Internet API [Events] SMS API • Unsafe use of Groovy Dynamic de def foo() { … } Method Invocation: Apps can be de def str = “foo” tricked into performing unintended “$str”() actions 16

Other Potential Security Issues – Unrestricted External Communication APIs SmartThings Cloud Platform Capability Groovy-Based Groovy-Based HTTPS System Sandbox Sandbox GET/PUT SmartDevice SmartApp [Cmd/Attr] Internet API [Events] SMS API • Unrestricted Communication Abilities: SMS and Internet; Can be used to leak data arbitrarily 17

Computing Overprivilege Coarse-Grained Capabilities Coarse SmartApp-SmartDevice Binding Requested Granted Cmds/Attrs Capabilities Used Used Cmds/Attrs Capabilities 18

Measuring Overprivilege in SmartApps Challenge Solution • Incomplete capability details • Discovered an unpublished REST (commands/attributes) endpoint, which, if given a device ID, returns capability details • Study source code of apps from • SmartThings is closed source; open-source app store instead can’t do instrumentation • Static analysis on AST • Groovy is extremely dynamic; Bytecode uses reflection (Groovy Meta Object Protocol) 19

Empirical Analysis Results Documented Completed Commands 65 93 Attributes 60 85 Reason for Overprivilege Number of Apps Coarse-grained Capability 276 (55%) Coarse SmartApp-SmartDevice 213 (43%) Binding Overprivilege Usage 68 (14%) Prevalence (Coarse Binding) 20

Exploiting Design Flaws in SmartThings Command OAuth Unrestricted Event Overprivilege Injection Compromise SMS API Spoofing Disabling Pincode Pincode Fake CO Vacation Injection Snooping Alarm Mode Popular Existing SmartApp Stealthy malware SmartApp; Malware SmartApps with no capabilities; with Android companion ONLY requests Misuses logic of existing SmartApps with fake app; Unintended action of capability.battery events setCode() on lock 21

Potential Defense Strategies • Achieving least-privilege in SmartApps • Risk asymmetry in device operations, e.g., oven.on and oven.off • Include notions of risk from multiple stakeholders, rank [1], and regroup • Preventing information leakage from events • Provide a notion of strong identity for apps + access control on events • Make apps request access to certain types of events, e.g., lock pincode ACKs [1] Felt et al., I’ve got 99 problems, but vibration ain’t one: A survey of smartphone users’ concerns, SPSM’12 22

Summary • First look at the security design of a programmable smart home platform : Samsung SmartThings; Challenge: Blackbox Cloud System • Two security design issues : • Overprivilege: Coarse grained capabilities, and Coarse SmartApp-SmartDevice Binding • Insecure Events: Apps do not need special privileges to access sensitive info • Empirical Analysis : 55% of apps do not use all operations their capabilities imply; 43% get capabilities they did not explicitly request • Four PoC attacks that combine various security design issues • These attacks are device independent, and long-range • Security Improvements: Notified SmartThings in Dec 2015; Improvements in vetting process and developer best practices for Groovy Strings (Apr 2016); Discussion on improvements to capability system (May 2016) 23