IoT Makers Could Fix Things, But They Won’t
This article fits in with two others I’ve written since Friday: That Map of the Internet Failing You Saw on Friday Didn’t Tell the Story at All (and Here’s What Really Did Happen) and Why the Internet broke and you couldn’t do anything about it.
The Internet of Things (IoT) has been weaponized. Internet-connected DVRs, webcams, alarm systems, baby monitors, and much more can be quietly compromised and run software that makes them part of massive “botnets” that can be targeted like deadly space-based lasers to take down sites and infrastructure.
Equipment makers could have prevented this, but there was no financial incentive, regulatory requirement, or retailer test process that stood in the way. The IoT was and remains a race to the bottom. For every gee-gaw like a Nest thermostat or camera that costs hundreds and maybe even has a recurring subscription fee, there’s a cheap one-time-purchase equivalent for 75 to 90 percent less that’s just good enough. Of the billions of IoT devices in homes and offices today, I’d wager at least three-quarters are “good enough” gear, just like an increasing number of smartphones use off-brand (non-certified) Android OS.
Blaming users for not changing a device’s password is like blaming a car driver for not performing an oil change when first buying a car, or for not swapping out a defective air bag when they learn of a recall. The IoT device maker needs to be responsible for setting strong defaults and guiding a user through setup. And many of the problems that lead to devices being hijacked have to do with a poorly configured operating system or even debugging processes left in place that even a sophisticated user would be unable to change—only a firmware update from a manufacturer could close those holes.
A hidden part of this is a monoculture that consumers don’t see. There are, say, 1,000 Internet-connected Wi-Fi cameras on the market, and the core parts of those systems come from just a handful of companies. Thus one flaw amplifies across the supply chain.
For instance, the security firm Flashpoint identified a problem in DVR software supplied by Xiongmai Technologies, affecting at least 500,000 devices Flashpoint has identified:
“The issue with these particular devices is that a user cannot feasibly change this password. The password is hardcoded into the firmware, and the tools necessary to disable it are not present. Even worse, the web interface is not aware that these credentials even exist.”
(Xiongmai issued a recall today, but blames the problem on users failing to change the initial default password, rather than the issue that Flashpoint says it found.)
Security weaknesses can’t be eliminated. But they can be reduced. Many of the IoT compromises allow hijacking 100,000s of devices using exactly the same technique.
What could manufacturers have done and still can do to limit this problem?
- Ship every device with a unique password printed on the device itself. This could use the last several characters of the unique hardware address built into the device if it has Wi-Fi, Bluetooth, or Ethernet, or a serial number. Because one of these numbers is already printed on the device, it easy to preprint a password deriving from it, or tell users how to find it. (The hardware address is set at the factory and is the Media Access Control or MAC address, unrelated to Mac computers.)
- Disable administrative from outside the Local Area Network (LAN) until the password is changed during a setup process. There’s no reason to allow Internet-based configuration if someone hasn’t changed the default admin password.
- Have a password back-off time and lockout to prevent attackers from using knowledge of a password algorithm derived from something on the device to just try millions of combinations per networked device to crack it. Many IoT devices neither throttle or lock out bad attempts to gain access. Such a feature is built into Linux, including Android OS and other relatives, which are used for most inexpensive IoT hardware. Progressively increasing the amount of time between password attempts and then locking out an IP address or administrative access altogether for a period of time unless the device is rebooted dramatically reduces the potential for brute-force attacks.
- Choose the least amount of inbound access necessary. Many IoT devices are wide open because programmers leave debugging configurations in place. Sounds sloppy, but it’s been found again and again. In other cases, it’s just laziness to leave a device completely open than to use firewall software (again, part of most embedded system’s default OS) to lock down.
- Have a notification process for updates from the device itself: a flashing LED, a note on the display (if one exists), or a network notification through connected software or hardware. If a device can reach the network, it can send you a message.
- Don’t send credentials provided for Wi-Fi or other networked resources in the clear over the local network or the Internet—don’t send them at all, in fact. Don’t ask for a user’s email password!
- Use https for everything over the local network. It takes a little extra effort, but it keeps a compromised system on the local network from gaining access to Internet of Things devices.
- Make updating a one-click process, not “find the site, find the model number, download the file to a computer, connect through the Web administrative interface, upload the file, wait to make sure nothing breaks.” I’ve found with some IoT devices, the updates are all .exe files, not useful for Mac, Linux, and other platforms.
- Use code-signing and https for updates. An insecure process for updates leads to “owned” devices, hijacked with fake updates that then lock down the valid update path. Even Apple fell afoul of this years ago: it initially failed to sign its Mac software updates.
- Require a code review and security audit before goods are put up for sale, like a UL seal. This wouldn’t catch obscure back-end debugging hooks that are left in, but would find the obvious stuff that automatic testing software or a security-minded reviewer could find—like leaving an open port for remote terminal access paired with a hardcoded password a user can’t change. For instance, Amazon could require this, and its inventory of Internet of Crap items would be reduced by 95 percent. The U.S. and other governments’ trade commissions and even import boards could require for product safety, although that would almost always require legislative or regulatory changes. As with Wi-Fi and other trade group certifications, it doesn’t assure perfection, but it establishes a reasonable low bar.
- Require a minimum warranty that includes automated security updates for a period of time. Most IoT gear is obsolete before it’s sold. It runs outdated software at the time it ships and has a terrible or no path to upgrade. That’s how it’s sold so cheaply. This is the hardest step: it means committing future resources to a task that may have no future revenue associated, as many cheap IoT products are on the market for very short periods of time before a new model replaces it—as short a period as months. It would require escrowing funds or code (to release for open-source continued development, say) or other assurances, and some group would have to monitor compliance. This would be a job for an industry association, but then makers would be obliged to join that association.
- Require a hardware swap if a unit can’t be updated through firmware. Few companies would want to commit to that.
Each step would add enormously to security, even if all steps remain impossible. Steps 11 and 12 might never happen. But, so far, even if larger, established companies follow many of these steps, most products sold conform to none of them.
Until any of this changes, the IoT will continue to be used for massive attacks: censoring individuals, holding others hostage for blackmail, and shaking the foundations of the Internet’s infrastructure.
Glenn Fleishman is a veteran technology writer who contributes regularly to the Economist, Macworld, Fast Company, TidBITS, and other publications.