14 March 2015

Home Automation Benchmarking Results


We recently completed a benchmarking test of 16 devices from cameras to home automation controllers to thermostats.  The devices were examined head to head to derive conclusions on the relative state of security across the board.

What did we find?  We wouldn’t be posting this if we thought there was nothing to be concerned about.  We found that in general, the Internet of Things (IoT) industry has some work to do in terms of following best security practices.

That said, we did identify some companies that are doing the right thing with few exceptions.  In particular, Nest was the overall leader across the categories we tested.

Other companies were also strong in certain areas. Hive, for example, demonstrated encrypted communications and automatic firmware updates. And Control 4 had a strong password policy.

To assess the security of the various products, we played out four attack scenarios:

  • The Open House – An attacker attends an open house at a home or business. No time for screwdrivers and soldering irons – he’ll be lucky to get two minutes alone with a device.  What can he accomplish?
  • The Stolen Phone – Most vendors have iOS or Android apps for their devices.  If an attacker has five minutes of alone time with your phone, do these apps put your remote IoT device at risk?
  • The Coffee Shop – Vendors know what they’re supposed to do when it comes to protecting data in transit, but how many actually execute? And what does this mean for consumers if an attacker is sitting on an open Wi-Fi network with them?
  • The Malicious ModificationImplanting nasty stuff before products leave the factory is usually the realm of nation states.  But what if we move the attack a bit further downstream? Say by spending a weekend systematically buying, implanting, re-shrink wrapping, and returning devices, what’s possible?

The Following Devices Were Examined:

Home Automation

Conclusions Based on Each Scenario:

  • Fortunately most devices passed the “open house” test.  Of those that didn’t, some offered a legitimate  USB update mechanism that could be abused to upload malicious code.  Others had insecure pairing mechanisms that could be used to gain access.
  • Most of the time the “dropped phone” scenario played out in the attackers favor (assuming the phone had been used to interface with the device in the past).  Many apps stored passwords in plaintext, or left behind non-expiring session credentials that would give an attacker indefinite access to a user’s devices.
  • Multiple devices failed the “coffee shop” test, in that we were able to view session credentials on an open WiFi network in plaintext.  Plaintext session data is bad, but some of the session lifetimes on devices are persistent.
  • The “malicious modification” was not pretty.  In 93% of cases, physical access + 20 minutes = a rooted device on the first try.  After a bit of practice we could generally get the process down to less than five minutes.  Adding persistent code to devices was trivial and our repackaging was indistinguishable from the original. With that said, it is well known within the security community that physical access almost always results in a successful compromise on ANY device.  Our results reinforce the idea that it is important to limit physical access from untrusted individuals.

See the full report on SlideShare


Best Practices:

All this being said, what we want people to take away is that risks aren’t something to be afraid of, they should be understood and then avoided where possible and mitigated where they are not. This is an outline of Synack suggestions for basic standards to set the bar for the industry:

  • *While it is not possible in all circumstances, when it is, all communication should use bidirectional encryption.
  • *Encryption should never be “homebrewed”
  • *All services should require authentication
  • *Self-signed certificates should only be used when the security tradeoff is understood. End users should not have to decide to trust (or not trust) these self signed certificates.
  • *SSL Pinning should be used to prevent advanced “Man-in-the middle” attacks
  • *Basic password strength requirements should be enforced
  • *Firmware updates should happen automatically since they often contain important security fixes that are time critical.
  • *Manufacturers should take responsibility for security and not rely on the user.
  • *Send notifications for users when device statuses change or when new sessions are initiated.

Study funded in part by Nest Labs, Inc.  Results are independent analysis conducted by Synack.