It’s Not the Doorbell, It’s the Cloud

Your password in the cloud was weak, not the IoT device this time. But there are emerging IoT standards like DPP that can help do away with passwords.

You have to have been hiding under a rock over the last week not to have heard about scare stories about kids being tormented by perverts and others being violently extorted through various Ring products. Not exactly what you were expecting from your security product, was it?

With so many reports of IoT devices being vulnerable to attack, one might leap to the idea that the Ring device itself has been poorly designed, and thus broken into, but one would be wrong. That is because, like so many IoT devices, Ring products make use of the cloud to offer a service. Here’s how it all works.

How you access that home IoT device

When you establish an account, you are doing this not on the doorbell, but on a service somewhere on the Internet to which the doorbell connects. This is evident, because when you go to ring.com, you can log in with the account that you have previously established in the app.

Later during device setup, the doorbell is registered with the service, using the phone’s setup app. This is likely the only time the phone would directly communicate with the doorbell. All other communications flow through the service, as drawn above.

So how did someone else get to control your device? If you are not using two factor authentication, an attacker requires two pieces of information to control your device: your email address and your password. Your email address can easily have appeared in public if you have joined a public mailing list, or had made a comment on a poorly designed web site. An attacker may also be able to guess your password if you have used that same password on a service that has been compromised (hint: many have), or the password itself is obvious.

Some recent research has found that long or complex passwords aren’t good because people write them down or forget them. On the other hand, Ring will accept “12345678” as a password, and quite a number of other commonly used passwords that can be found on this list of stupid passwords. First piece of advice in this article: don’t use those passwords!

Ring also offers the option to register a cell phone with your account, so that when you log in, you will receive a code via SMS that you must enter to access your account. This two factor authentication (or 2FA) is stronger, and well worth the mild inconvenience, given that this is your house and its security we are talking about.

All of this is about securing your online account. The only reason that the EvilBadDoer can bother Little Johnny and take over your doorbell or security camera, at least in this moment, is that EvilBadDoer hacked your online service password to the service controls the device.

Could this marriage of IoT devices and online services be used to provide a stronger authentication? Possibly. Because a device communicates with the cloud once it’s set up, and because your phone communicates with the cloud after the doorbell is setup, it is possible for the device to provide the doorbell a token. However, for that to work, communications must be secured between the device and the doorbell during setup. Earlier this year, researchers found that this was not the case, the reason being that the doorbell was simply using unencrypted HTTP to share information about your wifi network. Bad Ring! No Ring biscuit!

Luckily, there are some onboarding standards that Ring and others could leverage to help improve matters. One is EasyConnect by the Wifi Alliance, otherwise known as Device Provisioning Protocol (DPP). Here’s how DPP works:

Wifi Easy Connect

With DPP, you can use an app to scan a QR code printed on a label that came with the device that contains the public key that was installed during the manufacturing process. The app then looks for the device and authenticates using that key. Look, Ma! No passwords. DPP was primarily intended to be used for Wifi connectivity, but there’s no reason that the same trust couldn’t be leveraged to do away with Ring passwords. This is something that Amazon and others should consider.

There are some remaining challenges. For instance, what happens if you lose your phone? Can you repeat the exercise, and if you do so, would you have to do so with all the Ring devices in your house? To me this is best handled with some sort of backup before one loses one’s phone.

The key point here is that IoT can actually help itself if we adopt stronger onboarding technologies, like EasyConnect. This will take some time to get right. As a customer, you might want to ask about EasyConnect to help ease password problems so that Little Johnny can sleep easier.

Would you want your cousin using a connected oven?

Recently my cousin installed a smart oven into her home. It is top of the line. She wrote on social media that it texted her to tell her that it needed to clean itself, which it did before her second cup of coffee. How cool is that?

I immediately feared for her safety. Here is a slightly edited version of what I wrote to her:

IoT is a nice convenience, but there are a few things you should know. First, I guarantee that there are vulnerabilities in the device, even if some have yet to discover them. This is true for *any* connected device. Those vulnerabilities may be exploited at some point. What will happen then?

First, it’s possible that attacker could simply disable the oven. They probably won’t do this unless they are able to communicate with you. But since the oven seems to be sending you messages, it’s possible that they will do this and ransom you to re-enable it. (If that happens, don’t pay.)

Whether or not you can control the oven from the app, don’t think for a moment that hackers won’t be able to gain that level of control. That presents a far more serious risk: a fire, especially if the hackers are able to detect that the cooking temp is supposed to be 350, and turn the thing up to broil or clean.

The other thing that will happen is that the oven will attack other Wifi-enabled devices in your house or elsewhere. If you have a Wifi-enabled thermostat, maybe it will attack that. Some of those devices have cameras and microphones. The attackers aren’t going to be nice about what information they collect. They’re out to make money or worse.

Will any of this happen? Yes – to many people. Am I being paranoid? Maybe a little. Appliance manufacturers may know how to make excellent oven mechanisms, refrigerator compressors, stove top elements, etc, but they generally know very little about Internet security and their risks. Even those who know a lot get it wrong all the time, simply because we’re human.

And so are you gaining any great convenience by having the Wifi turned on, apart from a 5:30am wake up call to let you know that it needs to clean itself? If yes, you have a trade off to make. If not, just disable its darn Wifi.

This is how I feel about technology and the ones I love. Presumably you have some of those. There are definitely times when IoT is necessary, and when convenience is probably worth the risk. But consumers really need to think about this long and hard, and we professionals need to provide them a decent decision framework. I’ll talk about that next.



