Modern Wireless Tradecraft Pt II — MANA and Known Beacon Attacks
In Part I of this series, we went over some 802.11 fundamentals and described how the roaming and network selection features of the protocol can be abused to perform wireless Person-In-The-Middle (PITM) attacks. We also discussed how to perform basic rogue access point attacks in EAPHammer (see: https://github.com/s0lst1c3/eaphammer). If you haven’t read Part I yet, you can find it here:
In this next section of the series, we will describe how improvements in client device security have made karma attacks much less effective. We’ll then discuss three offensive techniques developed by Dominic White (@singe), Ian de Villiers, and George Chatzisofroniou (@sophron) that can be used to circumvent some of these improvements [1][2]:
- MANA Attack: a karma-style attack developed by Dom White and Ian de Villiers in which the rogue access point (AP) reconstructs the Preferred Network Lists (PNLs) of nearby devices [1]
- Loud MANA Attack: a variant of the MANA attack developed by Dom White and Ian de Villers in which the rogue AP sends beacon and probe response frames for each ESSID in the union of all PNLs of nearby devices (I’m describing this in terms of set theory, see detailed explanation below)[1]
- Known Beacon Attack: a rogue AP attack developed by George Chatzisofroniou in which the attacker attempts to bruteforce the PNLs of nearby devices in order to force a connection [2]
After discussing how these techniques work at both an algorithmic and technical level, we’ll cover how these techniques were implemented in EAPHammer.
Limits in Active Probing
In Part I of this series, we discussed how directed probing is a pretty obvious design flaw that has serious security implications for wireless client devices. Because of this, modern devices typically avoid relying on directed probe requests, which severely limits the success rate of the original karma attack [1].
As White and de Villiers pointed out in their presentation “Manna from heaven” at DEF CON 22, modern client devices usually exhibit one of the following two characteristics:
- the device ignores probe responses from APs that didn’t first respond to a broadcast probe [1]
- the device neglects to use active probing altogether and instead relies exclusively on passive scanning [1]
The sections that follow will go over techniques that were developed by White, de Villiers, and George “sophron” Chatzisofroniou to deal with these improvements in client device design [1][2].
MANA Attacks: Targeting devices with limited active probing
MANA attacks were developed by Dom White and Ian de Villiers in 2015, and are an improvement of Dino Dai Zovi and Shane Macaulay’s original karma attack that we covered in Part I. In the original karma attack, the rogue access point does not keep a history of which ESSIDs it has received probe requests for. Instead, the rogue AP blindly responds to every directed probe request it receives with a matching probe response [1][3][4]. This is problematic, since many modern devices ignore probe requests from APs that haven’t first responded to a broadcast probe. MANA is a technique for circumventing this restriction.
In a MANA attack, the rogue AP uses a hash table to record the MAC addresses of each client device from which it has received probe requests. Each MAC address in this main hash table maps to another hash table of ESSIDs that the device has probed for. By doing this, the rogue AP is able to efficiently reconstruct and track the PNLs of nearby client devices that use directed probing [1][3][4].
The MANA algorithm works like this: each time the access point receives a probe request, it first determines whether it’s a broadcast or directed probe. If it’s directed probe, the sender’s MAC address is added to the hash table (if it’s not there already) and the ESSID is added to that device’s PNL. The AP then responds with a directed probe response. If it’s a broadcast probe, the access point responds with probe responses for each of the networks in that device’s PNL [1][3][4]. The rogue AP’s ability to maintain state about the PNLs of nearby devices is what enables it to respond accurately to both directed and broadcast probes.
Executing MANA Attacks With EAPHammer
As of version 1.4.0, EAPHammer’s basic karma implementation has been replaced with its own implementation of White and de Villers’ algorithm, greatly increasing its effectiveness against modern wireless devices. From a developer’s perspective, this was some of the most challenging coding I’ve ever written, and I can’t even imagine what it was like for White and de Villiers to do this without an existing roadmap (especially considering that the entire attack must be implemented in C using kernel and driver level library functions).
To use EAPHammer’s new MANA functionality, use the —-mana flag as shown in the following example:
./eaphammer -i wlan0 -e theClientAcceptsTheRisk --cloaking full --captive-portal --mana --mac-whitelist whitelist.txtAlternatively, you can keep using the —-karma flag as before, which now is an alias for the —-mana flag:
./eaphammer -i wlan0 -e seemsLegit --cloaking full --captive-portal --karma --mac-whitelist whitelist.txtKnown Beacon and Loud Mode Attacks: Targeting devices without directed Probing
White’s and de Villers’ MANA attacks allow us to target devices that ignore probe responses from APs that cannot accurately respond to broadcast probes. However, the standard MANA attack still does not allow us to attack devices that don’t use directed probing at all [1].
To deal with these devices, we could use an evil twin attack if we possessed advanced knowledge of the target’s PNL. But what if we don’t have this information up front? There are two techniques that can be used to overcome this issue: the George Chatzisofroniou’s Known Beacon attack and White’s and de Villers’ Loud Mode attack. We’ll go each of these attacks in the sections that follow.
Loud Mode Attacks
Loud Mode is a variation of the MANA attack which relies on the idea that client devices within close physical proximity to one another are likely to have at least some common entries in their PNLs [1].
Let’s consider the security implications of this idea. I often find that breaking things down into (pseudo)mathematical logic can make it easier to reason about scenarios such as the one we’re considering:
Let A and B be wireless client devices within close physical proximity to one another.
Suppose A uses directed probing for network discovery.
Suppose B does not use directed probing for network discovery, and instead relies exclusively on passive scanning.Suppose that the PNLs of A and B intersect.
Since A uses directed probing, we have knowledge of its entire PNL.
Therefore we also have knowledge of at least one entry in B’s PNL, since the PNLs of A and B intersect.Hence, we can attack both A and B using a rogue AP attack.
Loud Mode attacks are similar to basic mana attacks, but with one key difference. Instead of responding to probe requests with each ESSID in a particular device’s PNL, the rogue AP sends probe responses for every ESSID in every PNL across all devices that it has seen before. Relating this to set theory, we can say that the AP sends probe responses for each ESSID in the union of all PNLs of nearby devices. By doing this, loud mode attacks allow an adversary to target a relatively secure device by exploiting the bad probing behavior of a second device [1][3][4]
Executing Loud Mode Attacks in EAPHammer
Loud Mode attacks in EAPHammer are algorithmically pretty similar to the one originally implemented in hostapd-mana, despite some differences in how they are implemented. Because of this, tradecraft considerations for both tools are the same.
To execute a Loud Mode attack in EAPHammer, use the --loudflag in combination with either the —-karma or —-mana flags (remember they are aliases for one another):
./eaphammer -i wlan0 -e replicantWifi --cloaking full --mana --loudAlternatively, the --singeflag can be used as an alias for the --loudflag (which I’ve included to troll the attack’s creator):
./eaphammer -i wlan0 -e tyrellCorp --cloaking full --mana --singeKnown Beacon Attacks
Although Loud Mode attacks can be highly effective, especially in densely populated areas, there are still cases in which they won’t succeed.
The Known Beacon attack, which was first developed and implemented by George Chatzisofroniou in early 2018, is an attempt to get around this problem [2]. The genius is this attack lies in its simplicity. The attacker begins by constructing a set of “known ESSIDs” from a wordlist file. Next, the attacker stands up a rogue AP that is patched to accept association requests for arbitrary ESSIDs (similar to the basic karma attack). Finally, the attacker begins transmitting beacon frames for all of the ESSIDs in the known ESSID list. Speaking in terms of set theory once again: if the set of all ESSIDs that are in the wordlist intersects with the set of all ESSIDs in the target device’s PNL, the target device will connect to the rogue access point [2].
Ideally, Chatzisofroniou’s Known Beacon attack should be performed using a wordlist of relatively common ESSIDs.
Executing Known Beacon Attacks in EAPHammer
EAPHammer’s implementation of the Known Beacon attack differs considerably from the original created by Chatzisofroniou. In the Chatzisofroniou’s implementation, the wordlist is loaded into a Python script that runs concurrently with the rogue AP. As the rogue AP runs, the Python script uses Scapy to forge and transmit beacon packets for each entry in the wordlist (see: https://scapy.net/). In EAPHammer, the wordlist is loaded into the same hash tables that are used to implement the MANA and Loud Mode attacks that were described earlier in this writeup. This allows EAPHammer to transmit the beacon frames directly from the rogue AP itself, rather than relying on standalone code that runs alongside the AP.
In terms of syntax, there are a couple of different approaches to using EAPHammer to execute Known Beacon attacks. Both methods rely on the use of the--known-beacons flag. The --known-ssids flag can be used to supply a short wordlist of ESSIDs directly via EAPHammer’s command-line interface (CLI), as shown in the following example:
# transmit beacons for the following ESSIDs: apples, oranges, grapes, pears, bananas./eaphammer -i wlan0 \
--mana \
-e apples \
--known-beacons \
--captive-portal \
--known-ssids oranges grapes pears bananas
Alternatively, you can use the --known-ssids-file flag to specify the path to a wordlist file containing a list of ESSIDs, as shown in the following example:
# transmit beacons for the following ESSIDs: apples + all ESSIDs in wordlist.txt
./eaphammer -i wlan0 \
--mana \
-e apples
—-known-beacons \
--captive-portal \
--known-ssids-file wordlist.txtThe wordlist file should be in the following format, with a single ESSID on each line:
oranges
grapes
pears
bananas
dragon
lycheeIt’s important to note that EAPHammer will permit you to place whitespace at the start and end of each line in the wordlist file, and will interpret this whitespace as part of the ESSID. Make sure to proofread your wordlist files accordingly before using them.
For increased effectiveness, the --known-beacons flag can be combined with the --loud flag alias shown in the following command:
./eaphammer -i wlan0 --mana --loud -e apples --known-beacons --captive-portal --known-ssids-file wordlist.txt
Known Beacon Burst Attacks
Known Beacon attacks tend to be a bit loud. EAPHammer provides a stealthier option in the form of its `forge-beacons` script (written in Python), which runs alongside your rogue AP and can be used to transmit a burst of forged beacon packets over a short period of time. All you have to do is point it towards a wordlist file and give it the BSSID of your AP, as shown in the following example (note that the --mana flag needs to be enabled on the AP for this to work):
# transmit a burst of 5 forged beacon packets for each entry in list
./forge-beacons -i wlan1 \
--bssid de:ad:be:ef:13:37 \
--known-essids-file known-s.txt \
--dst-addr 11:22:33:11:22:33 \
--burst-count 5
This script is most effective when paired with a rogue AP that uses Management Frame ACLs, which we’ll talk about in Part III.
Conclusion
This concludes Part II of this writeup. In Part III, we’ll go over how to use Management Frame ACLs (MFACLs) to constrain the MANA and Known Beacon attacks to specific targets, making them operationally viable within a professional context. We’ll also provide detailed descriptions of how MFACLs work at a technical level, and discuss their impact of hostapd’s runtime efficiency.
References
[1] https://sensepost.com/blog/2015/improvements-in-rogue-ap-attacks-mana-1%2F2/
[2] https://census-labs.com/news/2018/02/01/known-beacons-attack-34c3/
[3] https://github.com/sensepost/hostapd-mana/blob/master/src/ap/beacon.c
[4] https://github.com/sensepost/hostapd-mana/blob/master/src/ap/ap_config.h
