Announcing IoT Inspector: Studying Smart Home IoT Device Behavior

By Noah Apthorpe, Danny Y. Huang, Gunes Acar, Frank Li, Arvind Narayanan, Nick Feamster

An increasing number of home devices, from thermostats to light bulbs to garage door openers, are now Internet-connected. This “Internet of Things” (IoT) promises reduced energy consumption, more effective health management, and living spaces that react adaptively to users’ lifestyles. Unfortunately, recent IoT device hacks and personal data breaches have made security and privacy a focal point for IoT consumers, developers, and regulators.

Many IoT vulnerabilities sound like the plot of a science fiction dystopia. Internet-connected dolls allow strangers to spy on children remotely. Botnets of millions of security cameras and DVRs take down a global DNS service provider. Surgically implanted pacemakers are susceptible to remote takeover.

These security vulnerabilities, combined with the rapid evolution of IoT products, can leave consumers at risk, and in the dark about the risks they face when using these devices. For example, consumers may be unsure which companies receive personal information from IoT appliances, whether an IoT device has been hacked, or whether devices with always-on microphones listen to private conversations.

To shed light on the behavior of smart home IoT devices that consumers buy and install in their homes, we are announcing the IoT Inspector project.

Announcing IoT Inspector: Studying IoT Security and Privacy in Smart Homes

Today, at the Center for Information Technology Policy at Princeton, we are launching an ongoing initiative to study consumer IoT security and privacy, in an effort to understand the current state of smart home security and privacy in ways that ultimately help inform both technology and policy.

We have begun this effort by analyzing more than 50 home IoT devices ourselves. We are working on methods to help scale this analysis to more devices. If you have a particular device or type of device that you are concerned about, let us know. To learn more, visit the IoT Inspector website.

Our initial analyses have revealed several findings about home IoT security and privacy.

Finding #1: Many IoT Devices Lack Basic Encryption & Authentication

Some groups have published best practice guidelines for IoT devices, including the use of encryption to prevent malicious actors from intercepting and reading communications between devices and cloud servers, as well as incorporating appropriate authentication mechanisms to prevent unauthorized entities from accessing user information.

Unfortunately, many of the devices we have examined lack even these basic security or privacy features. For example, the Withings Smart Blood Pressure Monitor included the brand of the device and the string “blood pressure” in unencrypted HTTP GET request headers. This allows a network eavesdropper to (1) learn that someone in a household owns a blood pressure monitor and (2) determine how frequently the monitor is used based on the frequency of requests. It would be simple to hide this information with SSL.

We also analyzed several Internet-connected children’s toys and found several security and privacy vulnerabilities. None of the toys we studied used HTTPS or SSL when communicating with manufacturer-owned servers. One toy lacked authentication for user profile pictures. An eavesdropper could record or replay device communications to obtain profile photos.

Finding #2: User Behavior Can Be Inferred from Encrypted IoT Device Traffic

Even devices that use HTTPS/SSL may be vulnerable to privacy violations based on Internet traffic metadata, such as traffic volumes. We have demonstrated how observers from ISPs to devices in the home to neighbors running packet sniffers, can infer in-home user behaviors from patterns of encrypted traffic from IoT devices.

A network observer can first identify devices in a home using MAC addresses, DNS requests, or machine learning on packet timings. The observer can then monitor traffic and note spikes in packet frequency or size. The timings of these spikes, combined with the identity of the device, allows the observer to infer user behaviors.

Figure 1: Network traffic send/receive rates of selected flows from four commercially-available smart home devices during controlled experiments. Clearly visible changes in send/receive rates directly correspond with user activities. A passive network observer aware of this behavior could easily correlate smart home traffic rates with device states and corresponding user activities.

The figure demonstrates the effectiveness of this attack on four home IoT devices. Traffic rates from a sleep monitor revealed user sleep patterns, traffic rates from a smart outlet revealed when a physical appliance in a smart home is turned on or off, and traffic rates from a security camera revealed when a user is actively monitoring the camera feed or when the camera detects motion in a user’s home.

Most single- or limited-purpose IoT devices are susceptible to this simple attack. We are currently designing and evaluating obfuscation techniques to protect activity inference from network metadata.

Finding #3: Many IoT Devices Contact a Large and Diverse Set of Third Parties

In many cases, consumers expect that their devices contact manufacturers’ servers, but communication with other third-party destinations may not be a behavior that consumers expect.

We have found that many IoT devices communicate with third-party services, of which consumers are typically unaware. We have found many instances of third-party communications in our analyses of IoT device network traffic. Some examples include:

• Samsung Smart TV. During the first minute after power-on, the TV talks to Google Play, Double Click, Netflix, FandangoNOW, Spotify, CBS, MSNBC, NFL, Deezer, and Facebook—even though we did not sign in or create accounts with any of them.
• Amcrest WiFi Security Camera. The camera actively communicates with cellphonepush.quickddns.com using HTTPS. QuickDDNS is a Dynamic DNS service provider operated by Dahua. Dahua is also a security camera manufacturer, although Amcrest’s website makes no references to Dahua. Amcrest customer service informed us that Dahua was the original equipment manufacturer.
  
• Halo Smoke Detector. The smart smoke detector communicates with broker.xively.com. Xively offers an MQTT service, which allows manufacturers to communicate with their devices.
  
• Geeni Light Bulb. The Geeni smart bulb communicates with gw.tuyaus.com, which is operated by TuYa, a China-based company that also offers an MQTT service.
  

We also looked at a number of other devices, such as Samsung Smart Camera and TP-Link Smart Plug, and found communications with third parties ranging from NTP pools (time servers) to video storage services.

These third-party services are potentially single points of failure or vulnerability. Specifically, the same third-party services are often used by a broad array of IoT devices. A security vulnerability in one service might affect devices across a range of manufacturers. Third-party services also allow data aggregation across devices. A third party could aggregate user data from a wide range of devices, creating the possibility for tracking a user’s behavior across many devices. These devices are also not transparent about the Internet services with which they communicate or share data. Most IoT devices do not mention the specific third parties they communicate with in their privacy policies, which makes it difficult for consumers to make purchasing decisions based on security and privacy considerations.

Finding #4: Smart Home Device Traffic is Predictable, Facilitating Anomaly Detection

The Mirai botnet used hacked IoT devices to conduct distributed denial of service (DDoS) attacks on critical Internet infrastructure. Most owners of these devices had no idea that their security cameras or DVRs were participating in the attack.

Figure 2: Test network setup for experiments detecting misbehaving devices.

An in-network device or service should be able to automatically detect misbehaving devices and notify users that their devices have been compromised.To evaluate this concept, we have set up a test network to simulate a DDoS attack from a compromised IoT device in a consumer home, as shown in the figure.

We are experimenting with machine learning-based DDoS detection using features using IoT-specific network behaviors (e.g., limited number of endpoints and regular time intervals between packets). Preliminary results indicate that home gateway routers or other network middleboxes could automatically detect local IoT device sources of DDoS attacks with high accuracy using low-cost machine learning algorithms.