Trust Subversion

Calvin Klein Models Subvert Trust!

recently, a report went out stating that Public Key Infrastructure (PKI) is vulnerable to trust subversion. I'll spare the gory details, as they are all in the original report - but basically MD5 collisions are used to make a certificate appear as though it is signed by a trusted Certificate Authority (CA). This is a major flaw, but don't be discouraged. After all, the internet ended a while ago, remember...

Why is this Rogue CA attack important to know about?

Well, from the research that was done and the proof of concept that was demonstrated, an attacker can create a certificate for any domain. This certificate will appear to be signed by a trusted CA. Thus, you will see that the site's cert is trusted and you will never get any notification to the contrary.

Normally, a trusted CA will issue and sign a certificate and then if the browser trusts the signing CA, you will see a padlock in the GUI and you will often times see a message that lets you know that the certificate of the web site is trusted. If the CA is not trusted, you are shown a message that the certificate is not signed by a trusted party and you are given the option to leave or continue. This is PKI in a nutshell. The entire system relies on trust of the CAs and the CAs in turn provide reputable and responsible operation. This works very well, until you can subvert that trust.

What is trust subversion?
(no it's not a book about a doctor)

Any time a security measure is based on trust, an attacker has the ability to subvert that trust and use it to his advantage.

What I call "trust subversion" is any act that takes advantage of a relationship of trust between two parties. This encompasses specific spoofing attacks, masquerading, Man-in-the-middle (mitm) and other attacks. By appearing as a trusted party, an attacker can gain important leverage over a situation and can often gain confidential information (phishing/sniffing) or even infect a target computer with malware.

Real World Attack Vectors

DNS Cache Poisoning
You may be aware of the DNS cache poisoning attack that was all the rage in 2008. Well, if a user can use this type of attack to make a DNS server redirect a request for a trusted site to a rogue site and that rogue site is also signed with a rogue CA, then there is nothing that the user will be able to see under normal operating conditions to alert him (assuming the site is a good knock-off of the original and not obviously fake). This is probably the most common attack vector that will be reported.

Phishing Emails
Of course there is the ubiquitous phishing email. If you receive an email that appears to be from a bank or anywhere for that matter, DO NOT CLICK on anything (this should be ingrained into all our heads by now). You may be forwarded to an HTTPS site and think all is well, but with this attack, you can be owned.

Of course there are endless possibilities, but any way an attacker can redirect a user to a fake trusted site with a rogue cert, there lies the ability for subversion.

What should I do to prevent this?

Recommendations are in detail in the original report under "Countermeasures."

There are a few things to be aware of. First, if you are an end user, there is nothing that you can do in your normal browsing habits that will easily detect subversion. You can, however, go out of your way to inspect each certificate for subversion (details in report).

As website owners/admins, there is more that we can do, though. If you have a certificate that is hashed with the MD5 algorithm, ask your CA if they can issue you a new one signed in another algorithm (SHA-1 or SHA-2 for instance). Also, although this is not listed in the report, you can check into Extended Validation Certificates (EV Cert) - I'm not a researcher, but it stands to reason that these types of certs may prevent this type of subversion by forcing more validation checks of the certificate. I would be interested in finding out if this is indeed the case - your CA may have tested this and would be a good resource to ask.
Posted on 12:59 PM by Tim Cronin and filed under , | 0 Comments »