25

I was wondering that, when a hacker is trying to hack a Wi-Fi network, he/she would try to capture a handshake and then try to decrypt it, whereas when you want to log in to your Wi-Fi access point, you would type in your password, the password would be encrypted, and then sent to the router which would decrypt it using a key.

So why can't a hacker just intercept the encrypted password (the handshake) and the just resend it to the router without having to decrypt it like a replay attack?

2
  • What handshake do you mean? TLS? – mentallurg Apr 15 at 18:53
  • 1
    The four way handshake – nonope2454 Apr 15 at 19:21
60

Because the protocol is built to protect against that.

whereas when you wanna login to your wifi you would type in your password and the password would be encrypted then sent to the router which would decrypt it using a key

This is not how it works, on many levels. The password is never sent over the air, and it's a more complicated protocol, with multiple back and forth-messages - commonly referred to as a four way handshake.

It uses a nonce to ensure that the packets are not equal. The nonce is basically a random number added by either party to explicitly avoid replay attacks, by forcing the content to differ. The access point gives the client a nonce, and the client uses that nonce in further calculations. An attacker replaying the data would be betrayed by the fact that the AP can tell that it's not using the nonce supplied by the AP to the attacker.

Four way handshake process

Furthermore, if we have a look at the four way handshake, we see that neither party sends the actual secret over the air. They just prove that they know it for each other, so there's a mutual authentication.

2
  • 6
    @nonope2454: This is a good answer. The purpose of nonce is namely to prevent replay attacks. – mentallurg Apr 15 at 19:36
  • Very early "car fob" designs were vulnerable to such types of attack, but they quickly learned from it and started adopting similar strategies. – vsz Apr 18 at 13:00
22

Vidarlo's answer is mostly right, but, incidentally, there was one fatal flaw in the protocol: the protocol was intentionally designed to allow replays to some degree. In particular, it was designed to allow retransmissions of message 3 in the handshake to succeed. But who's to say that it's the original client retransmitting the frame instead of an attacker? As it turns out, no one. This is the basis for the KRACK attack which was indeed a successful replay attack against WPA2.

While KRACK (Key Reinstallation AttaCK) didn't directly allow spoofing a Wi-Fi client, it could be used to repeatedly reset the nonce and the replay counter, which caused future frames to be encrypted with nonces that had already been used, which could in turn allow the attacker to slowly discover key material.

Interestingly, despite being a fundamental problem in the 4-way handshake itself, knowledge of this vulnerability wasn't publicly disclosed until late 2017.

US-CERT described the attack this way (emphasis mine):

US-CERT has become aware of several key management vulnerabilities in the 4-way handshake of the Wi-Fi Protected Access II (WPA2) security protocol. The impact of exploiting these vulnerabilities includes decryption, packet replay, TCP connection hijacking, HTTP content injection, and others. Note that as protocol-level issues, most or all correct implementations of the standard will be affected. The CERT/CC and the reporting researcher KU Leuven, will be publicly disclosing these vulnerabilities on 16 October 2017.

If you want to read about the details of how the attack worked, the original paper by the researchers who discovered it is an interesting read.

Interestingly (and kind of amusingly,) the attack didn't affect the 4-way handshake in Windows and iOS because the Wi-Fi stack in those operating systems did not implement WPA strictly according to the 802.11 standard. In particular, they did not allow message 3 of the 4-way handshake to be replayed (which the standard requires to be allowed,) which defeated the attack. I'm not sure whether this invulnerability was due to a smart engineer noticing that the standard was poorly-designed on this point or a lazy engineer not implementing the state machine to allow replays of message 3, but, either way, it worked out for the best. However, their implementations of the group handshake (the one for negotiating keys for broadcasting messages to all connected stations) were still vulnerable to the attack.

4
  • 2
    Very good addition and extremely important clarification :) Thank you :) – vidarlo Apr 16 at 20:29
  • 1
    Interesting. So is not allowing message 3 to be replayed strictly better? If so, why is it in the standard in the first place? – justhalf Apr 17 at 6:23
  • 2
    @justhalf Because handshakes have been considered expensive (WPA2 is from 2004), and radio signals are notoriously unreliable. It seemed to be much more efficient to simply resend a lost packet instead of restarting the entire handshake. Furthermore, KRACK is a pretty recent discovery; until then nobody was aware that resending the message introduces a security vulnerability. – K. Biermann Apr 17 at 15:30
  • @justhalf Yeah, what K. said. The retransmission was allowed because it's a wireless protocol and missed frames happen frequently. It made the protocol more reliable (in terms of connections working,) but less secure. Incidentally, the 4-way handshake had been formally 'proven' correct, but the correctness proof didn't consider protection against key reinstallation, as I recall. The researchers who disclosed the vulnerability discuss that in the paper and mentioned that the discovery of the vulnerability was likely delayed by the fact that the handshake had been formally 'proven.' – reirab Apr 18 at 6:26

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.