A hacker intercepted your WiFi traffic, stole your contacts, passwords, & financial data.

Originally published by Patrick F. Wilbur Follow on February 2nd 2019 61,406 reads

A hacker intercepted your WiFi traffic, stole your contacts, passwords, & financial data. Patrick F. Wilbur is a security researcher and cypherpunk with a fascination for the human element and its role in everyday people’s privacy and security. Tons of online traffic remains entirely unencrypted today, leaving the public susceptible to attack. Wilbur: Public Wi-Fi is intentionally insecure and susceptible to several modes of attack. Here are a few ways to sniffing traffic on public networks.

@cryptack
Patrick F. Wilbur Follow

The future called, and it wants to give us its Internet.

Introduction

As the holiday season was in full swing, a hacker sporting a hoodie, sitting in a car with antennae on the dashboard and a computer on his lap, sat in a parking lot outside a popular cafe chain. Passersby, busied and high on holiday cheer, buzzed in and out and sometimes even stayed for a while.

As he watched Wi-Fi traffic for several hours, nobody called the police or even seemed to notice. People accessed websites like Netflix and Google insecurely over HTTP, revealed all of their browsing activities, made phone calls revealing phone numbers, and sent plenty of unencrypted traffic available for him to intercept or modify at will to carry out phishing or vishing attacks. This is how I think such a story could be carried out.

I didn’t actually hack anyone, but I did build a tool to show how hackable people are when they use the Internet.

It’s like a credit score, but for your security vulnerabilities.

A rare photo of me in my teen years with friends (I’m not sure how United Artists Pictures found this gem)

I am a security researcher and cypherpunk with a fascination for the human element and its role in everyday people’s privacy and security.

I have conducted (only a few years ago) social engineering experiments against, e.g., my own phone providers, having friends of mine trick them into letting them access my accounts and information in dangerous ways (resulting in those companies inadvertently violating federal privacy and consumer protection regulations).

In a past life, I had a lot of fun playing with payphones. I am also a big proponent of encrypting everything on the Internet, always.

During my day job, I work on making the Internet safer and more performant at Magic — which is building a decentralized Internet backbone for the future.

Over the holidays, I set up an experiment harvesting public Wi-Fi traffic. Since everything on the web should be encrypted nowadays (and many people incorrectly think that all traffic is encrypted), one might expect that there isn’t much to be seen.

Unfortunately, that’s not the case. While the state of insecurity has improved since Firesheep’s prime, an attacker can still phish you and play games with your packets when you use a public network. Sorry to be the bearer of bad news…

The scores are pretty bad: Tons of online traffic remains entirely unencrypted today, leaving the public susceptible to attack.

It’s So Easy to Monitor the Public’s Internet Traffic

