Wi-Fi Security: Attack and Defense

Originally appeared in 2600 Magazine issue 30:4

This article seeks to examine the current state of Wi-Fi security, with a practical emphasis on attack and defense methodology. The proliferation of mobile devices, decreasing cost of deployment, increasing speed, and overall convenience, likely all play huge roles in the snowballing popularity of wireless networking. These benefits do not come without drawbacks, however; it seems convenience and security are inversely related. As we gain one, we lose the other. Wi-Fi security has matured significantly since its birth around the turn of the millennium, starting with open networks and WEP encryption. With insecure networks declining along with the ratification of WPA2 in 2004, it would seem we are moving toward a more secure wireless world. Experience, however, tells a different story.

A brief overview of Wi-Fi security


The initial ratification of IEEE 802.11 in September 1999 brought with it Wired Equivalent Privacy, or WEP, as the only means of encrypting traffic. WEP uses a 40- or 104-bit key, combined with a 24-bit initialization vector (IV), which are then processed through the RC4 stream cipher to achieve communication privacy. Only two years later, security researchers Scott Fluhrer, Itsik Mantin and Adi Shamir published the first cryptanalysis of WEP, demonstrating that an attacker can recover the key by eavesdropping on enough encrypted traffic. Numerous successive cryptanalyses have been published, offering more efficient attack methods that reveal the key in a matter of minutes. These weaknesses have been implemented in widely available tools, such as aircrack-ng, and automated with scripts like wepbuster. With basic hardware, it is now utterly trivial to recovery any WEP key almost immediately. As such, in 2004, the IEEE officially deprecated WEP in favor of the newly-ratified 802.11i standard, commonly known as Wi-Fi Protected Access II, or WPA2. Statistics available on wigle.net show that about 20% of networks still implement WEP, even after nine years of well-documented weakness. We will not examine attacks on WEP or its defense further; attacks are well-known and the only defense is simply not using it.


The Wi-Fi Alliance developed Wi-Fi Protected Access as a replacement for WEP, starting in 2003 with WPA and ending with the IEEE’s ratification of WPA2 in 2004. WPA, also known as 802.11i draft, was intended to offer better security to Wi-Fi networks before official ratification of 802.11i. In its most common deployment method, known as Personal mode, WPA uses an 8-63 character pre-shared key (PSK) as a shared secret in favor of a hexadecimal string in WEP. By implementing Temporal Key Integrity Protocol, or TKIP, which generates a new 128-bit key for every packet sent, WPA was designed to mitigate one of WEP’s major weaknesses. Additionally, TKIP improved WEP’s practices by introducing packet sequencing and a true message integrity check (MIC) in favor of a simple CRC-32 for integrity. Packets received out of order are rejected, and MICs offer better assurance that packets have not been intercepted and altered by an attacker. Since WPA was intended to run on the same hardware that implemented WEP, TKIP also uses the same RC4 stream cipher to encrypt traffic. In 2008, Martin Beck and Erik Tews released a keystream attack on TKIP that allows an attacker to send between 7 and 15 packets of their choosing, by exploiting weaknesses in WPA’s MIC mechanism. Though the attack does not reveal the PSK, it does demonstrate a design flaw in WPA that will likely lead to its deprecation in favor of WPA2. Wigle.net reports that about 11% of networks currently employ WPA, with an overall declining trend.


Wi-Fi Protected Access II, officially standardized as IEEE 802.11i-2004, is the current, preferred and most secure method available to encrypt wireless traffic. It superseded WPA in 2004 when it became an official IEEE standard, and addresses most, if not all weaknesses found in WEP and WPA. Most commonly deployed as WPA2 Personal, the standard uses the same 8-63 character PSK from WPA as the shared secret. WPA2 rids itself of the cryptographic weaknesses found in both WEP and WPA by replacing TKIP and the RC4 stream cipher, with the very robust AES block cipher, employed as CCMP. As of this writing, no one has published a cryptanalysis of full 14-round AES, which is renowned worldwide as the gold standard of encryption. The emerging 802.11n specification mandates use of WPA2-AES/CCMP as the only acceptable encryption mechanism. Wigle.net reports about 25% of networks currently employ WPA2, with an overall increasing trend.


