Wi-Fi Security: Attack and Defense
by ternarybit (austindcc@gmail.com)
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 all play huge roles in the swelling popularity of wireless networking. These benefits do not come without drawbacks, however; it seems convenience and security are inversely related. 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, may tell a different story.
I ask the reader to use this information to explore and not exploit; please treat others' networks the way you want yours treated.
A Brief Overview of Wi-Fi Security
WEP
The initial ratification of IEEE 802.11 in September 1999 brought with it Wired Equivalent Privacy (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. They demonstrated that an attacker can recover the key by eavesdropping on enough encrypted traffic. Numerous successive cryptanalyses have been published, offering more and more efficient attack methods that reveal the key in a matter of seconds.
These weaknesses have been implemented in widely available tools, such as Aircrack-ng, and automated with scripts like wepbuster. It is now utterly trivial to recover 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 (WPA2). Statistics available on wigle.net show that about 20 percent 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 to simply not use it.
WPA
The Wi-Fi Alliance developed Wi-Fi Protected Access as a replacement for WEP, starting in 2003 with WPA. WPA, also known as 802.11i draft, was intended to offer better security to Wi-Fi networks before official ratification of 802.11i, which would become known as WPA2. The most common deployment method, known as WPA-Personal, uses an 8- to 63-character Pre-Shared Key (PSK) as a shared secret in favor of the hexadecimal string in WEP. By implementing Temporal Key Integrity Protocol (TKIP), which generates a new 128-bit key for every packet sent, WPA mitigates one of WEP's major weaknesses. An attacker can no longer recover the key by simply eavesdropping on enough traffic.
Additionally, TKIP improved WEP's practices by introducing packet sequencing and a true Message Integrity Check (MIC) in favor of 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 RC4 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 percent of networks currently employ WPA, with an overall declining trend.
WPA2
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, it uses the same 8- to 63-character PSK from WPA as the shared secret. WPA2 comes without the cryptographic weaknesses found in both WEP and WPA by replacing TKIP and RC4 with the very robust AES block cipher, employed as CCMP. As of this writing, no one has published a cryptanalysis of WPA2 or full 14-round AES. The emerging 802.11n specification mandates use of WPA2-AES/CCMP as the only acceptable encryption mechanism. Wigle.net reports about 25 percent of networks currently employ WPA2, with an overall increasing trend.
Attack
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. During this exchange, the STA and AP authenticate each other by generating a 256-bit Pairwise Master Key (PMK), which is then used to generate a session-specific Pairwise Transient Key (PTK), which then encrypts traffic.
To generate the PMK, both STA and AP pass the pre-shared key, salted with the AP's ESSID, through 4,096 iterations of the Password-Based Key Derivation Function (PBKDF2), using HMAC-SHA-1 as the cryptographic hash 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 then subsequently decrypt all network traffic. Salting the PSK with the ESSID ensures that no rainbow table of universally-usable PMKs will ever exist. The same pre-shared key used on networks with different ESSIDs will generate different PMKs. Utilizing 4,096 iterations of HMAC-SHA-1 stretches the key, which makes generating PMKs computationally expensive. Whereas most modern CPUs can calculate millions of SHA-1 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 captured PMK.
Obtaining Handshakes
Probably 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 derive the original PSK. On busy networks, sniffing a handshake can be trivial. On quieter networks, an attacker may send deauthentication packets to an associated STA, forcing the STA to re-authenticate (which usually does so automatically), 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 such eavesdropping, the latter more commonly used for this purpose. Assuming the attacker possesses a Wi-Fi chipset capable of RF monitor mode with appropriate drivers, issuing these simple commands within BackTrack 5 sets up an eavesdropping session:
These commands initialize a monitor interface, and log all frames from all channels 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 dictionary 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 attacking handshakes. This is because Pyrit has leveraged the massive computing power of graphics cards to dramatically increase attack speeds - often by orders of magnitude - compared to CPUs alone. For example, my Core2 Quad computes PMKs at about 2,300 per second, whereas my Radeon HD 4890 computes PMKs at about 27,000 per second. Multiple GPUs, cloud-based computing, and FPGA- or ASIC-based platforms offer even faster 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 eight characters and longer because of the very large keyspace and relatively slow attack rate. For example, attempting all possible eight-character mixed-case alphanumeric passphrases 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; there is no guarantee of success with a handshake attack.
Not only can Pyrit leverage GPU power, but it also leverages the convenience of a pre-computed database of PSKs, ESSIDs, and 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 the example above, an attacker can mount a basic dictionary attack with the following approach:
First, import a basic wordlist, included with BackTrack, into Pyrit's database:
Second, supply Pyrit with the captured handshake and attack it, saving computed PMKs in the database for future use:
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 may collect and pre-compute PMKs for many millions of PSK/ESSID combinations, making future attacks less cumbersome. However, success 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 CUDA and Cal++ modules, for NVIDIA and ATI/AMD GPUs, respectively. I leave this as an exercise to the reader.
Attacking Default Configurations
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. I will examine two cases from AT&T and NETGEAR.
AT&T Default Configuration
The latest modem/WAPs that ship with AT&T DSL service in the U.S. come configured with WPA2-AES/CCMP encryption, using a 10-digit numeric PSK printed on the unit. Such networks are identifiable by their ESSID in the form of ATT###, where ### represents a 3-digit number. This number is the last 3-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, but not necessarily helpful for auditing PSKs - I could find no obvious way to derive a default PSK from its serial number.
The keyspace of a 10-digit number is 10,000,000,000 (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 with default configuration is severely vulnerable to a dictionary attack.
Generating a list of all 10-digit numbers is trivial with sufficient time and disk space. The program Crunch does this effortlessly:
The first two arguments tell crunch the minimum and maximum line lengths; the third argument is our character set; the fourth and fifth arguments instruct crunch to split our list into files of one hundred 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 device and specify that in the output parameter. The uncompressed final list will occupy about 102 GiB.
If you're running BackTrack on a live medium, we need to change Pyrit's database location to external storage. Open the config file in Vim:
and point the default_storage directive to external media.
Next, import the word lists into Pyrit:
This tells Pyrit to import every file ending in .txt as a unique password list. Expect this to take quite some time. Importing the passwords into Pyrit's database compresses them and makes them most readily accessible by Pyrit for future attacks.
Then, attack the handshake:
In this example, I've added the -o parameter to save the recovered PSK when found.
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 2-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>, e.g. 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 3-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 order. After some searching and hacking, I came up with a reasonably comprehensive list of common adjectives and present-tense verbs which came to 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 - just tiger). I also didn't include adjectives or verbs that a NETGEAR 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 script to combine them into a master PSK list:
Usage example:
In my case, the final wordlist weighed in at a mere 293,265,000 lines and 4.8 GiB - less than three percent of AT&T's default keyspace.
It' 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 default PSK, it probably will succeed at least 75 percent of the time, and 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 8-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 is 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 8-digit PIN also need not cause concern, since 108 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 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. This would render PIN brute-forcing completely infeasible.
For inexplicable and inexcusable reasons, WPS is not deployed this way as of this writing. Quite the contrary, it 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, while others will lock WPS for a paltry five minutes after approximately 25 incorrect attempts, barely delaying an attack.
Most appalling yet, WPS also does not employ the full keyspace offered by an 8-digit number. The last digit is a checksum, and the remaining 7-digits are divided into groups of 4- and 3-digits, which are confirmed independently by the AP. This effectively reduces the keyspace to a mere 11,000 possible PINs (104 + 103). At two 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 six hours. In practice, WPS PINs usually crack in roughly two to ten 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, and comes paired with a tool called Wash which identifies vulnerable APs within range. Assuming one has enabled monitor mode on a wireless interface:
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:
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. A RSSI of -65 dBm 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:
Bare 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 to reveal any PSK, no matter how long or complex.
Defense
Disabling WPS and deploying WPA2-AES/CCMP with a strong passphrase offers very good protection in most circumstances. I recommend ten or more mixed-case alphanumeric characters, using at least one special character. In this scenario, an attacker would probably move to side-channel attacks, like social engineering - or just move along to lower-hanging fruit.
Since the wordlist is at 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.
Some APs offer the option to schedule 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.
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, a free aftermarket firmware that does not support WPS. Verify none of your networks employ WPS by running the Wash tool described above.
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 runs a candidate server and the increased security merits the investment, consider this option.
Finally, 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 cannot crack a PSK or PIN that doesn't exist.
I would like to thank Jesus, my wife, and the entire staff and community of 2600 for many years supporting my hacking endeavors.
Code: netgear-psk.sh
Here are several REAL-WORLD Wi-Fi cracking examples using actual captured traffic. We'll be using up-to-date Kali Linux and hashcat with a lowly NVIDIA GeForce GT 1030.
The first is an example for 2WIREXXX SSIDs.
Their default PSKs are only 10-digits long and only contain the digits 0-9.
Our target SSID is 2WIRE005 and our capture file is pmkid-1C:1B:68:49:1A:F0.cap which was made using the menus and utilties within the excellent airgeddon Bash script.
First thing to do after capturing a handshake is to rename the file(s) to get rid of those damn colons (:). LOL! Then upload the handshake file (pmkid-1C-1B-68-49-1A-F0.cap, in this example) to hashcat.net/cap2hashcat. (Select "Browse" and choose your CAP file.) This is an online utility which will extract a WPA/WPA2 handshake from a PCAP capture file, making a modern hashcat compatible hash file.
After uploading, select "Convert" and hopefully a handshake will be found inside the CAP file:
Handshake extraction successful: Download
hcxpcapngtool 6.2.7-45-g7ec5f4c reading from 20425_1685414955.cap... summary capture file -------------------- file name................................: 20425_1685414955.cap version (pcap/cap).......................: 2.4 (very basic format without any additional information) timestamp minimum (GMT)..................: 17.12.2021 07:34:34 timestamp maximum (GMT)..................: 17.12.2021 07:34:40 used capture interfaces..................: 1 link layer header type...................: DLT_IEEE802_11_RADIO (127) endianess (capture system)...............: little endian packets inside...........................: 9 packets received on 2.4 GHz..............: 9 ESSID (total unique).....................: 1 BEACON (total)...........................: 1 BEACON on 2.4 GHz channel (from IE_TAG)..: 11 EAPOL messages (total)...................: 8 EAPOL RSN messages.......................: 8 EAPOL M1 messages (total)................: 8 PMKID (total)............................: 8 PMKID (best).............................: 1 PMKID written to 22000 hash file.........: 1 frequency statistics from radiotap header (frequency: received packets) ----------------------------------------------------------------------- 2452: 1 2462: 8Download the new file (20425_1685414955.hc22000) containing the handshake extraction and rename it. I like to use the original capture filename plus .hc22000. For example: pmkid-1C-1B-68-49-1A-F0.hc22000
There is a Python 3 script called 2wireBruteForce.py (or 2wire.py) by INIT_6 which is very useful for finding the default 10-digit PSK on 2WIRE Wi-Fi routers.
The Python script counts from 0000000000 - 9990000000 skipping any numbers that repeat themselves more then 3 times like 333,444 anywhere in the number. You can change this to a higher number. However, I've only seen higher numbers a few times.
Test it like so:
Then to use it with hashcat, just pipe the output into hashcat, like so:
$ python3 ./2wireBruteForce.py | hashcat -m 22000 --status --session 2wire005 pmkid-1C-1B-68-49-1A-F0.hc22000 hashcat (v6.2.6) starting * Device #1: WARNING! Kernel exec timeout is not disabled. This may cause "CL_OUT_OF_RESOURCES" or related errors. To disable the timeout, see: https://hashcat.net/q/timeoutpatch CUDA API (CUDA 12.0) ==================== * Device #1: NVIDIA GeForce GT 1030, 1668/1999 MB, 3MCU OpenCL API (OpenCL 3.0 PoCL 3.1+debian Linux, None+Asserts, RELOC, SPIR, LLVM 15.0.6, SLEEF, DISTRO, POCL_DEBUG) - Platform #1 [The pocl project] ================================================================================================================================================== * Device #2: pthread-haswell-Intel(R) Xeon(R) CPU E5-2643 v4 @ 3.40GHz, 6898/13860 MB (2048 MB allocatable), 12MCU Minimum password length supported by kernel: 8 Maximum password length supported by kernel: 63 ...And, hopefully, you eventually get something like this:
The second is an example for NETGEARXX SSIDs.
Their default PSKs are based on a weird "adjective + noun + 3 decimal numbers" system.
Our target SSID is NETGEAR96 and our capture file is handshake-3C:37:86:63:5E:C7.cap which was made using the menus and utilties within the excellent airgeddon Bash script.
Here is a list I've collected of actual NETGEAR PSKs from in-use hardware, other hackers, or even from eBay pictures...
You'll need to repeat the above step by uploading the capture file in order to extract the WPA/WPA2 handshake from the PCAP capture file, and making a modern hashcat compatible hash file. Save it as handshake-3C-37-86-63-5E-C7.hc22000.
Next, download and extract fyy0r's NETGEAR Killer Dictionary in the working directory you're using. This will automatically generate the required "adjective + noun" lists, while hashcat will supply the tailing 3-digits. It isn't 100% successful at cracking all NETGEAR PSKs, but it'll get a good chunk of them. Please add your cracked PSK to the collection!
You'll then run hashcat like so:
And, hopefully, you eventually get something like this: