The most common IoT device security failings of 2017

2017 was a very busy year of IoT security testing at PTP. Time after time we found the same serious issues, so here’s a summary of the most common ones.

It’s hard to sort these in order of severity, as the security impact depends on so many different factors, particularly so the function of the device.

However, here are a series of security flaws we keep finding that turn simple security problems in to device pwnage:

All processes run as root

No principle of least privilege followed. Lots of devices could offer more granular permissions, but don’t bother.

This means there is no need to elevate privilege when the device is compromised. A simple compromise leads directly to root.

Device lacks secure storage

The System on Chip (SoC) used by the device has no provision to securely store keys or confidential material. An attacker with physical access can recover keys, certificates, hashes, and passwords.

TPM or similar should be used to safely store sensitive information. Choose a SoC without this and you may end up having to recall your IoT product.

WiFi connection process exposes SSID/PSK

It’s very common for devices to use a WiFi AP or BLE to allow the app to provide the user’s SSID/PSK for connection, often in plain text. Obviously, the attacker needs proximity physically.

Proximity is not a sufficient layer of security by itself to protect key exchange or similar. Do you trust your neighbours or the guy on a street outside?

No secure boot

Without this, the SoC cannot check the integrity of the bootloader, and the bootloader can’t check the integrity of the firmware. This can allow an attacker to modify firmware of the device, either by subverting controls on your firmware update process, or physical access to devices.

It’s also worthwhile reviewing your bootloader code to ensure it is secure – it has very low level access to the system.

Busybox not minimised

Busybox has been built with every single tool possible, providing a rich set of tools for an attacker to use.

This just makes life easier for the attacker; a Busybox build that has minimal functionality will slow the attacker down.

System not minimised

The system is running services and processes that aren’t used. It’s common to find a web UI running on a system, but undocumented and useless to consumers.

This increases the attack surface significantly, often providing a trivial vector to compromise the device through the embedded web server.

Compile time hardening not used

PIE/NX/ASLR/RELRO/Stack Canaries/Fortify haven’t been used. They make exploiting buffer overflows harder, which is a big concern when you start talking to the network.

Many of these come at low-cost on embedded systems which spend a lot of their time idle, but you will need to experiment to ensure performance or battery life is not impacted.

Unsafe functions used

strcpy/sprintf/gets are used heavily in binaries found on the system. These are closely associated with buffer overflow-tastic systems.

Buffer overflows are sometimes hard to convert into working exploits, especially if compile-time hardening is used, but you can still be left with trivially exploitable denial-of-service issues.

Out-of-date CA bundle

Lots of devices have a certificate authority bundles from 2012 or before. This means that many certs are out-of-date, some are from CAs that have been compromised and are no longer trusted.

Rather than solve the root problem, overworked developers will simply switch off certificate validation, exposing the device to MITM.

Out of date kernel

The kernel found on many devices dates back many years, with some having a 2007 vintage. There are often exploitable privilege escalation vulnerabilities and missing security functionality.

However, the downstream vendor providing your SDK/toolchain may not have anything more up-to-date.

Other out of date software​

Busybox 1.19 and below – dating from 2012 and before – is often found on these systems.

Also web servers that haven’t been touched since 2005.

Leaving software out-of-date and with known vulnerabilities can seriously impact the security of your system.

Encryption implementation issues

A custom protocol used by the device does not implement crypto correctly. Examples include encryption without MAC, hardcoded IV and weak key generation.

It can also be very dangerous letting developers roll their own crypto: stick with peer reviewed, proven algorithms.

Firmware not signed

This allows someone to create malicious firmware and deploy it to devices. Sign firmware and don’t forget to validate the signature during updates!

Firmware is often found without encryption – this makes it much easier to examine firmware and find security issues. Encryption adds a layer of protection.

Device does not validate SSL certificates

The HTTPS communications used by the device can be man-in-the-middled by an attacker. Can lead to serious compromise, especially if firmware updates are delivered by this mechanism.

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.

Serial consoles enabled

Either raw serial or USB serial is enabled, allowing either the bootloader, a login prompt, or an unprotected shell to be accessed.

Debug headers are present for troubleshooting during development and programming during manufacture. They shouldn’t be enabled in production consumer product.

Root user allowed to login

The root user either has no password, or a hardcoded password. Another vulnerability will allow them to login and use the system.

If you’ve left telnet running mistakenly in your production firmware, having a root user with a blank password is clearly a bad idea!

Conclusion

The device and system can’t be immediately compromised. But in the event of another vulnerability being found, there is little stopping an attacker from totally owning the device.