MUD sliding along

Your chance to try and chime in on Manufacturer Usage Descriptions, a way to protect IoT devices.

You may recall that I am working on a mechanism known as Manufacturer Usage Descriptions (MUD).  This is the system by which manufacturers can inform the network about how best to protect their products.  The draft for this work is now about to enter “working group last call” at the IETF.  This means that now would be a very good time for people to chime in with their views on the subject.

In the meantime, MUD Maker has also been coming along. This is a tool that generates manufacturer usage descriptions.  You can find the tool here.

MUD isn’t meant to be the whole enchilada of IoT security.  Other tools are needed to authenticate devices onto the network, and to securely update them.  And manufacturers have to take seriously not only their customers’ needs, but what risk they may impose on others, as Mirai reminded us.  Had MUD been around at the time, it’s possible that Mirai would not have happened.

How hard is it to secure a baby monitor?

Philips In.Sight B120/37Parents often seek the security of a baby monitor to know that their child is resting comfortably.  Unfortunately that security is often misplaced.  Last year Rapid7 produced a damning report, exposing numerous vulnerabilities in these devices.  As an example, the Philips In.Sight B120/37 made use of a fixed password over an insecure telnet or web service that resides on TCP port 8080.

Don AdamsThe thing is- the In.Sight came very close to getting right, or as the great Maxwell Smart would say, “Missed it by that much!”  That’s because Philips also offers a cloud-based service that would not otherwise require the device to listen to any TCP port.  That’s a good way to go because it is harder to probe the device for vulnerabilities.

One good reason to offer a local service is that some some people do not trust cloud services, and they particularly do not trust cloud services involving images of their children.  Indeed this makes for a very difficult choice, because that same Rapid7 report notes problems with some cloud based services, and so parents wouldn’t be wrong to worry.

Either way, I’ve built a MUD file using MudFileMaker.

A brief view of the application alongside tcpdump together with a quick view of the server binary seems to indicate that cloud communications are to api.ivideon.com.  We can thus come up with an appropriate MUD file as follows:

{
  "ietf-mud:meta-info": {
    "lastUpdate": "2016-10-03T12:56:08+02:00",
    "systeminfo": "Philips In.Sight B120/37 Baby Monitor",
    "cacheValidity": 1440
  },
  "ietf-acl:access-lists": {
    "ietf-acl:access-list": [
      {
        "acl-name": "mud-94344-v4in",
        "acl-type": "ipv4-acl",
        "ietf-mud:packet-direction": "to-device",
        "access-list-entries": {
          "ace": [
            {
              "rule-name": "clout0-in",
              "matches": {
                "ietf-acldns:src-dnsname": "api.ivideon.com",
                "protocol": 6,
                "source-port-range": {
                  "lower-port": 443,
                  "upper-port": 443
                }
              },
              "actions": {
                "permit": [
                  null
                ]
              }
            },
            {
              "rule-name": "entin0-in",
              "matches": {
                "ietf-mud:controller": "http://ivideon.com/babymonitors",
                "protocol": 6,
                "source-port-range": {
                  "lower-port": 8080,
                  "upper-port": 8080
                }
              },
              "actions": {
                "permit": [
                  null
                ]
              }
            }
          ]
        }
      },
      {
        "acl-name": "mud-94344-v4out",
        "acl-type": "ipv4-acl",
        "ietf-mud:packet-direction": "from-device",
        "access-list-entries": {
          "ace": [
            {
              "rule-name": "clout0-in",
              "matches": {
                "ietf-acldns:src-dnsname": "api.ivideon.com",
                "protocol": 6,
                "source-port-range": {
                  "lower-port": 443,
                  "upper-port": 443
                }
              },
              "actions": {
                "permit": [
                  null
                ]
              }
            },
            {
              "rule-name": "entin0-in",
              "matches": {
                "ietf-mud:controller": "http://ivideon.com/babymonitors",
                "protocol": 6,
                "source-port-range": {
                  "lower-port": 8080,
                  "upper-port": 8080
                }
              },
              "actions": {
                "permit": [
                  null
                ]
              }
            }
          ]
        }
      }
    ]
  }
}

Remember, the router needs to fill out which devices are authorized to be in class http://ivideon.com/babymonitors.  Note the use of incoming tcp port 8080.  It is possible at least for the server software run on another port if the configuration is changed.  At that moment, the above MUD file would be too restrictive, and the device would not function.  To fix that, one would simply remove the TCP port filter.

