Smart Home Devices: assets or liabilities? – Part 1: Security

This blog post is part of a series, keep an eye out for the following parts!

TL;DR – Smart home devices are everywhere, so I tested the base security measures implemented on fifteen devices on the European market. In this blog post, I share my experience throughout these assessments and my conclusions on the overall state of security of this fairly new industry. Spoiler alert: there’s a long road ahead of this industry to grow in maturity when it comes to security.

Great new toys, great new responsibilities

Increasingly often, we are surrounding ourselves with connected devices. Even those who are adamant about not having any “smart devices” in their homes usually happily switch on their smart TV at the end of a long day while they drop down on the sofa. According to market studies and economic forecasts, the market share of smart home devices has been steadily rising for quite some time now, and that is not expected to be changing anytime soon. Smart home environments are everywhere these days, and for the most part they make our lives a lot more convenient.

However, there is another side to the coin: just like the devices themselves, news coverage about security concerns surrounding these devices has been popping up weekly, if not daily. Crafty criminals are tricking smart voice assistants into opening garage doors, circumventing ‘smart’ alarms or might even be spying on people through their internet-connected camera. We’ve already taken a deep dive in the past into some smart alarms, which showed their security left a lot to be desired. This raises the question: how secure are these devices we introduce to our daily lives really? I’ve tried to find out exactly that.

File:HAL9000 I'm Sorry Dave Motivational Poster.jpg - Wikimedia Commons
The words none of us want to hear when we ask our smart assistant to unlock the front door.
(Image credit: Wikimedia Foundation)

Research methodology

To get an idea of the overall security of Smart Home devices on the European market, I selected fifteen devices, chosen in such a way that they represented as many different product categories, price ranges and brands as possible. Where possible, I made sure to get at least two devices of different price ranges and brands in each category to be able to compare them.

Devices of all kinds were chosen for the tests.
(Image credit: see “Reference” below)

Then, I subjected each device to a broad security assessment. Each assessment consisted of a series of tests that were based on ENISA’s “Baseline Security Recommendations for IoT”. Here, the goal was not to conduct a full in-depth assessment of each device, but to get an overview on whether each device implemented the baseline of security measures a customer could reasonably expect from an off-the-shelf smart home solution. In order to guarantee repeatability of the tests, I mostly relied on automated industry-standard testing tools, such as nmap, Wireshark, Burp Suite, and Nessus.

In my tests, I covered the following range of categories: Network Communications, Web Interfaces, Operating Systems & Services, and Mobile Applications.

Network Communications

Because (wireless) network communications make up a large part of the attack surface of Smart Home devices, I performed a network capture of the traffic of each device for an idle period of 24 hours.

Without even looking into the data itself, it’s already interesting to note the vast differences in the number of captured packets within this period, where smart voice assistants and cameras are the clear winners.

Why does a doorbell send that many packets?
(Image credit: see “Reference” below)

In the figure below, you can see the different protocols that these devices used.

Oh, and all of the devices used DNS of course!
(Image credit: see “Reference” below)

When we think about network security, the encryption of the data is the most obvious security control we can check. However, this proved to be not always easy: Wireshark will tell you if TLS is being used or not, but aside from that, how can we determine if a raw TCP or UDP data stream is encrypted or not? For this, I used two scripts written by my colleague, Didier Stevens: simple_tcp_stats and simple_udp_stats.

These scripts calculate the average Shannon Entropy in each data stream. Streams with a high entropy value are likely encrypted, whereas streams with a low entropy value will likely contain natural text or structured data. The results were surprising: when mapping the different entropy scores in some box plots, many devices had multiple data streams with low entropy values, indicating that data was likely not being encrypted.

The above results indicate that while yes, some devices used state of the art, standardised, and most importantly secure network protocols, about half of them used something that was either not recognised by Wireshark (e.g. raw TLS/UDP streams) or has been proven to be insecure in the past (e.g. TLS 1.0). The results of the entropy testing are striking: not a single device wasn’t guilty of sending some data that was likely not encrypted: even those devices that encrypted the majority of their communications still sent DNS or sometimes NTP requests unencrypted over the network.

Web Interfaces

A lot of devices need some type of interface to interact with them. In most cases, that’s the mobile application accompanying the device. Sometimes, devices also support interactions via a web interface. Then, there are two options: a local interface, directly running on the device, or a cloud interface that runs on online servers maintained by the manufacturer. In the case of the latter, which made up most of the devices, doing in-depth testing was simply not possible due to legal limitations. However, one thing I could do was scan the cloud interface for SSL/TLS vulnerabilities with Qualys SSL Labs. I tested local interfaces by running an active scan in Burp Professional and performing a nikto scan.

On local interfaces, the most common serious flaw I found was the lack of encrypted communications: all of them ran over HTTP and sent credentials (as well as all other information, such as configuration data) in plaintext over the network. Quite a serious violation of secure web development practices for a really long time now.

Cloud interfaces were accessible via HTTPS, and all of them scored a B on the SSL Labs test because they all supported old TLS versions 1.0 and/or 1.1. While a B is not an inherently bad score, this indicates many vendors prioritise compatibility over security, as a higher score would be expected of those that want to deliver the best security to their customers.

