How broken is WPA2 really and what to do?

Blog post 2017-10-17 by Ralph Moonen, Technical Director at Secura

How broken is WPA2 really? If you’ve followed the news in the last day or so, you can not have missed Mathy Vanhoef’s paper on a protocol vulnerability in WPA2 wireless networks. A big thing in infosec land! Most news agencies like to dramatise such events so when the news reaches the masses, it is usually quite distorted and sometimes outright sensationalist. To find out if that’s the case here also, I took a closer look at the vulnerabilities, and what would be necessary for an attacker to successfully exploit them.

First, we note that this attack allows an adversary who is physically near an active client, to intercept and decrypt traffic. So it is not an attack on the Access Points or clients, as the recent Broadcom chip attacks was. There has to be a client, associated with an AP. WPA authentication uses a 4-way handshake. First, the client authenticates against the access point, then the AP against the client, and in that second step, the AP sends the client an encryption key to be installed and used. Further communication uses that key.

Mathy noticed that due to reliability issues, the protocol accepts the 3rd packet of the WPA 4-way handshake being processed multiple times. However the protocol did not specify that a new key was to be installed. As it turns out, usually, the old key gets re-installed (including other assorted tidbits such as sequence numbers and nonces). This effectively forces the client to re-use a previously used key-stream. It can be easily shown that re-using a keystream cripples cryptographic systems. In fact, in an online challenge Secura did earlier this year where you could win Hack-in-the-Box tickets, this was the central challenge. It is not extremely difficult to extract plaintext and decrypt packets when keys are re-used multiple times (but depends a lot on what data is encrypted and if it contains predictable information!)

In this case, it gets worse, because on the Linux and Android clients, the WPA2 drivers do not re-install an old key, but rather a key of all zero’s. This is presumably because the developers did not want to keep the key in memory longer than necessary (security-wise this is a good idea), and zero’ed it out, forgetting or missing the fact that it could be used later again. So the situation is then as follows: attackers replays step-3 of the 4-way handshake, client re-installs used key (or a key of all zero’s), the client starts using that key for encrypting packets, attacker intercepts packets and decrypts those (with some additional effort).

But what's next? The AP is not aware of the client having other keys. It will not be able to process the packets. The attacker must allow the client to re-authenticate again, and re-transmit the packets. Rinse and repeat after that for decryption of packets.

To be clear: this attack required an active Man-in-the-Middle position and this can be detected. Also, if you are using a VPN or TLS, the attacker will not be able to decrypt those packets. But decryption of HTTP session identifiers on any non-TLS site seems very possible because of the predictability and location of HTTP headers. In the case of Android and Linux, the key is known and it is therefore possible to also inject fake packets. For instance containing malicious Javascript. Since the 4-way handshake is used in various places in the protocol, this vulnerability is also present in for instance 802.11r, the roaming standard.

In conclusion, it seems practical, but non-trivial, to make the whole exploit-chain work nicely as shown in the demo’s. But it’s a matter of time before simple implementations will become available, and become optimized. I would say that WPA2 is pretty broken, but fortunately, it will be easy to fix (the clients). In the meantime, what you can do is:

  • Use a VPN over WiFi
  • Make sure you use TLS-enabled services mostly
  • Update when a fix is available (check your vendor's site often!)
  • Disable unused features such as 802.11r (lowering attack surface)

Next post: A bad week for crypto: following KRACK, now there's ROCA

Blog post 2017-10-17 by Ralph Moonen, Technical Director at Secura

 

@Secura 2017
Disclaimer  /  Privacy policy  /  Sitemap / Log in
Webdesign Studio HB / webdevelopment Medusa