Again, note that only authorized communications are listed in the file, and so just because the developer left a telnet server in place doesn’t mean that just anyone would be able to access it.  This serves as a means to confirm the intentions of the developers.  Of course developers should never leave back doors, but if they do, perhaps MUD can reduce their impact, and let parents rest just a little easier.

How MUD could help against the Krebs Attack

CybercrimeIn the attack against krebsonsecurity.com, one of the systems that is said to have been used was the “H.264 Network DVR“.  This device accepts HTTP connections, and communicates outbound using FTP and EMail.  There may also be an undocumented protocol for a proprietary interface.

As I’ve previously discussed, use of Manufacturer Usage Descriptions (MUD) can limit the attack surface of a device, and it can also prevent devices from being used to source an attack.    MUD allows for manufacturers to define classes, and now one simply needs to fill them in on deployment.  From the manufacturer’s side, one needs to provide the file.  For the DVR in question, I used MudMaker to create a description that a network device could use to create appropriate network protections:

{
  "ietf-mud:meta-info": {
    "lastUpdate": "2016-10-02T08:28:19+02:00",
    "systeminfo": "DVR H.264",
    "cacheValidity": 1440
  },
  "ietf-acl:access-lists": {
    "ietf-acl:access-list": [
      {
        "acl-name": "mud-65333-v4in",
        "acl-type": "ipv4-acl",
        "ietf-mud:packet-direction": "to-device",
        "access-list-entries": {
          "ace": [
            {
              "rule-name": "entout0-in",
              "matches": {
                "ietf-mud:controller": "http://dvr264.example.com/controller"
              },
              "actions": {
                "permit": [
                  null
                ]
              }
            },
            {
              "rule-name": "entin0-in",
              "matches": {
                "ietf-mud:controller": "http://dvr264.example.com/controller",
                "protocol": 6,
                "source-port-range": {
                  "lower-port": 80,
                  "upper-port": 80
                }
              },
              "actions": {
                "permit": [
                  null
                ]
              }
            }
          ]
        }
      },
      {
        "acl-name": "mud-65333-v4out",
        "acl-type": "ipv4-acl",
        "ietf-mud:packet-direction": "from-device",
        "access-list-entries": {
          "ace": [
            {
              "rule-name": "entout0-in",
              "matches": {
                "ietf-mud:controller": "http://dvr264.example.com/controller"
              },
              "actions": {
                "permit": [
                  null
                ]
              }
            },
            {
              "rule-name": "entin0-in",
              "matches": {
                "ietf-mud:controller": "http://dvr264.example.com/controller",
                "protocol": 6,
                "source-port-range": {
                  "lower-port": 80,
                  "upper-port": 80
                }
              },
              "actions": {
                "permit": [
                  null
                ]
              }
            }
          ]
        }
      }
    ]
  }
}

What is left for the controller to do that is specific to this device is define which devices are in the class http://dvr64.example.com.  That might include the FTP-based logging system that this model uses, for instance, as well as those systems that are authorized to connect to the HTTP port.

The important part of that description is what you don’t see.  You don’t see any of the attack vectors used, because through this whitelist approach, you only specify what is permitted, and everything else aside from name service and time queries is explicitly denied.  This device uses a good few services, and so I haven’t specified each one in the example for brevity’s sake.

This may well have stopped the hacker from gaining access to the device in the first place, and would have stopped the device from being able to attack the blogger, and many other attacks as well.

Krebs attacked: IoT devices blamed, and MUD could help

CybercrimeIt’s rare that hackers give you a gift, but last week that’s exactly what happened.  Brian Krebs is one of the foremost security experts in the industry, and his well known web site krebsonsecurity.com was brought down due to a distributed denial of service (DDoS) attack.  Attackers made use of what is said to be the largest botnet ever to attack Akamai, Kreb’s content service provider.

Why would one consider this a gift?  First of all, nobody was hurt.  This attack took down a web site that is not critical to anyone’s survival, not even Krebs’, and the web site was rehomed and back online in a very short period of time.

Second, the attackers revealed at least some of their capabilities by lighting up the network of hacked devices for researchers to examine and eventually take town.  One aspect of this attack is the use of “IoT” devices, or non-general purpose computers that are used to control some other function.  According to Krebs, the attacks made use of thermostats, web cameras, digital video recorders (DVRs) and, yes, Internet routers.  The attacks themselves created an HTTP connection to the web site, retrieved a page, and closed.  That’s a resource intensive attack from the defense standpoint.

