HanGuard: SDN-driven Protection of Smart Home WiFi Devices from Malicious Mobile Apps Good morning. My name is Soteris Demetriou and I am a PhD student at the University of Illinois at Urbana-Champaign. Today I will present our solution for vulnerable WiFi smart home devices. This is joined work with Nan Zhang, Yeonjoon Lee and Xiaofeng Wang from Indiana University, Bloomington, and Xiaoyong Zhou and Michael Grace from Samsung Research America. Soteris Demetriou 🔵, Nan Zhang 🔴, Yeonjoon Lee 🔴, XiaoFeng Wang 🔴, Carl A. Gunter 🔵, Xiaoyong Zhou 🔸, Michael Grace 🔸 🔵 🔴 🔸

$79 Billion smart-home industry (2014) 50 - 200 Billion devices Cisco estimates that 50-200 Billion devices will be Internet connected by 2020 $1.7 Trillion IDC estimates that global spending on IoT devices and services will rise to $1.7 Trillion by 2020 The Internet of Things is an important topic of study. In fact, Cisco estimates that by 2020 at least 50 billion devices will be Internet connected. The smart-home industry on its own generated $79 Billion dollars in 2014, while estimations predict a market of 1.7 Trillion dollars focusing on IoT devices and services. Unfortunately, the plethora of available devices and their increasing penetration to the general public in tandem with the monetary worth of this ecosystem, attracts not only businesses and entrepreneurs but also adversaries. $79 Billion smart-home industry (2014)

*&@^%(@&!*%)#

In our work we studied the communication between WiFi smart home devices and their control. Here is a typical scenario of a modern home automation system: devices use WiFi to connect to the router and then to the smartphone or cloud. For the convenience of management, such interconnected IoT equipment often relies on the secure connections of HAN (Wi-Fi authentication) for protection and trusts all the computing systems on the same network. This treatment, however, completely exposes the device to the attacks from compromised local systems, a threat becoming increasingly realistic.

Weak/No App-Level Authentication Hardcoded Credentials To make things worse, most of the consumer home automation devices have a small form factor and development is driven by time to market business requirements. This leads to bad security practices such as hardcoding credentials in the devices’ firmware.

As a proof of concept, we have performed attacks that exploit similar vulnerabilities on 4 real world devices, including switches, motion sensors and multipurpose devices. Given the millions of such devices already sold and installed, and historical evidence of bad security practices, a practical solution needs to be independent of device manufacturers and application developers. INSECURE

HanGuard: SDN-driven protection of WiFi smart home devices Towards this end we designed HanFence. HanGuard: SDN-driven protection of WiFi smart home devices HanGuard

Design Requirements Backward Compatible independent from device manufacturers independent from application developers use of existing infrastructure Practical no hardware requirements no smartphone OS modifications Backward Compatible independent from device manufacturers independent from Practical

Adversary Model

Consider the following scenario Consider the following scenario. This WiFi smart switch can be installed in a home area network and can be controlled by its respective mobile application. The app sends a command which the router delivers to the switch. In response the switch turns on. However, this switch assumes that if a device is authenticated to the home area network then it should be trusted. This allows, any smartphone - could be the one of a guest - to control it. Things become even more problematic when a malicious app is installed on an authorized device. Once an authenticated phone also carries malware (even when the app has nothing but the network privilege), protecting the device it controls becomes impossible at the network level, as the phone is completely legitimate to access the device though the malicious app running on it is not.

High-Level Approach

Controller Router Monitors Drivers Domain: Cameras Domain: Lights LEGEND ROLE 1 ROLE 2 ROLE 3 ROLE M ROLE Guest control channel Monitors MCN data channel SCN 1 SCN 2 SCN n Admin Role WPA2 key Enforcement Hook Category tags Controller Flow Table Domain: Cameras Domain: Lights Drivers Router

> 95% Mobile OS Marketshare iotlist.co Monitor > 95% Mobile OS Marketshare

Setting The Policies

Scenarios Remote Adversary [full cone NAT] - Not covered here Device-level adversary [network partition] - Not covered here App-level adversary

Example: Authorized app on authorized phone To help me illustrate some of the functions of HanGuard I will use as an example an access request from a mobile apps. To the interest of time I will focus on the application level decisions and enforcement. Firstly lets look at a legitimate scenario, where an authorized application on an authorized user phone, attempts to access an IoT device. Example: Authorized app on authorized phone

