Abusing the Internet of Things (2015)
Chapter 4. Blurred Lines: When the Physical Space Meets the Virtual Space
Android and iOS are the most popular smartphone operating systems in the world. In addition to many other uses, these phones are useful for their mapping functionality. Prior to 2007, when the first iPhone was released, GPS functionality was barely usable. Before the iPhone, most of us printed out directions on a sheet of paper using Yahoo! Maps or MapQuest. It’s been only a few years since we began to rely so much on the GPS abilities of our smartphones, yet it’s now hard to imagine how we got by in the past.
The tools we now have at home are likely to go through the same revolution. We are rapidly headed toward replacing offline devices such as traditional door locks, radio based baby monitors, and lighting with IoT platforms that allow the devices to serve us wherever we are. In a few years, similar to our current sentiments on GPS on our smartphones, we are going to wonder how we were able to get by without various things (such as door sensors and motion detectors) in our homes being able to communicate with us regardless of our location. The notion that we were once remotely unable to tell if we left our home’s front door unlocked will seem unfathomable.
SmartThings (acquired by Samsung) is one company that is trying to lead the dream of the IoT-connected home with their suite of products, such as the SmartSense Multi Sensor and SmartPower Outlet. The SmartThings store has a slew of products that individuals can buy and install themselves.
Given that SmartThings is so focused on enabling IoT in the home, this chapter focuses on evaluating the security in the design of their products. It is important to identify companies like SmartThings and analyze what good and bad design principles are at work. People are installing and using such devices now, and the accompanying security architecture is bound to set precedents and be leveraged in future versions of similar products.
A lot of functionality of these products is also currently being used to ensure physical security. For example, when the main door is unexpectedly opened at midnight, an alert might be sent to the home owner on his or her smartphone. As such, it becomes an emergency for us to strategize the current state of security of such products, so we can learn how to secure them now and into the future.
The SmartThings system can also be used to control IoT products developed by third parties. Many companies are trying to figure out how to interoperate with devices manufactured by others, so it is important to learn how to make all of our devices work with each other securely. In this chapter, we will also take a look at the interoperability offered by SmartThings from a security perspective.
SmartThings
In this section, we will focus on the following components: the SmartSense Multi Sensor, the SmartThings app, and the SmartThings hub. Given the various methods the SmartThings platform can be programmed using the app, our focus will be on testing the secure design of the platform by analyzing the design and functionality of the app.
The SmartSense Multi Sensor (Figure 4-1) is a multi-purpose device that includes a temperature sensor, an accelerometer, and a magnetic open/close sensor for doors. In this chapter, we will focus on the use case of the SmartSense Multi Sensor being used to trigger an event when a particular door is open or closed.
Figure 4-1. The SmartSense Multi Sensor
The SmartThings hub (Figure 4-2) is the brain of the SmartThings platform. It connects to all the sensors (including some third-party devices), allowing the user to be notified of events that trigger based on the inputs the sensors receive. The hub also connects to the SmartThings cloud infrastructure, allowing you to program specific triggers when the sensors receive input.
Figure 4-2. The SmartThings hub
NOTE
The SmartThings hub uses the ZigBee protocol to communicate with the nearby devices. The focus of this chapter is to evaluate security design by analyzing the SmartThings app and the development environment. Please see Chapter 1 to learn how to capture and analyze ZigBee data.
The SmartThings app can be used to configure the SmartThings devices and check their status. In Figure 4-3, the app shows that the SmartPower outlet is toggled on and that the door to which the SmartSense Multi Sensor is attached is closed.
Figure 4-3. The SmartThings iOS app
Users must register for a SmartThings account and sign in at the screen shown in Figure 4-4.
Figure 4-4. SmartThings app login screen
When the user types in his or her credentials and presses"Log In, the app sends the following POST request:
POST /oauth/token HTTP/1.1
Host: graph.api.smartthings.com
Accept: application/json
Proxy-Connection: keep-alive
X-ST-Client-DeviceModel: iPhone
X-ST-Api-Version: 2.1
Accept-Encoding: gzip, deflate
Accept-Language: en;q=1
X-ST-Client-AppVersion: 1.6.5
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 191
User-Agent: SmartThings/1006 (iPhone; iOS 8.0.2; Scale/2.00)
X-ST-Client-OS: iOS 8.0.2
Connection: keep-alive
client_id=[DELETED]&client_secret=[DELETED]0&grant_type=password&
password=skeuomorphism&scope=mobile&username=scott.forstall@apple.com
The app is using the OAuth standard to submit the credentials and gain authorization. The client_id and client_secret values submitted by the app are always the same, so they can be considered public information. As expected, the combination of the username and password fields need to be correct. Once the user submits the right credentials, the graph.api.smartthings.com will respond in the following way:
HTTP/1.1 200 OK
Cache-Control: no-store
Content-Type: application/json
Date: Fri, 17 Oct 2014 04:46:45 GMT
Server: Apache-Coyote/1.1
Vary: Accept-Encoding
Content-Length: 135
Connection: keep-alive
{
"access_token": "[DELETED]",
"expires_in": 1576799999,
"scope": "mobile",
"token_type": "bearer"
}
The important token to note here is access_token, which the app will use to convince the graph.api.smartthings.com server that it has authorization. Anyone who knows this token can directly connect to the graph.api.smartthings.com server and impersonate the user. Note that the value of expires_in is the unit of seconds, which correlates to 18,250 days. In other words, the access_token value is valid and will be accepted by graph.api.smartthings.com for 18,250 days, after which the user will be required to log in again.
The SmartThings App allows the user to specify multiple physical locations, such as home and office, and manage devices within those locations. Figure 4-5 shows the app interface listing a current location (Home) with the ability to add additional locations.
Figure 4-5. SmartThings App interface for viewing and adding locations
To get the list of locations associated with the user, the app sends the following request:
GET /api/locations HTTP/1.1
Host: graph.api.smartthings.com
Accept: application/json
Authorization: Bearer [DELETED]
Proxy-Connection: keep-alive
X-ST-Client-DeviceModel: iPhone
X-ST-Api-Version: 2.1
Accept-Encoding: gzip, deflate
Accept-Language: en;q=1
X-ST-Client-AppVersion: 1.6.5
X-ST-Api-Key: [DELETED]
X-ST-Client-OS: iOS 8.0.2
User-Agent: SmartThings/1006 (iPhone; iOS 8.0.2; Scale/2.00)
Connection: keep-alive
The X-ST-Api-Key token is constant and can be considered public knowledge. The value submitted for Authorization is the access_token value that was received by the app upon successful authentication. The graph.api.smartthings.com server responds with the following:
HTTP/1.1 200 OK
Content-Type: application/json;charset=utf-8
Date: Fri, 17 Oct 2014 04:46:47 GMT
Server: Apache-Coyote/1.1
Vary: Accept-Encoding
X-Pad: avoid browser bug
Content-Length: 1204
Connection: keep-alive
[{"id":"[DELETED]","name":"Home","accountId":"[DELETED]","latitude":42.613706,
"longitude":-120.200028,"regionRadius":150,"backgroundImage":
"https://smartthings-location-images.s3.amazonaws.com/standard/standard62.jpg",
"mode":{"id":"[DELETED],"name":"Away","locationId":"[DELETED]"},"modes":
[{"id":"[DELETED]","name":"Away","locationId":"[DELETED]"},{"id":"
[DELETED]","name":"Home","locationId":"[DELETED]"},{"id":"[DELETED]","name":
"Night","locationId":"[DELETED]"}],"role":"owner","helloHomeAppId":"[DELETED]",
"temperatureScale":"F","hubs":[{"id":"[DELETED]","name":"Home","locationId":
"[DELETED]","firmwareVersion":"000.010.00246","zigbeeId":"[DELETED]","status":
"ACTIVE","onlineSince":"2014-10-08T18:42:52.679Z","signalStrength":null,
"batteryLevel":null,"type":{"name":"Hub"},"virtual":false,"role":"owner",
"firmwareUpdateAvailable":false}]}]
According to the response, the user has one location associated with his or her account. This is identified by the value of the id token. The latitude and longitude values represent the actual physical location. There are also several modes, such as Away and Home. The user can manually set the current mode, or the SmartThings system can be configured to do it automatically, such as setting the value to Away when the user’s phone is outside of the regionRadius value of the location.
The SmartThings app now needs to pull additional information about the SmartThings devices associated with the account and their configurations. It does this by issuing the following POST request using the location id and access_token (for the Authorization field) obtained earlier:
GET /api/locations/[DELETED]/smartapps/ HTTP/1.1
Host: graph.api.smartthings.com
Accept: application/json
Authorization: Bearer [DELETED]
Proxy-Connection: keep-alive
X-ST-Client-DeviceModel: iPhone
X-ST-Api-Version: 2.1
Accept-Encoding: gzip, deflate
Accept-Language: en;q=1
X-ST-Client-AppVersion: 1.6.5
X-ST-Api-Key: [DELETED]
X-ST-Client-OS: iOS 8.0.2
User-Agent: SmartThings/1006 (iPhone; iOS 8.0.2; Scale/2.00)
Connection: keep-alive
And the server responds with the following:
HTTP/1.1 200 OK
Content-Type: application/json;charset=utf-8
Date: Fri, 17 Oct 2014 04:46:49 GMT
Server: Apache-Coyote/1.1
Vary: Accept-Encoding
X-Pad: avoid browser bug
Connection: keep-alive
Content-Length: 18488
[{"id":"[DELETED]","label":"Intruder alert","smartAppVersion":{"id":"[DELETED]"
,"version":0.9,"state":"SELF_APPROVED","name":"Smart Security","description":
"Alerts you when there are intruders but not when you just got up for a glass
of water in the middle of the night","iconUrl":"
https://s3.amazonaws.com/smartapp-icons/SafetyAndSecurity/App-IsItSafe.png",
"iconX2Url":
"https://s3.amazonaws.com/smartapp-icons/SafetyAndSecurity/App-IsItSafe@2x.png",
"dateCreated":"2013-05-29T11:58:02Z","lastUpdated":"2014-05-14T21:55:47Z",
"preferences":{"sections":[{"input":[{"title":[DELETED]],"hideable":false,
"hidden":false,"mobileOnly":true}],"defaults":true},"legacy":true,"pageCount":
0,"installedCount":1420,"author":"SmartThings","photoUrls":[],"videoUrls":[],
"showModuleWithoutChildren":false,"smartApp":{"id":"[DELETED]"}},
"installedSmartAppParentId":null,"settings":{"textMessage":"Intruder alert!",
"intrusionMotions":[],"alarms":[],"intrusionContacts":["[DELETED],"silent":
"Yes","newMode":"","residentMotions":[],"residentsQuietThreshold":"0","phone":
"4151111111","lights":[],"seconds":"0"}
Notice the Intruder alert customization, which sends an alert to the user’s phone using a text message (to phone number 4151111111 in this case) every time someone opens the main door (detected by an installed SmartThings Multi Sensor). Figure 4-6 shows the corresponding user interface on the app.
Figure 4-6. SmartThings App configuration for “Intruder alert” customization
Now that the customization is set, the SmartThings app will send a text message to 4151111111 every time the door is opened. Figure 4-7 shows the text message (“Intruder alert!”) recieved by the user when the customization is triggered.
Figure 4-7. Text message alerting user when door is opened
It isn’t hard to imagine the amount of trust a family would have to place into a product to depend on it to send an alert in case of a physical intrusion. As such, it is important that products such as SmartThings architect security in the design and functionality of their products. In the next few sections, we will look at scenarios that could put SmartThings customers at risk and how the issues can be mitigated.
Hijacking Credentials
As we’ve seen, the SmartThings app stores the user’s settings and customizations on the external infrastructure available at graph.api.smartthings.com. This makes it possible for an external entity to take control over the user’s SmartThings devices if they are able steal the password. Malicious entities that successfully do this can switch on or off appliances connected to the SmartPower Outlet or disable customizations associated with the SmartSense Multi Sensor.
As shown in Figure 4-8, app requires a password at least eight characters long, including at least one number and one letter.
Figure 4-8. SmartThings app password requirements
Based on the complexity of the password requirments, SmartThings designers clearly intend to build in security. Complex passwords slow down attackers, who try to guess various combinations of possible passwords.
Should the user forget the password, he or she can request a new one can be requested, as shown in Figure 4-9.
Figure 4-9. Password reset request using the SmartThings app
As soon as the user presses the Send Recovery Email button, the app sends the email shown in Figure 4-10 to the user.
Figure 4-10. Email from SmartThings allowing the user to reset his or her password
The “click here to reset your password” link is in following form:
http://mandrillapp.com/track/click/30028387/graph.api.smartthings.com
?p=sdf9234msafd0234ASFASDf234023042342masdf0234SDAFSDF0234msdf0asfdsd
f02342msad
When the user clicks on this link, the browser is redirected to the SmartThings website with a link such as this:
https://graph.api.smartthings.com/register/resetPassword?t=2304ksdf0As
dfa3sdfd4asfasdf
Upon redirection, the user is allowed to pick a new password, as shown in Figure 4-11.
Figure 4-11. User picking a new password as part of the password recovery process
There are several security issues with the SmartThings authentication and authorization systems.
Single-factor authentication
Systems that protect against physical threats should not rely upon single-factor authentication. SmartThings markets its ability to secure and monitor the home as a primary feature. Even though the system has implemented a complex password requirement, a one-time access to the owner’s email account can compromise the physical security promised by the system. It might be overkill to protect your Pizza Hut account with anything more than a username and password, since the cost of implementing extra measures might be higher than accepting the cost if nefarious pizza-ordering activity. But a system you rely upon to protect your home and loved ones must offer greater security.
In the current situation, a malicious entity can use the password reset feature (Figure 4-9) to reset a victim’s SmartThings password. All the attacker needs is temporary access to the target’s email account, which can be gained by stealing a mobile device that belongs to the SmartThings user and capturing the resetted password (Figure 4-11) just by using the user’s preconfigured email client on the mobile device. This requires physical access to the mobile device, so it is less probable, but the attacker could also obtain access to the email account by launching a phishing attack or successfully infecting the victim with malware that captures email credentials.
The point here is that products that advertise physical security should take security seriously and implement tighter controls. Millions of people routinely have their email credentials compromised on a weekly basis. Users should not have to worry about an intruder remotely being able to monitor their home and influence the devices in their home just because they fell victim to a simple phishing attack.
Companies such as Google and Apple have realized that it is becoming harder to guarantee customer security by relying on a username and password mechanism alone. Google offers two-factor authentication, which requires the use of a password (first factor) in addition to the possession of a mobile device (second factor).
With two-factor authentication enabled, the user must first enter his or her credentials, after which a randomly generated code is sent as a text message to the user’s phone. The user must also enter this code to log into the account. This type of setup requires knowledge of something secret (password), along the possession of a physical object (mobile device).
Apple has implemented a similar method to protect their users and has also opened its TouchID system to third-party app developers. This could easily be leveraged by the SmartThings app to verify the user’s fingerprint as the second factor.
Another issue of concern is the longevity (18,250 days!) of the access_token discussed earlier. Since 18,250 days equals approximately 50 years, a potential attacker has five decades to try to obtain the access_token and reuse it to launch commands using the graph.api.smartthings.com service.
We hope that SmartThings and other emerging IoT manufacturers will enhance their designs to implement two-factor authentication, so that attackers won’t be able to disrupt physical safety using traditional attack vectors such as phishing and infecting desktops with malware.
Clear-text password reset link
The clear-text password reset link sent by the SmartThings app can be abused to hijack the user’s credentials. As shown in Figure 4-10, the user is sent a password recovery email when the user requests to reset his or her password (Figure 4-9). This link (in the form of http://mandrillapp.com/track/click/30028387/graph.api.smartthings.com, as discussed earlier) does not use Transport Layer Security (TLS), but is rather sent across the local network and the Internet in the clear.
The user is then redirected to a link that does use TLS (in the form of https://graph.api.smartthings.com/register/resetPassword, also dicussed earlier). However, anyone on the local WiFi network, such as a public wireless network in a cafe, can capture the original link if the user were to click on it. Once this link has been captured, the attacker can reset the password by submitting a new password before the victim does. Once the password is reset, the password reset link expires and the user will have to submit a new request.
In this case, an argument could be made that it is hard for a potential attacker to wait around for the victim to forget his or her password and submit a reset request at a cafe. However, in the case of a targeted attack in which the attacker is on the same wireless network as the victim, the attacker can initiate the password reset by submitting the request shown in Figure 4-9 on behalf of the user. In that case, the victim would likely be surprised by the password reset email.
But it is also likely for the victim to assume there is a glitch in the SmartThings system and go ahead with the reset process anyway, allowing the attacker to capture the initial link and take over the account. In addition to this scenario, individuals with access to the network devices between the victim and mandrillapp.com can also capture the initial link and compromise the user’s SmartThings account.
Abusing the Physical Graph
The upcoming age of IoT is bound to connect our physical world with our online virtual spaces. We have already witnessed this occur throughout the previous chapters of this book: being able to control lightbulbs based on triggers on Facebook using IFTTT, sending our companions electronic keys using our mobile devices that can be used to open physical doors, and storing information about our physical IoT objects on remote servers like graph.api.smartthings.com.
The SmartThings team has published a vision of their notion of a Physical Graph that will serve as a platform for IoT objects in the future:
At SmartThings, we believe the next and perhaps most life-altering evolution of the Internet will be the creation of the physical graph; the digitization, connectivity and programmability of the physical world around us. Whether you call this the Internet of Things, sensor networks or home and life automation, the implications for how we live, work, and have fun are profound. At our core, we also believe that for the ecosystem to be healthy, it must be open. An open physical graph is the only way to bridge the innovation, inventions and brilliance of the many device manufacturers, hardware makers, developers, and everyday people who are working to change our lives today and in the future.
SmartThings has brought their vision of “connectivity and programmability of the physical world” to life using their web-based integrated development environment (IDE). Using this free tool, users can easily program their IoT devices to perform tasks tailored to their personal specifications.
Anyone can sign up for a free SmartThings developer account and start using the IDE to create programs to control IoT devices. As shown in Figure 4-12, developers can quickly start building programs by selecting from a variety of Example SmartApps.
Figure 4-12. The SmartThings IDE
It is great that the SmartThings team has decided to open up a free tool to its users and developers, but from a security perspective, it becomes important to make sure the platform cannot be abused by malicious entities. For example, take a look at the Text Me When It Opens program available from the Example SmartApps library:
/**
* Text Me When It Opens
*
* Author: SmartThings
*/
definition(
name: "Text Me When It Opens",
namespace: "smartthings",
author: "SmartThings",
description: "Get a text message sent to your phone when an open/close sensor
is opened.",
category: "Convenience",
iconUrl: "https://s3.amazonaws.com/smartapp-icons/Meta/window_contact.png",
iconX2Url: "https://s3.amazonaws.com/smartapp-icons/Meta/
window_contact@2x.png"
)
preferences {
section("When the door opens...") {
input "contact1", "capability.contactSensor", title: "Where?"
}
section("Text me at...") {
input "phone1", "phone", title: "Phone number?"
}
}
def installed()
{
subscribe(contact1, "contact.open", contactOpenHandler)
}
def updated()
{
unsubscribe()
subscribe(contact1, "contact.open", contactOpenHandler)
}
def contactOpenHandler(evt) {
log.trace "$evt.value: $evt, $settings"
log.debug "$contact1 was opened, texting $phone1"
sendSms(phone1, "Your ${contact1.label ?: contact1.name} was opened")
}
This program sets up a virtual contact (emulating the SmartSense Multi Sensor) that can be toggled using the IDE. Once this contact is toggled to the Open state, the code in contactOpenHandler(evt) is invoked, which in turn invokes sendSms service to send a text message.
Take a look at Figure 4-7 again. Notice that the SmartThings service uses a short code (same as phone numbers, but specific to text messages) of 512-69. If anyone in the world (even those who don’t own a single SmartThings product) were to sign up for a free SmartThings IDE and use the Text Me When It Opens program, they could use this testing functionality to send any text message to anyone in the world and it will also appear from the short-code 512-69.
Now imagine if someone were to change the sendSms code to the following:
sendSms(phone1, "WARNING: Systems malfunction. All devices disarmed.
Possible intruder activity.")
In this case (Figure 4-13), the user will get a text message with the scary warning from the same 512-69 short code. Imagine getting such a text message past midnight, while you are sleeping or perhaps even away from home. Users that have gotten previous text messages from the SmartThings system are likely to trust the message, because it originates from the same short code. In fact, when the short code used by SmartThings recently changed (to 512-69), users inquired on discussion forums, indicating that they are indeed aware and trust messages that originate from the code.
Figure 4-13. Scary text message to SmartThings user
Many users might choose to use push notifications such as Apple Push Notification and Google Cloud Messaging services to send the notifications instead of text. However, others prefer text messages, especially when SmartThings needs to shut down non-text- based notifications for maintenance, as shown in an actual announcement in Figure 4-14. In fact, the announcement from SmartThings advises users to select to receive text messages instead of push notifications, making such intervals the perfect time for intruders to abuse the situation.
Figure 4-14. Email from SmartThings advising users of maintainance schedule
This is just one example of how such a system can be abused. A malicious person who knows of your cell phone number and knows that you rely on SmartThings products to remotely ensure the safety of your family could abuse this situation to cause you to leave a particular location (such as your office) and head home to check up on your family because you received a SMS from the SmartThings short code.
In addition, spammers can abuse the free sendSms functionality to use the SmartThings short code to send free text advertisements to anyone.
The lesson here is that the incoming number associated with text messaging should never be used to establish trust or prove authenticity. One solution is to request the user to input a four-digit number that will be reflected on every text message sent out by SmartThings. Users can be educated to disregard messages that do not contain the four-digit prefix. However, this creates greater burden on the users and hinders the experience of the product. Still, this is the price to pay if traditional protocols such as text messaging are to be used.
Data-driven push notifications are much more reliable, because they rely on certificate-based encryption and authentication and are much harder to spoof.
SmartThings SSL Certificate Validation Vulnerability
In March 2015, a report titled SmartThings SSL Certificate Validation Vulnerability exposed a critical issue relating to the SmartThings hub:
The communications between the SmartThings Hub and the SmartThings backend servers is encrypted with SSL. However, the SSL client implementation in use does not validate the authenticity of the SSL certificate presented by the server during the initial handshake. An attacker with the ability to monitor and intercept traffic can present a “forged” SSL certificate to the Hub claiming to be a legitimate backend server, which the Hub will accept as genuine. This makes it possible to perform a “man-in-the-middle” attack, whereby an attacker relays communications between client and server without their knowledge. In this scenario, the communications are available to the attacker in an unencrypted form and may be modified or disrupted, effectively defeating the protections offered by SSL encryption.
Secure and authenticated communications are vital to a platform such as SmartThings, which may be used as part of a home security system. As an example, the Hub transmits a data packet when a SmartSense Open/Closed Sensor opens. By simply not relaying this data packet, an attacker can prevent notification of this event from ever reaching the SmartThings backend servers, which in turn prevents notification being delivered to the end user.
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 network 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 SmartThings 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 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 patience to work with SmartThings and waiting for the patch to be rolled out before explosing the issue.
This is a good example of how a security issue in an IoT product can give rise to vulnerabilities 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 issue and roll out firmware patches to protect their customers.
Interoperability with Insecurity Leads to … Insecurity
We have to give credit where credit is due. The SmartThings suite of products should shore up its authentication capabilities and be cognizant about securely enabling traditional services such as text messaging with their free developer suite. That said, unlike the Philips hue or Belkin WeMo products, the SmartThings architecture does not implicitly trust the local network.
In the case of the Belkin WeMo baby monitor and the WeMo switch, any device on the same local network can readily connect and instruct the devices without the use of any further authentication. However, in the case of SmartThings, the hub and the app connect outbound 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 SmartThings account. This makes SmartThings’ approach more secure, because it doesn’t allow a workstation infected with malware to directly manipulate SmartThings devices.
In addition to SmartThings’ own devices, the system now supports interoperability with third-party IoT devices. With SmartThings Labs, the SmartThings App and hub can be used to control the Philips hue lighting system, the WeMo switch, and other devices. Having given credit to SmartThings for securely routing information through graph.api.smartthings.com and not trusting the local network implicitly, we will analyze weather this secure design principle holds up, by looking at how SmartThings interoperates with the Philips and Belkin products.
SmartThings and hue Lighting
Using the SmartThings App, it is possible to search for and connect to the Philips hue bridge (described in Chapter 1). In order to do this, touch the + button at the bottom of the Dashboard section of the SmartThings App. Next, select Light Bulbs → Philips hue Light Bulb. Once you do this, your screen should look like Figure 4-15.
Figure 4-15. SmartThings App connecting to a Philips Hue bridge
The SmartThings hub starts to look for a hue bridge on the local network by issuing the following SSDP query:
M-SEARCH * HTTP/1.1
MX: 1
MAN: "ssdp:discover"
HOST:239.255.255.250:1900
ST: urn:schemas-upnp-org:device:basic:1
The hue bridge responds to this query and identifies itself:
HTTP/1.1 200 OK
CACHE-CONTROL: max-age=100
EXT:
LOCATION: http://10.0.1.2:80/description.xml
SERVER: FreeRTOS/6.0.5, UPnP/1.0, IpBridge/0.1
ST: upnp:rootdevice
The SmartThings hub now fetches /description.xml from the hue bridge by issuing the following GET request:
GET /description.xml HTTP/1.1
Accept: */*
User-Agent: Linux UPnP/1.0 SmartThings
HOST: 192.168.2.2:80
To which the hue bridge responds:
HTTP/1.1 200 OK
Content-type: text/xml
Connection: Keep-Alive
<?xml version="1.0" encoding="UTF-8" ?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<URLBase>http://10.0.1.2:80/</URLBase>
<device>
<deviceType>urn:schemas-upnp-org:device:Basic:1</deviceType>
<friendlyName>Philips hue (10.0.1.2)</friendlyName>
<manufacturer>Royal Philips Electronics</manufacturer>
<manufacturerURL>http://www.philips.com</manufacturerURL>
<modelDescription>Philips hue Personal Wireless Lighting</modelDescription>
<modelName>Philips hue bridge 2012</modelName>
<modelNumber>929000226503</modelNumber>
<modelURL>http://www.meethue.com</modelURL>
<serialNumber>[DELETED]</serialNumber>
<presentationURL>index.html</presentationURL>
<iconList>
<icon>
<mimetype>image/png</mimetype>
<height>48</height>
<width>48</width>
<depth>24</depth>
<url>hue_logo_0.png</url>
</icon>
<icon>
<mimetype>image/png</mimetype>
<height>120</height>
<width>120</width>
<depth>24</depth>
<url>hue_logo_3.png</url>
</icon>
</iconList>
</device>
</root>
At this point, the user will see a notification that the bridge has been found, as shown in Figure 4-16.
Figure 4-16. SmartThings app locateing the hue bridge
When the Next button is pressed, the SmartThings hub sends the following POST to the hue bridge:
POST /api HTTP/1.1
Accept: */*
User-Agent: Linux UPnP/1.0 SmartThings
HOST: 10.0.1.2:80
Content-Type: application/json
Content-Length: 107
{"devicetype":"8f7ab27c-6c04-4378-b0b1-dcd4fd468815-0","username":"8f7ab27c-6c04
-4378-b0b1-dcd4fd468815-0"}
The values for devicetype and username are the same and seem random enough in nature. Recall (from Controlling Lights Using the iOS App) that the user will have to prove physical ownership of the bridge by pressing the button on it within 30 seconds. When this happens, the hue bridge will accept the value of username and it can subsequently be used by the SmartThings hub to connect to the hue bridge on the local network and issue commands.
Assuming the user presses the button on the hue bridge, the following response is returned to the SmartThings hub:
HTTP/1.1 200 OK
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Expires: Mon, 1 Aug 2011 09:00:00 GMT
Connection: close
Access-Control-Max-Age: 3600
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, DELETE, HEAD
Access-Control-Allow-Headers: Content-Type
Content-type: application/json
[{"success":{"username":"8f7ab27c-6c04-4378-b0b1-dcd4fd468815-0}}]
The user will be notified that the connection was sucessful, as shown in Figure 4-17.
Figure 4-17. SmartThings hub successfully gaining authorization from the hue bridge
From now on, the SmartThings hub can command the Philips hue bridge by always including the value of 8f7ab27c-6c04-4378-b0b1-dcd4fd468815-0 as the authorization token in request. For example, it can issue a POST request of the form /api/8f7ab27c-6c04-4378-b0b1-dcd4fd468815-0/groups/0/action with to turn of all the lights, as shown in Controlling Lights Using the iOS App.
NOTE
The hue bridge accepts incoming connections on port 80, which does not use encryption. This can allow a malicious device on the local network to launch ARP spoofing attacks and steal and proxy the username. However, this architecture is based on design from the hue team. The SmartThings hub has no choice but to use unencrypted communication, because the kue web server communicates only in clear text.
Recall from Chapter 1 that the earlier implementation of the hue App utilized the MD5 hash of the smartphone’s MAC address as the username. We know that was a bad idea, because it allowed any local device to cause a perpetual blackout. The SmartThings hub does not commit this error. The SmartThings team should be complimented for designing this diligently.
SmartThings and the WeMo Switch
The WeMo Switch (Some Things Never Change: The WeMo Switch) can also be controlled using the SmartThings app. Similar to setting up the hue, the user has to select the + button on the bottom of the Dashboard screen of the app, followed by selecting Switches & Dimmers → Belkin WeMo Switch → Connect Now. This causes the SmartThings hub to search for the switch using SSDP:
M-SEARCH * HTTP/1.1
MX: 1
MAN: "ssdp:discover"
HOST:239.255.255.250:1900
ST: urn:Belkin:device:controllee:1
The WeMo Switch responds to identify itself:
HTTP/1.1 200 OK
CACHE-CONTROL: max-age=86400
DATE: Mon, 20 Oct 2014 14:32:17 GMT
EXT:
LOCATION: http://192.168.2.10:49153/setup.xml
OPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01
SERVER: Unspecified, UPnP/1.0, Unspecified
X-User-Agent: redsonic
ST: urn:Belkin:device:controllee:1
The app alerts the user that a WeMo Switch has been located, as shown in Figure 4-18.
Figure 4-18. SmartThings app letting the user know that a WeMo Switch has been found
As expected, the SmartThings hub sends the following GET request to the WeMo Switch:
GET /setup.xml HTTP/1.1
HOST: C0A8020A:C001
And the Switch responds:
HTTP/1.1 200 OK
CONTENT-LENGTH: 3767
CONTENT-TYPE: text/xml
DATE: Mon, 20 Oct 2014 14:32:23 GMT
LAST-MODIFIED: Mon, 20 Oct 2014 14:26:28 GMT
SERVER: Unspecified, UPnP/1.0, Unspecified
X-User-Agent: redsonic
CONNECTION: close
<?xml version="1.0"?>
<root xmlns="urn:Belkin:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<device>
<deviceType>urn:Belkin:device:controllee:1</deviceType>
<friendlyName>WeMo Switch</friendlyName>
<manufacturer>Belkin International Inc.</manufacturer>
<manufacturerURL>http://www.belkin.com</manufacturerURL>
<modelDescription>Belkin Plugin Socket 1.0</modelDescription>
<modelName>Socket</modelName>
<modelNumber>1.0</modelNumber>
<modelURL>http://www.belkin.com/plugin/</modelURL>
<serialNumber>[DELETED]</serialNumber>
<UDN>[DELETED]</UDN>
<UPC>123456789</UPC>
<macAddress>[DELETED]</macAddress>
<firmwareVersion>WeMo_US_2.00.2769.PVT</firmwareVersion>
<iconVersion>0|49153</iconVersion>
<binaryState>0</binaryState>
<iconList>
<icon>
<mimetype>jpg</mimetype>
<width>100</width>
<height>100</height>
<depth>100</depth>
<url>icon.jpg</url>
</icon>
</iconList>
<serviceList>
<service>
<serviceType>urn:Belkin:service:WiFiSetup:1</serviceType>
<serviceId>urn:Belkin:serviceId:WiFiSetup1</serviceId>
<controlURL>/upnp/control/WiFiSetup1</controlURL>
<eventSubURL>/upnp/event/WiFiSetup1</eventSubURL>
<SCPDURL>/setupservice.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:timesync:1</serviceType>
<serviceId>urn:Belkin:serviceId:timesync1</serviceId>
<controlURL>/upnp/control/timesync1</controlURL>
<eventSubURL>/upnp/event/timesync1</eventSubURL>
<SCPDURL>/timesyncservice.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:basicevent:1</serviceType>
<serviceId>urn:Belkin:serviceId:basicevent1</serviceId>
<controlURL>/upnp/control/basicevent1</controlURL>
<eventSubURL>/upnp/event/basicevent1</eventSubURL>
<SCPDURL>/eventservice.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:firmwareupdate:1</serviceType>
<serviceId>urn:Belkin:serviceId:firmwareupdate1</serviceId>
<controlURL>/upnp/control/firmwareupdate1</controlURL>
<eventSubURL>/upnp/event/firmwareupdate1</eventSubURL>
<SCPDURL>/firmwareupdate.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:rules:1</serviceType>
<serviceId>urn:Belkin:serviceId:rules1</serviceId>
<controlURL>/upnp/control/rules1</controlURL>
<eventSubURL>/upnp/event/rules1</eventSubURL>
<SCPDURL>/rulesservice.xml</SCPDURL>
</service>
.
<service>
<serviceType>urn:Belkin:service:metainfo:1</serviceType>
<serviceId>urn:Belkin:serviceId:metainfo1</serviceId>
<controlURL>/upnp/control/metainfo1</controlURL>
<eventSubURL>/upnp/event/metainfo1</eventSubURL>
<SCPDURL>/metainfoservice.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:remoteaccess:1</serviceType>
<serviceId>urn:Belkin:serviceId:remoteaccess1</serviceId>
<controlURL>/upnp/control/remoteaccess1</controlURL>
<eventSubURL>/upnp/event/remoteaccess1</eventSubURL>
<SCPDURL>/remoteaccess.xml</SCPDURL>
</service>
.
<service>
<serviceType>urn:Belkin:service:deviceinfo:1</serviceType>
<serviceId>urn:Belkin:serviceId:deviceinfo1</serviceId>
<controlURL>/upnp/control/deviceinfo1</controlURL>
<eventSubURL>/upnp/event/deviceinfo1</eventSubURL>
<SCPDURL>/deviceinfoservice.xml</SCPDURL>
</service>
</serviceList>
<presentationURL>/pluginpres.html</presentationURL>
</device>
</root>
Seem familiar? It’s the exact same response as when the official WeMo App requests /setup.xml (as shown in Some Things Never Change: The WeMo Switch>>). This seems logical and expected. The point of reiterating it here is to demonstrate that the SmartThings app is following the same protocol as the WeMo app to interoperate with the WeMo Switch, which is a third-party device.
The SmartThings app can be used to create custom triggers, as shown in Figure 4-19. In this case, the lamp connected to the WeMo switch will turn on every time the door to which a SmartThings Multi Sensor is attached is opened. The lamp will then turn off after five minutes of no activity.
Figure 4-19. SmartThings app controllilng the WeMo Switch
Once set up, the SmartThings hub can connect directly to the switch and issue commands. For example, the hub can send the following request to the Switch:
POST /upnp/control/basicevent1 HTTP/1.1
SOAPACTION: "urn:Belkin:service:basicevent:1#GetBinaryState"
Content-Length: 277
Content-Type: text/xml; charset="utf-8"
HOST: 192.168.2.10:49153
User-Agent: CyberGarage-HTTP/1.0
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:GetBinaryState xmlns:u="urn:Belkin:service:basicevent:1">
</u:GetBinaryState>
</s:Body>
</s:Envelope>
The GetBinaryState request’s intention is to query if the switch is on or off. The switch responds:
HTTP/1.1 200 OK
CONTENT-LENGTH: 285
CONTENT-TYPE: text/xml; charset="utf-8"
DATE: Mon, 20 Oct 2014 16:33:36 GMT
EXT:
SERVER: Unspecified, UPnP/1.0, Unspecified
X-User-Agent: redsonic
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body>
<u:GetBinaryStateResponse xmlns:u="urn:Belkin:service:basicevent:1">
<BinaryState>0</BinaryState>
</u:GetBinaryStateResponse>
</s:Body> </s:Envelope>
The value of 0 for BinaryState indicates that the switch is turned off. As shown in Chapter 3, the hub can also send a SetBinaryState to toggle the power on.
Notice that, just like the official WeMo app, no authentication or authorization is required. In order to interoperate with other devices such as the WeMo switch and hue lighting, the SmartThings hub and app have no choice but to follow the protocol defined by the third-party devices they integrate with. This is precisely the point of this section and analysis: interoperability with third-party IoT devices that expose services insecurely maintains the insecurity and risk that is exposed.
There is little SmartThings can do to secure the design crafted by third-party devices they want to integrate with. The toss-up is between the decision of interoperability while maintaining the insecurity or the decision not to integrate. It appears that SmartThings has decided to go the route of interoperability, to be able to support a wide ecosystem of IoT devices, including third parties, that can in turn be programmed using the SmartThings app and their IDE. This approach makes sound business sense, because it positions SmartThings to be the hub of IoT devices of the future. However, the risk that is exposed is the sum total of the impact of all insecure devices that SmartThings decides to interoperate with.
Conclusion
Companies like SmartThings are clearly enabling IoT in the home and helping us push toward our digital futures that blur the lines between our physical spaces and our online virtual spaces. The SmartThings IDE is a powerful way to elegantly program both the spaces to maximize benefit from IoT devices in our homes.
The majority of popular use cases, such as an event triggered by the door opening, or a motion sensor detecting activity in the middle of the night, are clearly aligned toward protecting our safety. In cases in which our physical safety is the paramount issue of concern, it becomes extremely important that the technology supporting and enabling it be designed securely. In this chapter, we discussed why products like SmartThings need to enable authentication that is beyond the traditional username and password approach. We’ve learned the hard way why a mere password is not enough to protect our online accounts, and we can’t risk the same with devices that are put in place to ensure our physical safety.
A popular concern with IoT devices is the ability to issue security patches to fix known security flaws. Security researchers have pointed out a major attack against the SmartThings hub that can lead to a man-in-the-middle attack, which was duly patched by SmartThings. This is a good example of IoT device manufacturers doing the right thing, by communicating with security researchers and diligently issuing firmware updates to their customers to remediate the issue.
We also studied how the powerful SmartThings developer IDE can be tied with traditional technologies, such as text messaging, and how this can be abused to spoof messages to users to scare them or to distract them. As we enable further IoT sensors in the home, we ought to think through all the various avenues of notifications and communications and have a strategy for gradually retiring traditional mechanisms such as text messaging. Such an approach might have to be more gradual than we’d like, given spotty data coverage in some areas. However, it is important that we begin to have the discussion now and educate users on the current shortcomings.
Unlike the Philips hue lighting system and the WeMo suite of products, the SmartThings hub and devices do not connect directly. Instead, they connect outbound to an external cloud infrastrucutre and exchange instructions. The SmartThings architecture is therefore less likely to fall prey to another rogue device on the same local network, because there is no implicit trust of local devices.
Given the frequency of successful phishing attempts and workstation compromise due to malware, this is a welcome design decision, because it keeps the SmartThings devices from falling prey to other infected machines on the same network. However, SmartThings’ approach to this design does not stem from a conscious intent to be secure, but it’s more of a side effect of going to market with dependability on the cloud as the first step:
We made the decision at SmartThings to support a “Cloud First” approach for our platform. This means that in our initial release, there is a dependency on the Cloud. SmartApps run in the SmartThings Cloud, so for everything to work, your hub does need to be online and connected to our cloud. This will generally be the case, even when we implement hub-local capabilities as described below.
We believe in a “connected” service where local capabilities in the hub are meant to improve performance and insulate the customer from intermittent internet outages. We do not plan to support a perpetually disconnected mode.
We made the decision to limit SmartApps to the Cloud in our first release because it allowed us to focus on the experience of writing the applications and less on the mechanics of deploying that logic locally to the hub.
That said, we are actively considering implementation scenarios whereby we can distribute SmartApps to—and execute SmartApps locally on—the SmartThings Hub.
In all cases, we recognize the critical scenarios where a loss of communications with the SmartThings Cloud could have a degrading impact on critical, local use cases, and are being deeply thoughtful on how we minimize the risk of disruption.
We hope that SmartThings and other influential IoT device manufacturers design local and disconnected capabilities securely. Their recognition of critical scenarios due to a loss of communications is laudable and the right approach. However, we’ve seen in previous chapters how reliance the local network as inherently secure can lead to a high probability of disruption and compromise of our privacy and security. As we look into the future, we ought to demand secure design as an intention, not a side effect. It would be a shame if the architecture designed to support critical functionality in times of a communication disruption is vulnerable to attacks when the communication channel is available.
Companies like SmartThings are leading innovation that will help us enable IoT in our homes. We are also going to increasingly depend upon these devices for our well-being and for our safety. IoT device manufacturers and consumers ought to think more carefully about secure authentication, trustworthiness of communications, and secure interoperability between devices.