Top Web Hacking Techniques of 2008

Jeremiah has put out a request for the top web hacking techniques of 2008. This post serves to summarize my suggestion, which is ActiveX Repurposing attacks. These are attacks where malicious web sites abuse the functionality of ActiveX objects already installed on Windows machines, in order to download and execute code (among other things). No debugger necessary :-)

References:

1. An ActiveX Dropper described by Dean: Owning the Client without an Exploit

2. Sensepost Juniper SSL VPN ActiveX repurposing by Haroon: ActiveX Repurposing.. (aka: Other bugs your static analyzer will never find..) (aka 0day^H^H 485day bug!)

3. SonicWALL SSL VPN ActiveX repurposing by yours truly: Network World article
and SonicWALL announcement.

4. Hmm, I thought this was more recent, but it was actually from 2005 (read down in the wiki): Sony DRM Root Kit Scandal

How do you trust?

SSL PKI is designed to do two things: encrypt data on the wire, and allow web site validation through the use of trusted third party signatures. The former works pretty well, the Debian weak key debacle aside. Unfortunately, the latter seems about as robust and secure as Windows 98. Case in point, https://discovercard.com. As my colleague Mike Walker points out, DiscoverCard.com forces users to enter credentials on a page served over an insecure HTTP connection. In doing so, Discover leaves users with no real way to tell who they are giving their credentials to. This is a perfect example of an implementation specific design flaw that fails open and renders SSL site validation useless.

Unfortunately, Discover Card isn't the only organization breaking PKI. The pillars of Internet security, our trusted third party Certificate Authorities, have been having a rough time recently. A number of implementation specific flaws at multiple CAs have allowed outsiders to abuse their systems and obtain certificates for which they are not authorized to hold. Sure, these implementation specific flaws can be fixed, but the lasting damage to the trust we have in PKI can't be undone. Further, the way PKI has been handling these situations seems to further undermine whatever trust remains.

Last summer when I disclosed the details of how I got the live.com certificate to Microsoft, I told them I wasn't going to do anything bad with it, they said thanks, we shook hands, and that was pretty much the end of it. A few weeks ago, when Sotirov and crew disclosed that they derived their very own key capable of signing certificates that would be trusted by all web browsers, the researchers told Microsoft, Mozilla, etc, that they wouldn't do anything bad with it. These companies again said thanks, hands were shook, and that was pretty much the end of that.

We rely on WebTrust audits and other mechanisms to ensure that our commercial Certificate Authorities do their job well, and so we can be sure we're sending our data to the web sites we trust. Unfortunately, when the audits are useless and the Certificate Authorities screw up like they did in the above two scenarios, companies like Microsoft and Mozilla are forced to make a tough call:

Do they
a) Revoke the root CA for which a duplicate signing key was derived by unknown individuals, thus breaking the Internet for many businesses and individual users
or
b) Do nothing and trust that these guys really only have an expired certificate, and didn't generate one valid for the next couple of years since they so very easily could have.

In the end, the trust that backs PKI is replaced with the trust of a few select individuals at the organizations who manage our root certificate programs (a.k.a the browser vendors). The millions of dollars spent on web trust audits are meaningless. The CAs could have just paid all of their money earmarked for audits to Sotirov and Appelbaum in exchange for their silence, and PKI would lived to fall another day.

Burn your SSL Certificates?

PKI, while good on paper, is hard to implement securely. It has taken almost two decades for us to have web browsers that actually support the one method that PKI has to protect itself from rogue certificates: Certificate Revocation Lists. And it doesn't really matter, since not everyone is using IE7 or Firefox 3 yet. CRLs, which are essentially blacklists, are completely ineffective when you don't even know what rogue certificates are actually in existence.

I don't think trusted third parties are enough. We need technology that puts the ability to make trust decisions back in the hands of end users, rather than trying to make these decisions for them.

So what can we do differently? I'm of the mindset that client side certificate / public key caching, like that of SSH, can drastically improve our ability to make trust decisions when communicating on the Internet. SSH shows us that we can communicate securely without trusted third parties. The next question is how best to apply this to web browsers. Hashes of public keys are not easily consumed by casual Internet users. Another Intrepidus colleague, Aaron Rhodes, brought up the idea of vanity hashes that are actually easily recognizable patterns. This could help, but it would certainly complicate key management.

