Linux is part of the IT security problem, dev tells Linux conference

Does that 'thing' really need to run Linux, given alternatives have smaller attack surfaces?

The Mirai botnet? Just the “tip of the iceberg” is how security bods at this week's linux.conf.au see the Internet of Things.

Presenting to the Security and Privacy miniconf at linux.conf.au, embedded systems developer and consultant Christopher Biggs pointed out that Mirai's focus on building a big DDoS cannon drew attention away from the other risks posed by insecure cameras and digital video recorders.

IoT offers a full suite of risks, he said: a perpetrator could just as easily use badly-secured cameras or records to stalk a victim, or download videos for blackmail. There's a huge potential for mass data collection by someone driving around “sniffing for vulnerable devices”, and there's plenty of scope for unauthorised control.

“It might be briefly funny if someone works out subvert autonomous computers into delivering free groceries from Woolworths or free petrol from BP,” Biggs said, but how would you react if your lights started flashing every 200 milliseconds unless you paid Bitcoin to your attacker?

And firewalls fall far short of offering protection, he said, for obvious reasons: they're oriented to block traffic from the outside, and if you haven't turned off UPnP, Things expect to open whatever ports they wish.

As another presenter, Tom Eastman, told the conference: “You're inviting a device into your home or office that you have absolutely no control over. You don't know what threats it enables, and you have no way of updating the software on it.”

Biggs added that “The monsters are inside the room. If IoT devices use cloud services, there's the risk of that service being compromised … many devices on the market are finicky to install, have low-quality user interfaces, and no provision for maintenance.”

The enemy is “us”

Biggs therefore feels that the enemy is IoT developers who don't think of how real-world users behave when designing connected things, and create devices without upgrade paths.

“Most of the time there's no useful brand identification on the device. If there's a bug, you probably won't know. If you do know, there's probably no patch. And if you complain, there's probably no-one who cares.”

“We as geeks owe it to our friends to design things they can use,” he said.

Biggs emphasised the relative immaturity of the IoT market, something that's clearly evident from his self-defence advice, which is clearly more geek-ready than consumer-ready at this stage.

Too often, he said, there's too much in the Linux stack that device makers build: “It's easy to install a complete Linux distribution on the device and not bother to reduce the threat surface. In fact, sometimes it's arguable that there better choices than Linux for an OS for IoT's simple applications.”

“There's no incentive to do better. If the buyer doesn't care, the vendor won't care.”

But defence is hard, as Biggs' “selecting IoT devices” list illustrates:

• Look for unexpected devices or open Wi-Fi networks you don't recognise;

• When you see an unexpected device, run a port scan to see what services it's offering;

• Don't accept devices that ask you to do unacceptable things, such as running untrusted software;

• Look for devices that support standard protocols or a well-documented API.

Devices that support a well-known framework from the likes of Apple, Google or Amazon (or the open source HomeKit connector, HomeBridge), are only going to open one hole in your firewall, he added.

However, while such things may indicate devices that are a cut above the rubbish, it also demands knowledge that's a cut above the consumer.

The same could be said for his advice that an IoT buyer should create a separate network for those devices, rather than having them all on the same home LAN.

His developer advice sits much more readily with its intended audience:

• Align with one of the major frameworks – even if Apple is difficult to deal with;

• Watch the development of open source frameworks. The Open Connectivity Foundation is working on device profiles that define capabilities, based on “the best bits of UPnP and the Service Location Protocol”;

• Don't restrict configuration to a mobile app. Provide an API of some kind – “people installing thousands of sensors will thank you”;

• Put a copy of the instructions in the device, because everybody loses the instructions;

• Decide what the support life of the device is going to be, and commit to supporting it;

• If there are higher functions that aren't absolutely mandatory for operation, give people a way to turn those off if a vulnerability arises;

• Remember, “an IoT device is different from a PC – limit what software you put on it.”

This last item, Biggs concedes, is inconvenient for developers.

“Automate around it,” he said. “When you commit code, your system builds a debug, test, production version for each release. Only put the non-necessary tools in the debug version.”