Learning from the Dyn attack: What are the right questions to ask?

The attack on DNS provider DYN’s infrastructure that took down a number of web sites is now old news.  While not all the facts are public, the press reports that once again, IoT devices played a significant role.  Whether that it is true or not, it is a foregone conclusion that until we address security of these devices, such attacks will recur.  We all get at least two swings at this problem: we can address the attacks from Things as they happen and we can work to keep Things secure in the first place.

What systems do we need to look at?

  • End nodes (Cameras, DVRs, Refrigerators, etc);
  • Home and edge firewall systems;
  • Provider network security systems;
  • Provider peering edge routers; and
  • Infrastructure service providers (like DYN)

In addition, researchers, educators, consumers and governments all have a role to play.

Roles of IoT

What do the providers of each of those systems need to do? 

What follows is a start at the answer to that question.

Endpoints

It’s easy to pin all the blame on the endpoint developers, but doing so won’t buy so much as a cup of coffee. Still, thing developers need to do a few things:

  • Use secure design and implementation practices, such as not hardcoding passwords or leaving extra services enabled;
  • Have a means to securely update their systems when a vulnerability is discovered;
  • Provide network enforcement systems Manufacturer Usage Descriptions so that the networks can enforce policies around how a device was designed to operate.

Home and edge firewall systems

There are some attacks that only the network can stop, and there are some attacks that the network can impede.  Authenticating and authorizing devices is critical.  Also, edge systems should be quite leery of devices that simply self-assert what sort of protection they require, because a hacked device can make such self-assertions just as easily as a healthy device.  Hacked devices have recently been taking advantage of a gaming mechanism in many home routers known as Universal Plug and Play (uPnP) which permits precisely the sorts of self-assertions should be avoided.

Provider network security systems

Providers need to be aware of what is going on in their network.  Defense in depth demands that they observe their own networks in search of malicious behavior, and provide appropriate mitigations.  Although there are some good tools out there from companies like Cisco such as Netflow and OpenDNS, this is still a pretty tall order.  Just examining traffic can be capital-intensive, but then understanding what is actually going on often requires experts, and that can get expensive.

Provider peering edge routers

The routing system of the Internet can be hijacked.  It’s important that service providers take steps to prevent that from happening.  A number of standards have been developed, but service providers have been slow to implement for one reason or another.  It helps to understand the source of attacks.  Implementing filtering mechanisms makes it possible for service providers to establish accountability for the sources of attack traffic.

Infrastructure providers

Infrastructure upon which other Internet systems rely needs to be robust in the face of attack.  DYN knows this.  The attack succeeded anyway.  Today, I have little advice other than to understand each attack and do what one can to mitigate it the next time.

Consumers

History has shown that people in their homes cannot be made to do much to protect themselves in a timely manner.  Is it reasonable, for instance, to insist that a consumer to spend money to replace an old system that is known to have vulnerabilities?  The answer may be that it depends just how old that system really is.  And this leads to our last category…

Governments

The U.S. CapitolGovernments are already involved in cybersecurity.  The question really is how involved with they get with IoT security.  If the people who need to do things aren’t doing them, either we have the wrong incentive model and need to find the right one, or it is likely that governments will get heavily involved.  It’s important that not happen until the technical community has some understanding as to the answers of these questions, and that may take some time.

And so we have our work cut out for us.  It’s brow furrowing time.  As I wrote above, this was just a start, and it’s my start at that.  What other questions need answering, and what are the answers?

Your turn.



Photo credits:
Capitol by Deror Avi – Own work, CC BY-SA 3.0
Router by Weihao.chiu from zh, CC BY-SA 3.0
DVR by Kabel Deutschland, CC BY 3.0
Router by Cisco systems – CC BY-SA 1.0

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.

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.