More than one way to skin a CA

Alex Sotirov, Jacob Appelbaum, and crew did some awesome work. They showed that it was possible to exploit RapidSSL's use of MD5 for signing certificates in order to create their own rogue CA signing certificate. This exploitation is many orders of magnitude more severe than when I used a loop hole to get the login.live.com certificate from Thawte.

So what should happen when a CA screws up? Last summer, folks thought that the CA which issued the login.live.com certificate should have its status as a trusted CA revoked. I'm sure people feel the same way about RapidSSL. In my opinion, they are correct. However, it is clear that this could not happen, as it would effect the millions of businesses that rely on these CAs being trusted, which is what a VP at Verisign reaffirms in the comments of this post.

A different question that Appelbaum asked during the presentation in Berlin, and one I've asked many times during my research of Certificate Authorities, is: if we were able to do this, how do we know if anybody else has done the same thing?

No one can ever give a straight answer. I've reported a number of flaws to CAs responsibly; flaws that can allow people to get certificates that they shouldn't be allowed to get. The flaws get fixed, and thats great, but the damage that could have already been done is immeasurable.

It sucks when an online retailer gets hacked one or even multiple times. It's bad for them, and it's bad for their customers. When a trusted CA gets hacked, it sucks for the ENTIRE INTERNET. The CAs are supposed to help us secure the Internet. What does it mean if they are not secure themselves? To me, it means that we can't rely on trusted third parties.

I know that abandoning PKI and trusted third parties is a bad idea, and probably won't happen. However, people need to be more involved in the process of making trust decisions when communicating online. And I don't mean little yellow locks and green address bars. I have some ideas on how to make better use of SSL in web browsers and other SSL clients. So far, I've gotten mixed responses to them from my peers :-) However, with what the Sotirov/Applebaum team accomplished, maybe my ideas will make more sense. Stay tuned...


(Cross post on PhishMe)

You don't need to be a hacker to abuse DNS

This morning I woke up, took a shower, and went straight to my laptop to let everyone on Twitter know that I had made it through another night, and had even decided to bathe. Unfortunately for me and my loyal followers, Optimum online had some tricks up its sleeve. It seemed that my DNS servers could not resolve www.twitter.com or twitter.com. Hmm. Check out Google. It's up. CNN? Up. Log on to EVDO, Twitter is fine. What the heck?

This DNS error was not like any I was used to seeing. I wasn't getting a vanilla browser message saying the page could not be displayed. No, I was getting an Optimum branded page telling me that the "domain could not be found." Fortunately, the page offered me a variety of SPONSORED and pay-per-click links that I could burn some time clicking on. Of course, when you follow the links that actually go to Twitter, DNS still would not resolve, and I'd end up on the same "domain not found page," where I could click on more links and generate more cash for Optimum online.

Optimum better shape up. Fios is in town now, and I don't like it when my ISP earns cash if their DNS servers screw up. Let alone the thought that they could intentionally force DNS glitches in order to generate some fast cash via sponsored links. What a racket!

Lets not forget about the bad habits this teaches end-users. "The server you were looking for cannot be found, so here click on these links instead." I can't wait until I see a message like that on my banks web site!

Who thinks ISPs would not stoop so low as to launch DNS attacks against their own customers? As far as I'm concerned, thats what Optimum did to me.

CheckFree.com owned; SSL, little yellow locks surrender.

A Washington Post blogger reports that the CheckFree.com domain name was hijacked. CheckFree is an online bill pay solution which many banks use to provide customers with a convenient method of making payments online. Apparently, attackers took control of the domain name by obtaining Check Free's credentials for their domain registrar account at Network Solutions. They were able to simply change the name servers for CheckFree.com (as well as any other Check Free domain), and all users would be redirected to attacker controlled web servers hosting malware and self-signed certificates.

On SlashDot, one person mentions that they were served a self-signed certificate when they clicked through to CheckFree from their bank. This attack could have been even nastier if the attackers had procured a legit CA signed certificate. Maybe the Network Solutions credentials also worked for CheckFree's EquiFaxSecure/Geotrust account (check out the cert for https://mycheckfree.com). If they had a valid cert and weren't hosting malware, who knows how long the hijacking could have lasted. All Check Free traffic could have been routed through the attacker servers in plain-text. Scary.