Packet redirection on
Ermin Kreponic explains the principles of classic packet redirecting, using a man-in-the-middle attack to circumvent a website’s defences.
This article is all about sslstrip and ARP spoofing. Attacking wireless networks is about much more than just cracking the authentication keys. There are a lot of other techniques that can be used, especially on public Wi-Fi where you can authenticate without any problems.
Once you’re authenticated then you’re able to listen to all the traffic on that network. More likely than not, however, that traffic will be encrypted and probably won’t be all that much use to you. You’ll be able to see which IP addresses are visiting what websites, but you won’t be able to see anything of real value to an attacker.
The problem is HTTPS, which encrypts your web traffic. Login credentials ought to all be transmitted via HTTPS, which means they can’t be intercepted. The program sslstrip converts HTTPS connections to HTTP ones, effectively stripping the encryption. If this succeeds, then all packets will be transmitted in the clear and you’ll be able to see any usernames and passwords that people on the network are using to log in to websites, just as you would if those websites weren’t using HTTPS.
This tutorial assumes we’re working with Fedora. We’ll need two tools for this: sslstrip and arpspoof. The latter is for address resolution protocol (ARP) spoofing, in which we convince the router of our assumed identity so that it sends us the packets sent to it by the user. We then strip the encryption and retransmit the packets to the router, which then sends the packets to the internet.
Install the required packages (all commands in this tutorial need to be run as root ) with the following commands: # yum install sslstrip # yum install dsniff
On most other distros the second package is called arpspoof, and if you’re using the hacker-tailored Kali distro, then both of these are already installed.
By retransmitting the intercepted, sslstrip- affected packets back to the router, the attacker is communicating with the victim via HTTP, so everything is sent in the clear. This is a textbook Man in the Middle (MitM) attack.
This attack isn’t going to work 100 per cent of the time. Sometimes it depends on the target browser ( Internet Explorer is likely to be more susceptible than Firefox or Chrome) and some websites such as PayPal and Facebook have taken steps to make implementing the attack difficult.
Yet because people tend to recycle credentials across websites it’s possible that details harvested on a less-secure site can be used on one where our attack fails. We advise having one set of passwords for sensitive sites – banks, email, social media, anything that knows your address – and one set of passwords for less-sensitive sites, such as forum accounts. Re-use between less-sensitive sites is probably fine, and credentials are unlikely to be lifted (with the techniques we present here) from the likes of Paypal, so the worst-case scenario here is that a couple of your forum accounts are compromised. Hackers probably have no interest in these.
Mounting the attack
We first need to configure our kernel to forward packets: # echo 1 > /proc/sys/net/ipv4/ip_forward
Next we need to tell iptables to redirect packets appropriately: # iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080
The sslstrip program will listen on port 8080, so this will forward packets destined for webservers (port 80).
Now we need to find a target. This article assumes that a Windows 8.1 virtual machine is running on the network, but in
practice anything can be used. Don’t attack a machine without permission. In practice you’d scan the network first, which you can do with the well-known nmap utility: nmap 192.168.1.1/24 Our target VM is at 192.168.1.100, so nmap responds: Scanning 192.168.1.100 [1000 ports] Discovered open port 80/tcp on 192.168.1.100 Discovered open port 443/tcp on 192.168.1.100
We’ll need three terminal windows open for this attack: two to mount the actual attack and one to monitor the results. We’re going to convince the router that we’re the Windows 8.1 VM and at the same time convince the Windows 8.1 VM that we’re the router. Our ARP spoofing attack is carried out as follows (here we’re assuming the attack is being carried out over a wireless interface named wlp2s0 : # arpspoof -i wlp2s0 -t 192.168.1.100 -r 192.168.1.1 The -t argument is the target machine and the -r argument is the default gateway. This redirects all of the victim’s traffic to our attack machine. Because we enabled forwarding with iptables earlier, the victim machine’s connectivity will be unaffected, except that web traffic will be intercepted by sslstrip, which we now run: # sslstrip -l 8080
sslstrip will output a bunch of gibberish once it starts intercepting traffic, so it’s easier to follow the logs in our third terminal window with: # tail -f sslstrip.log
Now in the target machine open both InternetExplorer and Firefox. Sometimes the attack will work in one browser but not the other. Often it won’t work in either, but let’s not worry about that. In a real-world scenario you’d have to wait for your attacker to start browsing the web here. Try visiting
https://gmail.com in InternetExplorer. If the attack works, then sslstrip should interfere with the traffic so that the page is served over HTTP, which you can check by looking at the URL bar. This definitely won’t work with newer browsers, but for our slightly contrived target machine it does.
Enter some made-up details, say FAKE for both username and password, into the login form and hit Sign in. The sslstrip log should spew lots of data, beginning with something like: 2017-01-07 00:01:02,345 SECURE POST Data (accounts. google.com) But somewhere in amongst the gibberish there should be something like: ...checkedDomains=youtube&Email=FAKE&Passwd=FAKE which shows the attack has been successful. On our target machine this attack didn’t work in Firefox or Chrome, but the current Netmarketshare survey shows that about 18 per cent are still using some version of InternetExplorer, so it’s not unrealistic to suppose this will work somewhere. After all, many institutions are slack at applying security updates and force users to use certain terrible programs for legacy reasons. We saw similar success slurping login details for Facebook from InternetExplorer. While the sslstrip attack didn’t work with major sites on other browsers, it doesn’t mean the same is true for other sites.
Defeating sslstrip
Note that the websites themselves aren’t serving HTTP login pages, they’re transmitted to our attack machine via HTTPS and we send them to the target over HTTP. So mitigating against this from the server side is much more complicated than just serving HTTPS pages only.
The best way is to use HTTP Strict Transport Security (HSTS). Once implemented, the server will send an extra header over HTTPS connections which specifies a max-age flag. This is a duration (measured in seconds) after the first access for which the site will be assumed to be HTTPS only. Thus, so long as our victim’s first visit to the site proceeds untampered, any subsequent attempts to view the page over HTTP will cause the browser to complain.
Another defence is to train users to always look for the s in https:// or, failing that, the friendly green padlock. But users are fickle sometimes. The HTTPS Everywhere browser extension does a good job of stopping this attack dead and is generally a good thing to have enabled as part of a healthy web browsing regimen.