Earlier this year, we discussed the threat of 'thingbots' - a botnet made of zombie IoT devices. As we’ve seen recently, that threat has become a reality, used in sophisticated DDoS attacks on infosecurity site KrebsOnSecurity and perhaps most famously, DNS provider Dyn, which cut off access to some of the internet’s most trafficked websites.

How Do "Innocent" Things Become Thingbots?

Let’s use the Mirai botnet, the one behind the attacks mentioned above as an example of how thingbots work. Currently made up of about 500,000 compromised IoT devices (e.g. surveillance cameras, routers and digital video recorders [DVRs]) around the world, Mirai is constantly scanning for and targeting devices with commonly used default administrative credentials. Using dictionary attacks, it’s estimated these targeted devices can be compromised, or taken over, by Mirai in about 10 minutes.

The root of the issue is poor authentication practices. Those default passwords are hardcoded into the device during the manufacturing process and as the size of Mirai indicates, are often never updated again, leaving them ripe for exploiting by Mirai or some other type of botnet.

Best Practices for Device Manufacturers to Prevent Botnets

Let’s take a look at some best practices manufactures should consider to help protect their devices from becoming thingbots from the start.

Consider Limiting the Capabilities of Devices - Do They Need Remote Access?

Do these devices actually need to be accessed and administered remotely? Can authentication into the device environment be effectively eliminated? Removing this capability would close the hole Mirai is currently using to access and take over devices.

If You Need Remote Access, Implement Strong Device Authentication

Mirai takes advantage of the worst aspects of device passwords – default passwords are rarely changed and are rarely unique, often reused across a batch of devices. OWASP has some great basic guidance on password policy for IoT device manufacturers that could help prevent this type of attack in the future, but we’d suggest looking beyond the password alone when considering strong authentication methods.

For example, PKI offers multiple benefits for strong device authentication. First, the technology is very difficult, if not technically infeasible to spoof. Using it as part of the authentication process prevents dictionary based authentication attacks, such as those used by Mirai. 

PKI also gives you have the ability to use unique authentication credentials for the authenticating entities (both device and service). At time of device build, it is better to include unique device authentication credentials per device, rather than using shared or common authentication credentials for a range of devices. Even better is to leverage hardware security elements to protect the private keys on devices and prevent the credentials from being stolen or migrated off of the devices themselves.

Consider Strong Authentication for Administrative Users and Services

If you are going to enable login to the device itself for administrative purposes - either for a user or a service, you need to use stronger authentication methods there as well.  One approach also involves using a PKI-based trust model. This is where the devices are built or provisioned with the trust anchor of a Certificate Authority (and potentially other authentication rules, like expected domains of trusted servers), which enables the devices to leverage a stronger authentication method than just username and password for services to run.

Ensuring Only Authorized Software and Firmware Updates

As an additional layer of security, devices also should be configured with logic to verify any software updates that are pushed from a service. This can help prevent untrusted software, like the malware in the Dyn attack, from being installed on the devices. This validation logic will be based on a trust anchor or root, which can be provisioned onto the device during the manufacturing process and will determine which software to trust prior to execution or installation.

There needs to be a way for the device to use its trust roots to identify and validate it. This is another area to apply PKI for stronger security posture and can be achieved by digitally signing code, binding it to the developer’s identity. The digital signature and identity represented in the Digital Certificate would then be verified prior to execution. For example, you can specify that only software from XYZ Company signed with a certain type of certificate will be installed.

PKI Is Just One Piece of the Puzzle

IoT security is a deep and important topic for any device manufacturer to consider. There are many viable approaches toward mitigating attacks like these and I've presented part of the comprehensive security story here. The extent of the solution that is selected depends on the risks and risk mitigation concerns of the organization. 

However, as we're starting to see, there is fairly well established baseline of minimums that IoT providers have responsibility of addressing. Some of these concerns are enumerated in guidance from OWASP, OTA and Underwriters Lab.

GlobalSign is here and interested in helping organization address implementation of these guidance principles from the design stage through large scale production deployment.