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

Looming wireless problems with IoT security

Security experts have two common laments:

  • Security is an afterthought, and
  • Security is hard to get right.

No place else has this been more true than in wireless security, where it took the better part of two decades to get us to where we are today.  “Wireless” can mean many different things.  It could mean 3G cellular service or Wifi or Bluetooth or something else.  In the context of Wifi, we have standards such as WPA Personal and WPA Enterprise that were developed at the IEEE.  Similarly, 3GPP has developed secure access standards for your phone through the use of a SIM card.  With either WPA Enterprise or 3G, you can bet that if your device starts to misbehave, it can be uniquely identified.

Unfortunately that’s not so much the case with other wireless standards, and in particular for IEEE’s 802.15.4, where security has for the time being been largely left to higher layers.  And that’s just fine if what we’re talking about is your Bluetooth keyboard.  But it’s not fine at all if we’re talking large number of devices, where one of them is misbehaving.

mesh-insecurity

Here we have a lighting network.  It might consist of many different light bulbs.  Maybe hundreds.  Now imagine a bad guy breaking into one of those devices and attacking the others.  Spot the bad guy.  In a wired world, assuming you have access to the switch, you can spot the device simply by looking at which port a connection came into.  But this is wireless, and mesh wireless at that.  In the case where each device has its own unique key, you can trace per session per device.  But if all devices use a shared key, you need to find other means.  A well hacked device isn’t going to give you many clues; it’s going to try to mimic a device that isn’t hacked, perhaps one that isn’t turned on or one that doesn’t even exist.

These attacks can be varied in nature.  If the mesh is connected to other networks, like enterprise networks, then attacks can be aimed at resources on those networks.  This might range from a form of a so-called “Snow Shoe” attack, where no one device generates a lot of traffic but the aggregate of hacked devices overwhelm a target, to something more destructive, like attempts to reconfigure critical infrastructure.

Some attacks aren’t even intended as such, as Raul Rojas discovered in 2009, when a single light bulb took down his IoT-enabled house.

What to do?

The most obvious thing to do is not to get into this situation in the first place.  From a traceability standpoint, network managers need to be able to identify the source of attacks.  Having unique wireless sessions between leaf and non-leaf nodes that are bound to source addresses is ideal.  Alternatively, all communications in a mesh could tunnel to non-leaf nodes that have strong diagnostic capabilities, like IPFIX and port spanning.  At that point administrators can at least log traffic to determine the source of attacks.  That’s a tall order for a light bulb, but it’s why companies like Cisco exist- to protect your infrastructure.

If none of these alternatives exist, poor network administrators (who might just be home owners like Mr. Rojas)  are forced into a position where they might need to consider the entire mesh a single misbehaving device, and disconnect it from the network.  And even that might not do the job: a smart piece of malware might notice and quiet itself until it can determine that the mesh has been re-connected.

Some careful thought is required as these capabilities develop.

Not so fast on Cheney…

This LA Times Editorial discusses the complexities of the situation.  In a nutshell, it’s not clear that the program had advanced to the point to where it triggered a Congressional notification.  Furthermore, if the program was, as is being reported, designed to take out Al Qaida chiefs, the idea that we would not have had such a program is unbelievable, itself.

Baby Shaker Shakes Apple iTunes Model

iPhoneI have an expression that I have ruthlessly stolen from Star Trek IV: The Voyage Home, and it is,  “A double dumb-ass on you!”  Today I say that to Apple, for walking into a minefield with iTunes, and controlling what applications they allow on the iPhone and iPod Touch.  It seems that someone wrote an game called Baby Shaker, in which the idea is to cause the baby on the screen brain damage.  The game is sickening and tasteless, which I generally like, but in this case, it even turned me off.

So why is Apple in trouble?  They approved publication of the game and then after parental outrage they withdrew the approval.  Oops!  Somehow to Apple this debacle was not predictable.  Here is a lesson that many in the print media as well as the networking business already know.  If you attempt to control content at all, you take some responsibility for that content.  In no way can the iTunes store be viewed as an open market, in the same way, say as eBay.  And even eBay caves into pressure to remove some items from auction.

This is only the latest in a series of minor goofs they’ve made, the last one being the other side of this coin- they had a backlog of applications that people wanted approved for release on iTunes.  Instead of simply hiring more people they seem to have relaxed their standards.  Good news for developers, but bad news for consumers who are not careful, and bad news for Apple’s image.

The purpose of Apple’s review is nominally to ensure that an application does not interfere with the proper functioning of the consumer device.  When you have millions of these things out there, the last thing you want is to increase your support costs (such as people clogging Genius Bars) due to a poorly written application.  Of course, that’s not the only reason Apple has control.  They want a cut of the money for for-profit apps.  And indeed they would have profited from the distribution of this app, which sold for $0.99.  But if you want a piece of the action you have to work for it, and in this case Apple did not.  Even though the iPhone and iTunes largely sustained Apple’s top line growth, the company cut corners on the editorial review that they seemingly hold so dear.