You’ve just broken into your target’s internal network, whether it was some perfectly executed social engineering scheme or leveraging an overlooked unpatched vulnerability, you hit the jackpot. Now you figure it’s time to settle yourself in-between the would-be victim with a man in the middle attack and start sniffing traffic for some credentials. You fire up Wireshark, apply filters, and get ready for the keys to the kingdom to be handed over — except for one issue. Websites these days are starting to listen to the Security industry (it’s still like pulling teeth), and HTTPS is being leveraged for at least their login pages. Good thing we have a tool for just the occasion.

First let me introduce you to my virtual test environment (Virtualbox Host-only network)

Attacker:
OS: Kali Linux 2.0
IP: 192.168.56.103
MAC: 08:00:27:07:52:ef

Victim:
OS: Windows 10
IP: 192.168.56.104
MAC: 08:00:27:70:06:62

Server:
OS: Ubuntu Server
IP: 192.168.56.106
MAC: 08:00:27:9d:2a:da

In order for me to show you how to make full use of SSLStrip I’m going to cover how to perform a specific type of Man in the Middle attack known as ARP cache poisoning.

The Address Resolution Protocol

ARP is a layer-2 protocol that allows machines to map IP Addresses to MAC addresses, so if the Victim machine wants to send a packet to the Server on the same LAN it needs a destination MAC address in order to put it out on the wire. When connecting to the Server through my web browser I provide it with either a domain name or an IP Address (http://192.168.56.106), but no MAC address. Behind the scenes your machine uses ARP in order to obtain the MAC address for the system.

In Wireshark (a network protocol analyzer) we can view an example of this exchange at the packet level:

First, a machine would broadcast to the subnet asking for someone to tell them the MAC address for the IP address in question and leaves their IP address for the response.

Then, normally the owner of the IP address would send an ARP reply stating the the IP address in question can be found at the MAC address they provide (normally their own MAC address).

So the reason I underlined normally is because we are going to use this oversight in the protocol to our advantage, by performing what is called a gratuitous ARP reply. Imagine a real world scenario where your name is Bob and you want to know Alice’s address to send a letter but Oscar is determined to read the contents of the letter.

Bob: Hey what is Alice’s address? Tell Bob
Alice: Hey you can find Alice at 123 Candy Lane

Bob then has some short-term memory of Alice’s address before he may need to ask for it again at some point in the future. This is analogous to a machine’s ARP cache where they store previous answers to ARP requests for a period of time before it has to ask again.

Now the weakness of the ARP cache is that for a single IP address it will only remember the last MAC address it was told (it doesn’t matter who the reply comes from, just to make our lives easier), this is where the gratuitous reply comes in. Here is the same situation as before with a twist.

Bob: Hey what is Alice’s address? Tell Bob
Alice: Hey you can find Alice at 123 Candy Lane
Oscar: Hey you can find Alice at 456 Candy Lane
Oscar: Hey you can find Alice at 456 Candy Lane
Oscar: Hey you can find Alice at 456 Candy Lane

Since Bob has some odd short-term memory he is only able to remember the last reply to his question when he tries to send a letter to Alice it will instead go to Oscars address. Now all Oscar needs to do is open the letter, read its contents, close the letter, and then forward along the message to its intended destination with no one the wiser.

Using Arpspoof

The first thing that needs to be done in order to utilize this tool is to set the ip forwarding for the attacking machine’s operating system so that when it receive packets from our targets the network card will forward the packets to the destination IP address labeled on the network layer of the packet. Remember, we are attacking at Layer 2 so they are sending the packets to the wrong MAC addresses but they have the correct IP addresses. Normally the file in /proc/sys/net/ipv4/ip_forward will have a 0 to represent that ip forwarding is disabled, so we are going to change this to a 1 for enabled.

arpspoof [-i interface] [-t target] [-r] host

-i : What network interface you’re operating this attack on (can be applicable if you’re running multiple network cards on a single VM)

-t : The target who’s arp cache we want to poison (Victim)

-r : Allows us to poison both the target and host simultaneously

Host : The machine you’re lying about to the target  (Server)

Now our Victim will navigate to the Server’s IP address (192.168.56.106) and enter a set of  credentials into the login form.

Back on the attacker machine all it takes is spinning up Wireshark to check out the network traffic passing through to harvest the Victim’s credentials.

What about HTTPS?

So as I said before websites are starting to wisen up and employ HTTPS on their web pages more frequently, especially for sensitive pages such as the login. This time the Victim will connect to the server by manually putting https://192.168.56.106/form.html into the address bar.

The attacker machine is still sitting directly between the Victim and Server, let’s see how this affected our Wireshark packet sniffing results.

As you can see the messages are encrypted using TLS so when searching for HTTP packets there’s no packets in the viewer and when viewing the TLS packets all we can see is encrypted data… so I guess we should just pack up and admit defeat?

This is where a particularly cunning tool comes in…

SSLStrip is a tool written in python by Moxie Marlinspike that allows a user to circumvent HTTPS and the protection TLS (pretending that website’s don’t still use SSL 2.0/3.0 for the sake of my own sanity) normally provides when performing a man in the middle attack (MITM).

Lets take a peek under the hood

SSLStrip doesn’t have any fancy encryption breaking algorithm rendering TLS useless, it doesn’t somehow intrude into the endpoints and view the data as it is unencrypted, it takes advantage of weak implementation of HTTPS as tack on to HTTP.

SSLStrip’s logical process:

1) Watch as HTTP traffic goes by

