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.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- RSS Feeds
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- What's the tweeting protocol?
- Tech Tip: Really Simple HTTP Server with Python
- Kernel Problem
1 hour 47 min ago
- BASH script to log IPs on public web server
6 hours 14 min ago
9 hours 50 min ago
- Reply to comment | Linux Journal
10 hours 22 min ago
- All the articles you talked
12 hours 46 min ago
- All the articles you talked
12 hours 49 min ago
- All the articles you talked
12 hours 50 min ago
17 hours 15 min ago
- Keeping track of IP address
19 hours 6 min ago
- Roll your own dynamic dns
1 day 19 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?