Auditing Wi-Fi Protected Access (WPA) Pre-Shared Key Mode

Although the implementation of wireless networks has increased exponentially, the focus on network and information security has not kept pace. Empirical evidence suggests that fewer than one-third of wireless networks have implemented any sort of data encryption, be it wired equivalent privacy (WEP) or Wi-Fi protected access (WPA). Those network administrators and home users who have implemented these encryption methods may have been lulled into a false sense of security. WEP is known to be easily exploited, and substantial although relatively unknown problems exist with WPA when used in consumer mode. This article focuses on data confidentiality provided through encryption by reviewing the flaws in WEP and examining the issues surrounding WPA. Tools that demonstrate the risk of using WPA in pre-shared key (PSK) mode are explored.

WEP was ratified as an IEEE standard in 1999. It was designed to provide moderate protection against eavesdropping on data in transit and unauthorized access to the network resources. This protection was provided through an encryption scheme that utilized a flawed implementation of the RC4 stream cipher. The actual key size of the implementation was misleading, because the keys were 40-bit and 104-bit, with a 24-bit initialization vector (IV) added to the key. This led to the misnomer of 64-bit and 128-bit keys.

WEP suffered from a poor implementation of the key scheduling algorithm and transmitted the flawed IVs in the clear. A general acknowledgement that WEP was not an appropriate method of securing a wireless network came after Fluher, et al., published Weaknesses in the Key Scheduling Algorithm of RC4 in 2001 and the Shmoo Group released the beta version of Airsnort. Capturing approximately five million data packets statistically would ensure the collection of approximately four thousand weak IVs. From this information, Airsnort could discern most WEP keys. These statistically weak interesting IVs received wide recognition within the industry, and as a result, most vendors made changes to their WEP firmware and software implementations that filtered or removed weak IVs.

Older versions of Airsnort and other tools that attacked WEP by examining interesting IVs became unusable as an attack vector against most wireless equipment produced after 2002. In 2004, Korek released a new WEP statistical cryptanalysis attack and while still based on the weaknesses in the key scheduling algorithm, the Korek attack removed the requirement for collection of interesting IVs. This attack has been coded into several tools, most notably Aircrack, WepLab and the newest version of Airsnort. Each tool functions slightly differently, but each requires as few as half as many packets to break WEP than the previous generation of WEP cracking tools.

The IEEE recognized that WEP was not a sufficient method to protect wireless communications and set to work creating a new security standard, 802.11i, also known as WPA2. 802.11i was ratified as a draft standard in early 2004 and includes a robust set of security standards. The 802.11i architecture contains 802.1x for authentication and port-based access control, AES (advanced encryption standard) block cipher and CCMP (counter mode CBC MAC protocol) for keeping track of associations and providing confidentiality, integrity and origin authentication.

Of these robust requirements, AES is the most computationally intensive, and the 802.11b/g hardware that had been fielded for WEP was not up to the task of implementing the AES block cipher. It is likely that companies that fielded enterprise-wide wireless implementations would be concerned about fielding new equipment that was not backwards-compatible; legacy 802.11 hardware would not be capable of interoperating with new 802.11i hardware. This would cause companies either to field all new equipment at once or face a nightmare of interoperability.

Enter the Wi-Fi Alliance, a nonprofit industry association devoted to promoting the growth of wireless local area networks (WLANs). The Wi-Fi Alliance created the WPA specification as a bridging solution that would alleviate the concerns of WEP while providing a bridge to 802.11i. WPA was designed to conform to the majority of the 802.11i specifications. The major exception was WPA would not implement AES for encryption and would continue to use RC4. This methodology ensured that WPA would be backward-compatible with 802.11-certified hardware and forward-compatible with 802.11i hardware. In essence, it would provide a bridge as vendors brought new equipment on-line, allowing companies to leverage the WPA standard while migrating to newer equipment in a phased manner.

WPA solves several problems inherent in WEP. By implementing the Temporal Key Integrity Protocol (TKIP), the issues of privacy and encryption are mitigated, as the use of a RADIUS or Kerberos authentication server mitigates the problem of client-to-AP authentication and unauthorized network access. The TKIP protocol greatly expands the size of the keys, allows for per-user keying, creates an integrity-checking mechanism and removes the predictability in the WEP key scheme.

WPA can be implemented in two versions, WPA-Enterprise and WPA-Personal. WPA-Enterprise uses the 802.1x authentication framework with TKIP key encryption to prevent unauthorized network access by verifying network users through the use of a RADIUS or authentication server and ensures per-user-based keying. Thus far, WPA-Enterprise has not been prone to any attacks on the confidentiality of the per-user key. An intruder that could divine the key would find it unusable on all but the computer from which it was stolen.

