Someone Else

Robert Moir writes about Operating Systems, Computer Security and Virtualisation.

Have hackers "Broke" SSL?

Seems that there has been some rumbling that SSL encryption has been broken recently, which is quite interesting and would be a major threat to things we are all just starting to take for granted such as online shopping and banking, privacy and other important issues that people take for granted. For those who don't know what SSL is, it is that 'little padlock thing' in your browser that you've always been told means that the website you are visiting is secure.

Now this is scary stuff and a true break of the SSL encryption routines would be a tragedy, but that isn't quite what has happened here. What we have here is a trojan that uses "pharming" (targeted hacks looking for specific things, in this case connections being made to online banks).

The recent fuss revolves around a targetted hack attack using a particular trojan that sits between you in front of your computer and the data you send to secure website, and in this position it can intercept and monitor your traffic without having to actually "break" your encryption. Note that this is a very simplified "layman's terms" explanation of what happens, technical explanation here.

So where does this leave us? It is perhaps worth recapping what SSL is and what SSL isn't at this point: Some people attribute that 'little padlock thing' with super powers that guarantee that nothing can go wrong with their transaction and that just isn't true.
SSL is a way of providing a secure and encrypted 'tunnel' between a web server and a web browser on the Internet. 

Think of SSL like your local mail posting service offering a guarantee that certain letters can be sent to and from certain destinations securely. That is all SSL offers - it is a very important offering to be sure, but it only guarantees part of your security.

A SSL connection doesn't know about the fact that your computer has a trojan on it, generating a SSL proxy performing a Man In The Middle attack. It only provides secure communications between two points and can't know that someone is reading your secrets over your shoulder before you send them, so to speak.

A SSL connection can verify that the tunnel goes to the correct web server, which is great, but what if the correct web server has been hacked? Again, an unauthorised person reading your secrets over the shoulder of the person that you are talking to isn't the fault of the post office.

SSL cannot tell you if the secure connection goes to the correct web server and it hasn't been hacked, but the data is stored insecurely at the web server because the business you are dealing with is staffed by idiots. It isn't the fault of the post office if the person who receives your secret mail tapes a copy to their window for every passer-by to read.

Comments

flaws said:

I liked the explanation Robert, but there is something that you're under-playing here. The web browser is supposed to do it's job. The issue isn't that there is a trojan that can hook into IE and grab all traffic before it's encrypted, the issue is that it performed a successful man-in-the-middle by using a mixed-certificate technique to bypass the "EDUCATION" of SSL and the authentication. An example of this is here:

http://ip.securescience.net/exploits/ssl_mix.html

This demonstrates 4 frames 2 of which are SSL protected, and 2 which are not. No matter what browser we demonstrate this from, there are no warnings, pop-ups, or anything about non-secure pages, secure pages, and as we all know there is no Lock at the bottom. If you reverse the roll:

https://slam.securescience.com/threats/mixed.html

We see my Cert (which shouldn't alert, some browsers in mozilla still don't like Thawte), and we also have two frames with two separate SSL certs on the page. No warnings, and the SSL lock states that it's what the domain has. This is a problem with cross-user attacks as well as Trojans that Pharm because they easily fake "authentication" which is the intent of SSL for the home user, to authenticate the site and make sure they are there. The education around this for pharming is to use SSL to verify you are at the site. Well - in this report, this proves that not all cases will work.
# February 19, 2006 9:58 AM

Robert Moir said:

Hi Flaws,
Couple of nice demostrations there. I hope lots of people get to see them.

I honestly don't know what to think. I'm not sure that in "pure" technical terms there is anything wrong with what the browser is doing.

The problem is with user perception - or perhaps I should say with application designers who don't understand how and why users see how their product and the Internet and general works.

I don't think I know many normal users who would think to check a certificate at all if they don't see any errors, let alone know to click on components of a page to check the different sources.
# February 19, 2006 11:35 AM

Brad Freeman said:

m'afraid you don't know what you're talking about. people spent their lifetimes making SSL unbreakable and here you are, just saying "what if the server is broken into"... come on, be more responsible. someone equally uninformed could be reading your blog and actually taking it seriously. remember, there are things you simple DON'T KNOW ENOUGH ABOUT. so refrain from blogging about issues you don't understand.
# February 22, 2006 3:08 AM

Robert Moir said:

Brad, it is ok to disagree with people but that doesn't mean they don't know what they're talking about.

I'm not sure if you understand what I am trying to say here. Perhaps that is my fault. Or maybe I scared you and you don't want to face a nasty truth?

SSL encrypted traffic is a secure channel between two end points. I never said otherwise, in fact I went to some lengths to reinforce that point. Same goes for the sites who documented the exploit I was commenting on. I'm sure you will see that if you visit them.

It is possible for your home computer, the client in an SSL transaction, to have a Trojan horse running on it that records all your key-strokes and sends the data off to a criminal as soon as it recognises credit card numbers and other interesting data.

It is also possible that the computer at the other end has been broken into and compromised, either via a Trojan (it does happen!) or via an unpatched security exploit. This is very well documented.

It's also possible to "proxy" SSL connections from the client in the manner suggested in the articles I was commenting on. This doesn't "break" SSL encryption.

As I say in the original article, what it does is fool the user by showing them what they expect to see while doing something else in the background. Quite a common phishing scenario one would say.

In all these cases, the secure tunnel remains secure but the information is not safe because it is extracted at a less secure point.

I'm not trying to scare people away from using SSL. On the contrary, I would not conduct business with sites that never use it. However, it isn't a "magic button" that says your data is secure for ever after, it is simply a guarantee that you have a secure channel with whatever server you are connected to.

If what I'm saying is impossible because I don't know what I'm talking about then why is it so easy to find examples of data being stolen from e-commerce servers?

http://www.google.co.uk/search?&hl=en&q=credit+card+data+stolen+from+server
http://www.internetnews.com/ec-news/article.php/298021
http://www.fcw.com/article92132
http://software.silicon.com/malware/0,3800003100,39154991,00.htm
# February 22, 2006 10:13 AM