Bruce Cowper and myself are currently at Black Hat taking in a largevariety of talks. We’re here both out of passion for the securitycommunity and to cherry pick some of the best content and speakers forthe upcoming Security Education Conference in Toronto (SecTor).
Over the next couple of days, we’ll be posting some of our learningshere in Vegas. Below is some thoughts from Bruce on the latest SSLattacks.
——————-
It is interesting to me that much of the advice we give about secureonline transactions (banking / shopping / email etc) revolves aroundmaking sure you are using a website protected by an SSL encryptedconnection. We are all familiar with the idea of looking for thepadlock or using HTTPS://… These systems are based on using acertificate to encrypt the connect. In other words, we put our trust ina certificate issued by a vendor such as Thawte or VeriSign amongstothers, but what happens when we can no longer trust these certificates?
It is day one of BlackHat for me and I thought I would take in twopresentations on a similar topic. The first presenter was Moxie and histalk on ‘More tricks to defeating SSL in practice’ was focused on howMan In The Middle attacks could be used to fool us in to believing wewere safe and secure online… the second session was by our good friendDan Kaminski. Now Dan is well known for his recent DNS exploits and hissession included some interesting twists on how to defeat the SSLattacks through things like DNSSEC. I will go in to that shortly…
Essentially both talks were on the trust-worthiness of the SSL(X.509) certificates we use every day. The theory is this… Acertificate is issued by a trusted source. That source ultimately has aroot certificate that our computers can verify the certificate we havebeen presented with (for example at your bank’s web site) through achain. In many cases this root certificate belongs to companies likeThawte and VeriSign, or even your government. Moxie’s talk included adiscussion of older attack vectors and as we all know, the oldies inmany cases are still the goodies.
The attacks included Certificate Chaining and SSL Stripping where inthe event of a Man In The Middle attack, you essentially intercept theconnection and either issue your own certificates to fool the webbrowser (Certificate Chaining) or strip off the SSL component of theURL request (SSL tripping) to fool the user in to believing they areusing a secure connection when they may not be. Okay, to exploit this,you would likely have to use something like ARP or DNS poisoning toaffect the MITM attack.
That is all well and good, but what about you simply issuing yourown certificates… In this case both talks focused on how you cangenerate certificates for sites you don’t own… for example. I want togenerate a certificate for a bank – www.anybank.com(this name is referred to as the Common Name or CN). However, if Isimply request a certificate, the administrative contact at that sitewill be contacted to verify the certificate creation and hopefully notallow a certificate to be issued to you. So how can I get thatvalidation request to be sent to me? Well it seems the trick is in theway that a number of the automated systems parse the strings for in therequest you submit. Now I request a certificate for www.anybank.com (where /0 is a NULL, which is often used to terminate a string and I am the admin for mydomain.com). Many systems will parse this string and say that the domain the certificate is being requested for is actually mydomain.com.I get the email and validate the request. The trick is that when thedomain name is parsed for the Common Name (CN) many systems will return www.anybank.com as the NULL character acts as a string terminator.
It seems that other control characters can also be effective such asthe Tilde and even wildcards (*). For example, requesting a certificatefor */0mydomain.com potentially could issue you with a certificate forany domain. Both talks discussed these challenges at length, but Danwent somewhat further to suggest that many attacks could be defeatedthrough using things like Extended Validation (EV) certificates andDNSSEC. He definitely explained it better than I could hope to so Isuggest looking up the discussions online on these topics..
In real terms, the question becomes that we use certificates todayto provide a level of assurance about the sanctity of the connection wehave established for whatever purpose whether it be banking, email or amyriad of other services online. If we cannot trust those certificates,then how do we provide assurance. The good news is that even if Igenerate my own certificate, I still need to get you to go to my siteand none of us would ever be fooled by a phishing or MITM attack wouldwe?