Spying on web traffic sent over a network. Credit: Wireshark Team [GPL (http://www.gnu.org/licenses/gpl.html)], via Wikimedia Commons

First, find an easy target

One of the convenient things about the holidays is that plenty of potential victims congregate at shopping centers. This makes it relatively easy for an attacker to target a large number of personal devices just by “setting up shop” near locations where people are accustomed to finding unencrypted Wi-Fi.

These shoppers are also likely loaded with money to spend and are doing so at such a high frequency and at so many locations that they’ve probably already nullified some of their bank’s (and their own) ability to detect fraud with any timeliness whatsoever, making them perfect targets for theft as well.

Then, deploy your (very generous) free public Wi-Fi

Whats the recipe for a public Wi-Fi network?

1. Use absolutely no encryption at all, or
2. Use a pre-shared key and tell everyone (no different than #1)

Public Wi-Fi is intentionally insecure and susceptible to several modes of attack

And, use one of the simple public Wi-Fi attack methods

There are a variety of attack vectors for sniffing traffic on public networks. Here are a few surprisingly low-effort and low-cost methods:

An attacker can passively listen in on traffic (even from very far away, without connecting or otherwise indicating to the network the attacker’s presence) with either an off-the-shelf wireless network adapter (e.g. a USB network adapter from Alfa) or an off-the-shelf software-defined radio
Simply with freely-available software (e.g. Wireshark) and no additional hardware an attacker can connect to a network and promiscuously retrieve network packets from others (this is only sometimes prevented on switched networks)
An attacker can deploy a dedicated, rogue Wi-Fi pineapple to actively intercept packets by broadcasting a new Wi-Fi network for the sole purpose of carrying out attacks

But this is all probably illegal, right?

Does the law effectively protect people on Wi-Fi?

Short answer: Not really.

While certain caselaw has found that receiving unencrypted Wi-Fi communications under certain circumstances might not be illegal* under Federal law in the U.S., there exist some contradictory opinions on the matter, and there also exist a whole host of states’ laws that protect privacy.

That being said, the three modes I mentioned (above) are so easy that a lamer or script kiddie can use them. So, while The Fuzz should scare you away from hacking your friends, you should not base your own cybersecurity defenses on the assumption that (laws written on) paper will somehow shield you from cyber bullets.

* Disclaimer: The “jury” is still out (so to speak, since Federal courts are not in agreement) on the legality/illegality of intercepting unencrypted Wi-Fi communications under Federal law. I’m not a lawyer, and none of what appears in this article is legal advice; but, as an example, Google settled a lawsuit for a mere $7MM involving Google Street View intercepting and recording unencrypted traffic sent on other people’s networks, which contained passwords and all sorts of juicy information. Google can probably afford better lawyers than you, so consider yourself forewarned to not do naughty things! I refuse to be held responsible for the consequences of your own actions.

Cortados, Pineapples, and Packets: How people freely give an attacker all their data simply for some Wi-Fi

Cortados and compromised Wi-Fi go really well together (pictured here is an inexpensive Alfa USB wireless card, with high-gain/long-range antenna, capable of passive monitoring mode)

Pineapples are a symbol of hospitality, so I built a Wi-Fi pineapple to make new friends.

The Setup: Free Guest Wi-Fi

As someone who cares about obeying the law and protecting people’s privacy, I designed a white-hat experiment to uphold principles of honesty, consent, anonymity, and data privacy.

Unlike Google Street View, I chose not to surreptitiously record (in memory or to disk) application payloads, any personally identifiable information, or even any metadata about which hosts connected to which servers.

I set up a homemade captive portal analogous to what’s referred to as a Wi-Fi pineapple, but with the key difference that it did not impersonate the names of any nearby or common wireless networks (because I did not want users to have any misconceptions about who operated the network).

The SSID “Free Guest WiFi” seemed generic enough, and it greeted users with a nice captive portal splash page containing a non-verbose agreement that obtained from the user consent to having the user’s information and communications monitored.

Overall, this was a pretty friendly way to conduct the experiment. A real attacker would be far more aggressive.

The Would-be Exploit: I wrote specialized software to determine how hackable you are

To further protect users’ privacy, I wrote a small tool to gather statistics about the protocols and ports that applications were using over the network.

Three lines of code is all it really takes:

p = pcap.pcap(name=interface)
p.setfilter(‘’)
p.loop(0,handler)

My tool, as designed, does not record any IP addresses, MAC addresses, host names, or application data, and cannot be configured in a way to do any of that. It serves only one purpose: summarizing types of packets and ports being used in the least intrusive way possible.

In fact, my tool is less intrusive than the deep packet inspection and intelligence provided by enterprise access points and routers (e.g. Ubiquiti Networks products), which ensured that I would be less creepy than a sysadmin and significantly less creepy than an ISP. To further help protect privacy, I made sure any captive portal logs were written into a tmpfs volume just in case there could be any usage log leakage.

Again, I think this is pretty darn nice of me.

A black-hat hacker could simply use Wireshark and see all of the application data and which websites were being visited.

Okay, but for real, who uses the “Free Guest WiFi”?

Here’s how many people connected over the course of one afternoon:

49 devices connected

100% accepted the ToS in the captive portal and sent data

0 devices used VPNs

The scientists among you will notice my experiment introduces selection bias. The statistics gathered only included persons that explicitly scanned for open Wi-Fi networks, chose my network, and accepted the terms on the captive portal splash page. Such people selecting public networks might be more likely to engage in risky internet behaviors. But, the fact that human interaction was required highlights just how easy these types of attacks are.

I actively made choices that made it difficult to collect users data and nearly 50 people still connected, even though other open networks existed in the vicinity.

Furthermore, due the fact that using my network required human interaction in the first place, it necessarily excludes any Internet of Things (IoT) devices from being included in the statistics and includes only devices with which humans are directly interacting (e.g. mobile phones and laptops).

This is all a bit concerning, but important things on the Internet are all encrypted anyways, right? RIGHT? 😬

Unfortunately HTTPS is not enough to protect you. In fact, its often implemented incorrectly even by major websites you know and trust. (Image credit: TACstock1/Shutterstock.com)

More bad news here: >42% of all traffic through my pineapple was unencrypted HTTP traffic.

My tool ignored non-IP traffic from its statistics. After gathering 489,330 IP packets, it reported that:

>42% were on Port 80 used by unencrypted HTTP (compared to almost 57% on Port 443 used by HTTPS)
2,638 were unencrypted DNS packets
18 were unencrypted Network Time Protocol (NTP) packets

The raw transport, port, counts, and percentages were as follows:

Totals:
udp 8992  4      0.000817444260519
udp 5090  482    0.0985020333926
udp 67    49     0.0100136921914
udp 5353  64     0.0130791081683
udp 5355  37     0.00756135940981
udp 53    2638   0.539104489813
udp 137   73     0.0149183577545
udp 3544  54     0.011035497517
udp 123   18     0.00367849917234
udp 443   203    0.0414852962214
tcp 993   63     0.0128747471032
tcp 5223  79     0.0161445241453
tcp 9001  350    0.0715263727955
tcp 5228  199    0.0406678519608
tcp 80    207538 42.4126867349
tcp 53    12     0.00245233278156
tcp 443   277467 56.7034516584
489330

In conjunction with DNS and NTP being insecure, to have 42% of traffic potentially be unencrypted HTTP traffic sent via Port 80 is deeply concerning. What about those HTTP Strict Transport Security (HSTS) policies that web browsers should be enforcing? Is the traffic non-web traffic or some sort of other false positive?

With my hands tied by not being able to (ethically) examine packets at a deeper level…

I later set up a second experiment in my own lab to examine the behavior of a few popular websites myself. I discuss these findings further in Part 2 of this series (where I also explain why we are where we are today, and explain what some popular websites are doing incorrectly).

But, I’ll summarize the findings here:

Popular websites are not always implementing HSTS properly, if at all (this includes Google and Netflix)
Users of public Wi-Fi networks are still vulnerable to man-in-the-middle (MITM), interception of private data, and other attacks

Darn!

But, don’t take my word for it…

Before you go through the trouble of trying to find data to refute this analysis, LMGTFY: I tried really hard to prove myself wrong, but then I found Google’s HTTPS encryption on the web transparency report, which uses anonymous usage reporting among Chrome users as well as Google’s own internal data as sources to determine the state of HTTPS usage on the web.

According to Google’s own report (as of December 29, 2018):

11–31% of all websites are visited without encryption
(accessed over unencrypted HTTP)
~7% of traffic to Google products is unencrypted
(as high as 10% for some Google products)
82.6% of this traffic sent to Google originates from mobile devices
(makes me feel awkward to consider using a Google-developed OS ever again)

That’s not insanely far off from the statistics recorded by my tool, especially considering the selection bias and also my unscientific observation that more people were drinking coffee and using mobile devices (just look at that 82.6% number, again!) than were sitting at laptops.

I’m not saying we need to fear the FUD… but, actually, I am saying that we need to fear the FUD.

I’m also saying that you should fear hackers wearing hoodies, with antennae all over their vehicles, that are looking at you through binoculars in broad daylight, but I digress.

How Would an Attacker Use This Traffic to Hack You?

I did not hack anybody or compromise anybody’s privacy, and I did consult with legal counsel before publishing this. But, here are some of the ways that people using public Wi-Fi can be compromised, today, by inexpensive hardware and/or free tools (e.g. wireless adapter, Wireshark, Bettercap, etc.).

Phishing

First, to successfully carry out a phishing attack, an attacker could target some of the popular sites that are accessible over HTTP and not implementing HSTS properly, maybe also leveraging DNS requests since all are insecure (in a sense, captive portals used to work by carrying out DNS-forged MITM attacks every time they wanted to display their splash pages, and this is easily accomplished with DNS today since DNS has never been secured properly since).

Create a Sense of Urgency

Our hypothetical attacker could, ideally, create a sense of urgency to get users to make more mistakes by hurrying (i.e. overlooking the long and slightly modified URL in the address bar). For example, a captive portal that prompts a user for their email address and provides a very short amount of time to check email for a verification link before they get kicked offline could be the perfect companion to a phishing login page for said email provider.

Best yet, once grabbing the user’s credentials and confirming that they are correct, booting them off the network with a fake error message might slow them down from noticing the compromise or from resetting their email password. >:~>

Fabricate a Familiar Pretext

Serving up the hypothetical attacker’s own phishing pages and securing them with Let’s Encrypt certificates should be easy enough. At least, then, they should look “secure” just long enough to fool a frantic Internet addict into trading their digital identity for a few more minutes of Snapchat. If someone wanted to target credentials for a higher-profile website — perhaps one that actually implements HSTS properly but, with no surprise, just like a number of popular websites it isn’t in the preloading list — the attacker could just wait to target potential victims until after their computer sent an NTP request.

By playing with time travel and alternate universes (forging an NTP response with a time set in the future), all HSTS policies cached by the user’s browser whose cache entries expired before the new “present” time could be invalidated. Then, the attacker could just carry out a downgrade attack, 301 Redirect via HTTP to a phishing page, and the rest is gravy.

Confuse the s/Deputy/User/

Our hypothetical attacker could trick people into installing some backdoor or botnet software. From then on, the attacker could basically pwn their devices, information, and network of contacts whenever convenient, and identity theft or theft of money would be easy. For this, the attacker could pop up some “warnings” about viruses or spyware on the computer, and kindly suggest that users install an actual virus to “fix” it.

This would require the user to actually allow the attacker’s software to be installed. Alternatively, our hypothetical attacker could just mine cryptocurrency in users’ web browsers, which wouldn’t require tricking users into giving their consent for software to be installed.

Hit the Unencrypted Plaintext Jackpot

Additionally, the traffic that my tool saw sent over Port 5090 is interesting, in that it is a port used by common business VoIP mobile apps to send phone calls over the SIP protocol. Some cellular providers similarly offload voice traffic in this way. I was pleasantly surprised to see this in my statistics! Even if SIP payloads are encrypted, their headers are not, and often contain CID and DID (telephone numbers) in the clear.

This could be particularly useful to our hypothetical hacker for carrying a vishing attack on victims or their contacts, since CIDs are easily spoofed to make an attacker caller look familiar. If our hypothetical hacker wanted to hack you or your life by phone, he or she could gather these phone numbers and have a little fun with them later. >:~> >:~>

All the problems with public Wi-Fi

I’m not trying to over-hype the problems with public Wi-Fi, but I do want to keep these issues at the forefront of people’s minds.

We’ve made progress improving the Internet’s basic security, but it’s not anywhere close to enough.

There are still gaping problems that we (technologists) have failed to fix for the rest of humanity for way too long. On public Wi-Fi networks, even today, an attacker can:

See what sites you’re going to (simply by intercepting DNS requests)
Carry out downgrade and MITM attacks through initial HTTP page loads
Circumvent HSTS by injecting fake future times via NTP (those HSTS policies do have expiration dates, ya know)
Phish for sensitive information
Vish you, your friends, and your family
Inject fake content/ads or even mine cryptocurrency using your CPU
Trick you into running insecure plugins like an outdated version of Flash
Spoof a news headline about foodborne illness reports from the local establishment and watch people get up and leave abruptly
Spoof a captive portal page that looks like it’s from a nearby network and grab some contact information
Validate contact information by forcing you to click on a link in email in order to remain connected, thereby creating a sense of urgency and possibly tricking you into entering your email credentials

You’re sufficiently freaked out and want to know how you can protect yourself?

I’m glad you asked.

There are some commonsense things you can do to make yourself a less-easy target. By default, you should at least use a VPN and the HTTPS Everywhere browser plugin. If you are not, you probably should reconsider your security posture entirely.

We are actively working on solving these problems at Magic, where we are implementing VPN-like functionality and a capabilities-based security paradigm by default.

To learn more and join the conversation on how to build a safer, more performant Internet, check out magic.co or https://github.com/magic-network

And, then what?

In Part 2 of this series, I look into the question, “Why are we here?” and what popular websites and protocols are doing wrong to create such a mess. Then, in the upcoming Part 3 of this series, I will discuss the exhaustive list of things one needs to do in order to be safe online, in light of what I discussed in Parts 1 and 2.

Watch Now: Enforce K8s Best Practices with Datree