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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Control Your Linux Desktop with D-Bus
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)