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

Security Analysis of Emerging Smart Home Applica6ons

Earlence Fernandes, Jaeyeon Jung, Atul Prakash

Presented by: Gohar Irfan Chaudhry

IEEE Security and Privacy 24 May 2016

nsors Connected Ovens art TVs Plugs IP Cameras Smart Door Locks

Emerging Smart Home Frameworks

2

Poten6al Security Risks

3

Flooding [1] Remotely determine e Ome for Burglary [1,2] OR Denning et al., Computer Security and the Modern Home, CACM’13 FTC Internet of Things Report’15

Current Vulnerabili6es

Devices Protocols

These aUacks are device-specific and require proximity to the hom

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

4

Analysis of SmartThings

• Why SmartThings?
• RelaOvely Mature (2012)
• 521 SmartApps
• 132 device types
• Shares design principles with other exisOng, nascent frameworks

Access Control

5

Trigger-AcOon Programmin

• Methodology
• Examine security from 5 perspecOves by construcOng test apps to exercise

SmartThings API

• Empirical analysis of 499 apps to determine security issue prevalence
• Proof of concept aUacks that compose security flaws

Analysis of SmartThings – Results Overview

Security Analysis Area Finding Overprivilege in Apps Two Types of AutomaOc Overprivilege Event System Security Event Snooping and Spoofing Third-party IntegraOon Safety Incorrect OAuth Can Lead to AUacks External Input SaniOzaOon Groovy Command InjecOon AUacks API Access Control No Access Control around SMS/Internet API Empirical Analysis of 499 Apps > 40% of apps exhibit overprivilege of atleast one type Proof of Concept AIacks

6

Pincode InjecLon and Snooping, Disablin VacaLon Mode, Fake Fire Alarms

SmartThings Primer

WiFi ZWave

SmartThings Companion App

Configure Control

SmartThings Cloud Plagorm SmartApp SmartDevice Groovy-Based Sandbox Groovy-Based Sandbox Capability System [Cmd/AUr] [Events]

HTTPS GET/PUT

Internet API SMS API

7

Capability System

Untrusted SmartApp ZWave Lock SmartDevice

capability.lock capability.lockCodes capability.baFery … Send commands Read/set aUributes Receive events ility Commands AIributes lity.lock lock(), unlock() lock (lock status) lity.baUery N/A baUery (baUery status)

Usability Simpler Coarser CapabiliOes Security Very Granular CapabiliOes Ease of Development Expressive FuncOonality

8

SmartApps request Capabili6es

Device EnumeraOon

