Preventing SSL session exploits

Safe enough ?

I would start by stating that the current article does not underline any vulnerability with the SSL protocol itself, but it shows how can a person be induced into error despite the high level of confidence and comfort that SSL provides.

This type of exploit is known as Man In The Middle (shortly MITM) which is a form of eavesdropper attack. Although this type of exploit is mostly (and sometimes only) associated to plain non-secured connections like HTTP, it can be employed to HTTPS connections as well.

Below I will present the two most common techniques of running such an attack. While there are other methods to conduct a MITM attack, the two below are the easily camouflaged to user and they require no “intervention” on his/her computer.

These two procedures run with the following assumptions:

  1. the attacker has access to your network router
  2. the user ignores the lack of HTTPS in the browser navigation bar and/or accepts an invalid server certificate
  3. the SSL setup works with server certificates only
The procedures exposed below also assume you are familiar with the basic concepts of SSL protocol. In case you need a refresh you might take a look here.

 

HTTP mapping

This method was documented by Moxie Marlinspike (a security researcher and hacker) on his blog. It all started from the fact that most of the times a SSL session is not initiated directly by the user. Instead, a user is redirected to secure page from a main page or login button on a non-secure page. The trick here is to take control of the SSL session before it even starts.

That being said, Moxie created a tool called SSLstrip which should be deployed on the router, server, machine, middleware you want to control. Once configured, the tool will stop all the incoming HTTPS traffic from client and it will initiate the SSL session from here. The client, at his turn, will see only HTTP pages. So SSL strip will securiley communicate with the server and talk back to client on plain HTTP. As far as the server is concerned, the HTTPS connection is fulfilled and the client still gets his content on the page. So both parties are satisfied. The only thing changed here that might be noticed by the client is the HTTP connection instead of HTTPS.

The process follows these steps:

  1. client asks a HTTPS URL
  2. SSLstrip gets the URL and forward it to server; so, the client never talks HTTPS with the server
  3. the server response is retrieved, parsed (HTTPS HREFs are replaced with HTTP and Location headers follow the same rule) and passed back to client by SSLstrip
  4. also a mapping of stripped URLs is being kept; that is when such a link is called (http://site.com/page.html), SSLstrip automatically calls the secure version (https://site.com/page.html)

Certificate replacement

This approach also assumes the attacker controls the middleware like in the above examples. The way it works is that a fake certificate is being generated on the fly (with a tool like OpenSSL) and signed with the attacker’s private key. The fake certificate contains all the information available in the root certificate as  the essential information is taken from the original certificate.

Now, the browsers will issue a security warning but as the certificate seems to be valid – the identification data match the original one – the users are tempted to ignore it.

This scenario involves the following steps:

  1. the client calls a HTTPS resource on the server
  2. the attacker stops and intercepts it and issue the same request on his behalf; so the SSL session is started between the attacker and the server
  3. the attacker prepares a fake certificate
  4. the response is taken from the server and sent back to client along with the fake certificate
  5. depending on the browser, a SSL security warning will be issued (but only for the first time)
  6. if the client ignores the error, then it’s all done: all the requests are proxied through the attacker, that simply passes them along to server and returns the response back to client
Although I am not aware of any out of the box tool for such a thing, there a few papers out there describing quite detailed what and how you need to do to build up your own tool. One of them was published by Ume University in Sweden.

 

What can you do about it ?

Despite the technical and fancy terms that characterize these attacks, there are a few simple things that you can do to avoid them. All you need is a little attention.

  • do not ignore the browser security warnings
  • pay attention to HTTPS in browser’s navigation bar
  • save the banking operations for home as there are little chances for someone to get control of your home router
  • and password protected your internet access to your home router (WEP security is available on most of the routers)
  • for organizations, make sure to employ the SSL client certificates
  • in case your business expose sensitive webservices: make use of message encryption provided by WS-* stack
Update: I’ve got a tip from a reader who pointed out Cain and Abel, a Windows based tool that can also be used to impersonate digital certificates. An extensive tutorial explaining how to do that can be found here.

Leave a Reply

Your email address will not be published. Required fields are marked *