Tuesday, December 30, 2008

MD5 Collisions Allow Forged SSL Certificates

For quite some time we have been told about the weaknesses in MD5 and the potential for documents to be generated with the same md5. Hopefully many people have migrated away from md5; however, would you believe that several certificate authorities still use MD5. And some of these CAs are trusted by your browser!

What are the consequences of this you ask? An attacker can utilize the MD5 collision vulnerability to forge a certificate which contains the same MD5 as another valid certificate. The end result is that an attacker creates a forged certificate which is completely trusted by the browser!

Here are all the details - just released today.

Here is the list of certificate authorities using MD5. You may want to prune those root certificates from your browser

  • RapidSSL C=US, O=Equifax Secure Inc., CN=Equifax Secure Global eBusiness CA-1
  • FreeSSL (free trial certificates offered by RapidSSL)C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Network Applications
  • TC TrustCenter AGC=DE, ST=Hamburg, L=Hamburg, O=TC TrustCenter for Security in Data Networks GmbH, OU=TC TrustCenter Class 3 CA/emailAddress=certificate@trustcenter.de
  • RSA Data SecurityC=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority
  • Thawte C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com
  • verisign.co.jp O=VeriSign Trust Network, OU=VeriSign, Inc., OU=VeriSign International Server CA - Class 3, OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign

-Michael Coates

Monday, December 29, 2008

Pruning the Browser's Web of Trust

Whether you like it or not, your browser has established a fairly robust web of trust in order to implement SSL. Root certificates are installed in your browser and are used to determine if a certificate has been issued by a trusted third party. Ever received the following error message? The error is generated because the certificate was issued by someone that is not in your root certificate list.

www.cacert.org uses an invalid security certificate.

The certificate is not trusted because the issuer certificate is unknown.

(Error code: sec_error_unknown_issuer)
So who does your browser trust? Well for starters, it depends on the browser. Internet Explorer and Mozilla have very different root certificates.

To view Internet Explore Root Certs:
Go to Tools -> Options -> Content , now press the "certificates" button and navigate to the "Trusted Root Certificate" tab




For Mozilla:
Go to Tools -> Options -> Encryption, now press the "view certificates" button and navigate to the "Authorities" tab



First you should notice that Internet Explorer has significantly less root certificates than Mozilla. In fact, Mozilla has some certificates that just scare me. AOL Time Warner? I don't want them to validate certificates for me!

But let's step back, what does the root certificate actually do for us as the casual web browser? Well, when you browse to an SSL site, the browser will validate the certificate by performing checks such as ensuring the domain name matches the domain name listed in the certificate and that the computer's date is within validity period listed in the certificate. In addition, the browser will check if the certificate was issued by a trusted third party. Since anyone can create a certificate, this is especially important. Using OpenSSL, I can create a certificate for microsoft.com or any other website. However, the browser will detect that I, Michael Coates, am not listed within the trusted root certificates of the browser.

Now you should be thinking, what happens if Michael Coates was a trusted root certicate? Then he could issue certificates for any website to anyone and your browser would happily trust the site. Goodbye trusted SSL!

Luckily, I am not in your root certificate list. However, you should be questioning the root certificates that are listed. Since the holder of those certificates (ie verisign, thawte, comodo, etc) can create and issue new certificates to anyone for any site. You are trusting that the holders have sufficient policies and procedures to validate the identity of the requestor. Wouldn't you be concerned if a random individual could easily get a valid SSL certificate for a major website?

Now it's time to make some decisions - who do we really need to trust? Should we trust AOL? Should we continue to trust Comodo? Each root certificate means you are trusting whoever owns that certificate to properly validate the identity of anyone they issue a certificate to.

Personally, I think some pruning is needed. The security of my transactions with my banks is far more important than being able to establish secure sessions with sites using certificates from TÜRKTRUST Bilgi İletişim ve Bilişim Güvenliği Hizmetleri A.Ş.

-Michael Coates

Sunday, December 21, 2008

Eating your own dogfood

I, and likely many of the readers of these posts, are security consultants and provide security recommendations to our clients in one way or another. As we continue to tell other people how to be secure, we must not forget that we have to take our own advice. Just consider the business risk of a security company suffering a security breach! Not exactly a top selling point on your sales slick sheet

From the article:
A local business owner is on the hook for a $52,000 phone bill after his voice-mail system was hacked and hundreds of calls were made to Bulgaria. Alan Davison, who owns HUB Computer Solutions, noticed something was wrong when "feature 36" -- a message unknown to him -- kept popping up on his phone.
Fraud is a pain and will no doubt require substantial follow-up to resolve the situation. However, the bigger issue may be convincing customers to still buy the IT security and VOIP consulting services offered by HUB Computer Solutions.

-Michael Coates

Friday, December 5, 2008

WebScarab Search Plugin Examples

Thought I'd share some of my favorite Search strings for webscarab.

If you've tried to use the search plugin before you may have scratched you head a bit in confusion. I certainly did for awhile. That's not because it doesn't work, its just because it doesn't work in the way we think of search (ie google style). However, once you learn how to use it, it is incredibly powerful.

For the record, most of these search strings I found posted in mailing lists (several from Rogan himself). I thought I'dd add the few I created and post them all together for all to enjoy.

Catch cookies not using secure flag when connection is over https
request.getURL().toString().startsWith("https://") && response.getHeader("Set-Cookie").indexOf("secure") == -1
Similarly, find cookies using the secure flag when connection is over https
httpsrequest.getURL().toString().startsWith("https://") && response.getHeader("Set-Cookie").indexOf("secure") > -1
Detect if the session ID is exposed from URL rewriting
request.getURL().toString().indexOf("jsessionid") != -1
Look for the password (or any other string) within in a response
new String(response.getContent()).indexOf("the_password") > -1
Filter out just the POST messages
request.getMethod().equals("POST")

And if you are having trouble with the Search gui for some reason, here's the steps broken down:
  1. Add a title for your search in the description box
  2. Add one of the above search strings to the search expression box
  3. Hit Add
  4. Capture some traffic & do some things
  5. To view the results, select the title within the box located below the add/delete/reload button


-Michael Coates

Monday, December 1, 2008

INSECURE Magazine features OWASP Portugal

December's issue of INSECURE Magazine featured a 3 page article on the OWASP Portugal Summit.

See page 68

-Michael Coates