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.

Should I have that IoT device on my home network?

Yesterday I wrote about my cousin’s smart oven, and the risks of having it networked. Does this mean that you should have no IoT devices in your house? If not, how should you decide which ones are worth connecting? Here are three questions you might want to ask.

Does connecting the device to your network offer you any perceptible value?

Sometimes the answer is going to clearly be “yes”. For example, if you are taking a vacation in the middle of the winter in some cold place, you might want to know that your home’s heater broke down before your pipes froze. Having a thermostat configured to alert you to this fact might prove very useful. On the other hand, if you are in a place where such a concern is unwarranted or you would have no reason to worry about such things, maybe that same device does not need connectivity.

Will the device function correctly without connectivity?

Don’t expect an Amazon Echo to function, for instance. There is a reason why a great many IoT manufacturers are requiring Internet connectivity for their devices: the more intelligence they can move into their servers, the less intelligence is needed in the device itself, making it cheaper to build. If you are going to have a function like this in your house, this is actually an environmentally friendly way to go. Fewer parts require fewer resources used to build and to later dispose. But if a device does function properly and fully without Internet connectivy, why plug it in?

Does that device need continuous Internet connectivity?

You are unlikely to connect and reconnect your television every time you want to watch a video, but maybe you only need that thermostat connected while you are on vacation, for instance, or maybe an appliance needs a firmware update via the Internet. Occasionally connecting a device may make sense. However, take care: if you only plug in devices while you are on vacation, someone may be able to notice that and choose that time to break into your home.

Some Internet routers have the ability to block devices at certain times. Typically this is used to limit children’s access. However, one can also use these filters for other purposes. The problem is that this is nearly as annoying as having to deconfigure devices themselves. I’ll discuss this more in the near future.

Think before you buy!

The risk to your home and your privacy is real. Realistically, however, you will have some IoT devices in your house. Think about what value you derive from them, and what can go wrong if they are attacked before you buy.

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.



RFC 8520 on Manufacturer Usage Descriptions Released

Today the RFC Editor released RFC 8519 (the ietf-acl model) and RFC 8520 (Manufacturer Usage Descriptions).  The ACL model provides for a programmatic YANG-based interface that is flexibly extensible.  Manufacturer Usage Descriptions (MUD) extend this model so that manufacturers are in a position to request the network’s assistance.

MUD’s declarative model for manufacturers to describe to customers what network resources their devices are designed to use.  No guessing games are required. Manufacturers use simple abstractions to describe what access a device needs, such as a domain name for cloud-based service, or same-manufacturer or my-controller for local devices.

Even when one doesn’t use automated tools, there is benefit to manufacturers in writing MUD files.  A study by the University of New South Wales found that IoT devices often conflict with enterprise network policies, and that this goes largely unnoticed by administrators who don’t understand the needs of those devices.  What we can say is that if manufacturers do a little bit of work, they and our customers can both derive a whole lot of value from the network.

A fair amount of software already exists for MUD, including the NIST MUD Manager, and the tools built by CIRA, not to mention Cisco’s open source version, and osMUD.org, and commercial versions built by Yikes! and Cisco. Google has implemented a MUD manager as for build management. And of course you can build your own MUD file for your device by going to https://www.mudmaker.org.

MUD is part of a nutritious meal, but it is not the whole meal. Manufacturers should always use best coding practices, and update firmware and software promptly when they learn of vulnerabilities and exploits

Next Steps

It’s time for manufacturers to implement! Protect your devices with MUD!

Ain’t No Perfect. That’s why we need network protection.

If Apple can blow it, so too can the rest of us. That’s why a layered defensive approach is necessary.

When we talk about secure platforms, there is one name that has always risen to the top: Apple.  Apple’s business model for iOS has been repeatedly demonstrated to provide superior security results over its competitors.  In fact, Apple’s security model is so good that governments feel threatened enough by it that we have had repeated calls for some form of back door into their phones and tablets.  CEO Tim Cook has repeatedly taken the stage to argue for such strong protection, and indeed I personally have  friends who I know take this stuff so seriously that they lose sleep over some of the design choices that are made.

And yet this last week, we learned of a vulnerability that was as easy to exploit as to type “root” twice in order to gain privileged access.

Wait what?

 

Wait. What?

 

 

Ain’t no perfect.

If the best and the brightest of the industry can occasionally have a flub like this, what about the rest of us?  I recently installed a single sign-on package from Ping Identity, a company whose job it is to provide secure access.  This simple application that generates cryptographically generated sequences of numbers to be used as passwords is over 70 megabytes, and includes a complex Java runtime environment (JRE).  How many bugs remain hidden in those hundreds of thousands of lines of code?

Now enter the Internet of Things, where manufacturers of devices that have not traditionally been connected to the network have not been expert at security for decades.  What sort of problems lurk in each and every one of those devices?

It is simply not possible to assure perfect security, and because computers are designed by imperfect humans, all these devices are imperfect.  Even devices that we believe are secure today will have vulnerabilities exposed in the future.  This is one of the reasons why the network needs to play a role.

The network stands between you and attackers, even when devices have vulnerabilities.  The network is best in a position to protect your devices when it knows what sort of access a device needs to operate properly.  That’s your washing machine.  But even for your laptop, where you might want to access whatever you want to access, whenever you want to access it, through whatever system you wish to use, informing the network makes it possible to stop all communications that you don’t want.  To be sure, endpoint manufacturers should not rely solely on network protection.  Devices should be built with as much protection as is practicable and affordable.  The network provides an additional layer of protection.

Endpoint manufacturers thus far have not done a good job in making use of the network for protection.  That requires a serious rethink, and Apple is the posture child as to why.  They are the best and the brightest, and they got it wrong this time.