There’s No Such Thing as Free Wi-Fi

Have you connected your phone or laptop to a public Wi-Fi? This might be a free Wi-Fi hotspot at an airport, train station, shopping centre, hotel chain, or fast food franchise. If so, then your device may be vulnerable to a Known Beacons attack.

If you haven’t connected to any of the mentioned public hotspots, can you say the same for your colleagues? Connecting just once to an open wireless network is enough for most modern devices to save that network and automatically connect in future.

Beacon frames can be spoofed for common SSIDs (e.g. “Starbucks Wi-Fi”), enumerating any you might have saved. With this knowledge an attacker can configure a rogue access point to prompt an automatic association that may allow further attacks to be executed (data sniffing, phishing pages, client-side exploits, etc.). The technique can be scaled by cycling through wireless channels and flooding beacon frames from a dictionary list of common SSIDs.

In this post I’ll demonstrate why flooding beacons for common SSIDs can be a more effective method of attack than passively listening, and how to avoid being a victim of this attack.

Passive Attack: Listening for Probe Requests

Clients once freely transmitted more information about the wireless networks on which they had previously been connected. The client would actively send out targeted probe requests for an SSID, and if in range the network access point would respond with a probe response, after which an association would begin. Those probe request frames are in cleartext and can be passively sniffed and have enough information for an attacker to impersonate the network being probed and have the client automatically connect. Alternatively, an attacker could respond to all probe and association requests for any SSID, which is known as the KARMA attack.

1. Targeted Probe Request

However, the attack is more than 10 years old and has been largely mitigated on modern devices. Network Managers instead of actively probing for saved networks are now scanning passively. Clients will wait for a beacon frame from a network it recognises, and in the absence of a familiar beacon they will probe for only the broadcast SSID.

2. Broadcast Probe Request

Demo #1: KARMA Mitigation

In this example a client is connected to a WPA-PSK protected “Corporate_Wi-Fi” network. We mount a sustained deauthentication attack with aireplay-ng to and then observe the client.

aireplay-ng –-deauth 0 –a -c wlan0

With some filtering in Wireshark, we can see the client acting in two expected ways:

1.) The client sends targeted probe requests in acknowledgement of the beacon frames coming from the legitimate access point (however futile due to our deauth attack).

2.) The client sends broadcast probe requests, waiting for something in its preferred network list to make itself known.

The KARMA attack is effectively disarmed.

Active Attack: Flooding Beacon Frames

The client holds its cards close to its chest, but can be forced into a very one-sided game of Go Fish. If the client has previously connected to an open network, such as “AIRPORT_WIFI”, and is nowhere near the airport, what happens if a beacon frame is sent for that SSID?

Demo #2: Beacon Flooding a Single Known SSID

We run the same deauthentication attack but this time using mdk3 to flood beacons for the open network.

mdk3 wlan1 b –n AIRPORT_WIFI

3. AIRPORT_WIFI Targeted Probe Request

The client has been tricked into probing for a network that doesn’t exist (at least anywhere nearby). The saved network has been enumerated from their preferred network list, and again an attacker has learned everything they need to impersonate the network and coerce the victim into connecting.

4. Victim Connecting to a Rogue Access Point

This example was achieved with some cheating, though as it would be quite lucky to guess a single exact saved open network from a random client’s preferred network list. However, the attack can be scaled for better success by utilizing a dictionary of common SSIDs can be used in a beacon flood, hundreds of beacons sent every second if required.

Demo #3: Beacon Flooding Using a Dictionary While Hopping Channels

In the third test we’ll use the dictionary list of common SSIDs and a bash script to cycle the wireless adapter through channels in the 2.4 GHz range, while at the same time monitoring probe requests from a single client.

mdk3 wlan1 b –f /tmp/ssid_list.txt –s 100

5. Known Beacon Probe Requests

The client starts singing like a songbird.

The Impact

The attack exploits the Auto-Connect flag which makes it particularly hidden. The probe requests and automatic association to a rogue access point is done silently on the victim’s device, where the victim will experience only a momentary lapse in connectivity.

The previous tests were replicated on Android Nougat, iOS 11, and macOS High Sierra with similar results. Windows 10 requires the “connect automatically” option selected upon first connection to any of the saved networks.

The Fix

The simple answer is to just never connect to an open network, or if you must then do so sparingly and remove all trace of the network from your device when you’re finished. What is harder is having everyone in your company do the same. It’s recommended regularly testing of company devices to see if they’re probing for easily enumerated SSIDs.

In addition, disable auto-connect where possible, and turn off Wi-Fi when not in use, e.g. in sleep mode.