Man-in-the-middle attack with public wifi

Question

I'm using Charles to sniff out the traffic on my iPhone at Starbucks and for some reason it won't work with at&t wifi. Google Starbucks wifi does, however. I use my iPhone to connect to the same wifi network that my MacBook is connected to. Then, for the proxy settings on my phone, I enter my computer's local IP address and the port that I specified in the proxy settings on Charles. I'm aware that some wifi networks block certain ports, but even when I change the proxy settings on Charles so that it's dynamic and it finds an open port, it still doesn't work. Any ideas?

Answer 1

Your Charles Proxy software was working fine. The reason you won't see other users on a Starbucks WiFi network is because Starbucks enlisted Google to design and implement their WiFi networks (which is why the SSIDs are named "Google Starbucks"), and Google set them up in a really smart way. Each user that connects to a Google Starbucks hotspot is "sandboxed" on their own individual subnet. If you use a network analysis tool like Nmap, you won't see anyone else. This is a fantastic way to isolate users from each other, which eliminates direct attacks from other people connected to that hotspot. However, the threat of a Man-in-the-Middle attack still exists on ANY public WiFi network (i.e., WiFi that does not require a password to connect), because actually, these attacks do NOT come from other users who are already connected to that network. The vulnerability is at the moment you initially connect to a public WiFi hotspot. An attacker can set up their own WiFi hotspot and let unsuspecting people connect to it instead of the legitimate hotspot. This is how it works: an attacker can use a laptop with two WiFi adapters. They would connect one of them to the legitimate public hotspot which is connected to the Internet. Then they would set up their second adapter as another WiFi hotspot that uses the same SSID as the legitimate hotspot. They would also create a fake login screen that looks just like the legitimate one (which is not difficult to do). If you happen to be sitting closer to this "rogue" hotspot than you are to the legitimate hotspot, you may unwittingly connect to it instead of the legitimate hotspot. Then the attacker proxies all of your traffic to/from the Internet and you wouldn't notice the difference. Your secure connection (using HTTPS/SSL/TLS) terminates at their laptop, and then another secure connection is established to go out to the Internet and back, so you will still see that the websites you're using are happily connected using HTTPS. But meanwhile, ALL of your data is passing through the attacker's laptop as unencrypted, clear text that can be intercepted, viewed and recorded. This includes any and all information a user sends through a web page, including passwords. The only way to be absolutely sure your Internet connection is secure from end to end, is to use locally installed software that "tunnels" your traffic directly to a (proxy) server that the software already recognizes as a trusted provider. Then, even if you do connect to a rogue hotspot, your traffic passing through the attacker's computer is still encrypted, so the attacker cannot view anything at all. Some examples of tunneling software are corporate VPNs (they use client software), anonymous proxy services (only those that use a client app), and SSH (secure shell) tunnels that, once again, connect to and proxy your traffic through already known and trusted servers. Public WiFi can be safe. Now you know how. Happy surfing.

Answer 2

Some businesses/corporations have their "publically accessible" wifi routers setup to disallow internal traffic - essentially a firewall that allows a connected device to only access the internet, and any attempts to connect to something on the local network would be denied. The idea behind this is usually to prevent an "evil user" from intercepting/man-in-the-middling other users in the network, essentially protecting those using their wifi.

That said, I believe "att wifi" is usually unencrypted... so putting that type of control in place would be rather pointless.