All in all, it seems like developers adhered to the regular best practices when it came to cloud portals, but somehow forgot that local web interfaces also need the same care and protection as any other exposed service would have. It’s not because a device isn’t directly open for connections over the internet, that an attacker who gained access to the local network won’t try to gain a larger foothold by connecting to the devices within it.

Operating System & Services

I port scanned each device with nmap and ran some basic service discovery and vulnerability scans with Nessus Essentials. Sadly, I found that traditional scanning methods translate very poorly to these smart home devices: service discovery was very unreliable at best and plain wrong in most cases. Vulnerability scanning rarely yielded any interesting results besides some basic informational alerts. This is likely caused by the large amount of proprietary technologies or custom protocols that are being used by these devices.

What this concretely means is that there’s no straightforward, easy way to get an insight in the security of the devices. Gaining such knowledge would require tailored, targeted security assessments: a time consuming and difficult task, even for highly skilled professionals. Pretty discomforting, if you ask me.

Mobile Applications

As I mentioned earlier, users can often interact with their devices via web interfaces or a smartphone app. I performed static analysis on each of the corresponding android apps with MobSF (Mobile Security Framework). More specifically, I looked at:

  • the permissions requested by each app;
  • the known trackers embedded in the code;
  • domains that could be found in the code to get an indication of which and how many servers the app was calling out to.

I found that a lot of applications were asking for a disproportionally large number of permissions, sometimes even permissions an application arguably would not need to function properly. For example, what use does a smart light bulb app have for requesting permissions to record audio?

‘Dangerous’ permissions are any permissions the user needs to explicitly allow access for.
(Image credit: see “Reference” below)

I also noticed a significant number of mobile apps that included trackers. Most of them seemed to be for bug fixing and crash reporting, but others also included more intrusive tracking for advertising purposes.

Google Firebase Analytics and CrashLytics are likely included for crash reporting.
(Image credit: see “Reference” below)

The Verdict

So, based on all this information, what can we say about the security of the smart home devices currently available on the market? Well, for starters, in all the paragraphs above we can see there’s some good things, often followed by a ‘but’. Based on the fact that when we look at the bigger picture, devices that were properly secured on one front usually also seemed to do well in all the others, it seems to be quite a hit or miss when it comes to security. Vice versa, devices that were lacking certain security controls were usually insecure across the board. Most notably, in my results I clearly saw what security professionals already knew: security is a complete package. You simply can’t just cover one part and leave the other aspects of your product exposed. For products that came from manufacturers that understood this, I saw known to be secure network protocols, strong authentication options and user friendliness that made sure security was taken care of by default with little effort required from the consumer. The other products often had security as a mere afterthought: something that could be enabled if the user dug deep into the app menus, or maybe even not at all.

What can we do?

Now that we know it’s a hit or miss with these smart home devices, how can we make the right decisions in the store and make sure we don’t end up with one of the bad apples? Is it just a matter of luck, or can we steer the odds in our favour?

Luckily, there are a few things you can look out for; price is one of them, but – as we have already shown in these previous blog posts here and here  – should never be your only indicator. I found that brand recognition is an important factor in the level of attention the manufacturer will pay to security of their device. If a brand is well known and needs to uphold their good reputation to stay in business, they will also spend more time on fixing security flaws in the future, even after their product is already out for some time. And that brings me to the next point: automatic updates.

Even if you have a device that is secure today, if it’s never updated in the upcoming years it will eventually become vulnerable. Therefore, another good indication of security is the presence of updates. Ideally, automatic updates that are pushed to the device by the vendor without the need for user interaction, as we are probably all guilty of deferring updates out of convenience until it’s too late.

Afterthoughts and looking ahead

The overall security of devices on the market seems to be a hit or miss. Currently there are not many indicators consumers can look for when buying a device, but the combination of price, brand recognition and the presence of security updates can already give a general guideline on which device will be a good bet. If we want to get a clearer overview of the actual security of smart home IoT devices, an in-depth manual security assessment is needed because automated tools provide inaccurate or unsatisfying results.

Stay tuned for Part 2 of this series, in which I’ll be talking about smart home devices and privacy!

This research was conducted as part of the author’s thesis dissertation submitted to gain his Master of Science: Computer Science Engineering at KU Leuven and device purchases were funded by NVISO labs. The full paper is available on KU Leuven libraries.


[1] Bellemans Jonah. June 2020. The state of the market: A comparative study of IoT device security implementations. KU Leuven, Faculteit Ingenieurswetenschappen.

About the Author

Jonah is a consultant in the Cyber Strategy & Culture team at NVISO. He taps into the knowledge of his technical background to help organisations build out their Cyber Security Strategy. He has a strong interest in ICT law and privacy regulation, as well as the ethical aspects of IT. In his personal life, he enjoys video & board games, is a licensed ham radio operator, likes fidgeting around with small DIY projects, and secretly dreams about one day getting his private pilot’s license (PPL).

Find out more about Jonah on his personal website or on Linkedin.

2 thoughts on “Smart Home Devices: assets or liabilities? – Part 1: Security

Leave a Reply