There’s a quiet energy invasion underway. Smart energy devices are worming their way into homes as we become ever more energy conscious. But these devices are creating a new entry point into the home that could give attackers unprecedented control at a time when cyber attacks are becoming increasingly organised – and lucrative.
All too aware of this, energy providers have undertaken security reviews of the network infrastructure required for smart meters. It could be argued that these reviews have delayed rollouts, whereas someone more cynical might say that dealing with the hosts of security flaws found is what slowed progress. Either way, this is in direct contrast to the deployment of domestic smart home devices, many of which are not properly secured.
People like the idea of being able to run their homes via internet-enabled devices and one of the most widely adopted ones is the smart thermostat. The market has seen massive global growth of 123 per cent in 2015, according to IoT Analytics, with 4.9 million devices now deployed in homes.
So how susceptible are these devices to attack? Would it be possible, for instance, to upload malicious software that could disable or take over the system? Could the device even be used to carry ransomware? We wanted to see how feasible this was and so carried out an investigation on a smart thermostat that is available to buy today. (We have not named the vendor, in accordance with disclosure practices, to give the company the opportunity to remedy the issues found.)
The thermostat was Linux-based with plenty of processing power and storage on an SD card to allow users to create their own profiles and heating schedules, all accessed via an Adobe Air application. Access that and you can see the file system with rooted privileges. Some tinkering later and we discovered it was possible to inject code when loading settings that made it relatively easy to upload a shell which would allow us to install modified firmware. As a result, with the right code, we could take control of the device and do a number of things.
So what could someone do if they have access to your thermostat? Quite a lot, as it turns out. This particular thermostat had a piezoelectric buzzer, which one could set to a high decibel range. High enough to be outside the audible range of humans, yet drives your pets bananas. Or you could ramp up the heat or the A/C depending on the weather or to burn money at the owner’s expense. It was also possible to trigger this on/off functionality several times a second – potentially destroying your boiler.
We took it further and deployed ransomware on the device with a simple proof of concept message saying “Ha! Pay 1 Bitcoin to get control back”. To stop anyone overriding our attack by resetting the PIN, we modified it to lock the user out and by running a shell script we were able to ensure that PIN was reset every 30 seconds to prevent the user from trying to guess the passcode.
Admittedly, these compromises were local to the device rather than a remote code execution, but there is little to prevent remote attacks in the future. It is plausible that an attacker could obtain and dissect a second-hand thermostat, for instance, or gain access to devices via a compromised supply chain, thereby planting malware before sale, or simply gain access by conning the user into becoming complicit in the attack. Should remote access become viable, the device might even pose a threat to their home network and other connected devices. Suddenly that thermostat’s security has become the lowest common denominator, effectively putting other control mechanisms at risk of attack.
Of course, none of this should be possible. Simple firmware security implemented by the vendor could prevent these types of attack. For instance, it is advisable to encrypt firmware to prevent it being unpacked and analysed and to sign the firmware to prevent it being modified, then checking the signing at boot. Other principles that should be considered are: never trust user input, even filenames; always work to the rule of least privilege, that is, on a need to access basis and don’t run everything as root; implement simple firewalls to prevent unwanted/unintended connections; use hardware interlocks to stop repeated on/off switching and concurrent heat/cooling; and remove debug information to make it harder to reverse engineer.
Those are all advisable precautions for the vendor, but it is worth noting that energy providers are implicated too. It is the energy provider that has fought hard to satisfy security requirements and ensure their infrastructure is beyond reproach. But that careful groundwork is liable to be undermined by the cavalier attitudes of a few commercial vendors. In this case, the thermostat makes it difficult to secure power consumption and that’s a slippery slope, possibly leading to bill shock and payment disputes. Pinning responsibility on the vendor, who has zero culpability when it comes to how power is consumed, is nigh on impossible and that leaves the energy provider dealing with a jaded customer and bad debt.