Addressing the Department Gap in IoT Security

People in departments outside of IT aren’t paid to understand IT security. In the world of IoT, we need to make it easy for those people to do the right thing.

So, Mr. IT professional, you suffer from your colleagues at work connecting all sorts of crap to your network that you’ve never heard of?  You’re not alone.  As more and more devices hit the network, the ability to maintain control can often prove challenging.  Here are your choices for dealing with miscreant devices:

  1. Prohibit them and enforce the prohibition by firing anyone who attaches an unauthorized device.
  2. Allow them and suffer.
  3. Prohibit them but not enforce the prohibition.
  4. Provide an onboarding and approval process.

A bunch of companies I work with generally aim for 1 and end up with 3.  A bunch of administrators recognize the situation and fit into 2.  Everyone I talk to wants to find a way to scale 4, but nobody has, as of yet.  What does 4 involve?  Today, it means an IT person researching a given device, determining what networking requirements it has, creating firewall rules, and some associated policies, and establishing an approval mechanism for a device to connect.

This problem is exacerbated by the fact that many different enterprise departments have wide and varied needs, and the network stands as critical to many of them.  Furthermore, very few of those departments reports through the chief information officer, and chief information security officers often lack the attention their concerns receive.

I would claim that the problem is that incentives are not well aligned, were people in other departments even aware of the IT person’s concerns in the first place, and often they are not.  The person responsible for providing vending machines just wants to get the vending machines hooked up, while the person in charge of facilities just wants the lights to come on and the temperature to be correct.

What we know from hard experience is that the best way to address this sort of misalignment is to make it easy for everyone to do the right thing. What, then, is the right thing?

Prerequisites

It has been important pretty much forever for enterprises to be able to maintain an inventory of devices that connect to their networks.  This can be tied into the DHCP infrastructure or to the device authentication infrastructure.  Many such systems exist, the simplest of which is Active Directory.  Some are passive and snoop the network.  The key point is simply this: you can’t authorize a system if you can’t remember it.  In order to remember it, the device itself needs to have some sort of unique identifier.  In the simplest case, this is a MAC address.

Ask device manufacturers to help

Manufacturers need to make your life easier by providing you a description what the device’s communication requirements are.  The best way to do this is with Manufacturer Usage Descriptions (MUD).  When MUD is used, your network management system can retrieve a recommendation from the manufacturer, and then you can approve, modify, or refuse a policy.  By doing this, you don’t have to go searching all over random web sites.

Have a simple and accessible user interface for people to use

Once in place you now have a nice system that encourages the right thing to happen, without other departments having to do anything other than to identify the devices they want to connect.  That could be as simple as a picture of a QR code or otherwise entering a serial #.  The easier we can make it for people who know nothing about networking, the better all our lives will be.

Removal of privacy protections harms service providers

Removing privacy protections harms consumer security AND service provider business prospects.

As the media is reporting, the administration has removed privacy protections for American consumers, the idea being that service providers would sell a consumer’s browsing history to those who are interested.  Over time, service providers have looked for new and novel (if not ethical) ways to make money, and this has included such annoyances as so-called “supercookies”.

Why, then, would I claim that removing consumer privacy protections will harm not only consumers, but telecommunications companies as well?

In the new world that is coming at us, our laptops, cell phones, and tablets will be a minority of the devices that make use of our home Internet connection.  The Internet of Things is coming, and will include garage door openers, security systems, baby monitors, stereos, refrigerators, hot water heaters, washing machines, dishwashers, light bulbs, and lots of other devices.  Many of these systems have been shown to have vulnerabilities, and the consumer does not have the expertise to protect these devices.  The natural organization to protect the consumer is the telco.  They have the know-how and ability to scale to vast quantities of consumers, and they are in the path of many of communications, meaning that they are in a position to block unwanted traffic and malware.

The consumer, on the other hand, has to be willing to allow the service provider to protect them.  Why would would consumers do that if they view the service provider as constantly wanting to invade their privacy?  Rather it is important the these companies enjoy the confidence of consumers.  Degrading that confidence in service providers, therefore, is to degrade security.

Some people say to me that consumers should have some choice to use service providers who afford privacy protections.  Unfortunately, such contractual choices have thus far not materialized because of all the small print that such contracts always entail.

What is needed is a common understanding of how consumer information will be used, when it will be exposed, and what is protected.  The protections that were in place went a long way in that direction.  The latest moves reverse that direction and harm security.

Yet another IoT bug

Miele could have benefited from MUD, as well as the experience of the Internet security community.

The Register is reporting a new IoT bug involving Miele PG 8528 professional dishwashers, used in hospitals and elsewhere.  In this case, it is a directory traversal bug involving an HTTP server that resides on port 80.  In all likelihood, the most harm this vulnerability will directly cause is that the dishwasher would run when it shouldn’t.  However, the indirect risk is that the device could be used to exfiltrate private information about patients and staff.  The vulnerability is reported here.

Manufacturers expect that it will be very simple to provide Internet services on their devices.  To them, initially, they think that it’s fine to slap a transceiver and a simple stack on a device and they’re finished.  They’re not.  They need to correct vulnerabilities such as this one.  They apparently have no mechanism to do so.  Manufacturers such as Miele are experts within their domains, such as building dishwashers.  They are not experts in Internet security.  It is a new world when these two domains intersect.

We need MUD

And yes, Manufacturer Usage Descriptions would have helped here, by restricting communication either to all local devices or to specifically authorized devices.