Have you
connected your phone or laptop to a public Wi-Fi? This might be a 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 to
be executed ( 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 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
.

- 001 - There’s No Such Thing as Free Wi-Fi

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.

- 002 - There’s No Such Thing as Free Wi-Fi

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 <bssid> -c
<client> 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).

- 003 - There&#8217;s No Such Thing as Free Wi-Fi

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

- 004 - There&#8217;s No Such Thing as Free Wi-Fi

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_”,
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

- 005 - There&#8217;s No Such Thing as Free Wi-Fi

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.

- 006 - There&#8217;s No Such Thing as Free Wi-Fi

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

- 007 - There&#8217;s No Such Thing as Free Wi-Fi

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 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
  • References:

    https://census-labs.com/news/2018/02/01/known-beacons-attack-34c3/

    https://theta44.org/karma/

    https://www.aircrack-ng.org/

    https://www.wireshark.org/

    https://github.com/charlesxsh/mdk3-master

    https://w1.fi/hostapd/

    https://en.wikipedia.org/wiki/Go_Fish

    https://wifiphisher.org/

    https://wigle.net/

    https://en.wikipedia.org/wiki/IEEE_802.11#Management_frames



    Source link

    LEAVE A REPLY

    Please enter your comment!
    Please enter your name here