Two-factor authentication turns off a lot of people because they think it’s too hard but it honestly isn’t, and the security benefits it provides are outstanding. Two-factor authentication operates on two principles or components for an authentication “token” (or password for lack of a better term): one thing you know (your password) and one thing you don’t (a random time-based PIN that a hardware device generates for you). This means that if someone has my username and password, that information is utterly useless without having my hardware token (which can be, in the case of Google, an iPhone or Android phone, etc.). Which makes my account really quite secure, and certainly more secure than it would be with just a password.

If you sincerely care about your Google Apps security, you really owe it to yourself to check out the two-factor authentication support. It’s easy to setup, cheap to setup, and easy to use as well.

CERT changes keys often — way more often than their once-a-year policy on their web site indicates; well, this year they have anyways. Previous years were one key a year. However, they don’t follow any of these “best practices”. And they know it, because I’ve told them in the past. And yet, even now, they still can’t get it right. What’s more amusing is that on their Sending Sensitive Information to CERT page, which is SSL encrypted, shows two different fingerprints. For posterity, I took the following screenshot:

The wrong fingerprint listed in section #2 belongs to the old key.

The key released today is:

pub   2048R/72C33BD5 2010-09-13 [expires: 2011-09-30]
      Key fingerprint = 79DA 4C07 0AE5 EB20 D641  3F80 67B1 5F29 72C3 3BD5
uid                  CERT Coordination Center 
sig 3        72C33BD5 2010-09-13  CERT Coordination Center 

While the previous key is:

pub   2048R/9A478CA0 2010-03-03 [revoked: 2010-09-13]
      Key fingerprint = E9EA E7FB D8AF E5AE FD36  41DE 5146 432C 9A47 8CA0
rev          9A478CA0 2010-09-13  CERT Coordination Center 
uid                  CERT Coordination Center 
sig 3        9A478CA0 2010-03-03  CERT Coordination Center 

To see how things are getting sloppy, we need to go back a bit further to see what had been done in the past:

pub   2048R/B7FBBBC1 2010-01-20 [revoked: 2010-03-03]
      Key fingerprint = 66A6 DAC9 3014 21CB DCA6  A6F6 3389 F064 B7FB BBC1
rev          B7FBBBC1 2010-03-03  CERT Coordination Center 
uid                  CERT Coordination Center 
sig 3        B7FBBBC1 2010-01-20  CERT Coordination Center 
sig          AF30D800 2010-01-20  CERT Coordination Center 

Notice the difference here? This third-latest key was signed by another CERT-owned key (AF30D800), which was the previous-to-that key used. Trust is then established to the new key, from the old (known) key. The most current and previous keys were not signed by their predecessors, which makes them harder to trust. So in the last three keys, two are self-signed, one is properly signed to establish trust (by the previous key). What’s even more sad is that key AF30D800 was nicely signed: not only by the previous key, but also by a “master key” which also establishes more authenticity of the key:

pub   2048R/AF30D800 2009-06-15 [revoked: 2010-01-20]
      Key fingerprint = 943C 0A2E 4CB8 4C8F CA53  22F8 680D 4DC1 AF30 D800
rev          AF30D800 2010-01-20  CERT Coordination Center 
uid                  CERT Coordination Center 
sig 3        AF30D800 2009-06-15  CERT Coordination Center 
sig          18DEBE70 2009-06-15  Networked Systems Survivability Master Key 
sig          14C33F57 2009-06-15  CERT Coordination Center 

Now this one is a good key, a trustable key. The last two keys are not.

Couple that with the half-updated web page and you’re left scratching your head — or, at least, I was. Not so much this time because, sadly, I’m no longer surprised. But last time I actually phoned CERT to verify the new key’s fingerprint because I had nothing to trust it with. In fact, when the mail came out to notify of the new key, it was signed with the new key, not the old key.

Ummm… excuse me, but I can spoof sending a mail from cert@cert.org and generate my own key with the uid cert@cert.org and bloody well sign it with the spoofed key I just generated! The only thing I couldn’t do is update their web page but, honestly, I wonder how many people check. And of those that do, have they done it in the past and noticed prior inconsistencies and just chalked it up to… incompetence? Negligence? Key distribution malpractice?

Again, there is nothing for me to trust that this new key is legit.

