Share this article
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 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 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.
Tips for Testers
The attack is not elaborate, but all the dominoes need to be lined up for the best results. Here are some tips for testing your company devices.
- The channel matters. If the client joins an open network on one frequency and beacons are flooded for that SSID on another frequency, the client will likely be silent. It’s recommended to cycle through wireless channels.
- Flood fast – Hop slow. The more SSIDs in your dictionary then the more beacons you need to flood for the attack to be effective, which in the extreme could lead to a DoS. In this tester’s experimenting, at least 30-60 seconds per wireless channel and 50+ beacon frames per second had best results. This will however require further testing.
- The best results come from a targeted deauth and filtered sniffing on a single client. You’ll still have results from a scaled attack, however, disruption will be maximised and probe requests will be more erratic.
- The attack is as good as the dictionary used. The Wifiphisher community has put one together, alternatively, you can create a targeted list by wardriving the general area or using online tools such as WiGLE that catalogues wireless hotspots around the world.
- I’ve made a tool here to help conduct the attack - https://github.com/b3n-j4m1n/flood-kick-sniff
Speak with a Tesserent
Tesserent is a full-service cybersecurity and secure cloud services provider, partnering with clients from all industries and all levels of government. Let’s talk.