WPA-Personal also uses the TKIP key encryption mechanism but uses a pre-shared key (PSK) instead of a per-user key generated from an authentication server. This mode often is referred to as WPA-PSK. In WPA-PSK, users must share a passphrase that may be from eight to 63 ASCII characters or 64 hexadecimal digits (256 bits). Similar to WEP, this passphrase is the same for all users of the network and is stored on the AP and client computer. WPA-PSK was designed for personal or small-business environments in which an authentication server is not required. In actual implementation, several mid-sized firms use WPA-PSK instead of WPA-Enterprise in an effort to simplify enterprise management.

In November 2003, Robert Moskowitz, a senior technical director at ICSA Labs (part of TruSecure) released “Weakness in Passphrase Choice in WPA Interface”. In this paper, Moskowitz described a straightforward formula that would reveal the passphrase by performing a dictionary attack against WPA-PSK networks. This weakness is based on the fact that the pairwise master key (PMK) is derived from the combination of the passphrase, SSID, length of the SSID and nonces. The concatenated string of this information is hashed 4,096 times to generate a 256-bit value and combine with nonce values. The information required to create and verify the session key is broadcast with normal traffic and is readily obtainable; the challenge then becomes the reconstruction of the original values. Moskowitz explains that the pairwise transient key (PTK) is a keyed-HMAC function based on the PMK; by capturing the four-way authentication handshake, the attacker has the data required to subject the passphrase to a dictionary attack. According to Moskowitz, “a key generated from a passphrase of less than about 20 characters is unlikely to deter attacks.”

In late 2004, Takehiro Takahashi, then a student at Georgia Tech, released WPA Cracker. Around the same time, Josh Wright, a network engineer and well-known security lecturer, released coWPAtty. Both tools are written for Linux systems and perform a brute-force dictionary attack against WPA-PSK networks in an attempt to determine the shared passphrase. Both require the user to supply a dictionary file and a dump file that contains the WPA-PSK four-way handshake. Both function similarly; however, coWPAtty contains an automatic parser while WPA Cracker requires the user to perform a manual string extraction. Additionally, coWPAtty has optimized the HMAC-SHA1 function and is somewhat faster. Each tool uses the PBKDF2 algorithm that governs PSK hashing to attack and determine the passphrase. Neither is extremely fast or effective against larger passphrases, though, as each must perform 4,096 HMAC-SHA1 iterations with the values as described in the Moskowitz paper.

To perform the audit, we need a libpcap file that contains the WPA-PSK four-way authentication handshake and the program WPA Cracker or coWPAtty. Capturing the four-way handshake in the libcap-compatible dumpfile format is the most challenging part of the exercise. It requires a wireless NIC that is capable of rf monitor mode and a set of modified wireless drivers that allow packets to be passed up through the interface.

libpcap is either pre-installed or available as a package for most modern Linux distributions and is the de facto standard for low-level network monitoring. The libpcap network library provides a system-independent interface for user-level packet capture. The steps for installation are straightforward for those that prefer to compile vice install packages. Download the latest libpcap file from SourceForge.net and then expand the libpcap file, configure, make and make install. When compiling your code, the filename depends on the version you downloaded:

# tar zxvf libpcap-current.tar.gz
# cd libpcap-2005.06.01
# ./configure && make && make install

Now that the system has the ability to capture the network data, a method is needed to read the data from the air. Most modern Linux distributions ship with one or more wireless drivers, but few ship with the modified drivers that allow raw monitor mode or rfmon. rfmon is a sniffing mode that allows the wireless NIC to report data from the 802.11 layer. Although few major distributions ship with rfmon-capable drivers, many live CD security distributions, such as Knoppix-STD, Auditor and Whoppix, have precompiled modified wireless drivers as well as compiled binaries of the audit tools.

The modified driver to be used is dependent on the type of chipset. For example, the Prism2-based cards may use the wlan-ng drivers or Host-AP drivers, and Orinoco cards and clones can use the patched orinoco_cs drivers. Orinoco cards that use the Orinoco drivers greater than version 0.15 have built-in monitor mode, while Atheros-based cards may use the MadWiFi drivers. This list is not inclusive, and there are many possible options in the form of driver patches, standalone packages that build driver modules outside of the kernel tree and kernel mainline drivers that are part of the kernel source itself. It is assumed that readers have the ability to install a driver for their particular cards and distributions that permits wireless monitor mode.

