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
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.
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.
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
1. Targeted Probe Request
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
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
aireplay-ng –-deauth 0 –a <bssid> -c
filtering in Wireshark, we can see the
client acting in two expected ways:
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).
The client sends broadcast probe requests,
waiting for something in its preferred network list to make itself known.
The KARMA attack
is effectively disarmed.
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
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.
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
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
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.
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
disable auto-connect where possible, and turn off Wi-Fi when not in use, e.g.
in sleep mode.
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.
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
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.
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.
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.