Background: WPA(2) Authentication

During authentication with an access point (AP), a client station (STA) engages an Extensible Authentication Protocol over LAN (EAPoL) 4-way handshake with the AP. During this exchange, the STA and AP authenticate each other by generating a 256-bit pairwise master key, or PMK, which is then used to generate a session-specific pairwise transient key (PTK), which then encrypts traffic between AP and STA.
To generate the PMK, both STA and AP pass the pre-shared key, salted with the the AP’s ESSID, through 4096 iterations of the password-based key derivation function, version 2 (PBKDF2), using HMAC-SHA1 as the cryptographic hashing function. The PTK is computationally trivial to derive from the PMK; possession of the PMK offers an attacker all the information necessary to potentially derive the pre-shared key, and subsequently decrypt all network traffic. Salting the PSK with the AP’s ESSID ensures that no master table or “rainbow table” of universally-usable PMKs will ever exist; the same PSK on networks with varied ESSIDs will generate different PMKs. Utilizing 4096 iterations of HMAC-SHA1 serves to stretch the key, which makes generating PMKs computationally expensive. Whereas most modern CPUs can calculate millions of SHA1 hashes per second, in most cases they can only compute thousands of PMKs per second. Both salting and stretching were designed to deter brute force attacks on the PMK, but as we shall see, they have not succeeded in all areas.

Obtaining Handshakes

The most well-known attack on WPA(2) involves an attacker eavesdropping on the 4-way EAPoL handshake between an authorized STA and target AP, then using a dictionary attack to convert the 256-bit PMK to its original PSK. On busy networks, sniffing a handshake can be done trivially by monitoring channel traffic and logging packets. On quieter networks, an active attack is possible, whereby an attacker sends deauthentication packets to an associated STA, forcing the STA to re-authenticate, thereby revealing the PMK to the attacker. On very quiet networks, eavesdropping a handshake may become very difficult and time-consuming.
Tools like Kismet and airodump-ng are capable of reading raw packets, the latter more commonly used for this purpose. Assuming the attacker possesses a Wi-Fi chipset capable of RFMON mode with appropriate drivers, issuing these simple commands sets up an eavesdropping session:

# airmon-ng start wlan0
 # airodump-ng -w pentest mon0

These commands initialize a monitor interface, and log all packets from channels 1-11 to files prefixed with ‘pentest’. Assuming the attacker is within range of an authenticating client and the target AP, airodump-ng will report the capture of the WPA handshake, which is then immediately ready for attack.

Attacking Handshakes

Various tools exist to mount dictionary attacks on captured handshakes, most notably aircrack-ng and pyrit. Aircrack-ng is part of the canonical Wi-Fi auditing suite of the same name, but pyrit has overtaken the spotlight as the most effective tool for the job. This is because pyrit has successfully leveraged the massive computing power of consumer-grade graphics cards to dramatically increase attack speeds, often by orders of magnitude, compared to CPUs alone. For example, my Intel Core2 Quad Q9550 CPU computes PMKs at about 2,300 per second, whereas my ATI Radeon HD 4890 GPU computes PMKs at about 27,000 per second. Multiple GPUs and even cloud-based computing platforms offer even faster cracking speeds, increasing feasibility of dictionary attacks dramatically.
A successful dictionary attack consists of at least four elements: the pairwise master key captured from a legitimate authentication; the ESSID of the target network; an appropriate dictionary file; and sufficient time. The heart of any dictionary attack requires that the PSK used to generate the captured PMK exists within the attacker’s dictionary–these attacks simply exploit weak passphrases. True brute-force attacks are infeasible on PSKs 8 characters and longer, because of the very large keyspace and relatively slow attack rate. For example, attempting all possible 8-character mixed-case alphanumeric passphrses would take approximately 256 years at 27,000 PMKs per second–and this doesn’t include any special characters. Obtaining an appropriate dictionary for specific networks remains the attacker’s challenge in mounting successful attacks. Very weak, common passphrases are easy to crack, but longer and more complex passphrases may never capitulate to a dictionary attack.
Not only can pyrit leverage GPU power, but it also leverages the convenience of a database of PSKs, ESSIDs and computed PMKs. This means an attacker can begin pre-computing PMKs for a given ESSID with a chosen dictionary before capturing a handshake. Looking up pre-computed PMKs takes a fraction of the time computing them does, so cracking an obtained handshake may only take seconds in an ideal scenario.
Assuming airodump-ng reports successful capture of a WPA(2) handshake in our example above, an attacker can mount a basic dictionary attack using BackTrack Linux 5 with the following approach:

