The security of the Internet of Things is fundamentally broken. Developers and manufacturers understandably are eager to get their new hi-tech products to market and unfortunately often overlook security, instead operating under the misapprehension that security-by-obscurity in their proprietary systems will do. The problem is that security researchers, and those with more malicious intent, can almost always extract binary code from the device memory via JTAG or similar in-circuit debugging facilities, or find it online in the form of updates, and reverse engineer via one of the many tools readily available.
Furthermore, a lack of security subject matter expertise among hardware-oriented engineers creates major vulnerabilities, compounded by the fact that firmware can too easily be modified; and a lack of logical separation between critical and non-critical components within the device opens up further avenues for attackers.
Some Examples of Compromised IoT Security
There have been quite a few instances of vulnerabilities in IoT -- from tea kettles used in DDoS attacks and unauthorized access of webcams, to the remote takeover of drones to cause havoc. And more recently, security researcher Troy Hunt demonstrated how he could hack the Nissan Leaf using little more than the car’s Vehicle Identification Number. He could then drain the battery through the car’s climate control system accessed through a mobile application.
A very frightening example is Ukraine’s power grid hack. At its core, it involves connected devices used in industrial control and automation (IoT): attackers wrote malicious firmware to replace the legitimate firmware on serial-to-Ethernet converters at more than a dozen substations (the converters are used to process commands sent from the SCADA network to the substation control systems). Taking out the converters prevented operators from sending remote commands to re-open breakers once a blackout occurred.
Who Is Targeting the Internet of Things?
Anyone with an interest in breaking things is likely to try. While admittedly a lot of stories we read about IoT hacks are done by researchers merely wanting to point out the possibilities and gain notoriety, it’s only a matter of time -- if it’s not happening already -- that the bad guys will have a go.
Organized crime for profit, nation/states for unconventional warfare, commercial third parties for espionage are all likely to hack the Internet of Things. Of them all, whitehat researchers are the only ones who disclose their findings.
From remotely taking control of devices, to using IoT devices for catalysts to a DDoS attack and causing havoc, there’s a scary amount of possibilities of what malicious actors could do by commandeering connected devices. IoT is in cars, smart cities, weapons, drones, hospital equipment, connected homes -- all around us. If we don’t start making the necessary steps towards true interoperability and security in these devices, lives could quite literally be at stake.
How Can IoT Security Be Improved?
I advocate three focus areas to make IoT more secure: using open source security software and interoperable open standards; forging a root of trust in hardware to support signed firmware updates and secure boot; and more importantly, security by separation -- i.e. hardware virtualization.
Open Source and Open Security
Security by obscurity simply doesn’t exist. It’s a myth. Instead, we need to look to open source and open security. With thousands of eyeballs on a piece of code rather than tens, we’ve got a much better chance of engineering something more robust. Just think about the unnecessary complexity of mainstream proprietary software -- where new products are built on the foundations of legacy versions -- versus the clean, clear Darwinism of open source. The open source community is 100 percent focused on quality and usability. There are no internal decisions made on feature sets for commercial reasons, politics or other corporate dynamics, in open source it’s all about doing what’s best for the software itself and the end-user community.
What’s more, thanks to the strength, dedication, and sheer size of the open source community, security flaws are routinely fixed within hours of discovery. It’s not uncommon to have a rolling process producing and making available near-real-time updates -- i.e. Linux Debian security model.
It’s In the Silicon
The software in so many embedded devices contains a potentially fatal original sin: it’s not signed. This means that attackers can reverse engineer the code, modify it, reflash the firmware, and reboot to execute arbitrary code -- see Ukraine’s incident above. So what can be done? After all, software on the device needs to be updateable so that vendors can apply security patches.
The answer is to ensure that the system boots up only if the software to execute is cryptographically signed by a trusted entity -- i.e. the vendor. It needs to match on the other side with a public key or certificate which is somehow hard-coded into hardware, so it is virtually irreplaceable. By anchoring this root of trust into the hardware, it becomes extremely difficult to tamper with firmware. A determined attacker might still be able to extract the original firmware via JTAG, for example, reverse engineer and modify it, but it won’t match the public key burned into the hardware, so the first stage of the boot up will fail, and the system will refuse to come to life.
It won’t be an easy feat, but it is possible, and once the root of trust has been established, that initial piece of software will make identity and integrity checks with the next piece in the boot chain and so on until the system is fully and securely operational -- the integrity check will eventually continue at runtime to make sure no modifications are applied after boot.
Security by Separation
Too many embedded systems allow for lateral movement within the hardware, allowing attackers to jump across non-critical and critical subsystems inside until they find a way to exploit what they’re really after. It’s understandable that manufacturers are trying to rationalize, collapsing as many functions as possible within one single piece of hardware -- i.e. board or SoC. But from a software perspective, there’s no reason why these separate functional domains should be visible to each other. It shouldn’t be possible to access an airplane flight control system via its on-board entertainment platform, for example, or a car’s brakes and assisted steering wheel from the car stereo unit.
Let’s make no mistake -- it’s a journey the industry must take if it has any hope of managing the potentially fatal security issues which have broken the Internet of Things.
Art Swift, president of the prpl Foundation
Published under license from ITProPortal.com, a Net Communities Ltd Publication. All rights reserved.
Photo credit: Scott Bedford/Shutterstock
ShareByLinkShareByLink is an open-source file sharing service and application for Windows, Linux and Mac.
