The Frame of Deception: Wireless Man-in-the-Middle Attacks and Rogue Access Points Deployment

Our next stop is wireless man-in-the-middle attacks. The first question you might have is why we need man-in-the-middle attacks on 802.11 LANs at all. On the switched wired networks, man-in-the-middle attacks are frequently used to allow the possibility of traffic sniffing. 802.11 LANs are shared medium networks by definition, and once you've dealt with the encryption (if present) you can sniff all the packets on the LAN even without being connected to it. We have already answered this question when describing Dsniff utilities: The answer is connection hijacking and traffic injection. Positioning yourself between two wireless hosts gives an unmatched opportunity to inject commands and even malware into the traffic streams between both hosts. Becoming a rogue access point or wireless bridge means there are far more than two hosts to target with the connection hijacking or traffic injection and modification tools we review in the next chapter.

A specific implication of man-in-the-middle attacks is providing a rogue access point to attack one-way 802.1x authentication systems that use EAP-MD5. To perform such an attack, your rogue AP will also have to be a rogue RADIUS server providing fake credentials in the form of always positive authentication reply to the deceived client hosts. As you will see later, setting both a rogue access point and a RADIUS server on a laptop is not as difficult as you might think. However, such an attack would have a limited use, because the current 802.1x solutions support mutual (client-to-server and server-to-client) authentication and will use EAP-MD5 as a fallback solution only.

Wired man-in-the-middle attacks can be performed using DNS spoofing, ARP cache poisoning, or sneaking into the switch room and changing some cable plug-in positions (a la Kevin Style). Wireless man-in-the-middle attacks are akin to the latter case, but you can be miles away from the switch room. Man-in-the-middle attacks on WLANs can occur on both the first and second OSI layers. Layer 1 man-in-the-middle attacks refer to jamming an existing wireless AP while providing your own clear signal AP at least five channels away from the attacked AP channel. The jamming can be performed using a specific jamming device or by flooding the AP channel with junk traffic (e.g., using FakeAP, Void11 or File2air). If a jamming device is used, the defending side will need a decent frequency analyzer to detect the jamming attack; traditional wireless IDS won't help.

Of course, the parameters of your rogue AP (ESSID, WEP, MAC) should reflect the parameters of the legitimate access point. Layer 2 attacks differ by using a spoofed deassociation or deauthentication frames flood to kick the target host from its link with a legitimate AP. This is generally more efficient than the channel jamming. A determined attacker can easily combine both Layer 1 and Layer 2 attacks to reach the maximum effect. The majority of modern client cards will detect the new rogue AP on a channel different from the one they currently use and automatically associate with it if the association with the legitimate AP has been made hard or impossible. However, if the clients are preset to work at the specific frequency only, the chances of a successful man-in-the-middle attack are dramatically decreased because the attack will depend on outspoofing or outpowering the legitimate AP on the channel it runs. Such an attempt is likely to end up as a DoS attack due to the RF interference.