In an effort to actually try and help make things better, rather than just ranting about how bad PKI is on this blog, I've actually been working on a plug-in for Firefox that lets users white list SSL public keys SSH style and alerts the user when they change. It is actually alot harder than it would seem. In my next post, I'll talk more about this plug-in, and the challenges I've faced in getting it working.

-schmoilito

(Cross post on blog.phishme.com)

A brief description of how to become a CA

Anyone can create a Certificate Authority. Check out this blog describing how to do it with OpenSSL.

Becoming a trusted CA is a different story. Microsoft, Mozilla, Apple, and other browser companies and OS vendors have a policy stating what it takes to participate in their root CA programs.

http://technet.microsoft.com/en-us/library/cc751157.aspx
http://www.apple.com/certificateauthority/ca_program.html
http://www.mozilla.org/projects/security/certs/policy/
http://www.opera.com/docs/ca/

Nobody is perfect

Just before Christmas, an admin from StartCom certificate authority disclosed that he was able to procure an SSL certificate for Mozilla.com from a registered agent of the CA Comodo. He was not authorized to obtain this certificate, and the RA and CA clearly failed to properly vette his cert signing request. Shame on Comodo. You can read the entire saga on mozilla.dev.tech.crypto.

The discussion resulting from StartComs blog post is quite interesting, and touches on many issues spanning from internal CA domain validation procedures, to how to revoke a certificate in the Mozilla root cert program. One issue in particular, is exactly what I talked about in my last post.

Frank Hecker, of the Mozilla Foundation, said "[right] now we have no real idea as to the extent of the problem (e.g., how many certs might have been issued without proper validation, how many of those were issued to malicious actors, etc.)."

When a flaw in a CA validation mechanism is uncovered, it can sometimes be trivial to fix. The hard part is determining if any other certificates were obtained by taking advantage of the same flaw, and then revoke them. Although I can imagine a methodology for this process, I can't comment on how any given CA would actually tackle this problem. Based on my own application security experience, I will say that I'm sure lots of logs that would need to be parsed, might not actually exist.

One person who commented on the StartCom post that started this all critiqued the post by saying it seemed dodgy that StartCom was blatantly pointing out flaws in a competing CA. The reader did, however, understand the severity of the problem that was found and thanked StartCom for publicly disclosing it. I agree with the reader, and I think StartCom did a good thing in disclosing this bug.

So in the interest of full-disclosure, here is what happened on Friday December 19 (three days before the StartCom disclosure). I found a flaw in StartCom's domain validation mechanism that easily allowed anyone to authorize themselves for ANY domain name, on various .TLDs. While I only tested .COM, many other TLDs were available including .GOV.
The screen shot above shows the domain names my StartCom account was allowed to create signed certificates for. These certificates would have been trusted by Firefox, but not Internet Explorer. The first one is a domain I control. Phishme.com and Intrepidusgroup.com are domains owned by my employer for which I am not an authorized contact, and for which I should not have been, but was, granted a signed certificate. Needless to say Paypal.com and Verisign.com are companies I'm also not authorized for.

Fortunately for Verisign and PayPal, a defense in-depth strategy succeeded for StartCom. While I by-passed StartComs domain validation process, my attempts to create a signed certificate for Verisign.com was flagged by a black-list and not permitted. This is good news for the prominent sites on the black-list, but bad news for lesser known sites that rely on the trust gained by having a valid SSL certificate (small credit unions, for example).

Because they're a good CA, the StartCom team was immediately aware of my attempt to get a certificate for Verisign. I disclosed the details of the flaw to them, and the simple problem was fixed within hours. But the question remains: did anyone else take advantage of the flaw?

PKI is not a perfect system, and there is no perfect CA. But, there are at least two types of CAs. One type treats SSL certificates as a cash cow, pushing signed certificates out the door, and counting the money. The second type is like StartCom. This second type understands that trust comes before money and that trusted CAs are a critical piece of Internet infrastructure.

(cross post on PhishMe)