Abusing the Internet of Things

A potential mitigating factor is the lack of WiFi communication used by the Hub, making traffic

interception more difficult as it requires that an attacker be physically connected to the same net-

work as the Hub or for interception to occur during transit over the Internet. However this does not

offer complete protection, as several home networks make use of WiFi bridges or repeaters. An

attacker may also have compromised another device residing on the network such as a router or

personal media server that may be used to perform traffic interception.

Security vulnerabilities such as this can allow an attacker on the same WiFi network (or
on a device that is between the home network of the user and the route to the SmartThings
network) to modify and influence all of the communication between the Hub and the Smart-
Things network. Attackers can abuse this vulnerability to trigger or deny alerts that the user
might have set up, and this can put the physical safety of SmartThings customers at risk.
The good news is that the SmartThings team worked with the researchers who identified
the problem and responded with a security patch:

11/10/14 - Initial report to vendor

11/11/14 - Report acknowledged

11/21/14 - Vulnerability confirmed

01/29/15 - Updated firmware rollout begins

03/04/15 - Public disclosure

The researchers of this vulnerability should also be given credit for having the patience to
work with SmartThings and waiting for the patch to be rolled out before exposing the issue.
This is a good example of how a security issue in an IoT product can give rise to vulnera-
bilities that attackers can abuse to formulate man-in-the-middle attacks. However, this is also
a great example of how IoT vendors, such as SmartThings, should work with security
researchers to understand the issues and roll out firmware patches to protect their customers.

Interoperability with Insecurity Leads to...Insecurity

We have to give credit where credit is due. SmartThings should shore up the authentication
capabilities for its suite of products and work on securely enabling traditional services such as
text messaging its their free developer suite. That said, unlike the case of the Philips hue or
Belkin WeMo products, the SmartThings architecture does not implicitly trust the local net-
work.
In the case of the Belkin WeMo Baby and the WeMo Switch, any device on the same local
network can readily connect to and instruct the devices without any further authentication.
However, in the case of SmartThings, the Hub and the app establish outbound connections to
graph.api.smartthings.com to communicate with each other. In this way, every update and
instruction is validated against an established and authenticated session tied to the user’s

CHAPTER 4: BLURRED LINES—WHEN THE PHYSICAL SPACE MEETS THE VIRTUAL

(^106) SPACE