Let me tell you a personal story. I rarely ever go to coffee shops. I also just about never use public Wi-Fi (even before my government started locking me in my house), preferring to use my mobile data connection. But there was this one time when I had to go to a coffee shop and use their public Wi-Fi. It was a prestigious international coffee shop chain, in a high-end shopping mall. Let’s call the coffee shop chain “The Coffee Bear”.
So I was at The Coffee Bear, bought a drink (of course it was coffee), asked for their Wi-Fi password, and turned my phone’s Wi-Fi on to connect to their network. I saw two such Wi-Fi networks that I thought belonged to them: “TheCoffeeBear” and “THECOFFEEBEAR”. At first I thought that one must be for the staff to use and the other must be for customers, or maybe one was a 2.4 GHz network and the other was a 5 GHz network. But then I thought that if one was for the staff and the other was for the customers, it should have clearly said so in the names of the networks. And then I thought that one of them couldn’t be a 5 GHz network because my phone’s Wi-Fi adapter didn’t have 5 GHz functionality to even detect such networks.
I decided to go to the staff and ask them which Wi-Fi network I should use. They told me that I should use TheCoffeeBear. Out of curiosity, I asked them what the THECOFFEEBEAR network was for. They told me they didn’t know what that network was. I asked them if it was set up by them or if they knew who had set it up. They told me no. I asked them if it was something that just comes out of nowhere every now and again. They told me yes.
I think some of you have already guessed that THECOFFEEBEAR was probably a hacker trying to perform a MITM attack on people connecting to the Wi-Fi there. The hacker was probably hoping at least some people would connect to THECOFFEEBEAR instead of TheCoffeeBear. The staff never informed me of this until I asked them (I don’t blame them, but they should have), nor did they ever manage to figure out where the fake Wi-Fi network was coming from (that’s actually rather hard to do without specialized equipment or software, so I don’t blame them for that either).
Now, keep in mind, I rarely ever go to a coffee shop, and even more rarely use public Wi-Fi; but this one time when I did, I ran into a potential MITM attack. Most likely, malicious Wi-Fi networks such as this that pretend to be regular public Wi-Fi networks are very common. If I had logged in to, say, Facebook, while I were on that THECOFFEEBEAR network, I might have been giving away my username and password to this hacker. (Or, worse yet, my Facebook-associated email address and the password I use for everything. This is why you don’t reuse passwords; always use a unique password for anything even remotely important.)
ʕ·ᴥ·ʔ: Well, yeah, you might have. But if you had gone to
facebook.comand you made sure you were doing it via HTTPS by seeing the green padlock icon in the address bar of your web browser, then you’d have had an encrypted connection to what was probably the real facebook.com, and ain’t no way any man in the middle reading that!
You’re absolutely right! Okay, let me change the circumstances a bit then.
ʕ·ᴥ·ʔ: Huh? “Change the circumstances?”
Yeah. Let’s say instead of going to facebook.com via a web browser like Google Chrome, I went to facebook.com via the Facebook app on my phone. Would my connection be encrypted then? Would it be going to the real facebook.com and not some fake?
ʕ·ᴥ·ʔ: Uhhh, hmmm… Is there a way to tell?
No easy way, unfortunately.
First of all, let’s talk about the real vs. fake facebook.com issue. A hacker controlling the Wi-Fi network could easily point my device to a fake facebook.com. Using a technique called DNS Hijacking, he could point me to an IP address that’s not actually for Facebook, but my device will think it’s for Facebook.
He could also perform IP Address Spoofing, in which he pretends that his device is an IP address of facebook.com, even though it actually isn’t. This would be a little harder and more complicated to do, but certainly possible.
Both of these attacks would be thwarted by HTTPS, which both encrypts my communications with the real facebook.com, and proves that I’m talking to the real facebook.com. Thing is, not all mobile apps on my phone (and almost certainly not all on yours either) use HTTPS for all communications. Some apps do, but others not quite.
The good news is that 80-90% of all apps on Android use HTTPS for all communications. The bad news is that, it’s only 80-90%. So if I’ve got 10 or more Android apps on my phone (and who has only 10 apps?), then probably at least 1 of them is sending out unencrypted messages that THECOFFEEBEAR can read, redirect, modify, and drop.
ʕ·ᴥ·ʔ: Wait, what? He can do more than just read your messages and point you in the wrong direction?
Oh yeah, definitely. As long as it’s his device’s internet connection that’s sending my messages, he can change them and choose not to send them at all.
ʕ • ᴥ •’ʔ: Scary…
And there’s even worse news: only 27% of the most popular iOS apps for employees enforce HTTPS for all communications.
ʕ ಠ ᴥಠ ʔ: WHAT?!
Yep. Apple. “Privacy. That’s iPhone.”
To be fair to Apple, this is more the responsibility of app developers than it is Apple’s. Still, if I’ve got 10 (just 10!) apps on my iPhone, chances are that 7 out of 10 of them are sending out unencrypted messages, which are going straight to THECOFFEEBEAR, messages that he can do a lot with.
ʕ • ᴥ • ’ʔ
And I didn’t just randomly pick Facebook as the account to log into in my example. Here is a graph from Wandera, the same security company behind the research showing that only 27% of iOS apps enforce HTTPS:
Credit: Wandera
As you can see, almost 8% of the most popular iOS apps connect to facebook.com. And when they do connect to facebook.com, almost half of them don’t enforce HTTPS. I (or you) could be sending my (your) Facebook login credentials or session cookies or who-knows-what-else to THECOFFEEBEAR, and there would be no easy way for (us) to tell because (our) apps don’t show green padlock icons to tell us.
ʕ • ᴥ • ,’ʔ
And if you look at the graph above again, you’ll see that apps communicating with CDN’s like Facebook, Amazon, and Akamai are also almost half the time not enforcing HTTPS. CDN’s (Content Delivery Networks) are how advertisers keep track of us and show us ads. If THECOFFEEBEAR can change and redirect those ads, he can do all sorts of things; including show us real, legitimate ads that, instead of pointing us to the advertiser’s website, point us (you) to malware that can infect (y)our phone!
ʕ º ᴥ º ʔ
Kuma?
ʕ º ᴥ º ʔ
Hey, Kuma. You okay?
ʕ • ᴥ • ʔ: Oh, uh, yeah. I’m fine. I was just thinking of scanning my phone for malware and changing all my passwords.
You like clicking ads on public Wi-Fi, don’t you?
ʕ·ᴥ·ʔ: Only ads for honey! Guilty as charged!
Okay. Maybe go do that later.
There is a way to protect yourself when you’re on public Wi-Fi though, even when you’re on a hacker’s Wi-Fi network and don’t know it.
Not all advertising is false advertising
You might have been told by VPN ads that VPN’s protect you on public Wi-Fi. Thankfully, that’s true. With a VPN on, all of the data coming out of your phone is encrypted until it reaches your VPN provider’s servers, at which point it is decrypted and sent off to where it’s really supposed to go. If I were connected to THECOFFEEBEAR and used a VPN, I’d still be getting man-in-the-middle’d, but it wouldn’t matter because the hacker wouldn’t be able to read anything, seeing only encrypted gibberish. Anything he changes would become so corrupted that it would be useless. And redirection would only redirect the encrypted gibberish that can’t be decrypted by anybody other than me or my VPN provider.
Unfortunately, VPN’s only protect your traffic when you finally turn them on and manage to connect to your VPN provider’s servers. Up until that point, your connections may or may not be exposed, depending on whether they’re using HTTPS or not. And, as before, the hacker can just drop your messages, even disconnect your entire VPN connection. If they do that, you’re out in the open again, sending potentially unencrypted messages to the hacker. Also, some apps try to bypass VPN connections, potentially sending unencrypted traffic out of your device against your wishes.
A great way to deal with this is to use a VPN kill-switch. VPN kill-switches are just functionality that is included in many VPN apps and operating systems. They block all connections from your device that aren’t going through the VPN. With a kill-switch on, unencrypted traffic can’t leave your device. And the best thing about kill-switches: if the hacker cuts your VPN connection, your device just stops communicating at all.
ʕ·ᴥ·ʔ: Radio silence!
Yeah, radio silence! And that’s exactly all the hacker will hear from you.
…
…
…
ʕ·ᴥ·ʔ: ♫ The sound of silence ♫
Did you like this article? Think you’re now better equipped to keep yourself safe on public Wi-Fi? If so, then consider signing up for my mailing list by entering your email address down below, or subscribing to my RSS feed linked to in the menu. You’ll be notified of new articles (and only new articles) when I post them.