Last updated at Fri, 01 Feb 2019 14:15:39 GMT
When considering or testing the security posture of an IoT product’s ecosystem, it is important to take into account how that product handles failure conditions. When failures are examined for an IoT device, we typically look at scenarios in which normal communication channels become unavailable. The question then becomes, what behaviors does the device exhibit that might be different in a failure state versus its intended operating state?
In this post, we will discuss a few failure conditions that should be tested to avoid the potential compromise of IoT products.
Interrupted internet connectivity
Start by considering what would happen if the device’s internet connectivity is interrupted. One option is that the device would fail into a local-mode connectivity condition, meaning it will still allow the management application (such as a mobile app) to control the device from the local network if the internet cannot be accessed. Or, the IoT technology could become unmanageable until internet access is restored.
Typically, one would expect the technology to allow local network management of the product. However, when local mode is allowed during an internet communication failure, what is the security state of the impacted device? Many IoT researchers have encountered IoT devices in which the local mode management access did not require any level of authentication or encryption, allowing an attacker on the local network to gain access that could significantly impact the device’s functionality. It is critical that these types of conditions be tested on IoT product ecosystems and that manufacturers establish the same level of security for both local and remote access and management of products.
IoT product setup
Another common issue is directly related to how many IoT products are initially set up when you take them out of the box. Consumer IoT products are often designed to connect to your personal WiFi network by starting up an internal WiFi access point when first powered up. You can then connect to the device’s WiFi access point with some default or generated credentials supplied by the vendor and make the needed configuration changes to the device. Once that is done, the device will then automatically reconnect to your personal WiFi, shut down the internal WiFi access point, and begin operating as designed.
With this common configuration, you are left to wonder what would happen if the IoT product cannot connect to your personal WiFi access point as configured at some point in the future. Will it fail to operate? Or, will it fall back into its initial configuration stage, meaning the device starts up the internal WiFi access point as if it needs to be configured due to the failure? The device should ideally stop working correctly and require a factory reset before dropping back into configuration mode, but that’s not always the case. We continue to encounter products that drop back into configuration mode when they fail to connect to their configured WiFi access point.
This issue can be easily exploited by flooding the primary WiFi access point with deauthentication packets, forcing the IoT product to disconnect and not successfully reconnect. If the device is vulnerable, you should see its default internal WiFi access point start up and allow configuration access.
On a positive note, some vendors use unique authentication credentials to access the internal WiFi access points of the IoT product. In those cases, the devices are somewhat protected from this type of attack.
Because of security issues like these, it is very important that all possible failure conditions be examined during product security testing to ensure IoT products continue to maintain a strong security posture that protects against this and similar types of device compromise, information loss, and violation of privacy.