Let’s ask this question: why would any of Mudpitthose systems normally talk to anything other than a small number of cloud services that are intended to support them?  This is what Manufacturer Usage Descriptions (MUD) is meant to defend against.  MUD works by providing a formal language and mechanism for manufacturers to specify which systems a device is designed to connect with.  The converse, therefore, is that the network can prevent the device from both being attacked and attacking others.  The key to all of this are manufacturer and their willingness to describe these devices.  The evolving technical details of MUD can be found in an Internet Draft, and you can create a test MUD file against that draft by using MUD File Maker.  I’ll go into more detail about MUD File Maker in a later post.

Would MUD eliminate all attacks?  No, but MUD adds an additional helpful layer of protection to those manufacturers and networks should use.

This time it was a blog that was taken down.  We are in a position to reduce attacks the next time, when they may be more serious.  That’s the gift hackers gave us this time.  Now we just need to act.

Here’s MUD in your eye! A way to protect Things on the Internet

How can the network protect so many types of things? We need for manufacturers to step up and tell us.

U.S. Army Pvt. Charles Shidler crawls through mudSince 2011 Cisco Systems has been forecasting that there will be at Since least 50 billion devices connected to the Internet by the year 2020.  Those are a lot of Things. but that’s not the number I’m worried about.  Consider this: Apple manages somewhere in the neighborhood of 1 billion active iOS devices on their own, and there are about 1.4 billion Android devices that are also managed, though less well.  Rather, it’s the number of types of things that people should be concerned about.  To begin with,not everyone is going to do such a great job at managing their products out in the field as Apple and Google do.  Moreover, even Apple and Google end support for different versions of their products after some period of time.

I call this the Internet of Threats.  Each and every one of those devices, including the device you are reading this note on right now, probably has a vulnerability that some hacker will exploit.

A good number of the manufacturers of those things will never provide fixes to their customers, and even those that do have very little expectation that the device will ever be updated.  Let’s put it this way: when was the last time you installed new software on your printer?  Probably never.

The convenient thing is that many Things probably only have a small set of uses.  A printer prints and maybe scans, thermostat like a Nest controls the temperature in your house, and a baby monitor monitors babies.  This is the exact opposite of the general purpose computing operating model that your laptop computer has, and we can take advantage of that fact.

If a Thing only has a small number of uses, then it aspirinprobably only communicates on the network in a small number of ways.  The people who know about those small number of ways are most likely the manufacturers of the devices themselves.  If this is the case, then what we need is a way for manufacturers to tell firewalls and other systems what those ways are, and what ways are particularly unsafe for a device.  This isn’t much different from a usage label that you get with medicine.

So what is needed to make all of this work?  Again, conveniently most of the components are already in your network. The first thing we need is a way for devices to tell the network where to get the manufacturer usage description file (or MUD file).  There’s an excellent example of that in your browser right now, called a Universal Resource Locator (URL), like https://www.ofcourseimright.com.  In our case, we need something a bit mroe structured, like https://www.example.com/.well-known/mud/v1/someproduct/version.  How you get that file, however, is exactly the same as how you got to this web page.

Next, we need a way for the Thing to give the URI to the network.  Once again, the technology is pretty much done.  Your device got an IP address today using Dynamic Host Configuration Protocol (DHCP), which provides an introduction between the device and the network.  All we need to do is add one new parameter or option so that the client can simply pass along this MUD URI.  There are even more secure ways of doing that using public key infrastructure (PKI) approaches such as IEEE’s 802.1AR format and 802.1X protocol.  The nice thing about using a manufacturer certificate in 802.1AR is that it is then the manufacturer and not the device itself that is asserting what the device communication patterns are.

Now, thanks to DHCP or IEEE 802.1X, the network can go get the MUD file.  What does that look like?  At the moment, <it> <looks> <like> <a> <bunch> of <XML>.  {“it” , [“may”, “look”, “more”], “like, {“json”}} in the future.  The good news here is that once again, we’re building on a bunch of work that is already complete.  The XML itself is structured using a data model called YANG.  So long as it conveys to the network what sort of protections a device needs, it could be anything, but YANG will do for now.

Finally, the basic enforcement building block is the access control function in a router or access point.  That function says what each device can communicate with, and they’ve been around since the earliest days of the Internet.

And that’s it.  So now if I have printer from HP and they make a MUD file available, they might tell my network that they only want to receive printer communications, and that the printer should only ever try to send certain types of unsolicited messages.  If anyone tries to contact the printer for another use, forget it.  If the printer tries to contact CNN – or more importantly random devices on my network, it’s probably been hacked and it will be blocked.  Google can do the same with a Nest.

We’re talking about this at the IETF and elsewhere.  What do you think?