If you would like to be notified of when Chris Sanders releases the next part in this article series please sign up to our WindowSecurity.com Real Time article update newsletter.
If you would like to read the other parts in this article series please go to
- Understanding Man-in-the-Middle Attacks – ARP Cache Poisoning (Part 1)
- Understanding Man-In-The-Middle Attacks – Part2: DNS Spoofing
- Understanding Man-In-The-Middle Attacks – Part 3: Session Hijacking
Introduction
So far we have discussed ARP cache poisoning, DNS spoofing, and session hijacking on our tour of common man-in-the-middle attacks. In this article we are going to examine SSL spoofing, which is inherently one of the most potent MITM attacks because it allows for exploitation of services that people assume to be secure. I will begin by discussing some theory behind SSL connections and what makes them secure, and then follow by showing how that can be exploited. As always, the last section of the article is reserved for detection and prevention tips.
SSL and HTTPS
Secure Socket Layers (SSL), or Transport Layer Security (TLS) in its more modern implementation, are protocols designed to provide security for network communication by means of encryption. This protocol is most commonly associated with other protocols to provide a secure implementation of the service that protocol provides. Examples of this include SMTPS, IMAPS, and most commonly HTTPS. The ultimate goal is to create secure channels over insecure networks.
In this article we will focus on attacking SSL over HTTP, known as HTTPS, because it is the most common use of SSL. You may not realize it but you probably use HTTPS daily. Most popular e-mail services and online banking applications rely on HTTPS to ensure that communications between your web browser and their servers in encrypted. If it weren’t for this technology then anybody with a packet sniffer on your network could intercept usernames, passwords, and anything else that would normally be hidden.
The process used by HTTPS to ensure data is secure centers around the distribution of certificates between the server, the client, and a trusted third party. As an example let’s say that a user is trying to connect to a Gmail e-mail account. This involves a few distinct steps, which are briefly simplified in Figure 1.
Figure 1: The HTTPS Communication Process
The process outlined in Figure 1 is by no means detailed, but basically works out as follows:
- The client browser connects to http://mail.google.com on port 80 using HTTP.
- The server redirects the client HTTPS version of this site using an HTTP code 302 redirect.
- The client connects to https://mail.google.com on port 443.
- The server provides a certificate to the client containing its digital signature. This certificate is used to verify the identity of the site.
- The client takes this certificate and verifies it against its list of trusted certificate authorities.
- Encrypted communication ensues.
If the certificate validation process fails then that means the website has failed to verify its identity. At that point the user is typically presented with a certificate validation error and they can choose to proceed at their own risk, because they may or may not actually be communicating with the website they think they are talking to.
Defeating HTTPS
This process was considered highly secure up until several years ago when an attack was published that allowed for successful hijacking of the communication process. This process doesn’t involve defeating SSL itself, but rather, defeating the “bridge” between non-encrypted and encrypted communications.
Moxie Marlinspike, a well known security researcher hypothesized that in most cases, SSL is never encountered directly. That is, most of the time an SSL connection is initiated through HTTPS it is because someone was redirected to an HTTPS via an HTTP 302 response code or they click on a link that directs them to an HTTPS site, such as a login button. The idea is that if you attack the transition from an unsecured connection to a secure one, in this case from HTTP to HTTPS, you are attacking the bridge and can man-in-the-middle an SSL connection before it even occurs. In order to do this effectively, Moxie created the SSLstrip tool, which we will use here.
The process is fairly straightforward and is reminiscent of some of the attacks we’ve completed in previous articles. It is outlined in Figure 2.
Figure 2: Hijacking HTTPS Communication
The process outlined in Figure 2 works like this:
- Traffic between the client and web server is intercepted.
- When an HTTPS URL is encountered sslstrip replaces it with an HTTP link and keeps a mapping of the changes.
- The attacking machine supplies certificates to the web server and impersonates the client.
- Traffic is received back from the secure website and provided back to the client.
The process works quite well and as far as the server is concerned it is still receiving the SSL traffic it wants to, it doesn’t know the difference. The only visible difference in the user experience is that the traffic will not be flagged as HTTPS in the browser, so a cognizant user will be able to notice that something is amiss.
Using SSLStrip
The program that makes all of this happen is called SSLstrip and is available from here. This program only runs on Linux so you can download and install it yourself, or if you don’t want to deal with the hassle of installing it yourself you can download and run Backtrack 4 which has it preinstalled.
Once you have access to SSLstrip there are a few perquisite tasks that must be done. First of all, the Linux distribution you are using must be configured for IP forwarding. To do this, enter the command echo “1” > /proc/sys/net/ipv4/ip_forward into a shell.
Figure 3: Enabling IP Forwarding
Once this has been done, we have to force all HTTP traffic that is intercepted to be routed to the port that SSLstrip will be listening on. This is done by modifying the iptables firewall configuration. This is done by using the command iptables -t nat -A PREROUTING -p tcp –destination-port 80 -j REDIRECT –to-port <listenPort>.
Figure 4: Configuring IPTables to properly route HTTP traffic
Of course, you will replace <listenPort> with a random port of your choice. After these items have been configured we can run sslstrip and configure it to listen on the port specified with the command sslstrip -l <listenPort>.
Figure 5: Using sslstrip
The last step in this process is to configure ARP spoofing to intercept the traffic of the target host. We did this using Cain and Abel in Windows previously, but in this case we will use the arpspoof utility, which is built into Backtrack 4. The command to do this is arpspoof -i <interface> -t <targetIP> <gatewayIP>.
Figure 6: Configuring ARP Spoofing
Using this command you would substitute <interface> for the network interface you are performing these actions on (eth0, eth1, etc), <targetIP> for the IP address of the target client, and <gatewayIP> for the IP address of the gateway router the target is using.
Once completed you should be actively hijacking any SSL connections being established. From here you can fire up a packet sniffer and collect passwords, personally identifiable information, credit card numbers, etc from the traffic.
Defending Against SSL Hijacking
As discussed previously, SSL hijacking in this manner is virtually undetectable from there server side of the equation because as far as the server is concerned this is just normal communication with a client. It has no idea that it is communicating to a client by proxy. Luckily, there are a few things that can be done from the client’s perspective to detect and prevent these types of attacks.
- Ensure Secure Connections Use HTTPS – When you perform the attack described here it strips the secure aspect of the connection away, which is visible in the browser. This means that if you log into your online banking and notice that it is just a standard HTTP connection there is a good chance something is wrong. Whatever browser you choose to use, you should ensure you know how to distinguish secure connections from insecure ones.
- Save Online Banking for Home – The chance of somebody intercepting your traffic on your home network is much less than on your work network. This isn’t because your home computer is more secure (let’s face it, its probably less secure), but the simple matter of fact is that if you only have one or two computers at home, the most you have to worry about in terms of session hijacking is if your 14 year old son starts watching hacking videos on YouTube. On a corporate network you don’t know what is going on down the hall or in the branch office 200 miles away, so the potential attack sources multiply. One of the biggest targets for session hijacking is online banking, but this principal applies to anything.
- Secure your internal machines – Not to beat a dead horse, but once again, attacks like these are most commonly executed from inside the network. If your network devices are secure then there is less of a chance of those compromised hosts being used to launch a session hijacking attack.
Wrap Up
This form of MITM attack is one of the deadliest because it takes what we think is a secure connection and makes it completely insecure. If you consider how many secure sites you visit each day and then consider the potential impact if all of those connections were insecure and that data fell into the wrong hands then you will truly understand the potential impact this could have on you or your organization.
If you would like to be notified of when Chris Sanders releases the next part in this article series please sign up to our WindowSecurity.com Real Time article update newsletter.
If you would like to read the other parts in this article series please go to
