Securing Your Organization Against WPA Vulnerabilities — Part 2

In my first blog post on securing against Wi-Fi Protected Access vulnerabilities, I talked about the fact that attacks are still being developed to take advantage of weaknesses found in WPA/WPA2, which are known and have been around for a while. This post continues that discussion, getting into how exactly most attacks are carried out against WPA.

Basics of Cracking

In very boiled-down terms, WPA cracking software uses the gathered elements and a generated Pairwise Master Key (PMK) to compute a Message Integrity Code. This MIC is then compared with a captured MIC to determine if the generated PMK is considered valid.

The PMK itself is made by using a hashing function with some known rules and includes the PSK and the SSID as a salt (see more about salting here). Here is where the actual computation piece of the cracking is done and where our new attack doesn’t gain any advantages. The hash function is considered “one way,” so the cracking software doesn’t “reverse” the password, rather it is just run as fast as possible, changing the PSK value, and then using the output for the MIC comparison.

It can be likened to a user entering a password of “aaaaaaaa,” receiving a failure message, then entering “aaaaaaab” with failure, and so forth ad infinitum. This would be considered a brute force attack. Obviously, we gain efficiency by instead having a computer dedicate a lot of resources to running this very, very fast. So how do we use this knowledge to our advantage to reduce the likelihood of our PSK being guessed?

Going back to the concept of the salt, there are things known as “rainbow tables” which are essentially precomputed hash values. A quick internet search will show you various places you can download these to try to crack wireless networks.

These are built by using common service set identifiers (SSIDs), such as Linksys, Netgear and hhonors, for the salt along with common PSKs (123456, Password, letmein, etc.) to generate a resultant table of hash values and PSKs. Each different salt value (or SSID, in this case) will generate a brand-new hash for every single password that’s used in combination in the hashing function.

This means the easiest thing an organization can do to combat these precomputed tables is to use a non-default SSID. If your SSID doesn’t appear in the list used to create the hashes this essentially becomes a worthless data set and will give the attacker no efficiencies when trying to crack your PSK.

While this is low-hanging fruit, and likely being done anyway to create a distinguishable SSID name for your purposes, it is still worth noting that a default SSID can put you at more risk than a custom one.

Do Not Use Default or Frequently Used SSIDs

Now that we’ve forced our attacker to go through the effort of trying massive combinations of passwords against our unique SSID, actual computing power starts to get more important. Many white hat hackers (including CDW’s own group) build cracking rigs made up of powerful computers usually leveraging Graphics Processing Units (GPUs) to vastly parallelize the computational workload to achieve incredible rates of speed and efficiency.

Noted security and password cracking expert Jeremi Gosney publicly posts benchmarks for his builds, which at the time of this post, shows one setup that can generate more than 5 million hashes per second against WPA. To put that in to some understandable numbers, let’s look at an eight-character long PSK (the 802.11i standard states that a PSK can be a passphrase of 8 to 63 printable ASCII characters).

Assuming a character set of 64 (alphanumeric characters), we have a total of 64^8 total PSKs that could exist. This results in roughly 1.4 years of computation time to calculate all the hashes in the set running at 5 million hashes per second. Though 1.4 years sounds like an inconvenient amount of time for an attacker, that timeline assumes that your PSK happens to be the last hash calculated.

In normal practice, hackers tend to use large password lists built with known common passwords, password dumps posted after large compromises, and tailored information gathered during an engagement (other passwords, the name of the CEO’s spouse, and so on). Cracking with these techniques can often yield results long before the need to generate and hash every permutation in our example.

Even simple password reuse, such as an employee using a well-known corporate password on a personal account that gets compromised (by no fault of their own), can lead to that password existing in a list that a hacker is using to crack a key.

In Part 3 of this series, I will offer some suggestions for better secure your PSKs to keep intruders out of your network.

Learn more about the different security assessments CDW offers.