Friday’s hack and DDoS attack on Dyn that brought down portions of the Internet within the US should not be much of a surprise to the cyber security community. For years, manufacturers have developed and sold IoT devices like IP Security Cameras or IP-connected DVR solutions that have baked-in login credentials. Often these credentials are installed for developer testing and left in by accident. However, sometimes they are left in on purpose, usually to enable remote debugging or, possibly, a backdoor. Regardless of why, now everyone knows that these devices have a major vulnerability in their firmware (the built-in software that makes them function), and it must be addressed.
How hard is it to hack these IoT devices? It’s relatively easy, actually, as many have a single, non-unique username and password built into their software. Once a hacker discovers that username and password he or she can take over every single one of those devices everywhere in the world. Imagine if some maker of electronic car keys, those wireless fobs we use to open and start our cars, created a master key that could open and start any and all cars (unfortunately an example with some element of truth but that is for another blog)? The sequel to Gone in 60 Secondswould be a very, very short film.
Many Consumer IoT Devices Cannot be Secured and Once Compromised are Forever Hacked
So why haven’t these known vulnerabilities been fixed? Often it is because they cannot be. Many of these devices are already in the market and do not have the ability to update their firmware to a secure version automatically. Each user would need to login to the device and tell it to update. When was the last time someone you know who is non-technical updated their WiFi router drivers on their own? There may not even be an online method to update these devices; the user may have to download the firmware and directly load it into the device, either by a local web app or even with a USB! Even worse, once a system is hacked, it is possible that the attacker could turn off any auto-update feature, removing any option the device may have had to prevent that malware from taking hold.
IoT Devices need to be able to Phone Home for Authenticated Security Updates
There is some possible good news. Methods exist to mitigate this kind of attack. The first and foremost approach is for IoT device manufacturers to enable these devices to update their firmware securely. These devices need to “phone home” and pull down patches and bug fixes. This is how a manufacturer could fix the current bug in Friday’s news. However, simply sending updates alone are not sufficient. Those updates have to be secure and authenticated. The device needs to know that the update is coming from a valid source and not an attacker. Something we hope the automotive industry, now updating cars online, is thinking about. These updates must be signed with a digital signature, a known method for authenticating a party online, that the device can validate. Manufacturers should also consider encrypting their updates to prevent leakage of any important information that may live in the updates.
Another tool that should be considered is a “secure boot” mechanism. When the device loads its firmware, (boots), it can validate that the firmware (and associated settings) have not been tampered with by referencing a root of trust. This can involve digital signatures, message authentication codes, cryptographic hashes, and other encryption techniques. Together these methods ensure that a device cannot be tampered with through its firmware.
Of course, none of these methods completely protect against an IoT device manufacturer who puts a fixed set of credentials into a device. It only enables the manufacturer to correct its mistake after the fact. Hopefully, by that time not too much damage has been done.
Want to learn about our security solutions for constrained devices? Click here or the button below to register for our webinar, “Jump-start Your IoT Security Project with the Latest Tools in Authentication & Data Protection.”