How Responsible Are Consumers for the Insecurity of IoT?

Many of you may have read about, or even experienced firsthand, the recent DDoS attacks, especially if you have used popular sites such as Amazon, Pinterest, Tumblr, Netflix, Twitter, Reddit, and PayPal. From users’ perspective, it may have looked like these sites were down. Some of you might even have participated in the attack; or some would have you believe. So you might be wondering: Just how responsible are you for this massive attack?

Let’s begin with what a DDoS attack is. Here’s a quick analogy I wrote on the topic back in 2014:

A DDoS (distributed denial of service) attack is basically a large-scale attempt to disrupt a web server using requests from many different “zombie” computers. Suppose there’s a pizza store in your town, and it normally gets 3-4 orders by phone every hour. A group wants to put the store out of business using unethical means, and they make a fake post on a social network that claims the store is giving out free pizzas. For 10 hours, the pizza store, which isn’t really giving out free pizzas, is inundated with an average of 10,000 calls per hour, making it unable to get any real business. This is essentially how a DDoS attack works, but with computers. When a website or a gaming server is hit by such an attack, legitimate users cannot visit the site or log in because there are so many other requests.

So there it is; DDoS in a nutshell. Hijacking “computers” in the sense of mobile devices, laptops, and desktop computers is not the only way DDoS attacks can be launched. As we saw last year, routers can also be used. The malware used in the recent attack, named Mirai, uses Internet of Things (IoT) devices.

The obvious and ultimate answer to the question of responsibility is that attackers are ultimately responsible for launching the attack. Regardless of what vulnerabilities there may have been in IoT devices, the vulnerabilities only enabled the launching of the attack; a volitional process. In this post, I want to focus instead on which parties were responsible for enabling or preventing the attack.

To ask the question of how responsible users are for enabling this recent attack is to ask how responsible users are for the insecurity of IoT. This latter question isn’t an easy question to answer. Perhaps we should start by considering what “security” means. In 2014, Todd Greene, CEO of PubNub, delineated three specific parts of IoT security:

1. Authorization

Is the device allowed to send or receive data? For example, in a DDoS scenario, the clear answer is no. The consumer did not give permission for the device to send data to bring down the Internet.

One way to control authorization is, as Krebs observed, the username and password of a particular device. As the article notes, many devices with usernames and passwords set by the factory were targeted by Mirai. This is one area in which I can agree that the consumer may bear some moral responsibility for the security of their devices, or at least has some control over whether they are vulnerable.

After all, usernames and passwords are not new concepts, and anyone who has ever had an e-mail or an account on social media at least knows what they are. It is therefore up to consumers to learn how to use non-default usernames and strong passwords where possible. Schneier has some tips on how to create strong passwords.

2. Open ports:

Krebs wrote in a recent article that even when you are behind a NAT router, which in many cases will prevent open ports on your device from being exposed to the Internet, can be bypassed via UPnP. Last year, the FBI recommended turning UPnP off on your router and even specifically mentioned that UPnP can be exploited to access many IoT devices. But let’s be honest. How many everyday consumers have even heard of UPnP, let alone know where the setting is in their router?

I personally could not immediately know where the UPnP section was in many routers; the setting can be buried deep in one of many categories, and I would have to look for it. If you’re using stock (factory) firmware, the easiest way to find it quickly would probably to Ctrl + f “UPnP” in a PDF of its manual. If you’re using third-party firmware like Tomato, DD-WRT, or OpenWrt, you are probably already savvy enough to know where to look.

Fortune magazine places some of the responsibility for the attack squarely on consumers. It rhetorically asks “No one think it’s acceptable for consumers to be clueless when they operate products like automobiles or propane tanks—so why is it okay for them to be careless with routers and security cameras?” The situation may not be so simple, however. How much should a consumer be obligated to know about their devices, exactly? A propane tank might have specific warnings about what not to do around the tank, for example.

But where do we draw the line? If a car manufacturer produces cars that have a defect in the brakes, should a consumer know about that defect, and should they know how to fix it? Should all drivers getting their license be required to be licensed mechanics first? How can a consumer be called considered “careless” unless the router makes it clear that UPnP is a security risk? I cannot remember a single router’s stock firmware ever making the dangers of UPnP clear.

And let’s blur the lines between security and car safety for a second. We have known for some time that cars can be hacked, and that such hacking can pose a real danger. How much responsibility should we lay at the feet of a consumer who was only licensed to drive cars and not to understand the networking concepts behind that car? Should drivers now be both licensed mechanics and certified networking professionals?

Some safety precautions like creating strong passwords are without question easier to apply than others. I have deep caveats about holding the consumer responsible for not taking precautions against every conceivable danger. I also want to make an important distinction between between legal responsibility and moral responsibility. We may chide people for not doing their due diligence, but we should be careful of scapegoating innocent individuals who are the victim of malware.

Let us not forget the tragic case of Julie Amero, a victim of malware who was prosecuted. Her life was ruined, and the ordeal took a serious toll on her health. The case has been called a dangerous farce, a tragedy of errors, and a travesty of justice. We can pontificate about morals all day long, but before we even consider holding users of devices legally responsible for the consequences of a security breach, let us remember and learn from the miscarriage of justice that was the Julie Amero case, and tread carefully, lest we ruin more innocent lives.

3. Encryption

I would argue that at least at the moment, encryption is primarily, if not exclusively the province of device manufacturers; either the manufacturer built encryption into their devices, or they didn’t.

In short, I would impute at most some degree of moral responsibility to consumers who could have taken easy measures to secure their IoT devices, such as changing the default factory password to something more secure. However, the bulk of the moral, if not legal responsibility, should fall on the manufacturers of IoT devices, for they decide whether to ship devices with open ports, whether to enable UPnP on those devices, and whether to use encryption. In fact, manufacturers can even mitigate the risk of shipping their devices with weak, default passwords, should they choose to do so. Instead of using the same password for every device, for example they could instead ship each device with a randomly generated default password, so that even consumers who fail to change the factory password would be afforded some degree of protection.

When manufacturers of IoT devices both have the means to greatly decrease the vulnerability of their devices to cyberattacks and fail to do so, as they did in the recent DDoS attacks, I fail to see any alternative but to lay most of the blame squarely at their feet.

Leave a Reply

Your email address will not be published. Required fields are marked *