Today’s tutorial is nothing new, but I just thought I’d share some recent experience with Microsoft’s PowerShell. I’ve been playing around with PowerShell (PS) for a little while now, nothing too extravagant. I’m not an administrator, so I don’t have hundreds of little tasks I have to do on a daily basis (unless I can write a script to help me wake up and get ready in the morning.. C:\>Set-TeethClean ? ) – Anyways, I was recently assigned the rudimentary task of searching through the Windows Certificate store and finding all CAs that were signed with MD5. If MD5 rings a bell it’s most likely because of this.

I really didn’t want to go through the list one by one, double-clicking, then selecting the Details tab. So, I decided there had to be an easy way to parse this information. My first idea was to fire up Visual Studio and write a quick C# app to do this as it has built-in Certificate Store classes/functions. This seemed too cumbersome, but I still wanted to leverage the .NET framework for the same features. PowerShell it was then.

Read the rest of this entry »

If you haven’t heard yet, a practical attack on the X.509 infrastructure using MD5 hashes has been demonstrated at the Chaos Communication Congress (CCC) today.

The basic gist of the attack is that a “normal” certificate is issued from a well-known and trusted CA (in this case “Equifax Secure Global eBusiness CA-1″) and then use the “magic” of MD5 hashing to create a certificate that collides with the “real” one, but just happens to be a CA. This CA can then issue certificates as they please, and your browser will trust them, no questions asked.

The details are a bit more in depth, and unless you study cryptography, you will find rather boring and dry. However, MD5 hashes have been known to collide in X.509 certificates since 2005, and this paper just takes it a step further and shows how bad this really is. The attack requires a little bit of money (to buy certificates) and some statistics on how the CA operates (how soon certs are issued, what the “next” serial number will be). Then a knowledge of how to collide MD5 hashes is used to create a new certificate – with the CA basic constraint set to “true”. Suddenly, you have a CA certificate that is trusted by all of the major browsers.

What does this mean for “normal” people? It means that an attacker can now create a site that looks just like your bank’s but takes your username and password, and your browser isn’t going to complain about it. You’ll have a lock, or a yellow location bar, or whatever your browser uses to indicate that the site is “trusted” and “secure”. However, you’ll be giving your username and password to the attacker.

What can you do about it? Immediately, remove the Equifax Secure Global eBusiness CA-1 from the list of trusted CAs – I’ve provided links below for how to do that on various systems and browsers. However, that is certainly not the only CA that is vulnerable, just the one that’s been proven to be vulnerable. There are several CAs listed in the linked paper that issue MD5 certificates – stop trusting them too. In the long run, the CAs have to fix themselves and stop using MD5 hashes in certificates. SHA-1 is better, and SHA-256 is best (good luck finding a CA that issues only SHA-256 hash certificates).

How to distrust CAs:

• OS X – Keychain. Double-click the CA in X509Anchors (Tiger) or System Roots (Leopard) and under Trust, select “Never Trust”.
• Firefox – The instructions are for the Comodo certificate, but it’s the same thing.
• Internet Explorer (and anything that uses MS CAPI, like Outlook).