Fit and forget: The threat posed by unconfigured IoT - IoT global network

Blogs

Fit and forget: The threat posed by unconfigured IoT

January 31, 2019

Posted by: Anasia D'mello

The march of ‘smart’ technology has seen every conceivable device in our homes and offices ‘enhanced’ with some form of connectivity. While this offers additional functionality for some, says Ken Munro, partner at Pen Test Partners, for others these smart enhancements are surplus to requirement.

After all, why wirelessly connect your washing machine if you’re happy to use the controls manually? Inevitably, this means that Internet of Things (IoT) devices are being bought and used without connecting them and this creates a real problem.

IoT devices that aren’t configured still effectively act as unencrypted open wireless access points, making them vulnerable to compromise. This is an issue that seems to have escaped the attention of both manufacturers and regulators. Despite the publication of numerous advisory guidelines, none of them deal with this issue, including our own Code of Practice for Consumer IoT Security.

Attack vectors

Connecting to a non-configured IoT device is trivial. An attacker can identify the SSID for the device using a geolocation site such as wigle.net. Device are readily identifiable, for instance, kettles use the SSID: iketttle, hot tubs: BWGSPa, Google Chromecast: Chromecast, LG air conditioners: LGE_AC and EcoWater smart water softeners: H2O-6c. All they then need do is download the app, wardrive past the location, connect to the wireless access point, and voila they have control.

An attacker can identify the SSID for the device using a geolocation site.

Devices using Bluetooth connectivity are potentially at even greater risk than those using Wi-Fi. This is because such devices often have no process in place for authenticating or authorising the mobile device they are connecting to, enabling anyone within range to connect.

Once compromised, these devices can be abused in various ways. They can be used to create a backdoor onto the network, for instance. We’ve even seen this in an enterprise environment where an unconfigured screencaster installed by an AV engineer (and, therefore, not on the security department’s radar) bridged the wired and wireless corporate network.

Consider also that many of these devices will have been languishing in the supply chain, stuck in a warehouse somewhere until shipped, meaning they usually seek to update their software once configured. Unconfigured and running out-of-date software they are exploitable and a prime target for rogue firmware.

Once the rogue firmware has been uploaded, this can be used to modify the device, potentially seeing it used for eavesdropping, for instance. Failing to update devices is also an issue for other long-term IoT devices, from smart lightbulbs to thermostats, which are likely to stay in situ for a long time and which the user may not bother to update.

Ken Munro

Solving the problem

There are some design solutions that could resolve the issue of unconfigured IoT. One option is to physically install a button on the device that the user must then use to authenticate, be it for wireless connectivity or Bluetooth pairing.

This then ensures the device can only be manually made to connect to the app on the users’ device when it is in proximity. Short of the key being intercepted in transit, this vastly reduces the potential for compromise, however, with security often being an afterthought at best, very few devices have a physical control mechanism like this.

A more cost-effective solution would be to compel all IoT devices to have their radio frequency radios switched off by default. This may sound like it runs counter to the point of the IoT but I believe we need to be in control of our tech rather than the other way round.

The fact that the product is shipped as smart does not mean the user will use it as intended. Consumers must be given the choice over how they wish to use the device. Otherwise, we run the risk of our smart homes becoming susceptible to local attacks over Wi-Fi.

The author is Ken Munro, partner, Pen Test Partners.

Comment on this article below or via Twitter @IoTGN