When launching man-in-the-middle attacks, you don't have to pose as an access point in all cases; sometimes an attacker might want to knock off a selected client host and substitute his or her machine as that host to the access point and the rest of the network. This task is significantly easier: A client host is likely to have lower EIRP, so you don't have to set your host as an access point (emulating the attacked host's IP and MAC is enough) and a quick man-in-the-middle attack against a single host is less likely to cause user complaints and disturbance in the logs. Besides, you can be closer to the victim machine than you are to the access point.

DIY: Rogue Access Points and Wireless Bridges for Penetration Testing

Many wireless security literature sources depict wireless man-in-the-middle attackers as people carrying hardware access points and accumulator batteries around. Frankly, this is ridiculous and makes it sound more like a van-in-the-middle attack. How long would you be able to wander around with a heavy battery, an access point, a laptop, cables, and antennas? Also, it is much easier to hijack connections and inject data if you do it on one of the hijacking machine network interfaces rather than force a hardware access point in a repeater mode to route all traffic through the Ethernet-connected attacking host (how would you do it in reality?). Thus, the optimal solution is to set a software-based access point on a client card plugged into the attacker's laptop (or even PDA). A second plugged-in card can be used as a jamming/frame-generating device to bring down a legitimate AP. Both cards might have to run using different drivers or at least be produced by different vendors to provide proper functionality separation. Several variations of the attack exist, such as using two bridged access point-enabled client cards or using two laptops instead of one, with the obvious functionality of one being used as an access point and another as a DoS-launching platform.

Our discussion will be mainly devoted to Linux-based access points, because we had more play time with them. There is nothing wrong with using BSD-based APs in wireless security auditing. A Windows-based ZoomAir access point is easy to set up, but offers limited functionality, and there are hardly any decent hijacking or traffic injection tools for the Microsoft platform.

The easiest way to launch a man-in-the-middle attack is by using the monkey_jack utility provided with AirJack, assuming your AirJack compilation and configuration went well as we described in Chapter 5:

Supply all the necessary parameters, press Enter, and see your host's Hermes/Orinoco chipset card being inserted between the target host on the WLAN and the access point. To amplify the attack on the first layer, use the highest EIRP you can reach with your cards and available antennas on both flooding and the AP cards. Try -v FF:FF:FF:FF:FF:FF for a weapon of mass deception.

Alternatively you can set an access point employing two Prism chipset cards and hostap drivers and use FakeAP as a channel flooding tool on one of the cards, while the second card runs in a Master mode (AP). Flooding a channel with beacons is not as efficient as sending deauthentication frames, so you might opt for combining one card running under HostAP and one using airjack_cs. To do the latter, edit the /etc/pcmcia/config file and bind one card to the "hostap_cs" and another to "airjack_cs" modules. Restart the PCMCIA services, insert both cards, and go. Use wlan_jack or fata_jack to deassociate hosts from the network AP. Alternatively, you can stick to HostAP drivers only, install Libradiate, and use omerta to generate deassociation frames sent by one of the cards. Even better, you can strike with Void11 using an opportunity to deauthenticate multiple hosts, run concurrent floods, or even try to take down the legitimate access point with authentication or association frames bombardment. The choice is yours.

Installing and setting HostAP drivers is very easy. Grab the latest version of HostAP from the CVS at http://hostap.epitest.fi/, do make && make_pccard as root (we assume you use a PCMCIA client card), restart the PCMCIA services, and insert your card. You should see something like this:

The card automatically runs in the access point (Master) mode with the default ESSID "test." Note that if you insert a Hermes chipset card, it will work with hostap_cs, but you cannot place it into the Master or Repeater modes, the interface is eth1, and the default ESSID is blank. To change the card modes use iwconfig <interface> mode ad-hoc || managed || master || repeater || secondary || monitor. Read the fine manpages to learn more about the modes supported. Try the Repeater mode with HostAP and Prism chipset card to insert a rogue repeater into the testing wireless network as another man-in-the-middle attack possibility:

Another similar and rather fanciful thing to try is inserting a double card wireless bridge into a point-to-point link (a true man-in-the-middle attack, because the best position for the attacker would be right between the endpoints, in the middle of the Fresnel zone). For this attack you'll need to have bridging and 802.11d (if you want to use the Spanning Tree Protocol, or STP) support enabled in the Linux kernel and bridging tools (http://bridge.sourceforge.net/) installed. Setting a wireless bridge is similar to setting a wireless distribution system (WDS), but you'll have to use another wireless interface on a second card instead of the usual wired interface:

Then the bridge can be set to participate in the STP process and add new distribution links automatically. To accomplish the latter, the command prism2_param wlan0 autom_ap_wds 1 is used. As the README.prism2 file outlines, you can use several commands to check the operation of your bridge:

Now you probably want to become a root bridge on the STP network. Run Ettercap on one of the wireless interfaces, go to the plug-ins selection ("p/P") and select the plug-in lamia. The priority value for the root bridge should be as low as possible—select zero. You might also need to set your MAC address to a lower value in case there is another bridge with a zero priority. When a tie based on a priority value takes place, the lower MAC wins.

Imagine the amount of traffic you will get through on a busy wireless network using such a bridge!

If you only have a Hermes/Orinoco chipset card (we strongly recommend that you have three different chipset cards [Cisco Aironet, Prism, and Hermes] for proper wireless security testing), you can use Hermes-AP (http://www.hunz.org/hermesap.html) to set a software-based access point. HermesAP is much younger than HostAP and lacks many of the features of HostAP, but it is catching up. Installing HermesAP is more complicated than setting up HostAP because both the Hermes card firmware update and orinoco driver/pcmcia-cs patching are required; see the README file (http://www.hunz.org/README). Once set, HermesAP is configurable via Linux Wireless Extensions, and supports WDS, RFMON, and closed ESSIDs. Because we don't know how to generate traffic (other than beacons) with HermesAP, we do not review it any further in the man-in-the-middle attacks discussion. Nevertheless, HermesAP is a very interesting project and we hope that this paragraph will spark more interest in its development and attract more hackers on its side.

Finally, on the BSD side you can set an access point functionality with a command like wicontrol -n foobared -p 6 -f 6 -e 0 (this is an OpenBSD example, as we are going to use Wnet later; -p 6 stands for hostap mode, -f sets channel, -e 0 means WEP is not required to associate). The interface set to act as an access point can then be employed to bombard the network with deassociation and deauthentication frames (Wnet dinject) telling the defenseless hosts to disconnect from the current access point. Yes, this means that under OpenBSD you might not need a second card to perform an efficient man-in-the-middle attack, thus saving some configuration time and a lot of battery power. You will probably need to write a small shell script to make dinject tools send multiple deauthenticate or deassociate frames for a successful DoS attack. Also, don't forget that you are limited to Prism chipset cards only.

Hit or Miss: Physical Layer Man-in-the-Middle Attacks

To conclude the man-in-the-middle attack section, we would like to share some thoughts on Layer 1 attack attempts. On a physical layer there are two possible avenues reinforcing a chance of a successful man-in-the-middle assault:

Network management is restricted by the legal FCC, ETSI, or equivalent EIRP output regulations. At the same time, the attackers do not care about these restrictions (when an attack is launched the law is broken anyway) and can easily surpass all legal power output limits imposed. For instance, a cracker can use a powerful 23 dBm (200 mW) PCMCIA client card with a decent gain antenna (e.g., 24 dBm dish or grid directional). The EIRP would reach about 45 dBm (subtract 2–3 dBm for the obvious connectors and pigtail loss), which equals about 31.62 W of output. Such output is much higher than the legally permitted 1 W point-to-multipoint wireless LAN EIRP and should be significantly higher than the allowed EIRP on the majority of point-to-point wireless links deployed.
802.11 hosts are supposed to associate with a wireless access point on the basis of basic error ratio (BER). In practical terms, it comes down to the signal strength and SNR ratio, assuming all other parameters such as ESSID and WEP key are correct. Theoretically, introducing the rogue access point with a very high EIRP as described earlier should be able to force the hosts on a WLAN to associate with the rogue and not the legitimate AP. The reality is not that simple, as many wireless clients tend to reassociate with the AP they were associated with before and will only change the frequency to a different one in case of a very powerful RF noise flood hitting the used channel. These association choice features are usually built into the card's firmware. In several cases, such as the AirPort client card configuration under Mac OS X, it is possible to configure manually whether the host will join the AP with the highest SNR or stick with the most recently associated access point. Of course, roaming WLANs are at greater danger from physical layer man-in-the-middle attacks, because roaming hosts should associate on the basis of AP signal strength. Nevertheless, for the reasons outlined earlier, Layer 1 man-in-the-middle wireless attacks are rather unreliable and should be supplementary to the data link attacks employing targeted deassociation and deauthentication frame floods.

Phishing in the Air: Man-in-the-Middle Attacks Combined

A man-in-the-middle attack does not have to be limited to a single layer. Just like the defense-in-depth would cover all seven layers of the OSI model, so can the attack-in-depth, efficiently sneaking under and over the safeguards deployed. Consider the possible disadvantages of the Layer 1 man-in-the-middle attack we have discussed. Nevertheless, if both Layer 1 and Layer 2 attacks are combined, the outcome is almost certain. Not only do you deassociate the hosts from the network AP to lure them to yours, you also outpower the AP, making sure that your rogue AP is preferred. At the same time, you can flood the legitimate AP channel with noise.

This is not hard to accomplish. For example, you can combine the HostAP Master mode (the rogue AP >= 5 channels away) with FakeAP (generating noise on the network AP channel) and Void11 (single or mass host deassociation). If EAP-MD5 is used on the network, you can add the hostapd authenticator and authentication server functionality to trick the connecting hosts into an association with your rogue AP and obtain the password. In a few pages, we review this attack in more detail. Finally, if higher layer security protocols such as SSH or SSL are involved, you can add man-in-the-middle attacks against these protocols to the combined Layers 1 and 2 man-in-the-middle attack for the full efficiency.

An interesting and rather specific case is when the wireless access point or authentication server uses Web-based user authentication, as commonly done by wireless hotspots. This can be performed using NoCat (see Chapter 13) or by employing various proprietary hotspot user authentication solutions. In such a case, the appearance of the user login Web page defines the trust. Once you can fake the page, the unsuspecting users would happily log in and enter their credentials, only to be told later that "a network error has occurred and the connection was lost." Even better, a sequence of other Web pages can be faked to present the target with common login pages (e.g., eBay, Paypal, Hotmail) for more credentials to grab. A suite to abuse users' trust in such a sneaky way is called Airsnarf. It doesn't matter if the connection uses SSL or PGP keys a la NoCat, the end users won't know it and some of them will inevitably associate with the rogue AP and enter their credentials. The question is how many of them. Airsnarf, as presented first at Defcon 11, uses Layer 1 outpowering to overcome the legitimate network AP. This, of course, brings in all the previously discussed problems of Layer 1 man-in-the-middle attacks. What if the clients are set to use a specific channel? What if the interference is too strong? What if the rogue AP is PDA-based and uses a casual built-in antenna in a CF client card, whereas the AP under attack has a high IR value and is connected to a high gain antenna via an amplifier?

This is exactly the case when combining a Layer 1 and Layer 2 attack is necessary for success. The Airsnarf + HostAP + Void11 + FakeAP combination immediately comes to mind. In fact, a determined attacker can also try to shut the legitimate access point down at the same time. This can be done using other instances of Void11, hammering the AP with authentication and association frame floods. If the attacker can associate with the hotspot or is an already associated rogue user, he or she can launch higher layer DoS attacks to disable the network AP first. Such attacks can be SNMP-based (how many users or "administrators" don't change the default community names?) or employ more traditional DoS attacks, such as SYN flooding. We found out that many commonly deployed access points have problems dealing with intensive traffic using large packets and can be knocked out by ping -s 65507 -f or similar actions. At the same time the rogue AP, perhaps a Zaurus PDA in the attacker's pocket using Airsnarf from an ipkg package, will entrap unsuspecting users and snatch their user names and passwords. This underlines the necessity of profound AP testing for resistance to various common higher layer attacks as well as known Layer 2 wireless threats before the production cycle starts. If, in the process of a security audit, a penetration tester can crash or freeze the AP, too bad. This isn't just a DoS attack; it signifies an additional vulnerability of every host on the tested WLAN to the man-in-the-middle menace. To reduce this particular threat, make sure that any kind of AP management from the wireless side is turned off completely and no open AP ports are presented to the users on the WLAN.