Cisco and others have developed several wireless protocols based on the Extensible Authentication Protocol (EAP). All these protocols involve a back-end authentication server (AS), with the AP acting mostly as a conduit for the authentication messages. An attacker can target these protocols either passively, by watching the traffic and attempting to gain useful information, or actively by becoming a participant. As a participant, the attacker can try to impersonate the client, the server, or both, as an MitM.
MitM generally refers to an active attack in which an attacker interposes between two parties for nefarious purposes. In the case of wireless networks, the physical challenge is greatly reduced, and an attacker simply needs to sniff or send the right packets to perform such attacks. Wireless protocols need protections to prevent MitM attacks. Impersonating a server usually means that the attacker must set up both an intercepting AP and a back-end AS. Several software programs exist that allow a Linux machine to act as an AP, so the AP and AS could be the same machine.
802.1x and EAP are network authentication protocols that are covered in Chapter 7, but a short summary is provided here for convenience. 802.1x is a protocol designed to provide security on network ports. It uses EAP to exchange authentication information.
In WLANs, 802.1x generally involves three entities: the client (called the supplicant), the AP, and the authentication server. Essentially, it is an end-to-end communication between the client and the AS, with the AP acting as a relay. The client and AP communicate via EAP over LAN (EAPOL), whereas the AP and the AS communicate via RADIUS. Figure 6-12 illustrates these communication paths.
The client requests access.
The AS and client exchange messages so that the server can verify the client's identity. This might be mutual, with the client verifying the server, too.
When the AS is satisfied that the client has authenticated, it instructs the AP to let the client onto the network.
Optionally, the AS might pass additional information to the AP.
In LEAP, the client and AS authenticate via a modified version of Microsoft Challenge Handshake Authentication Protocol version 1 (MS-CHAPv1). The AS sends a challenge, and the client must perform a calculation based on the challenge and the password to prove that it knows the password. The challenge is there to prevent replays. In PEAP, the client and AS set up an encrypted tunnel and then do one of several possible authentication exchanges within the tunnel.
Lightweight Extensible Authentication Protocol (LEAP) is a Cisco-proprietary protocol described in Chapter 7. LEAP's major weakness is the use of MS-CHAPv1 in an unencrypted form for authentication. MS-CHAPv1 is vulnerable to offline dictionary attacks against dictionary-based passwords. An attacker first must sniff both the challenge and the response of a LEAP authentication. He can then run through all the words in a dictionary and attempt to obtain the response to match the challenge. When he does, he has guessed the password and can now successfully pose as the client using LEAP. The LEAP password might be identical to other network passwords, such as the active directory password. This enables an attacker to gain further access after he is on the network. There are at least two public tools that implement this attack. Figure 6-13 shows a sample run of asleap, written by Joshua Wright. Note the username "best" in both the challenge and response. Another implementation, much less refined, is referenced at http://www.securityfocus.com/archive/1/340184.
The main countermeasure to dictionary attacks is to enforce a strong password policy. Passwords should be changed on a regular basis. Frequency of password changes depends heavily on the security requirements of a site. A good policy should also require a password length of at least 12 characters, including numbers, mixed case, and punctuation. It should also include a requirement that passwords be based on neither words found in any dictionary nor any variant of the username. There are cracking dictionaries for hundreds of languages and commonly used words, such as names of places, people, and movies. Usually the only way to enforce strong passwords is with tools that enforce passwords at creation time. Users are good at choosing easy-to-remember passwords and tend to ignore unenforced rules. It is a good idea to run regular, automated password cracking on your organization's passwords and warn users or disable accounts with bad passwords. Your organizational environment determines what strength of password enforcement and frequency of password changes is acceptable to your user community.
The Protected Extensible Authentication Protocol version 1 (PEAPv1) relies on two key requirements for its security:
The client must validate the server certificate.
The inner, protected authentication method must not be used outside of PEAP in a form where the attacker can sniff it.
If either of these rules is violated, security can be compromised. Thus, if the client fails to validate the server's certificate, an attacker could put up a rogue AP and AS and steal the client's credentials. He could turn around and use these stolen credentials to successfully authenticate to the real server.
If the client application is poorly designed or badly configured and uses the inner PEAP authentication credentials in an unprotected wireless protocol, it violates the second requirement. An attacker can capture the password and successfully launch his own successful PEAP authentication session. Figure 6-14 illustrates the general concept of a wireless MitM attack. A rogue AP running on a laptop can act as an MitM and intercept user credentials. It can then use those credentials to authenticate to the real network. It can forward user traffic if it wants to prevent detection of the attack. The perceived connection is the connection that the wireless user thinks he has.
Thus, in PEAPv1, the client must properly use the protocol to be protected. In general, it is best not to allow users to override invalid server certificates. Users cannot be trusted to have the knowledge to validate a certificate and to differentiate a self-signed certificate from a real one. Any configuration that gives security-naive users the ability to weaken PEAP by merely clicking "Yes" in a dialog box is asking for trouble. EAP Tunneled Transport Layer Security (EAP-TTLS) has the same two security requirements mentioned for PEAPv1 and is similarly vulnerable to an MitM if the requirements are violated.
As of this writing, no publicly available tools implement these MitM attacks on PEAPv1 or EAP-TTLS.