If for some reason you’re still using TKIP crypto on your Wi-Fi, ditch it – Linux, Android world bug collides with it

August 9, 2018 TH Author

It’s been a mildly rough week for Wi-Fi security: hard on the heels of a WPA2 weakness comes a programming cockup in the wpa_supplicant configuration tool used on Linux, Android, and other operating systems.

The flaw can potentially be exploited by nearby eavesdroppers to recover a crucial cryptographic key exchanged between a vulnerable device and its wireless access point – and decrypt and snoop on data sent over the air without having to know the Wi-Fi password. wpa_supplicant is used by Linux distributions and Android, and a few others, to configure the Wi-Fi for computers, gadgets, and handhelds.

This key is used in networks that employ EAPOL (Extensible Authentication Protocol over LAN). The good news is that no more than around 20 per cent of wireless networks will be vulnerable, it is estimated, because the attack requires TKIP and WPA2 to be in use – and no one should be using TKIP in 2018.

In this paper [PDF], “Symbolic Execution of Security Protocol Implementations: Handling Cryptographic Primitives,” to be presented at the Usenix Workshop on Offensive Technologies symposium next week, Mathy Vanhoef and Frank Piessens of the Katholieke Universiteit Leuven in Belgium, explained how a decryption oracle can be used to perform unauthorized decryption of wireless network traffic.

Doing back, er, bit flips

In this Twitter thread, Vanhoef summarized what’s going on: “The problem is that data is decrypted with RC4, and then processed, without its authenticity being checked. So you can flip bits, see how to client reacts, and based on that, recover plaintext.”

And as wpa_supplicant maintainer Jouni Malinen explained in his advisory on Wednesday: “It is possible for an attacker to modify the [EAPOL] frame in a way that makes wpa_supplicant decrypt the key data field without requiring a valid MIC [Message Integrity Code] value in the frame, ie: without the frame being authenticated.”

Malinen added that WPA2 shouldn’t be set up with TKIP as the latter is known to be weak anyway. However, as Vanhoef noted, there’s still people out there using this combination. So, in short, just ensure TKIP is disabled. Malinen added that to recover group encryption keys, a snooper would have to make 128 connection attempts per octet, because an attacker’s bit-flips will make the four-way authentication handshake fail. Not only is this slow, it could crash the access point under attack.

Vanhoef conceded that an attack would be slow to pull off, taking around 20 minutes per byte recovered. “Several clients can be attacked in parallel, but it’s still a non-trivial attack. Patch, but don’t worry too much,” he said.

Nonetheless, the wpa_supplicant team has taken the bug seriously, and developed a fix that should hopefully or eventually trickle down to netizens. Access points and devices will need an update for networks to be free from the flaw. Malinen said if possible, affected users should just kill off TKIP in their networks.

The wpa_supplicant maintainers have pushed out a hotfix here, and the next version, 2.7, will carry the fix. Vanhoef has a proof-of-concept of his attack over on GitHub. ®

Sponsored: Following Bottomline’s journey to the Hybrid Cloud