Recently, my partner Howdy wrote a blog post on EE Times describing security best practices for embedded devices. This is an area of great interest. We know from the Snowden documents that the US and other governments have been targeting networking devices such as routers and switches and other embedded systems in preference to attacking PCs.
Attacking network infrastructure devices has advantages for the attacker. Most of these devices do not run any anti-malware, and embedded systems in general are often left unpatched—they run old versions of open source or proprietary operating systems with easily understood vulnerabilities. Often the end user does not monitor them as diligently as desktop and server machines. This is especially true for Internet of Things devices.
Tech moves over time. Attacks that are initially restricted to the realm of esoteric, government-backed spooks become accessible over time to run-of-the-mill cybercriminals.
Take, for example, the Linux.Darlloz worm, which attacks embedded devices and is interesting for a couple of reasons. First, as the article points out, it propagates by exploiting a vulnerability that was patched in May 2012. But the firmware images on many embedded devices are much older than that. The second reason I find it particularly interesting is it targets PHP, a scripting language largely used for web development.
It’s not uncommon to use the same software stack on embedded devices as servers, just scaled down, especially for web services. This approach has the advantage of shortening development time, but it can significantly increase the attack surface of the device. (And it violates several of Howdy’s best practices!)
In this case, we have a general purpose scripting language running in an Apache web server, which offers a huge amount of functionality. Any configuration error in Apache, coding error in the PHP scripts, or outright bug in one or the other (as in this case) allows the attackers an opportunity to exploit the system.
If the embedded device has to implement a bunch of complex web functionality, then perhaps there is no better implementation alternative. But in many cases, the simplest possible solution should be used to ensure the IoT device has the smallest possible attack surface.
The Linux.Darlloz work is hardly the only recent exploit against embedded devices in the press. This summer, Samsung’s Smart TV product line was exploited.
What got the press on the Samsung exploit was the creepy possibility of an attacker surreptitiously controlling the camera on the TV. But it seems to me that we should be more worried about a Trojan that can steal a user’s Skype and other network credentials, poison the local network’s DNS cache, and host malware for the user’s PC to connect to. There is likely to be more opportunity for profit from these types of hacks.
As Howdy mentioned, one important design consideration you should be taking into account is how your system will be upgraded over time.
If your CPU and memory are “just enough” for your present software stack, what will you do when a newer version of the kernel or a software package is required? If you’re going to depend on back-porting new fixes to an old Linux distribution, who is going to do that? Is your OS vendor doing it? Your staff? For how long will they support you? Are they diligent about patching every package you’re using? (Do you even have a precise list of every package you’re using?) What is your sustaining engineering budget for these activities? How will you communicate with customers in the event that your device is exploited?