Building an Internet of Things (IoT) product that is secure and maintainable both today and into the future takes time and expertise, plus a grasp on where the ecosystem has been and where it is going.
Looking back at some of the biggest failures in the IoT space over the last few years, it’s quite easy to come up with a short list of low-hanging fruit for device developers and manufacturers. Using history as our guide, here are what I consider the top 3 ways to ensure IoT devices can be more secure.
Before that, a quick digression. Let’s quickly address one of the biggest security misconceptions on the web. Just because you don’t have a hostname for your IoT device – in other words, you have to type in the numerical IP address of the device to access it – it doesn’t mean it is safely hidden from the bad guys on the web. In fact, there’s a plethora of scripts and programs built for simply scanning the entire range of valid IP addresses for common devices and vulnerable systems (often time performed by a network of other compromised systems, ironically).
Connect any device to the web and it will be tested in some way in a matter of seconds. With that out of the way, here’s some easy ways IoT products can be made more secure.
Don’t Use Common Default Passwords
Most of the compromised IoT devices out there were vulnerable because they had hard-coded, default passwords. They had a common admin password assigned for telnet access or a web dashboard and when they were actually modifiable, users or installers wouldn’t know enough to change them.
This left a ton of devices out on the web that anyone could log into if they had prior knowledge of the default passwords. And that’s what led to the creation of one the largest botnets ever assembled in the fall of 2016, called Mirai, which led to one of the largest Denial of Service (DoS) attacks the internet has ever seen.
Instead, device manufacturers can, for example, print a random password on the bottom of the device. This is exactly what wireless router manufacturers have started to do. With this approach every devices comes out of the factory with different login credentials and if you don’t have physical access to the devices, you can’t know the default. This isn’t the perfect approach, but it does close one more door to would-be hackers and botnet “recruiters.”
Bar the Backdoors and Close all Ports
Many devices used in IoT botnets had open telnet ports. This insecure service allowed the manufacturers to remotely login to these devices for support, maintenance or to make changes to the underlying operating system. The biggest recommendation we’d make to other IoT manufacturers is: if at all possible, don’t open incoming ports.
It’s far better to instead instantiate outgoing TCP/IP connections to trusted hosts. This step, too, would have put a stop to the Mirai botnet as it used open telnet and SSH ports to infect its hosts.
Which leads to the question, what do you do if you need a path for remote access or maintenance? One solution is to use a feature of SSH known as reverse tunneling. Using existing messaging connections (like MQTT, for instance) you can instruct your device to “phone home” when needed, making a connection to a control server and opening a reverse tunnel.
This reverse tunnel can be used to SSH into the IoT device. With this sort of approach, hackers who come knocking on your device’s virtual doors never get an answer. As a bonus, this approach also allows you to solve the problem of connecting with devices that customers have securely placed behind network address translation (NAT) without resorting to the oft-unsupported Universal Plug and Play (UPnP) which allows devices open incoming ports through NAT devices.
Build Secure Web Applications
There is a not-so-small number of IoT devices that have a web server built in. And it makes the device a great standalone platform: The user can type in the IP address of their printer or security camera and control the device or view its status from any browser without a need for manufacturers to provide ongoing cloud services.
However, IoT device builders don’t necessarily know how to build secure web applications, which as an art unto itself. For starters, the Open Web Application Security Project (OWASP) has a list of the top-10 most common web application vulnerabilities, a great asset for any would-be web developer.
In March of 2017, Dahua, a large manufacturer of security cameras and digital video recorders (DVRs) issued a security patch for a number of their devices to fix an issue with the embedded web server on their devices. The issue allowed a hacker to use a carefully crafted URL to extract all the usernames and passwords for the device. This vulnerability essentially opened up the functionality of each device to anyone connected to the internet.
Even if you’ve mastered the art of secure web applications, there’s still the potential for future, yet-unknown vulnerabilities, sometimes present in the software dependencies, daemons or frameworks that have been chosen. With this in mind, it’s critical to have a system in place to make swift updates to web apps (not to mention any of the software on an IoT device) when the need arises. With proper attention paid during the development phase, IoT devices can be made to look for and receive software updates so that future bugs can efficiently be patched and devices can be secure over their full lifecycle.
Written by Eric Bigoness, Chief IoT Engineer at DornerWorks
New Episode
Latest IoT News
