IoT: over before it’s truly begun?

The Internet of Things (IoT) has the power to transform lives, making people more productive at work and happier and safer at home. But it’s also developing at such a rate that it threatens to outstrip our ability to adequately secure it. A large component in any IoT system is software; yet, a piece of software that doesn’t contain mistakes has never been written – after all, we’re only human. But with non-IoT security experts designing and building connected systems, the risks grow ever greater.

 

There are some common challenges that plague IoT that need to be addressed in order for the industry to truly thrive and keep users safe:

 

1)      Proprietary software

A huge proportion of IoT security flaws are discovered thanks in part to reverse engineering of proprietary software, mostly done in the name of security research.  But if security researchers can do this, then the bad guys, in theory, can too. In the past, too many programmers have relied on ‘security by obscurity,’ hoping that their ‘secret’ proprietary systems would be beyond the reach of most hackers.

 

This simply won’t do today. Firmware binary code is usually available online if you know where to look. If it is not, hardware debugging tools such as JTAG can be used to extract a copy of the software from the device itself. And interactive disassemblers like IDA can generate assembly language source code from machine-executable code. In combination with other tools and techniques, it is becoming easier than ever to reverse engineer a binary image, work out what it does, where its vulnerabilities are and how to exploit them.

 

In short, over and over again closed proprietary software has proven to be simply unfit for purpose. Compared to mainstream open source software it represents the path of least resistance for a determined and sufficiently resourced attacker.

 

2)      Network Connectivity

The most dangerous Achilles heel of IoT devices is their connectivity – whether to the public facing internet or with other networked devices. It gives attackers who have found a weakness in the code a means to hack their victims remotely. On an unprecedented scale. Automation means an almost limitless number of systems can be hacked simultaneously.

 

The situation is compounded because many of the engineers tasked with designing and building IoT systems are not experts in network protocols and even less in network security. They may know how to put together hardware components, but implementing TCP/IP protocols is a rarefied discipline which requires expert knowledge and extensive debug and testing. It’s unfair to expect mechanical and electrical engineers to shoulder this burden and stay up-to-date with the latest secure development best practices. But their lack of subject matter expertise is leaving systems wide open to attack allowing hackers to infiltrate routes left inexplicably open and unauthenticated.

 

3)      Broken firmware updates

If it’s not surprising enough how many IoT and embedded devices don’t have a means to be updated, more are fatally flawed in the way updates are delivered. Though it is right that systems are designed so that their firmware can be updated in case flaws are found, it should not be in a way that could allow just anyone to do this.

 

A technique that can be used is exploiting this weakness to modify chip firmware and reflash the image, allowing threat actors to reboot and execute arbitrary code. A simple analogy is installing the best alarm system money can buy to protect your house, but a robber coming along and merely replacing it with their own. What’s the point of having one? A similar issue has enabled hackers to run a malicious backdoor on various Cisco router models – by inserting an implant the same size as the legitimate Cisco router image.

 

The issue with this kind of attack is that it gives the hackers complete control of the device and it is persistent – it can’t be undone via a system reboot, for example. And it gives them privileged access to an affected device. In the case of incidents targeting network router and home gateways this means an attacker gets to see and control all the traffic flowing in and out of the corporate or home network.

 

4)      Systems promiscuity

A strategy used by cyber criminals to attack data centres is to exploit the lack of the internal security controls which limit lateral movement inside targeted systems. They gain an initial foothold into an endpoint via malware download, made possible by a spearphishing email or by simply cracking or stealing user credentials. Then they move around laterally inside the network, escalating privileges until they find the real prize – typically a database full of sensitive IP or customer information.

We can see this method used again when Troy Hunt recently hacked the Nissan Leaf through its air conditioning system to gain control of the entire vehicle.

 

Separation is one of the fundamental principles of security, so it’s not only dispiriting to see it ignored in so many cases when it comes to IoT-related systems, it’s downright dangerous.

As the Internet of Things becomes an ever larger part of everyday life, it has found its way into an increasing number of the systems and platforms we take for granted today. These systems control airplanes, automobiles, drug pumps and even rifles.

 

We must act now to lock down the risks that come from software vulnerabilities.  There are three main areas of focus needed to do this:

 

The core requirement is a trusted operating environment enabled via a secure boot process that is impervious to attack. This requires a root of trust forged in hardware, which establishes a chain of trust for all subsystems.

 

Secondly, security by separation is a classic, time-tested approach to protecting computer systems and the data contained therein, especially in embedded systems that can retain their security attributes even when connected to open networks. It is based on the use of logical separation created by hardware-enforced virtualisation, para-virtualisation, hybrid virtualisation and other methods.

 

Thirdly, developers and manufacturers need to enforce secure development and testing. Developers must provide an infrastructure that enables secure debug during product development and testing. Rather than allowing users to see an entire system while conducting hardware debug, a secure system to maintain the separation of assets is needed.

 

The model described above is obviously an ideal – the “promised land” of hardware security. But in practical terms, not everyone is going to be able to get there straightaway. Chip support for the hardware-assisted virtualisation is not yet widespread. But a good intermediate step would be to use Linux containers, which will enable the running of multiple isolated applications from the one kernel. Secure elements and root of trust might not be available in most hardware today, but this should not prevent security-conscious manufacturers from encrypting and signing their firmware and from making security patches available.

 

Let’s be in no doubt though – it’s a journey the industry must take as a whole if it’s going to manage the potentially fatal security issues which have broken the Internet of Things and could limit its potential before it’s even truly begun.