First, import a basic wordlist, included in BackTrack, into pyrit’s database:

# pyrit -i /pentest/passwords/wordlists/darkc0de.lst import_unique_passwords

Second, supply pyrit with the captured handshake and attack it, saving computed PMKs in the database for future use:

# pyrit -r pentest-01.cap attack_batch

Assuming pentest-01.cap contains at least one valid handshake for a single network, pyrit will automatically select that handshake and begin attacking it with the passwords imported with the previous command. If the capture file contains more than one handshake from multiple networks, one will need to specify which to attack.
Over time, an attacker can collect and pre-compute PMKs for many millions of PSK/ESSID combinations, making future attacks less cumbersome. However, the attack still relies on the AP using a PSK within an attacker’s dictionary; strong PSKs will withstand dictionary attacks from even advanced hardware and software.
By default, pyrit only supports CPU-based cracking. Various guides exist online for compiling pyrit CUDA and Cal++ modules, for NVIDIA and ATI/AMD GPUs, respectively. I leave this as an exercise to the reader.

Attacking Default Configurations

Though custom-configured, strong PSKs remain resilient and offer the best protection for networks employing WPA2 Personal, often networks are not set up properly with them. In an effort to mitigate security risks, vendors have generally improved their hardware’s default configurations. While these changes improve upon open or weak configurations, they often fall prey to basic attacks. We’ll examine two cases with access points from AT&T and Netgear.

Attacking AT&T Default Configuration

The latest combination modem / router / AP / switches that ship with AT&T U-Verse DSL service in the US come configured with WPA2-AES/CCMP encryption, using a 10-digit numeric PSK printed on the unit. Such units are identifiable by their ESSID in the form of ATT###, where ### represents a 3-digit number. According to AT&T’s website, this number is the last three digits of the unit’s serial number. Some experimenting revealed that the unit’s serial number is simply the decimal form of the AP’s hexadecimal BSSID. Interesting trivia, but not necessarily helpful for auditing PSKs.
The keyspace of a ten-digit, base ten number is 10^10, or ten billion. With my hardware, I can exhaust this keyspace in a theoretical maximum of four days and seven hours, but this assumes the target PSK resides at the end of the list; in practice, attacks usually take around half the theoretical maximum time. This means any AT&T AP is severely vulnerable to a dictionary attack on fairly basic hardware.
Generating a list of all 10-digit numbers is trivial with sufficient time and disk space. The program crunch does this effortlessly:

# cd /pentest/passwords/crunch
 # ./crunch 10 10 0123456789 -c 10000000 -o START

The first two arguments tell crunch the minimum and maximum line lengths; the second argument is our character set; the fourth and fifth arguments instruct crunch to split our list into files of ten million lines for ease of management. The files will be named <start of range>-<end of range>.txt in the current working directory. If you’re running BackTrack on a live medium, you will need to mount an external storage medium and specify that in the output parameter; the uncompressed final list will occupy about 102GiB.
Next, let’s import the lists into pyrit’s database:

# for i in *.txt; do pyrit -i $i import_unique_passwords; done

This tells pyrit to import every file ending in ‘.txt’ as a unique password list. Then, attack the AT&T handshake as usual:

# pyrit -r att-01.cap -o att-owned.txt attack_batch

In this example, I’ve added the -o parameter to save the recovered PSK when found.

Attacking Netgear Default Configuration

