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.

Web (in)Security and What Can Be Done

We all like to think that web security is perfect, but we all know better.  You know about spam, phishing, and all manner of malware.  You probably run a virus scanner on your computer.  But what you don’t expect and shouldn’t expect is that the core of our security system would have a flaw.  It does, and has, from the beginning.  What’s more, it’s a known flaw.

How is it your browser decides to trust a site, or to show that lovely lock icon and perhaps a green URL bar when your communication is both encrypted and verified to be to a specific end point?  The simple answer is that your browser provider, Microsoft, Mozilla, Apple, or Google, has made a decision on your behalf that – at least as initially configured – your browser will trust a certain set of authorities– certificate authorities (CAs)– who will validate others.

One such certificate authority got hacked.  Badly.  And because they were trusted by your browser, so might you have been.  Here’s how it works.

  • When you access a URL that begins with “https”, a certificate is sent by that site that is signed by one of the trusted CAs, saying “yes, I agree that this is google.com,” (for example).  If someone gets in between you and Google, they won’t have the private key associated with that certificate, and they won’t be able to validate to your browser.
  • If someone breaks into a CA and gets a certificate for “google.com” (again, for example), and then gets between you and the real Google, they will be able to masquerade.  It doesn’t matter which CA it is, as long as your browser trusts it.  Google needn’t have any relationship with that CA.

This is what happened with DigiNotar.  Not only did they get hacked, but they didn’t notice.  They didn’t have sufficient controls in place to even spot the attack.  That they should have had.

But now there’s something else we can do.  In the Internet Engineering Task Force (IETF), a few folks led by a gentleman by the name of Paul Hoffman have developed an approach where sites like Google can effectively register which certificates are valid for them in an separate alternative authority that we largely trust, the Domain Name System (DNS).  You use DNS to convert site names like ofcourseimright.com to IP addresses like 10.1.1.1.

The group working on it is called “dane“.  Had the dane mechanism been in place in the browser, the attack on Diginotar and Google would have failed, even if Google was a customer of Diginotar (which they weren’t).

When we speak of security we always discuss defense in depth.  That is– never rely on exactly one mechanism to protect you, because at some point it will surely break.  In this case, the attacker needed to (a) compromise the CA and (b) get in between the service and the end user to succeed.  Had dane been in place, atop (a) and (b), the attacker would also have to have compromised Google’s DNS for the attack to succeed.  That’s likely even harder than compromising a CA.

Dane has another potential benefit: in the long run, it may get browsers completely out of the business of telling you who to trust, or it will extremely limit that trust.

This attack also demonstrates that as threats evolve our response to those threats evolves.  Here we understood the threat, but just didn’t get the work done fast enough before a CA was compromised.  I still call this a win, as I think we can expect to see dane even faster than we expected before the attack.