SSL Hijacking part 4 by

Eworld.0fees.net

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:

1. The client browser connects to http://mail.google.com on port 80 using HTTP.

2. The server redirects the client HTTPS version of this site using an HTTP code 302
redirect.
3. The client connects to https://mail.google.com on port 443.
4. The server provides a certificate to the client containing its digital signature. This
certificate is used to verify the identity of the site.
5. The client takes this certificate and verifies it against its list of trusted certificate
authorities.
6. 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:

1. Traffic between the client and web server is intercepted.

2. When an HTTPS URL is encountered sslstrip replaces it with an HTTP link and keeps a
mapping of the changes.
3. The attacking machine supplies certificates to the web server and impersonates the client.
4. 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.