Netgear’s latest crop of routers ship with default ESSIDs and PSKs designed to give the user enhanced security out of the box. The ESSIDs take the form of NETGEAR##, with ## representing two numeric digits. I was interested to find the default PSK on two routers I tested take the form of <adjective/verb> + <common animal> + <3-digit number>; for example, smilingrabbit318. The use of words and numbers seems to offer a secure approach to default PSKs: the English language employs hundreds of thousands of words, and using two of them with three digits would seem to offer a robust, yet memorable, default passphrase.
However, this approach degrades quickly under closer examination. Netgear has not randomly chosen any two words; they are two fairly common words in a grammatically correct (if not slightly awkward) order. After some searching and hacking, I came up with a fairly comprehensive list of common adjectives and present-tense verbs containing only 1,715 words. A list of common animals came in much smaller, at only 171 words. I didn’t include highly esoteric animals (like archaeopteryx), or very specific ones (like saber-toothed tiger.) I also didn’t include adjectives or verbs that a customer would view as offensive or inappropriate. Somehow, PSKs like “murderinglion666” and “sexygorilla690” seem unlikely. I used crunch in much the same way as the example above to create a list of all 1,000 3-digit numbers, and wrote this simple bash script to combine them:


echo "Creating a list of all combinations of the files <${PRE}>+<${SUF}>+<${NUM}> in wordlist ${OUT}."

TOTAL=$(expr $(cat $PRE | wc -l) '*' $(cat $SUF | wc -l) '*' $(cat $NUM | wc -l))

echo "Total combinations: $TOTAL"
echo "For large dictionaries, this may take significant time and disk space…"

while read PREFIX
   while read SUFFIX
      while read NUMBER
         echo ${PREFIX}${SUFFIX}${NUMBER} >> $OUT
       done < $NUM
   done < $SUF
done < $PRE

echo "Done."
exit 0

Then, issue these commands:

# chmod +x netgear-psk.sh
 # ./netgear-psk.sh adj-verbs animals numbers netgear.lst

In my case, the final wordlist weighed in at a mere 293,265,000 lines and 4.8GiB–less than three percent of AT&T’s default keyspace. It’s possible my list isn’t exhaustive, and in the absence of several networks to test it on, I can’t say for sure. Even if it won’t crack every possible default PSK, it probably will succeed at least 75% of the time, maybe more. My retired gaming rig chews through this list in just over three hours, which means I could pre-compute PSKs for all 100 default Netgear ESSIDs in about twelve and a half days, making recovery of any default Netgear PSK utterly trivial.

Wi-Fi’s Achilles’ Heel: WPS

In 2007, the Wi-Fi Alliance sought to unify the diverse auto-configuration methods sprouting up from various vendors, which purportedly offered consumers the ability to easily set up secure networks without any knowledge of networking or security. They published the Wi-Fi Protected Setup (WPS) protocol apart from any involvement with the IEEE, which uses hardware or software buttons and PINs to set up secure networks. At the heart of the protocol is an eight-digit PIN, usually printed on the hardware itself, which allows its possessor full control over its configuration, including any currently employed PSK—no matter how long or complex.
In theory, such a protocol is not inherently unwise or insecure. It’s reasonable to accommodate inexperienced customers who can’t intelligently decide between various encryption options, who will very likely choose insecure configurations. The use of an eight-digit PIN also need not cause concern, since 10^8 offers some hundred million possibilities. An example of one such secure deployment would instruct the customer to press the physical WPS button on the router, then enter the PIN into a prompt on the computer. The router will accept a PIN for up to 30 seconds after pressing the button, then lock itself to further PIN requests.
For seemingly inexplicable and inexcusable reasons, WPS is not deployed this way. Quite the contrary, WPS suffers from several critical design flaws that now threaten the security of millions of networks worldwide. In December 2011, Stefan Viehböck publicly announced this vulnerability, which currently has no known countermeasure, aside from disabling WPS entirely. Tragically, this isn’t even possible on some APs, and firmware updates to address this have come slowly, if at all.
Very few routers limit the number of allowed PIN attempts in a given time interval; some allow for one attempt every 1-2 seconds. Others will lock WPS for a paltry five minutes after approximately 25 incorrect attempts, barely delaying an attack.
WPS also does not employ the full keyspace offered by an 8-digit number. The last digit is a checksum, and the remaining seven digits are divided into groups of four and three digits, which are confirmed independently by the AP. This effectively reduces the key space to a mere 11,000 possible PINs (10^4 + 10^3 = 11,000). At 2 seconds per PIN, an attacker can recover the AP’s PSK, and gain authority to (re)configure the device, in a theoretical maximum of about 6 hours. In practice, WPS usually cracks in roughly 2-10 hours, depending on the AP. Any AP with WPS enabled is vulnerable to this brute-force attack, which has been implemented in the program reaver, also available on BackTrack 5.
Reaver offers an attacker many options to carry out such an attack, and comes paired with a tool called wash, which identifies vulnerable APs within range. Assuming one has enabled monitor mode on a wireless interface,

