When developing its security guidelines and checklists for consumer IoT and similar devices, the IoT Security Foundation’s working groups tested their recommendations against what is known about real-world hacks and attacks.
Formed late last year, the IoT Security Foundation (IoTSF) moved quickly. It put together its first set of guidelines and checklists for secure-product development in less than 12 months. The organization expects to update them over time and is looking for feedback. But rather than develop guidelines that seem to have little real-world relevance, the working groups looked at hacks that have occurred to make sure the guidelines are workable and useful.
Richard Marshall, managing consultant at Xitex, explained at the organisation’s recent conference in London, UK: “When looking at developing the requirements, we asked ourselves: ‘Would any of those requirements have done anything to stop breaches that have happened?'”
Marshall said the group knew they had to get down to basics: “IoT has a broad reach. Many organisations getting involved with IoT haven’t made a connected device before. Now companies have to explain to the media the vulnerability in their connected product. But it’s slightly scary that things like default passwords are still an issue as recent attacks have demonstrated.
Ready for audit
“One of the first things we understood was the need for clear and auditable requirements,” Marshall added. “As auditability is a requirement we provide a questionnaire as part of the framework.
“Would it have any impact?” Marshall asked. He took as his first worked example the botnet of IoT devices formed by a group using a derivative of the Mirai malware. “It’s probably first major industrial bot attack on the IoT. The malware scans a lot of devices. If they have default passwords it will log in. It then updates the firmware for the hacker to take over the device and then make connection back to command-and-control server so it can form part of a botnet.”
Marshall pointed to several requirements that should have slowed Mirai down dramatically if not stop it entirely. The worm spread so rapidly because manufacturers baked the same default password into all their devices.
“One of our first requirements [184.108.40.206]: default passwords are unique to a device,” Marshall said. Not only that OEM or other default accounts should be capable of being disabled by the user [220.127.116.11]. “I want the ability to overwrite the hard coding,” Marshall added.
“If there is a default password, on installation it gets changed [18.104.22.168]. And we made it a requirement that you prevent unauthorised software being loaded onto the device, possibly some form of digital signature to identify authorised updates [22.214.171.124],” Marshall explained.
The next example Marshall used was the iKettle. “Ken Munro discovered this about a year ago. It was a fairly straightforward attack. Through the default SSID on the kettle someone can retrieve the default password of your network.”
The attack used by Munro was to have the iKettle attach to his own WiFi router by giving it an SSID that is the same as the one to which it normally connects. The kettle does not attempt to check the access point’s credentials. He then used
telnet with its default password of six zeroes to dump out the key for the kettle owner’s WiFi network. So, not only was the way it handled WiFi SSID’s an issue so was the password – a common, factory-set default. Back to requirement 126.96.36.199.
“When you look at carriers in the UK, BT provides a good example of what to do. There is a sticker on the bottom of the router that has the default [individually generated] password. Other manufacturers please copy,” Marshall said.
Other requirements that, if followed, should have prevented Munro’s hack were 188.8.131.52, 184.108.40.206, and 220.127.116.11 – which cover the removal of inactive OS accounts, the changing of passkeys after initial pairing and the secure storage of network keys, respectively.
Although BT provides a good example of how to deal with some of these issues and the working group acknowledge the work performed by telcos to build security into their products – perhaps most successfully in mobile handsets – they also provide a ready source of easy-to-exploit vulnerabilities. Marshall pointed out how the Mirai botnet attack used unauthenticated ports – left exposed because they were traditionally only seen on the local-area network side.
The TR-069 and TR-064 management ports were, Marshall said, “intended for managing routers on the local network. You can imagine there isn’t a great deal of authentication. But on a number of routers TR-064 protocol is now exposed on the wide-area network side. Mirai does a straightforward unauthenticated connection and exploits vulnerabilities based on the time server. It then deletes itself from filesystem and helpfully closes the vulnerable port. After that it announces itself as part of the botnet having found the command-and-control servers. It then scans for other vulnerable routers.”
To the now familiar requirements for password management and authentication, Marshall cited requirement 18.104.22.168, which calls for remote software upgrades to be digitally signed.
But even digital certificates have presented hackers with mechanisms to implement attacks. Jeff Day, a senior security consultant at BT, pointed to research carried out by SECconsult. The company found in the firmware for devices made by a variety of vendors lurks a HTTPS certificate for “Daniel”. Close to half a million devices on the internet share this one certificate. It originally came from a software development kit, hence its presence in not just one vendor’s product but several.
Marshall said the IoT Security Compliance Framework fits together with a set of guidelines for consumer product development. In its current version 1.0, the framework shows which requirements fit that market – enterprise requirements will be determined in a later release.
“A separate working group let by Jeff Day developed best-practice guidelines to sit alongside the framework. If you come across a requirement you don’t understand its rationale this is what the best practice guideline document is for,” Marshall said.
Day added: “As examples occurred in the process we ran them past the best practice guidelines to see what they would have happened. Hand on heart we believe it would not have happened or it would have made the attacker’s job that much harder.
“When I looked for cases that involved connected consumer products, every single time the attack tried to take advantage of weak password handling. I looked through a fair few of these. Every single one was initiated through poor port or password handling. You could mitigate so many problems just by doing good key or password handling.”
Day said it’s important to treat security as a core part of product development and not to simply perform a checklisting exercise once features have been defined and implemented. In some cases, it may simply not be possible to follow the guidelines. A device that has no user interface presents problems when it comes to password and credential management.
“It may be that you can’t address all these issues,” Day said. “With a very constrained device, there may be security negotiations that you can’t do. Well, fine: if that’s the level your product is operates at. But our recommendation is that should still follow through this guide. If there is something you can’t do in your own security documentation, you document it: ‘We haven’t addressed this and this is why we have for good business reasons’. If that is a limitation based on its capability then people can decide for themselves how to handle it.”
It may be that an ultra simple device that collect environmental data and uploads it to a gateway has no practical confidentiality issues because the data is not associated with a person until the gateway processes it. So the bulk of the onus of security falls on the gateway and its important role in the overall supply chain. For this and similar reasons, the IoTSF leaders talk about building “a supply chain of trust”.
Day said: “If you follow [the guidelines document] it won’t give you perfect security. Perfect security does not exist. But we like to think if you follow this guide with our checklist as thoroughly as you reasonably can, and you keep people down the supply chain reasonably informed, you can hold your heads up. And you get a good reputation,” Day concluded.