12

We know that WPA/WPA2-PSK uses a PTK (Pairwise Transient Key) for each client to encrypt the communication. This PTK is generated through the process known as 4-way handshake. As told in the related page on Wikipedia:

The PTK is generated by concatenating the following attributes: PMK, AP nonce (ANonce), STA nonce (SNonce), AP MAC address, and STA MAC address. The product is then put through a cryptographic hash function.

So, if an attacker has the ability to setup a rogue AP (Access point) and make some clients automatically deauth & connect (especially mobile clients) to that rogue AP of his, can he gain some advantage to speed up calculations for cracking the PSK by introducing some specially generated inputs for example ANonce, AP MAC -the variables which he can control-?

We can assume that he has the chance to do this for some reasonable times such as 10. So he will obtain that number of 4-way handshakes which he used some specially selected inputs (similar to a chosen-plaintext attack). I wonder if there is some component in the design which will prevent that he gains some speed advantage by using a rogue AP rather than simply capturing the 4-way handshakes?

  • If the hash function used is any good and the attacker has no knowledge of the PMK (=PSK), there should be no way of doing this. – Paŭlo Ebermann Oct 30 '11 at 13:44
  • What I'm asking is exactly this, but I want a detailed and confident answer. – sanilunlu Oct 31 '11 at 3:56
8

The key derivation of the PTK is defined in section 8.5.1.2 of IEEE 802.11-2007, Figure 8-20 (page 198, which is page 247 in the PDF file):

PRF-X(PMK, "Pairwise key expansion",
      Min(AA,SPA) || Max(AA,SPA) ||
      Min(ANonce,SNonce) || Max(ANonce,SNonce))

AA and SPA are the addresses of both communicating partners, ANonce and SNonce are the nonces sent by them.

X is the number of bits needed, and depending on the use, X is here either 384 or 512.

In the previous section 8.5.1.1, the PRF (pseudo-random function) is defined, and it is effectively

PRF-X(K, A, B) = HMAC-SHA-1(K, A || 0 || B || 1) ||
                 HMAC-SHA-1(K, A || 0 || B || 2) ||
                 ...

(with as many repetitions as needed to fill the needed number of bits, discarding the remaining ones.)

So the question effectively is: Can one attack HMAC-SHA-1 in a way that, knowing some of the input and choosing other parts of the input, but not knowing the key, one can (a) derive parts of the output, or (b) derive the key?

As far as is known, neither the HMAC construction nor the SHA-1 hash function has a weakness in this respect.

So the only currently known way to break this would be to brute-force the PSK (or the password from which it is derived), which would need not much more than one listened handshake, but lots of computation to find the key.

There is no realistic chance to break the 256-bit key, but one might find a password from which it is derived quite easier. So use a good password.

  • So we can't be sure without having a detailed inspection on the construction of PTK. Unless there is some chosen-plain-text attack on HMAC construction or SHA-1, we can't gain any thing further than brute force. – sanilunlu Oct 31 '11 at 20:13
4

If a user has connected before, their client should complain if the MAC address of the AP has changed and warn the user about connecting. Under windows it will forcibly append "2" to the ap name. This should reduce the likelihood of success. However, if the MAC address is the same, the client will have no way of knowing if the AP is rouge. This means that you could have a hard-coded ANonce value which would reduce the key space that has to be searched. If you where brute forcing the offset one handshake would reduce the number of permutations to the size of the SNonce.

  • For many clients let's say that MAC address change is not a problem or if we want to be strict we can just use only the ANonce value. Our aim is not to ensure that user won't notice the change and know about a rogue AP. Let's assume we've succeed to trick the user/device. That's not a problem I think. The problem is, if we change this value for a few times and recapture 4-way handshakes for each, would this information help us cracking the password? I am asking that is it's helpful to speedup the cracking phase, that could be integrated into tools such as aircrack-ng, cowpatty and pyrit. – sanilunlu Oct 29 '11 at 23:59
  • @sanilunlu Multiple captures would not speed up cracking unless there was a flaw in the underlining primitive. For instance the flaws in RC4 leading to the downfall of WEP. WPA2 uses AES which is significantly more secure. – rook Oct 30 '11 at 1:12
  • What I'm trying to learn is if someone knows there may be some weakness in the use of crypto (hashing alg., etc.), so we can gain more information about the key having captured different PTKs computed using different ANonces. So we'll have for example 5 different PTK calculations which use 5 different ANonce values and same MACs, PMK but potentially different SNonces as the inputs. Rather than having one capture of 4-way handshake, having for example 5 different captures constructed using attacker-chosen ANonces. – sanilunlu Oct 31 '11 at 3:52
  • @sanilunlu I honestly don't see how that helps. At the end of the day you just have to iterate over that keyspace. – rook Oct 31 '11 at 5:26
1

Although difficult, obtaining a WPA2 password via a rogue AP is theoretically possible.

One would create an AP with a different MAC so that you don't deauth yourself but the same ESSID.

A web server running on this AP combined with some iptables rules would reroute all http traffic to a locally served web page that allows the users to enter their password.

Since the Vendor and model of the router can often be found using a network sniffer such as wireshark, one could make a fairly convincing "Firmware Update" page.

The webpage could POST the password to a mysql database.

The only thing left is incentive to connect to a strange open AP with the same name as his own AP. Using another wireless interface, one can use a deauth attack against all clients connected to the original AP.

Clients will get frustrated and will want their internet back which could lead to them checking available networks and seeing the rogue one.

Their are a lot of variables:

  • Signal strength of Rogue AP
  • Deauth being able to reach clients at all locations.
  • Victim is desperate enough to check available networks and connect
  • Victim navigates to http page
  • Victim is desperate/dumb enough to enter password in a web page.

But it is not impossible.

  • This doesn't answer what OP asked – Mr. E Mar 10 '17 at 17:00
  • @Mr.E I disagree. If you go by the title it is a direct response to his question. Also, there is a question marked as a duplicate of this and it asks explicitly if there is any way. – NULL Mar 10 '17 at 17:09
  • Actually, not. The question is about speeding up WPA/WPA2 PSK cracking, your answer is about another type of attack using a captive portal. Also you can't guide your answer just using the title, questions have a body in which the context of the problem is explained and your answer doesn't fit in that context either – Mr. E Mar 10 '17 at 17:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.