It’s sad that an organization built around security has no clue about this. What’s worse, is they’ve been told (twice!) about a better way to distribute new keys. I know. I told them. Both times.

So, to recap, these are things you should do when distributing a new GPG key:

1. Sign the email sending out the new key with the old key. Seriously, it establishes trust and proves you are who you say you are
2. Fully and completely update your web site. It’s nice you have one, and it’s nice that it’s semi-updated, and even better that you can get to it via SSL. But if it lists the new key in section 1 and section 2 is about verifying the fingerprint but lists the old key’s fingerprint, how do you trust any of it?
3. Sign the new key with the old key. It proves that the person/organization who has the old key trusts the new one enough to sign it. Like giving it a seal of approval or just saying “hey, this is legit”
4. For Pete’s sake, revoke the old key! It doesn’t have to necessarily be in the same message, but it should be revoked. Heck, send out a mail signed with the old key, containing the new key, and then send out another message signed with the new key, revoking the old key. Or have one email message sending two different GPG-signed sections so one email does it all.

None of this is difficult to do, and it makes trusting these new keys so much easier. I’ve not paid attention to see if other people/organizations fail so badly here, but I don’t get what makes this so hard to do. It’s not rocket science, just common sense. I can see Joe Average maybe not thinking about it, but for an organization like CERT? Come on. How are we supposed to trust what you send out when you can’t even get Simple Key Management 101 right?

Another thing that makes this a problem today is the how fast information spreads, and how quickly something posted online is taken as gospel. For instance, starting a rumour like this is extremely simple and can be done by one person with a bunch of email addresses and a little bit of knowledge. This kind of social engineering can be used for a lot of things beyond just phishing (money, passwords, whatever). It can be used to sow confusion, which could be used as a smoke-screen to cover other nefarious deeds and redirect attention from the truly nasty things going on, and it can also be used to perpetrate such fear that people are essentially causing a Denial of Service against themselves and/or their customers simply because of rumours spreading like wildfire.

Either way, half the battle here is dealing with this stuff smarter and better, and more responsibly. Outfits that claim inside information but aren’t willing to share it are not being responsible. I’m not saying to necessarily share it with the public at large (right away, at least), as that may not serve the public’s best interest. But to provide crucial information to affected vendors (who can then take that and develop fixes to help a much larger audience) or upstream is absolutely the responsible thing to do.

To that end, I’d like to share a few links that can help people disclose issues they are aware of, or suspect, in a more responsible fashion. Holding info tight to your chest like a bag of sour gummies doesn’t help anyone but you, and even then, it can harm more than help. Individuals or companies that claim to have inside info and are working on a fix may not be the appropriate people to work on a fix in the first place. After all, who knows code better than the folks who wrote it? It makes more sense to take the issue and all the information you have and open up communication with the vendor/upstream in order to facilitate an appropriate fix that helps *everyone*, not just yourself. Quite often the fix you suggest is quite a ways from that which the vendor or upstream would use, and may cause more problems than it corrects. So getting appropriate people involved just makes sense, and peer review is an asset that the open source community understands — and views as necessity.

So here are a few links:

• OSS Security wiki: Security-related mailing lists contains a list of mailing lists you can use to get in touch with people who care and sincerely want to help. Many vendors are represented on both public and private lists, suitable for discussing issues that are currently public (oss-security) or those that are currently private (vendor-sec)
• What to do if I encounter a security issue is a page that documents how to deal with a security or suspected security issue and how to make sure it gets to the right people
• Backporting of Security Fixes talks about why many vendors, including Red Hat, backport fixes to packages rather than just updating to new ones (I’m including this because there was a lot of misinformation about OpenSSH versions being out-of-date and presumably insecure because they aren’t the latest-and-greatest)
• Red Hat Security Contacts and Procedures is the contact page for the Red Hat Security Response Team; please use it if you think you have something as we absolutely want and love to help with this sort of stuff and if you don’t know who to contact, chances are we can take care of that on your behalf

Responsible disclosure is really important, and everyone needs to do their part when it comes to this stuff. Irresponsible disclosure, or no disclosure, hurts more people than it helps and has been the source of many a headache for a whole lot of people over the years.

]]> http://linsec.ca/blog/2009/07/09/towards-responsible-disclosure/feed/ 0