Control Channel Data Channel Control Packet Data Packet App Monitor User-space As mentioned before, the Monitor app on the user’s phone detects the application responsible for initiating a flow to the target IoT device. Here I will focus on the Android Monitor internals since it is more interesting. I will just say that on iOS we utilized a VPN API available to third-party apps to trap all network traffic to the HanGuard Monitor. On Android, we utilized side channels to detect benign flows. This allowed us to minimize performance overheads. In particular, when when app generates network traffic, the network-related kernel data structures are mirrored in the process virtual file system. Our Monitor app continuously observes flow information in the procfs to identify the apps responsible for the flows. The data flows remain unhindered whereas security information are forwarded to the router through the control channel. Kernel /net/tcp Virtual File System /net/tcp6 TCP Transport Layer IP Protocol Layer WiFi Drivers

Controller Worker Thread Control Channel Data Channel Flow ID # Control Packet Data Packet Flow Rule Controller Interface # Userspace Kernel Controller Worker Thread # Flow Table Device-Level Policy Base ?

Controller Worker Thread Control Channel Data Channel Flow ID # Control Packet Data Packet Flow Rule Controller Interface Userspace Kernel Controller Worker Thread # Flow Table Device-Level Policy Base ?

Example: Unauthorized app on authorized phone

Control Channel Data Channel Control Packet Data Packet App Monitor User-space On Android, we utilized side channels to detect benign flows. This allowed us to minimize performance overheads. In particular, when when app generates TCP or UDP traffic, the network-related kernel data structures are mirrored in the process virtual file system. Our Monitor app continuously observes flow information in the procfs to identify the apps responsible for the flows. The data flows remain unhindered whereas security information are forwarded to the router through the control channel. Clearly, the data and control flows traverse the network stack once in contrast with the iOS approach which require two passes. Kernel /net/tcp Virtual File System /net/tcp6 TCP Transport Layer IP Protocol Layer WiFi Drivers

Controller Worker Thread Control Channel Data Channel Control Packet Data Packet Controller Interface Userspace Kernel Controller Worker Thread Flow Table Device-Level Policy Base ?

Evaluation

Evaluation: effectiveness VANILLA HANGUARD Phone-Level App-Level WeMo Switch ✓ ✗ WeMo Motion WeMo Insight N3rd

Battery Consumption Trepn Power Profiler by Qualcomm Our approach on Android requires continuous polling of the procfs we evaluate the battery consumption on the phone. On the same Nexus 5 phone, we also ran Trepn [68] by Qualcomm to collect the baseline power profile of the phone for 30 seconds before running our Monitor app for 2 minutes. We tried two approaches. The HanGuard Simple approach polls the files every 10ms, opens and reads from them. The HanGuard Smarter approach also polls every 10ms but it doesn’t open the file unless it has been modified since the last check (last modified time - mtime). The simple one incur similar consumption with a popular antivirus program in scanning mode, while the smarter one was less than Gmail in idle mode (an optimized service which is always running). On iOS we used Xcode's Instruments tool Energy Use Level which was given to be 0 out of 20. The value observed was consistently 0. This can be explained since we used a feature offered by the platform and as such is optimized by the platform developers.

x10 Vanilla HanGuard ( ) TCP APP Throughput 20MB In terms of Throughput, we use a custom app to transmit a file of 20MB to its server counterpart on the same network. This was repeated 10 times. We found no significant drop in throughput. This is expected as the data plane is untouched on the phone and the checks at the router are minimized. TCP APP 20MB x10 Vanilla

Throughput In terms of Throughput, we use a custom app to transmit a file of 20MB to its server counterpart on the same network. This was repeated 10 times. We found no significant drop in throughput. This is expected as the data plane is untouched on the phone and the checks at the router are minimized.

Summary Designed a system to control access to WiFi smart home devices. Achieves application - level access control without client OS modifications. Backward Compatible Implementation on a commodity router and both iOS and Android (>95% of mobile OSs) HanGuard

Thank You! HanGuard Soteris Demetriou | sdemetr2@illinois.edu I sincerely hope this triggered your interest in reading our work. You can find Pluto’s source code and the full set of our evaluation results online. With this I conclude my presentation and I would be more than happy to address any questions you might have. Project Website: https://sites.google.com/site/seiot4han/ HanGuard