IoT devices are repeatedly exhibiting the same flaws creating a massive vulnerable attack surface which will inevitably lead to more major attacks. We’ve already seen DDoS attacks increase 91 percent over the course of 2017 due to vulnerable deployed devices, yet estimates suggest only 9 percent of IoT vendor budgets are spent on security. This pitiful investment is leading to shortcuts and a ‘live, die, repeat’ attitude to development that spells disaster for the user and the long-term viability of the IoT seedbed.
So what are these common issues that are cropping up time and again? Security research reveals specific issues across all aspects of IoT design, from access and connectivity, hardware and firmware, and update mechanisms.
Access all areas
In terms of access, vendors often fail to implement ‘least privilege’ in the permissions on the device. Without this an attacker can quickly gain root access to the entire system. The root user log-in should require a password and this should not be set by default or hardcoded in as this could mean that one vulnerability, such as having telnet enabled, could provide root access.
Encryption is also another common failing, without which the attacker can recover keys, certificates, hashes, and passwords and again gain control. Using System on a Chip (SoC) to store encryption keys or sensitive information on the device using Trusted Platform Module (TPM) is the preferred option. A secure boot should also be implemented as without this the SoC cannot check the integrity of the bootloader, and the bootloader cannot check the integrity of the firmware. This can allow an attacker to modify firmware of the device, either by subverting controls on the firmware update process, or through physical access to devices.
Just because the device is encrypted doesn’t mean it is protected, however. Poor implementation of encryption such as encryption without MAC, hardcoded IV and weak key generation can all lead to compromise and steer clear of home-grown cryptography. Ensure encryption is extended to include firmware. Attacks can see malicious firmware deployed to devices so sign and validate the signature during updates and ensure that the HTTPS connection is secure, with SSL certificates validated.
Wireless weaknesses
Connectivity is also a major sticking point. There’s a tendency to assume that a local connection over a WiFi access point or Bluetooth Low Energy (BLE) confers some protection because of the limited range of the signal but this can still lead to drive-by attacks. Typically wireless communication is used to pass the user’s SSID and pre-shared key (PSK) to the device, often in plain text, which the attacker can then capture and use.
Redundant functions often provide a convenient entrance point for the attacker. Developers favour off-the-shelf toolkit such as BusyBox, described as the Swiss army knife of embedded Linux, but it’s important to minimise the use of these functions. Similarly, open ports or redundant web user interfaces should be disabled rather than left in place. Devices that ship with serial ports enabled are particularly vulnerable. This can allow the bootloader, a login prompt, or an unprotected shell to be accessed. Such debug headers may well be present for troubleshooting during the development and programming stages but should be disabled in the end consumer product, an issue often overlooked.
Exploiting buffer overflows is another prime way for the attacker to seize control of the device once it’s on the network but it’s possible to prevent this by using compile time hardening in the form of PIE, NX, ASLR, RELRO, Stack Canaries or Fortify. These are often included in embedded systems but can affect performance and battery life so some experimentation will be required. Consider also whether unsafe functions associated with buffer overflow are used ie strcpy, sprint, and gets, used in binaries on the system.
Keep it current
Is the software up to date? This sounds obvious but lots of devices have Certificate Authority (CA) bundles predating 2012, kernels dating back ten years, old versions of Busybox or even web server connections last accessed in 2005. Old CAs may have already been compromised but are still used by developers because it’s generally easier to leave them in place and simply switch off certificate validation. Unfortunately, this can then expose the device to man in the middle attacks. Check the certificate is correctly signed by a valid certificate authority, check that it matches the server name, and check that it hasn’t expired.
If IoT vendors take the necessary steps to address these common security failings these devices will no longer be so easy to hijack and to subvert. A failure to do so will inevitably lead to yet more behemoth botnets, as well as the emergence of malicious firmware updates and ransomware attacks, which could potentially threaten the viability of the IoT itself.
Interested in hearing industry leaders discuss subjects like this and sharing their IoT use-cases? Attend the IoT Tech Expo World Series events with upcoming shows in Silicon Valley, London and Amsterdam to learn more.
The show is co-located with the AI & Big Data Expo, Cyber Security & Cloud Expo and Blockchain Expo so you can explore the entire ecosystem in one place.
