SSL: Broken even more

In January I wrote an article, SSL: Really broken this time, in which I described how forged certificates could be created if the signing Certificate Authority used the MD5 algorithm for signing.

That wasn't too difficult of a problem to rectify; it just required Certificate Authorities to use SHA-1 instead of MD5. Even so, most people in the know realized that it won't be too long before SHA-1 has the same problem as MD5.

SSLsniff
Well, I'm afraid that cracking SHA-1 is the least of our problems.

You may remember Moxie Marlinspike, he's the developer of a sophisticated hacking tool called SSLsniff. The application exploits vulnerabilities in Internet Explorer, allowing Man-in-the-Middle (MitM) attacks even if SSL connections are used. Microsoft eventually fixed the vulnerabilities by disallowing leaf certificates to act as signing certificates.

Even with the vulnerability fixed, SSLsniff is still a powerful tool. As evidence, SSLsniff was used to demonstrate MitM attacks by the group of cryptographers who discovered the MD5 exploit I mentioned earlier.

SSLstrip
Marlinspike's new and improved tool is called SSLstrip. Quite simply, SSLstrip allows an ill-intended attacker to capture sensitive personal information without even worrying about encryption.

He decided to sidestep the encryption process once he realized that users almost always request Web pages using the http (unencrypted) prefix. That's even the case for the more confidential Web sites like those provided by financial institutions as shown below:

After the initial portal page is brought up, https is enabled after some user intervention as the following image shows:

SSLstrip is simply a MitM proxy that advantages this flaw/oversight in the https process by stepping in between the user and in this case the bank's Web server. Let's look at the process using me as the guinea pig:

1. I enter the URL http://www.usbank.com into the Web browser.
2. I then type my user name in the appropriate box and hit enter.
3. SSLstrip captures the URL and my username.
4. SSLstrip connects to the USBank Web server and provides my username.
5. SSLstrip then returns the new Web page provided by the bank Web server to my computer.
6. I provide my password and hit enter.
7. SSLstrip once again captures that information and transmits it to the bank Web server. As far as the bank Web server knows, I'm officially logged in.
8. SSLstrip once again passes the new Web page provided by the bank Web server to my computer. I then go about my business.

Something is wrong though, how come the "s" is missing from http in the URL? I thought the bank's Web site was secure. It's not there because the SSL connection was setup between my attackers' computer and the bank's Web server. I was getting all the correct Web pages sent to my computer, but not over secure channels. Guess who now has my log in credentials?

I realize that an observant user would more than likely be aware of the sleight of hand taking place here, but then I suspect that many more will be fooled by this. For more details about the exploit, please view Marlinspike's Black Hat presentation New Tricks for Defeating SSL in Practice (pdf). He did a great job explaining the entire process.

Even sneakier
In Marlinspike's presentation, he points out a few other techniques that can be applied to make the unsecure Web page look more convincing. Most Web browsers display the favicon supplied by the Web server right next to the URL in the address bar. What SSLstrip allows you to do is replace the favicon with one of your choosing.

By doing this many more people will be fooled as they have been told to look for a closed lock and if it's there then they can be assured that they are safe.

It's even possible for the attacker to supply a real SSL connection to the requesting computer with a URL that's almost identical to the one asked for. The difference being a few extra characters at the end. Moxie Marlinspike explains in the next slide:

Change the Web browser
We humans are creatures of habit; I doubt that anyone would argue that. Knowing that, I honestly can't say that I'd catch the deception every time myself. One good thing is that this dilemma has been talked about by others. I was fortunate that TechRepublic's managing editor Jason Hiner alerted me to George Ou's article HTTPS Web hijacking goes from theory to practice.

The article explains that developers need to give Web browsers enough intelligence to know whether the connection should be SSL encrypted or not and if encryption isn't occurring to disallow the connection. George also mentions that Google is working on this very problem in their early versions of the Chrome 2.o Web browser. Hopefully other Web browser developers will follow suit.

Final thoughts
First, I'd like to thank Black Hat for the use of their logo and Marlinspike for the use of his presentation slides in this article. I also admire his wanting to make everyone aware of this potentially serious attack vector.

I realize that this exploit is one that requires inattentiveness on our part. Fortunately, most people I talk to mention that they wouldn't get caught by this. Just to test that theory, think back to the last time you went to a Web site that used SSL. Did you check the URL? Were you sure that the traffic was encrypted? I didn't.

Michael Kassner has been involved with IT for over 30 years, and is currently a systems administrator for an international corporation and security consultant with MKassner Net.