Several methods can be used to capture the wireless traffic that contains the WPA-PSK four-way handshake of interest. tcpdump allows for network monitoring and data acquisition, but it does not readily provide meaningful AP data. Kismet is arguably the best tool for wireless data capture, auditing traffic, network detection and general wireless sniffing. Specifically, Kismet can log the packet data into a dump file required for this demonstration, but it is overkill for this situation. The most elegant method of capture is to use airodump, which is part of the Aircrack 2.1 suite written by Christopher Devine. Aircrack can handle large capture files and displays meaningful AP information to include SSID, total number of unique IVs and packet size. Aircrack is available in the Tar File Gzipped format (tgz). Install by following these steps to build the Aicrack suite of tools; the specific tool of interest in this situation is airodump:

# tar zxvf aircrack-2.1.tgz
# cd aircrack-2.1
# make

With the tools compiled, wireless traffic now can be captured. The wireless NIC first must be placed in rf monitor mode. For example, if using the patched version of the Orinoco driver, the following commands would be issued, where <AP channel> is the channel of interest:

# iwpriv eth0 monitor 1 <AP channel>

The wireless NIC then is enabled:

# ifconfig wlan0 up

Finally, commands to capture traffic would be issued:

# airodump wlan0 datafilename

Airodump continuously displays the AP SSID and packet capture information on the specified channel. To reduce the amount of captured data, the MAC address of the AP may be appended after the datafilename. To exit airodump, use the Ctrl-C command.

Although airodump happily captures traffic, the four-way handshake is not captured until a client-to-AP association occurs. This is a random occurrence from the attacker's point of view, but forced reassociations can be accomplished by executing a death attack using a tool such as void11 that forces the de-authentication of wireless clients from their associated APs. The wireless client automatically attempts reassociation, which allows the capture of the WPA-PSK four-way handshake. Assuming the handshake has been captured, it is time to execute the brute-force dictionary attack.

coWPAtty requires that OpenSSL be installed on your system. After downloading coWPAtty, install it using the following steps:

# tar zxvf Cowpatty-2.0.tar.gz
# cd cowpatty
# make

You now have built the coWPAtty binary. Execute the binary by supplying the libpcap that includes a captured four-way handshake, a dictionary file of passphrases from which to guess and the SSID of the network. The options are:

The binary is executed with the following command:

# ./cowpatty -r datafilename \
 -f dictionaryfile -s SSID

If there is no WPA four-way exchange, the following message is displayed:

End of pcap capture file, incomplete TKIP four-way exchange.
Try using a different capture.

If the file did contain the four-way handshake, the following is displayed:

coWPAtty 2.0 - WPA-PSK dictionary attack.
<jwright@hasborg.com>
Collected all necessary data to mount crack against
passphrase.  Loading words into memory, please be
patient ... Done (XX words).  Starting dictionary
attack. Please be patient.

coWPAtty continues the intensive and relatively slow process of testing each dictionary word as a passphrase by using the PBKDF2 function and making 4096 SHA-1 passes on each passphrase in the supplied data set. coWPAtty updates its progress until it reports either it has found the WPA-PSK passphrase or it was unable to identify the WPA-PSK passphrase from the supplied dictionary file. As noted in the documentation, coWPAtty is not fast, due to the number of repetitions required for each passphrase. Expect approximately 45 keys per second in actual use.

For users who care to demonstrate this tool but are unable to capture the network data, coWPAtty includes a sample packet capture file, named eap-test.dump, that was generated from an AP with SSID somethingclever and a PSK of family movie night. To demonstrate the attack utilizing the supplied file, enter the following command ensuring that the supplied dictionary has the phrase somethingclever included:

# ./cowpatty -r eap-test.dump \
-f dictionaryfile -s somethingclever

This article examined some of the vulnerabilities within WEP and WPA and provides the tools and method for auditing WPA pre-shared key mode passphrases. To do this, we examined the framework and flaws in WEP and reviewed the risks associated with using WPA-PSK passphrases of less than 20 characters. It has been demonstrated that although the method to crack the WPA-PSK is not trivial, it also is not beyond the reach of an average Linux user. Home users can lessen their security risks by using a passphrase significantly greater than 20 characters or, alternatively, by using WPA-Enterprise and incorporating an authentication server. Corporate users should implement an authentication server, use per-user keying and refrain from implementing WPA in PSK mode.

Resources for this article: /article/8405.