DDoS, the IoT and Nucleus

First off, I lay no claim to be an Internet security expert. Maybe because of this, I was quite shocked by the scale and effect of the major DDoS attack that hit the news recently. This attack restricted access to some major websites for Internet users on both sides of the Atlantic. The really interesting aspect of this incident is that the attack was implemented by hijacking large numbers IoT devices …

Once upon a time, embedded systems were very secure and could not be hacked unless you could gain physical access to the device, because the code was stored in ROM of some kind. Such devices tended to execute the code out of that ROM and only had enough RAM to hold data. There was no possibility of downloading malware to such devices.

Nowadays, most devices have flash instead of ROM and, because access is slow, the code is copied into RAM for execution. Flash is seen as convenient, as field upgrades may be sent via the Internet. This means that there are two key opportunities to hackers:

1. They can persuade the device to put the malware in RAM and execute it.
2. They can send an “upgrade” to be flashed, which is actually malware.

The safest way to protect an embedded device is to not design in any connectivity. That is OK in some cases, but, obviously, for an IoT device this makes no sense. So how can an embedded developer mitigate these possible attacks?

Option (1) is a classic mechanism whereby virus code can be introduced into a system and has been common on desktop systems for many years. Typical approaches are to use buffer over-runs to insert the code where it will be executed. An embedded developer can use a number of strategies to protect their code from such violation. Initially, the possibility of buffer over-runs should be removed by careful code design and run time data checking – basically defensive coding. Another approach is to ensure that the RAM used to store the code and that used to contain data are separated; this may be achieved straightforwardly using good embedded development tools. If a memory management unit [MMU] is available, memory may be protected by rendering it invisible or read-only, as required. This is somewhat complex to achieve, but using an RTOS, such as Nucleus, which has a light-weight process model option, makes it simpler.

Option (2) is ultimately more dangerous, as power cycling the device does not expunge the malware, but ought to be simpler to avoid. The key thing is to use secure protocols which are likely to be available with any commercial RTOS solution. It is important to ensure that all protocols are certified for full compliance with published standards.

In the meantime, I need some advice. I have an IoT device that we use to remotely switch on an electric blanket. The app tells me that a firmware upgrade is available. Should I trust it? How can I be sure that the “upgrade” is not malware? Answers please by email, comment or via social media. Thank you.