The recently announced improved version of the original Beck-Tews attack on WPA/TKIP appears to have put the wireless security community in a tizzy again. In this post, I argue that the new attack is neither groundbreaking in academic terms, nor is it more worrying in practical terms.
The proposed attack assumes (somewhat unrealistically) that the AP and client cannot hear each other but the attacker can hear both (and can thus act as a man-in-the-middle). In terms of attack speed as well, it is actually slower than the original attack under its stated assumptions.
Security is hard to get right and shortcuts — be it coding shortcuts or design shortcuts – come back and haunt the product designers when the rubber hits the road.
The recently discovered “skyjacking” vulnerability of the Cisco LAPs seems to be a classic example. The “Over The Air Provisioning” (OTAP) feature allows an out-of-the-box Cisco LAP to automatically discover available WLC controllers to connect to by listening to wireless OTAP packets broadcast by neighboring Cisco LAPs. This feature obviously has attractive plug-and-play benefits for the end user but has also resulted in some critical security holes in the Cisco wireless infrastructure as reported recently. Malicious OTAP packets transmitted by an intruder can make a LAP connect to a “rogue” WLC controller on the Internet. This controller can modify the wireless settings of the AP in devious ways resulting in an AP that is in your airspace, connected to your wired network but completely controlled by an attacker.
Many security vulnerabilities are due to coding bugs (for example, inadequate input checking or the infamous buffer overflows). In contrast, the skyjacking vulnerability has its root, in my opinion, in two questionable design decisions that were probably made as early as the requirements definition stage.