Embedded devices. Typical security issues

I’m sharing a series of security findings and insights that are typical for an embedded device, in ascending order of severity.

This could be any device, but it’s fairly typical ofLinux-based IoT products.

1. Out-of-date CA bundle – lots of devices have a CA bundle from 2012 or before. This means that many certs are out-of-date and there are some no longer trusted CAs. Developers will switch off cert validation as a result.
2. Device lacks secure storage – the 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.
3. Factory reset not correctly implemented – either configuration (such as user’s SSID/PSK), authentication information (certificates etc.) or data (stored videos) are not deleted or renewed when reset.
4. Encryption implementation issues – a custom protocol used by the device does not implement crypto correctly. Examples – encrypt without MAC, hardcoded IV, weak key generation.
5. System not mimimised – 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.
6. Serial consoles enabled – either raw serial or USB serial is enabled, allowing either the bootloader, a login prompt, or a unprotected shell to be accessed.
7. Wi-Fi connection process exposes SSID/PSK – it’s very common for devices to use a Wi-Fi AP or BLE to allow the app to communicate the user’s SSID/PSK for connection. Often in the plain. Attacker needs proximity physically.
8. Firmware not signed – this allows someone to create malicious firmware and deploy it to devices. Firmware not encrypted – this makes it much easier to examine firmware and find issues.
9. Busybox not minimised – busybox has been built with every single tool possible, providing a rich set of tools for an attacker to use.
10. 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.
11. Compile time hardening not used – PIE/NX/ASLR/RELRO/Fortify haven’t been used. They make exploiting buffer overflows harder.
12. Unsafe functions used – strcpy / sprint / gets are used heavily in binaries found on the system. These are closely associated with buffer overflow-tastic systems.
13. All processes run as root – no principle of least privilege followed. Lots of devices could do this, but don’t. No need to privesc when compromised.
14. 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 delivered by this mechanism.

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.

Once again, the problem is adversarial research has conditioned vendors to ignore these level of findings. They aren’t remote root access, not every device has been compromised. So often, these issues will not be fixed.

This is a real problem. The solution isn’t pen-testing and remediation. The solution is secure development practices. All of these are known.