# wash -i mon0

shows all WPS-enabled APs in range, along with some basic WPS information. One only needs the BSSID of the target AP to begin a basic reaver attack:

# reaver -i mon0 -b <BSSID of target> -c <channel of target> -v

Using -v tells reaver to enable verbose logging, printed to standard output. Most often, problems carrying out the attack are solved by achieving better signal quality with the AP. An RSSI of -65dB or better offers the best chance of success. Depending on the AP, the attacker may need to adjust the delay between PINs with the -d option, or set a recurring delay after a number of attempts with the -r X:Y option, which sleeps Y seconds after X PIN attempts. Using small Diffie-Hellman numbers with the -S option may also speed the attack. An alternate invocation will log reaver’s progress to a file, with optional monitoring from a separate terminal:

# reaver -i mon0 -b <BSSID of target> -c <channel of target> -v -o reaver.log
 <switch to second terminal to monitor progress>
 # tail -f reaver.log

Bear in mind that MAC spoofing works with reaver only when the physical interface is spoofed (e.g. wlan0), not just the monitor interface (e.g. mon0).
The only major drawbacks to a WPS attack are that they generate a lot of traffic, and the attacking device must remain within range of the target for the duration. Even still, this attack remains very attractive because it offers a guarantee of success on any PSK, no matter how long or complex.


Disabling WPS and deploying WPA2-AES/CCMP with a strong passphrase (10+ characters, not in an dictionary, mixed case, including symbols and numbers) offers very good protection in most circumstances. In this scenario, an attacker would probably move to side-channel attacks, like social engineering, to obtain the PSK.
Some APs offer scheduled downtime, which automatically disables the Wi-Fi radio at certain intervals. This narrows an attacker’s window of opportunity, which is especially relevant to WPS attacks.
Since the wordlist is the heart of any handshake attack, it’s wise to take measures to ensure your PSK never ends up in one. Various password database leaks form the basis of many likely wordlists. For example, RockYou.com was compromised and leaked some 32 million plaintext passwords. More recently, attackers released about 450,000 plaintext passwords from Yahoo, many of which may be considered “secure” passphrases. I have personally verified that none of my PSKs were part of these disclosures, and I suggest you do the same.
If disabling WPS is not possible on your router (for example, some Linksys units won’t actually disable WPS even if you opt for manual configuration), consider flashing it with DD-WRT, an aftermarket firmware that does not support WPS. Verify none of your networks employ WPS by running the wash tool described above.
Another advantage to DD-WRT is that it allows one to set up segregated public SSIDs on separate VLANs that cannot access the private network. If you only use Wi-Fi for Internet access, you can easily disable all access to private resources and simply allow WAN traffic. This way, even if an attacker did compromise your PSK, they would gain virtually nothing.
Arguably the most secure wireless protection comes from deploying a RADIUS (802.1X) server and WPA2-Enterprise, but this is not practical for many small networks. If your network does run a candidate server and the increased security merits the time investment, consider this option.
Finally, consider that in some circumstances, Wi-Fi offers more risk than reward, and should not be deployed at all. Networks that house very sensitive information would do well to avoid the risk altogether; an attacker can’t crack a PSK or WPS PIN that doesn’t exist.

Leave a Reply

Your email address will not be published. Required fields are marked *