Yes, but stupid question. If Radius is being used, there's no way to successfully impersonate the AP and have the victim accidentally try to join it because the AP won't be able to authenticate the WPA2-Enterprise credentials? Then the attack fails? Or silly me, the fake AP could be configured to somehow accept the login attempt by the victim? But if so, then it'd be able to record the login credentials thus making the attack's impact even larger than I've seen discussed, because then not only is the attack successful in decrypting the victim's traffic, but the victim's Wi-Fi credentials are also stolen?
> If Radius is being used, there's no way to successfully impersonate the AP and have the victim accidentally try to join it because the AP won't be able to authenticate the WPA2-Enterprise credentials?
From what I understand the credentials won't matter. Anyone else more knowledgeable please correct me if I'm wrong, but the attack goes something like this:
1. Capture trafic that includes the 4-way handshake
2. replay message #3 of the handshake
3. client's encryption key is set to zero (in the case of wpa_supplicant), and nonce/IV are reused going forward
4. you are now in control of the encryption key being used (again, only wpa_supplicant) so you can go ahead and MITM the victim's DNS queries, capture cookies, etc...
The Details section of the researcher's site explains it pretty well:
Lastly, the most urgent task for mitigating this is to patch client devices as quickly as possible.
Android's fractured vendor-specific distributions and lack of long-term support for the low-mid level models is going to make this a difficult/impossible task...
Thanks, it's right there in the text, clear as day. :)
Note that our attacks do not recover the password of the Wi-Fi network. They also do not recover (any parts of) the fresh encryption key that is negotiated during the 4-way handshake.
This attack happens after the authentication stage and the client is trying to negotiate session keys with the AP. As a note, this is also why the pre-shared key isn't intercepted by this attack in WPA2-PSK.
The initial authorization/pre-shared keys are used to negotiate and share session keys. It is the negotiation of these session keys that is attacked, leading to insecure session keys being used. The initial auth parts of the handshake are not being abused here, only steps 3/4 of the 4-way handshake.
I believe in this auth situation, the password is not sent in to the server in cleartext, but rather the server sends a challenge to the client, the client performs the challenge using the password as a parameter, sends the result to the server, then the server checks the result is valid for the expected password. The password itself cannot be determined from the challenge result.
So, even by impersonating an AP you don't get the user's password.
