SYSSEC: January 2009 Archives


January 9, 2009

I disclosed responsibly. You published without warning. He leaked a zero-day.

January 7, 2009

Pete Lindstrom points to an article about what went wrong with Twitter. The short story: one of the admins had a weak password and Twitter has no limited try lockout on their system, so the attacker was able to mount an online dictionary attack. He wasn't even trying to crack an admin account; he just got lucky. Outstanding!

UPDATE: Fixed Pete's name. I'd thinkoed it...


January 6, 2009

In the wake of the recent attack on MD5 in certificates (see my summary here), the topic of replacing X.509 certificates with DNSSEC has come up.
i wasn't clever but i was in that hallway. it's more complicated than RFC 2538, but there does seem to be a way forward involving SSL/TLS (to get channel encryption) but where a self-signed key could be verified using a CERT RR (to get endpoint identity authentication). the attacks recently have been against MD5 (used by some X.509 CA's) and against an X.509 CA's identity verification methods (used at certificate granting time). no recent attack has shaken my confidence in SSL/TLS negotiation or encryption, but frankly i'm a little worried about nondeployability of X.509 now that i see what the CA's are doing operationally when they start to feel margin pressure and need to keep volume up + costs down.

The basic observation is as follows: the role of certificates in SSL is to bind domain names (e.g., to public keys. But this creates a parallel authentication hierarchy; the CA is attesting to your ownership of some DNS zone, but you also need to be able to control the zone itself, or people won't be able to talk to you. It's natural, then, to think about just stuffing your public key in the DNS. Unfortunately, you can't trust the DNS, at least not without DNSSEC. However, if you had DNSSEC (so the argument goes) you could stuff public keys into the DNS and people could then trust them and skip the whole certificate step. This is a fairly natural idea and has been proposed many times over the years (I remember proposing it back in 1996 or so).

It's not clear that this is really as useful as it sounds, for reasons I'll get into in a subsequent post. However, right now let's assume it's useful and explore the design space a bit.

Mostly when this topic comes up, there is a lot of discussion of encoding. In particular, there are two big issues:

  • Should we store certificates or keys?
  • What resource record type should we use?

Certificates versus keys
The argument for keys rather than certificates is straightforward: certificates are redundant. Most of the stuff in the certificate is various kinds of control information (issuer, serial, the signature, etc.) that isn't relevant here because the DNSSEC record is itself a quasi-certificate. And since this stuff is big and we'd like DNS records to fit within 576 bytes, it's naturally to strip things down as much as we can. There's an RR type for this for IPsec, but not SSL.

The counterargument here is that most of our software is already designed to deal with certificates and it's a pain to make it use raw public keys. For instance, if you're doing SSL, the server is going to send you a certificate and you can just memcmp() it against the certificate you get out of DNSSEC. Note that you don't need to use a real certificate here. Self-signed works fine. This also has the advantage that it's a a useful transition mechanism in settings where you don't have DNSSEC; if you have a mechanism for putting certificates in DNS, potentially you could use it as part of a mechanism to reduce client-server traffic (the client tells the server "I think I have your cert, don't send it to me if it has hash X") which doesn't rely on the DNS to provide authenticated data. Oh, adn btw, there already is an RR for doing this as well.

There's actually a third possibility: have the DNS store a digest of the certificate. This lets the DNS act as an authentication channel for the server certificate but doesn't chew up as much bandwidth as the certificate or the public key. Of course, that still requires some channel for the certificate, but if you're doing SSL that happens by default. It obviously works less well for non-cert protocols like SSH, and doesn't give you any kind of preloading benefit.

RR Type
The second issue is what resource record type should be used. While this seems like a topic that ought to be of interest only to DNS weenies, it turns out to be important for at least one reason: you can have multiple services with different keys running on different ports on the same host. As far as I can tell, none of the proposed mechanisms really provide for this. It's not really an issue for IPsec, where there is more or less one cert for each IP, but it's definitely an issue for SSL or SSH. One could imagine inventing a new record type which segregated by port, or using a TXT record, or... Anyway, my impression is that this isn't totally trivial.

Of course, we've totally ignored the question of whether this is a good plan. But this post is getting awfully long, so I'll deal with it in a subsequent post.


January 5, 2009

Computerworld reports that a bunch of famous people's Twitter accounts were subverted and used to send quasi-embarassing messages:
"This morning we discovered 33 Twitter accounts had been 'hacked,' including prominent Twitter-ers like Rick Sanchez and Barack Obama," Twitter co-founder Biz Stone said in post to the company blog. "We immediately locked down the accounts and investigated the issue. Rick, Barack and others are now back in control of their accounts."

Earlier in the day, the hacked accounts had been used to send malicious messages, many of them offensive. CNN correspondent Rick Sanchez's account, for example, tweeted a message claiming that "i am high on crack right now might not be coming to work today," while Fox News' Twitter update reported "Breaking: Bill O Riley [sic] is gay," referring to the network's conservative talk show host.

According to Twitter, the accounts were hijacked using the company's own internal support tools. "These accounts were compromised by an individual who hacked into some of the tools our support team uses to help people do things like edit the e-mail address associated with their Twitter account when they can't remember or get stuck," Stone admitted. "We considered this a very serious breach of security and immediately took the support tools offline. We'll put them back only when they're safe and secure."

I would be interested to hear more about exactly what happened with the support tools—though I doubt we will. It's easy to imagine a bunch of vulnerabilities in these tools (remote compromise, predictable URLs, insecure address changes) and most of them are easily fixed. However, even if the tools are implemented correctly, account recovery is one of the most challenging problems for this kind of application. The basic problem is that you don't know that much about your user other than their username and password, so it's very hard to distinguish an attacker from a user who has forgotten his password. The two conventional techniques are "security questions" ("what's your mother's first pet's maiden name and when did it graduate from high school?") and email recovery ("we've sent a message to the email address you registered with. Please click on the link in the message"), but neither of these is really that great for reasons the security community has hashed over ad nauseum. Obviously, we can make account theft harder by creating a tighter relationship with the user (get more personal information, have him pay for access so you can double check is credit card number), etc. However, this comes at a convenience and effort cost. Unless you're willing to make password recover incredibly painful, it's pretty hard to reduce this risk down to the level where a dedicated attacker wouldn't have a shot at cracking some people's accounts (and that's not to mention the use of weak passwords). This isn't to say, of course, that Twitter's tools aren't broken. As I said, I don't know much about that.

What I find interesting about this attack and most other "content" hijacking attacks you hear about (e.g., Web sites) is how lame they are. The attackers take over someone's site and then post something transparently forged that is supposed to be embarassing to the victim. Surely if you were serious about it you could generate some content which would be credible and much more damaging (remember when Google replayed an old article and tanked United's stock price?). The more that organizations use the Web, Twitter, etc. as primary communication mechanisms, the more effective this is going to be.