The Internet of scary things
The risks associated with insecure IoT devices are serious and come in many forms. Compromised devices can be used for unauthorized information retrieval, for example. The paparazzi of the world will certainly appreciate the opportunity to look through a celebrity's camera, but stalkers, blackmailers, and nosy neighbors are also a threat. There's the threat of mass data collection that is not specifically targeted at anybody. Unauthorized control of devices is an obvious problem; pranksters have fun playing with lighting systems now, but the problem gets more severe when your front door is involved. With control systems and medical devices, the possibility of loss of life is real. It would not be funny if all the traffic lights in a city turned green at once, he said.
When identical devices are manufactured and sold in huge quantities, the
possibility for mass takeover of those devices is real. The Mirai botnet is
just one example of what can happen. These networks can be used for
denial-of-service attacks, spamming, bitcoin mining, extortion, and more.
![[Christopher
Biggs]](https://static.lwn.net/images/conf/2017/lca/ChristopherBiggs-sm.jpg "Christopher Biggs")
There is also the problem of "plain old network intrusion". Networks are
set up to deal with threats from the outside; IoT devices bring that threat
to the inside. Firewalls are
not always effective at preventing devices from tunneling out of the local
network. The monsters, he said, are in the room with us.
For extra fun, these devices are finicky to set up, difficult to manage, and generally without any provision for updates. Their security is criminally bad, to the point that he has sometimes wondered if they are deliberately malicious. Hanlon's razor suggests that the state of IoT devices can be easily attributed to stupidity instead. Laziness is also part of the problem: devices ship with debug access enabled, with hard-coded passwords, and more. All of this failure is far from new: the Morris worm in 1988 used a vector quite similar to that employed by the Mirai botnet.
Part of the problem can also be attributed to fragmentation. Each device has its own cloud service, with different apps for each device. There are lots of little walled gardens out there. This problem could be fixed within the industry and, he said, there is actually a glimmer of hope that things are moving in that direction.
Why, he asked, does everything suck? Sturgeon's law is sufficient to explain much of the problem on its own, but there is more to it than that. IoT devices are created in short product cycles using software that is not necessarily up to the task — the industry is simply not sufficiently mature yet. Fragmentation is a big problem, with each vendor wanting to lock in customers. And security is simply hard. It's easy enough to scan for vulnerable devices that nobody can rely on obscurity as a way of staying safe. A test involving putting a Mirai-vulnerable device onto the net saw the first attack arrive within 70 seconds. The threat surface is too large, especially when vendors are lazy and don't strip out unneeded software; this leads him to believe that, for many of these devices, there may be better operating systems out there than Linux. Finally, the fact that users may not even notice a compromise factors into the problem; if the buyer of a device doesn't care, the vendor won't care either.
Staying safe
The nature of IoT devices is thus pretty clear. What is less clear is how to protect oneself from the threats posed by these devices without just tossing them all into the ocean. To that end, Biggs offered a few pieces of advice for worried IoT users.
The first suggestion is to simply accept that some IoT devices will not be fit for purpose. It may be a pain to return such items, but that should be done anyway in the hope of pushing the market toward better security. It is a good idea to regularly look for unexpected devices on one's WiFi network. LG has recently announced that it will be including WiFi in every device it sells; soon one might plug in a new toaster and not realize that it has just jumped onto the local net — or established a new, open WiFi network of its own. Running port scans on devices to see what services are running also makes sense.
Do not keep devices that ask you to do unacceptable things like running untrusted software. Users will also typically have better luck if they stick to devices running on one of the "big 3" frameworks managed by Apple, Google, and Amazon. These devices should have a common management interface, minimizing the number of holes being poked in the firewall. Support for open protocols should be demanded, he said; in general, interoperability demonstrates a certain level of competence.
Even better, of course, is a device that allows the firmware to be flashed with something of the owner's choosing. He cited the Sonoff series of power-control devices as being good in this regard. Isolating devices from the network and building your own control system can prevent a lot of mischief; projects like Homebridge and Node-RED can be helpful in this regard. Checking reviews can be helpful. In general, he said, positive reviews are meaningless, but negative reviews are often valid.
Once a device has been purchased, it should be deployed safely. IoT devices should, in general, be put on their own WiFi network whenever possible. OpenWRT makes it easy to create a separate network with its own filters. Even on a poor router with factory firmware, there is usually a guest network that can be used for IoT devices. Universal plug-and-play (UPnP) can be used to automatically poke holes in the firewall; it should be turned off if possible.
One should simply plan for breaches and think about what will happen when a device goes rogue. The network used for IoT devices should have a strict deny-by-default policy. Imposing rate limiting as well can help to limit the damage a device can do. Installed devices should be checked up on occasionally; if they show a traffic spike, something unwanted may be happening.
And, again, setting up your own "cloud" can offer some advantages; this is most easily done with devices that use one of the big frameworks. Homebridge can be used to make older devices available on the Apple control network, for example. Users of Amazon's Alexa protocol may want to look into Node-RED, which can bring hundreds of devices into the Alexa sphere. Surveillance cameras, in particular, should be managed with ZoneMinder or Motion; these can replace the higher-level functions of the firmware in the camera itself, reducing the camera to a dumb peripheral.
Building your own
What if, instead, you want to develop your own IoT device? The best advice is "get someone else to do the hard parts". One choice is Apple's HomeKit API; getting approval for new devices is hard, but success means that your product is better than most. If you're not going to get official approval, consider creating a Homebridge module to serve as a backdoor into the Apple protocol. In general, Apple has taken the approach of minimizing the intelligence in the devices themselves, allowing that logic to be placed in the higher-level control software.
Working with Amazon is easier, in that Amazon doesn't require certification, but the hub hardware is only available in the US and UK currently. He is impressed with the level of security built into these products. They are built on the MQTT protocol, making it relatively easy to make your own devices that can talk to Amazon's cloud services.
In the open-source world, there has been a lot of consolidation as a number of projects have joined together into the Open Connectivity Foundation. This group is designing a set of device profiles that describe the capabilities of individual devices and let devices discover each other. This builds on "the good parts" of UPnP and the Service Location Protocol.
IoT devices should not rely on a mobile app for setup. People installing thousands of devices in a new building will thank you. Devices should support open protocols like MQTT; they are the glue that holds the IoT together. Speaking MQTT allows interoperation with a number of home-automation frameworks. MQTT can be thought of as a sort of IRC for robots, he said.
Do not forget long-term support. Everybody will lose the instructions, so devices should be self-documenting. The device should have a well-defined support life, with updates provided regularly. Finally, IoT developers need to recognize that these devices are not just miniaturized Unix PCs; they should be carefully stripped down to be sure they are not running any software that is not absolutely necessary.
Things may be getting better
There is, he said, some light at the end of the tunnel; various groups are realizing that they need to get serious about this problem. BITAG is a group founded by Google, Intel, Microsoft, and others to put together a set of recommendations on best practices. Its advice can be boiled down to "don't be lazy and stupid". The Open Connectivity Foundation is also doing good work. Bruce Schneier has been advocating for more regulation, but Biggs said that could go badly wrong. He could support regulations analogous to radio emissions testing, though.
Recently, Google shipped a developer's preview of its Android Things toolkit. It's not ready for prime time; its device profile support is limited currently. But the technology looks promising. He likes the standard camera interface in Apple's HomeKit, which allows bypassing most of the bundled firmware in such devices. Amazon's Alexa is looking good, though, he said, there is some concern about how much it listens to. The Open Connectivity Foundation has a reference framework implementation called IoTivity. It is, he said, one to watch, though he expressed concerns about the use of C as its implementation language.
One other framework worth considering is resin.io. It's open source, and has some good tools. It is based on Linux and Docker; the project can handle the containerization of an IoT application and send it out to the devices. These devices maintain a connection back to the cloud allowing for remote management and updates. The number of systems supported is relatively small at the moment, though. The project's focus is more in enterprise devices than consumer devices, but it is still worth checking out.
One app that is useful for consumers is Fing; it can be used to scan your local network. Fing is working on a small hardware device that can sit on, and monitor, a network; it will serve as a sort of intrusion detection system for networks without their own administrator. [Editor's note: potential Fing users may want to look at its privacy policy before installing the app.]
What's missing? We need to move beyond allowing devices to connect to anything they want; device profiles should be extended to describe their connectivity requirements. There is also a need to make vulnerability alerting and patch distribution work. He suspects that few members of his family are going to subscribe to Bugtraq for that purpose. Frameworks like resin.io are good for patch distribution, but it's still a centralized service; what is really needed is a common standard.
In summary, things are awful, but that's not unexpected in a "baby industry" like IoT. If buyers choose and deploy devices with care, and if builders focus on doing the job right, the worst should be avoidable. The job will get easier over the next year as the frameworks mature.
The video of this talk is available on YouTube.
[Your editor would like to thank linux.conf.au and the Linux Foundation
for assisting with his travel to the event.]
| Index entries for this article | |
|---|---|
| Security | Internet of Things (IoT) |
| Conference | linux.conf.au/2017 |