2) If any https links appear in the HTML responses such as <a href=”https://…”> swap those out with <a href= “http://…”> when you pass along the response to the victim.

3) For cases where the user connects to a website by typing in their browser website.com (which autofills to http://www.website.com) and the website sends a 302 redirect to https://www.website.com replace the https:// in the location header to http://.

4) Keep a map of all of these swaps and if packets come through from the Victim trying to access one of the websites in the mappings, initiate an HTTPS connection with the Server and maintain an HTTP connection with the Victim.

So all sides of the conversation are happy; the server directed who he believes is the client to a TLS connection, the victim is able to get requests/responses to the server and browse at their leisure, and the attacker gets those sweet coveted credentials.

Using SSLStrip

Usage for our purposes:

sslstrip [-l port]  

-l : the port for sslstrip to listen on for incoming http connections

Like arpspoof, there is a configuration that has to be taken care of in our iptables firewall before this tool can do its job. Basically what we need to do is instruct iptables to take inbound packets coming into the attacker machine with a destination port of 80 (from the Victim) and redirect them to the port sslstrip is listening on.

iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port <myPort>

Now to set up our listener….

In this scenario the Victim will connect to 192.168.56.106 over HTTP and would expect to be taken over to HTTPS when clicking the Login button. SSLStrip is going to put a little wrench in this plan.

Defenses against SSLStrip

So it may seem like an eternity ago but remember when I said security professionals were finally being listened to? That was only half-true, it’s more like they record our recommendations and start listening to them a few years down the road. In response to this particularly deadly tool there is a great HTTP header that was created known as HSTS (HTTP Strict Transport Security) which basically has your browser cache for a specified amount of time “when you connect to me, use HTTPS”. Here is what the header looks like in an HTTP response from facebook.com:

Now we have minimized the attack window for someone to SSLStrip our secured browsing to a point where they have to be in the middle of a MITM attack either the first time we ever connect to the website or when the HSTS cache entry for the website expires and it is our first new connection. By stripping out the header in either of those scenarios the attack goes through as normal.

So we have this great standard that appeared in RFC 6797 in November 2012 for a tool that was created in 2011, which allows for websites to secure their visitors by easily adding a single header to every HTTP response and as long as the browser being used accepts and understands the HSTS policy we can ensure that websites that require a secure connection get one. Since the user’s browser will know ahead of time it needs an HTTPS connection it won’t give SSLStrip the opportunity to keep the connection as HTTP. Yet either because of lack of knowledge or motivation HSTS has had a low adoption rate amongst the industry and attacks like this are still viable as a result. So until website owners get their act together and apply the stupidly simple fix, it looks like we’ll have to stick to using client-side alternatives such as the browser plugin HTTPS Everywhere.

For more information:

http://www.thoughtcrime.org/software/sslstrip/
https://github.com/moxie0/sslstrip
https://tools.ietf.org/html/rfc6797