ni6on(name: “DemoApp”, espace: “com.tes6ng”, category: “U6lity”) uery the user for capabili6es ferences { sec6on(“BaFery-Powered Devices”) { input “dev”, “capability.baFery”, 6tle: “Select baFery powered devices you wish to authorize”, mul6ple: true }

9

ZWave WiFi

SmartThings Companion App

Configure Control

SmartThings Cloud Plagorm SmartApp SmartDevice Groovy-Based Sandbox Groovy-Based Sandbox Capability System [Cmd/AUr] [Events]

HTTPS GET/PUT

Internet API SMS API

Overprivilege in SmartApps

10

Overprivilege in SmartApps

Coarse SmartApp-SmartDevice Binding

SmartApp input “dev”, “capability.baFery” SmartDevice1 [ZWave Lock] capability.battery capability.lock capability.refresh SmartDevice2 [Smoke Sensor] capability.battery capability.smoke capability.refresh Physical Lock Physical Smoke Sensor

Coarse-Grained CapabiliOes

• “Auto-lock” app from app store
• Only needs “lock” command, but

can also issue “unlock”

Overprivilege Increases AUack Surface of the Home

11

ZWave WiFi

SmartThings Companion App

Configure Control

SmartThings Cloud Plagorm SmartApp SmartDevice Capability System [Cmd/AUr] [Events]

HTTPS GET/PUT

Internet API SMS API

Insufficient Event Data Protec6on

Groovy-Based Sandbox Groovy-Based Sandbox

12

Insufficient Event Data Protec6on

SmartApp ZWave Door Lock 71c9344e-6bea-4ae8-993a-28a7817a7d9e subscribe dev, “door.unlock”, handler

13

handler(EventData: {unlocked, Ome: 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 capabiliOes the device supports

• Using the 128-bit ID, a SmartApp can spoof physical device events
• (aper being registered it can read device.id value)

Insufficient Event Data Protec6on

SmartApp ZWave Door Lock 71c9344e-6bea-4ae8-993a-28a7817a7d9e subscribe dev, “door.unlock”, handler

14

handler(EventData: {unlocked, Ome: 9AM})

• Can lead to leakage of confidenOal informaOon
• Spoofed Events can lead to Apps/Devices taking incorrect acOons
• Apps can use the locaOon object (vacaOon mode aUack)

15

SmartThings Cloud Plagorm SmartApp SmartDevice Capability System [Cmd/AUr] [Events]

HTTPS GET/PUT

Internet API SMS API

Other Poten6al Security Issues - OAuth

[1] Chen et al., OAuth DemysOfied for Mobile ApplicaOon Developers, CCS’14

• Insecurity of Third-Party IntegraOon: SmartApps expose

HTTP endpoints protected by OAuth; Incorrect implementaOon can lead to remote aUacks [1]

Groovy-Based Sandbox Groovy-Based Sandbox

SmartThings Cloud Plagorm SmartApp SmartDevice Capability System [Cmd/AUr] [Events]

HTTPS GET/PUT

Internet API SMS API

Other Poten6al Security Issues - OAuth

Unsafe use of Groovy Dynamic Method InvocaOon: Apps can be tricked into performing unintended acOons

16

def foo() { … } def str = “foo”

“$str”() Groovy-Based Sandbox Groovy-Based Sandbox

SmartThings Cloud Plagorm SmartApp SmartDevice Capability System [Cmd/AUr] [Events]

HTTPS GET/PUT

Internet API SMS API

Other Poten6al Security Issues – Unrestricted

17

External Communica6on APIs

• Unrestricted CommunicaOon AbiliOes: SMS and Internet;

Can be used to leak data arbitrarily

Groovy-Based Sandbox Groovy-Based Sandbox

Compu6ng Overprivilege

Coarse-Grained CapabiliOes

Requested Cmds/Attrs

Coarse SmartApp-SmartDevice Binding

Granted CapabiliOes

18

Used Cmds/ AUrs Used CapabiliOes

Measuring Overprivilege in SmartApps

19

• SmartThings is closed source;

can’t do instrumentaOon

• Groovy is extremely dynamic;

Bytecode uses reflecOon (Groovy Meta Object Protocol)

Challenge

• Incomplete capability details

(commands/aUributes)

SoluOon

• Discovered an unpublished REST

endpoint, which, if given a device returns capability details

• Study source code of apps from
• pen-source app store instead
• StaOc analysis

Empirical Analysis Results

20

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

21

Empirical Analysis of SmartThings

Total number of SmartDevices 132 Number of SmartDevices raising events using createEvent and sendEvent. Such events can be snooped on by SmartApps 111 Total number of SmartApps 499 Number of apps using potenOally unsafe Groovy dynamic method invocaOon 26 Number of OAuth-enabled apps, whose security depends on correct implementaOon of OAuth 27 Number of apps using unrestricted SMS APIs 131 Number of apps using unrestricted Internet APIs 36

22

Exploi6ng Design Flaws in SmartThings

AIack DescripLon AIack Vectors Physical World Impact Backdoor Pincode InjecOon AUack Command injecOon into exisOng WebService SmartApp; Overprivilege; OAuth impl. flaws Enabling physical entry; Thep Door Lock Pincode Snooping AUack Stealthy baUery-level monitoring app; Overprivilege; leak data using SMS Enabling physical entry; Thep Disabling VacaOon Mode AUack AUack app with no capabiliOes; Misusing logic of benign app; Event Spoofing Thep; Vandalism Fake Alarm AUack AUack app with no capabiliOes; Event spoofing; Misusing logic of benign app MisinformaOon; Annoyance

Exploi6ng Design Flaws in SmartThings

Overprivilege Command InjecOon OAuth Compromise Event Spoofing Unrestricted SMS API Pincode InjecOon Pincode Snooping Disabling VacaOon Mode Fake CO Alarm

lar ExisOng SmartApp Android companion Unintended acOon of tCode() on lock Stealthy malware SmartApp; ONLY requests capability.baUery Malware SmartApps with no capabiliOes; Misuses logic of exisOng SmartApps with fake events

21

24

Poten6al Defense Strategies

• Achieving least-privilege in SmartApps
• Risk asymmetry in device operaOons, e.g., oven.on and oven.off
• Include noOons of risk from mulOple stakeholders, rank [1], and regroup
• PrevenLng informaLon leakage from events
• Provide a noOon of strong idenOty 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 vibraOon ain’t one: A survey of smartphone users’ concerns, SPSM’12

Backdoor Pincode Injec6on AFack

28

WebService SmartApp

HTTP PUT HTTP GET client_id client_secret

mappings { path(“/devices/:id”) { ac6on: [ PUT: “updateDevice” ] } def updateDevice() { def cmd = request.JSON.command def args = request.JSON.arguments // code truncated device.”$cmd”(*args) } { command: setCode, arguments: [3, ‘5500’] }

Example of Stealing an OAuth Bearer Token

• Decompile APK bytecode to get the client_secret + client_id
• Send email to user asking to “reauthenOcate” to SmartThings

hUps://graph.api.smarUhings.com/oauth/authorize?response type=code&client_id=REDACTED&scope=app& irect_uri=hUp%3A%2F%2FssmarUhings.appspot.com

Open Redirector

29

39

Door Lock Pincode Snooping AFack

Lock Code Manager App ZWave Lock Device Handler SmartThings Hub BaUery Monitor App setCode(‘5500’)

28

codeReport event zwave.userCodeV1.userCodeSet zwave.userCodeV1.userCodeGet subscribe(‘codeReport’) [Possible due to overprivilege] ZWave commands and reports

29

Summary

• First look at the security design of a programmable smart home pla[orm:

Samsung SmartThings; Challenge: Blackbox Cloud System

• Two security design issues:
• Overprivilege: Coarse grained capabiliOes, and Coarse SmartApp-SmartDevice

Binding

• Insecure Events: Apps do not need special privileges to access sensiOve info
• Empirical Analysis: 55% of apps do not use all operaOons their capabiliOes

imply; 43% get capabiliOes they did not explicitly request

• Four PoC aIacks that combine various security design issues
• These aUacks are device independent, and long-range
• Security Improvements: NoOfied SmartThings in Dec 2015; Improvements

in vezng process and developer best pracOces for Groovy Strings (Apr 2016); Discussion on improvements to capability system (May 2016)

• First look at the security design of a programmable smart home pla[orm:

Samsung SmartThings

• Two security design issues:
• Overprivilege: Coarse grained capabiliOes, and Coarse SmartApp-SmartDevice

Binding

• Insecure Events: Apps do not need special privileges to access sensiOve info
• Empirical Analysis: 55% of apps do not use all operaOons their capabiliOes

imply; 43% get capabiliOes they did not explicitly request

• Four PoC aIacks that combine various security design issues
• These aUacks are device independent, and long-range
• Security Improvements: NoOfied SmartThings in Dec 2015; Improvements

in vezng process and developer best pracOces for Groovy Strings (Apr 2016); Discussion on improvements to capability system (May 2016)

24

Security Analysis of Emerging Smart Home Applica6ons

hIps://iotsecurity.eecs.umich.edu Earlence Fernandes

Discussion

• 1. Smart home or dumb security risk?
• 2. How should we redesign the system?
• 3. Make the programmable frameworks open source?
• 4. Videos? hIps://iotsecurity.eecs.umich.edu