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

Smart Door Locks nsors Connected Ovens Plugs IP Cameras Emerging Smart Home Frameworks art TVs 2

Poten6al Security Risks Current Vulnerabili6es Devices Protocols Remotely determine e Ome for Flooding [1] OR Burglary [1,2] These aUacks are device-specific and require proximity to the hom Denning et al., Computer Security and the Modern Home, CACM’13 3 FTC Internet of Things Report’15

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

Analysis of SmartThings Access • Why SmartThings? Control • RelaOvely Mature (2012) • 521 SmartApps • 132 device types Trigger-AcOon • Shares design principles with other exisOng, nascent frameworks 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 5

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 > 40% of apps exhibit overprivilege of Empirical Analysis of 499 Apps atleast one type Pincode InjecLon and Snooping, Disablin Proof of Concept AIacks VacaLon Mode, Fake Fire Alarms 6

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

Capability System Send commands ZWave Lock SmartDevice Untrusted Read/set aUributes SmartApp Receive events capability.lock capability.lockCodes capability.baFery ility Commands AIributes … lity.lock lock(), unlock() lock (lock status) lity.baUery N/A baUery (baUery status) Security Ease of Development Usability Very Granular CapabiliOes Expressive FuncOonality Simpler Coarser CapabiliOes 8

SmartApps request Capabili6es 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 } Device EnumeraOon 9

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

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

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

Insufficient Event Data Protec6on subscribe dev, “door.unlock”, handler ZWave Door Lock SmartApp 71c9344e-6bea-4ae8-993a-28a7817a7d9e 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 13 • (aper being registered it can read device.id value)

Insufficient Event Data Protec6on subscribe dev, “door.unlock”, handler ZWave Door Lock SmartApp 71c9344e-6bea-4ae8-993a-28a7817a7d9e 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) 14

Other Poten6al Security Issues - OAuth SmartThings Cloud Plagorm Capability Groovy-Based Groovy-Based HTTPS Sandbox System Sandbox GET/PUT SmartDevice SmartApp [Cmd/AUr] Internet API [Events] SMS API • Insecurity of Third-Party IntegraOon: SmartApps expose HTTP endpoints protected by OAuth; Incorrect implementaOon can lead to remote aUacks [1] [1] Chen et al., OAuth DemysOfied for Mobile ApplicaOon Developers, CCS’14 15

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

Other Poten6al Security Issues – Unrestricted External Communica6on APIs SmartThings Cloud Plagorm Capability Groovy-Based Groovy-Based HTTPS Sandbox System Sandbox GET/PUT SmartDevice SmartApp [Cmd/AUr] Internet API [Events] SMS API • Unrestricted CommunicaOon AbiliOes: SMS and Internet; Can be used to leak data arbitrarily 17

Compu6ng Overprivilege Coarse-Grained CapabiliOes Coarse SmartApp-SmartDevice Binding Requested Granted Cmds/Attrs CapabiliOes Used Cmds/ Used AUrs CapabiliOes 18

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

Empirical Analysis Results Documented Completed Commands 65 93 AUributes 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

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

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

Exploi6ng Design Flaws in SmartThings Command OAuth Unrestricted Event Overprivilege InjecOon SMS API Spoofing Compromise Disabling Pincode Pincode Fake CO VacaOon InjecOon Snooping Alarm Mode lar ExisOng SmartApp Stealthy malware SmartApp; Malware SmartApps with no capabiliOes; Android companion ONLY requests Misuses logic of exisOng SmartApps with fake capability.baUery events Unintended acOon of tCode() on lock 21

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 24

Backdoor Pincode Injec6on AFack WebService HTTP PUT SmartApp HTTP GET mappings { path (“/devices/:id”) { ac6on: [ PUT: “updateDevice” ] } { def updateDevice() command: setCode, { arguments: [3, ‘5500’] def cmd = request.JSON.command client_id } def args = request.JSON.arguments client_secret // code truncated device.”$cmd”(*args) 28 }