Auditing Wi-Fi Protected Access (WPA) Pre-Shared Key Mode
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.
|Omesh Tickoo and Ravi Iyer's Making Sense of Sensors (Apress)||Apr 21, 2017|
|Low Power Wireless: 6LoWPAN, IEEE802.15.4 and the Raspberry Pi||Apr 20, 2017|
|CodeLathe's Tonido Personal Cloud||Apr 19, 2017|
|Wrapping Up the Mars Lander||Apr 18, 2017|
|MultiTaction's MT Canvus-Connect||Apr 17, 2017|
|Android Candy: Facebook Everything?!?!||Apr 14, 2017|
- Teradici's Cloud Access Platform: "Plug & Play" Cloud for the Enterprise
- The Weather Outside Is Frightful (Or Is It?)
- Low Power Wireless: 6LoWPAN, IEEE802.15.4 and the Raspberry Pi
- Simple Server Hardening
- Understanding Firewalld in Multi-Zone Configurations
- Gordon H. Williams' Making Things Smart (Maker Media, Inc.)
- Non-Linux FOSS: Control Web-Based Music!
- Server Technology's HDOT Alt-Phase Switched POPS PDU
- IGEL Universal Desktop Converter