A WrightCore take on WPA2...Is it really dead?

By Andy Winford on October 17, 2017
Tags: WPA2, Cybersecurity, Vulnerability

WPA2 is not dead, but it took one heck of a gut punch today.   This morning, an announcement made public a known vulnerability affecting all implementations of WiFi Protected Access (WPA1 or WPA2) pre-shared key based and enterprise deployments using any cipher suite (WPA-TKIP, AES-CCMP, and GCMP).  This vulnerability attacks WPA's 4-way handshake used to secure client authentication to a wireless network.  Note, there are several Common Vulnerabilities and Exposures (CVE) identifiers around this including PeerKey and Group Key handshakes but we will discuss the more commonly used PTK (CVE-2017-13077) and 802.11r (CVE-2017-13082) versions of the vulnerability.   Here is how we understand it at this point:

·       Although some may argue with me on this  (they already have), WPA is not ‘broken’ and while this is a serious vulnerability, there are still many ways to mitigate.   

·       The attacker is not remote.  The attacker must be physically onsite or near the AP to accomplish this task.  Exploiting the vulnerability relies on a Man-in-the-Middle attack as the first step.  wIPS anyone?  Just be careful when using public wifi as this attack goes after the client.

·       Your pre-shared keys or, if using WPA2 Enterprise, user and password authentications are not exposed in this attack (unless you send them in plain text in a wireless message to your co-worker and I know you wouldn’t do that).

·       If the traffic being transmitted wirelessly is itself encrypted (HTTPS browsing for example) the traffic cannot be seen by the attacker.  For you VPN guys think of Phase I being compromised but Phase 2 remains encrypted and unseen.   Other attacks against the encrypted traffic using an HTTPS interceptor (as was demonstrated by the researchers who found this vulnerability), for example, can still occur but that is for another post.

·       Windows and iOS machines appear to not implement 802.11 standards as the IEEE gods intended.  For example, they don’t support message 3 retransmissions.   For once breaking the rules is a good thing as these supplicants are not susceptible to the PTK 4-way handshake.  However, they are to the Group Key and 802.11r (more on this later) attacks as both of these target the AP the client is communicating with, not the client itself.


How It Works

Here’s how we understand it to work.   Communication in WPA secured networks includes protection based on what is called the Pairwise Transient Key or ‘session key’.   This key performs the necessary encryption of data as it is transmitted.   The key is made up of several things including:

·       Your PSK or 802.1x authentication wrapped into what is called a Pairwise Master Key (PMK)

·       MACs from both the client and the AP.

·       Nonces from both the client and the AP.

Nonces are the key (no pun intended) to this attack.  Nonces are random numbers created in authentication protocols to guard against replay attacks.   With each session key, the nonces are changed to prevent decryption of data being transmitted and ensuring old communications cannot be used by injecting randomization into a packet with common attributes (client and AP MAC addresses, for example).   In the 4-way handshake, the client installs the session key and randomizes the client (supplicant) and AP (authenticator) nonces.   However, the rub comes with the sometimes-unreliable nature of wireless transmissions.   The AP and Client must agree on the session key for communication to commence.   But if the quality of the wireless transmission causes the session key to not be received by the AP, the AP will ask the client to resend.   When it resends, it reinstalls the same session key, reusing the same nonce and resetting the replay timer.   To me, this is the secret sauce of this vulnerability.    If I can make myself appear as the client’s AP via a Man-in-the-Middle attack, I can then control the reinstallation of the session key through what I tell the client.  ‘Hey didn’t get that, resend’.  Reusing the same nonce basically means reusing the same keystream which allows for the decryption of traffic.   Resetting the replay timer allows for replaying traffic or creating (forging) traffic.   Reminds me a little of the weak Initialization Vector (IV) attacks against WEP back in the day when I had more hair.  


While the attack exploits the client specifically, APs are also exposed to the vulnerability if you are using 802.11r or Fast Secure Roaming (FT).   Fast Secure Roaming allows the client and APs to do the session key calculation in advance and install these keys on the client and AP after the client re-associates to a new AP when roaming.   This is an especially good thing for wireless VoIP as it reduces latency in the roam.    However, there are no replay counters in the handshake and the PTK is reinstalled at the re-association request.   With this new vulnerability Client to AP packets can be replayed and AP to client packets can be decrypted.    Furthermore, a Man-in-the-Middle is not necessary to initiate this attack. 

What You Can Do About It

WrightCore suggests the following:

·       Unless using Voice, disable 802.11r or Fast Secure Roaming.   Disabling 802.11r on the AP infrastructure will mitigate 802.11r vulnerabilities but does not address the 4-way handshake vulnerabilities on the client.

·       Ensure you are running Wireless IPS on your network to prevent MAC-spoofing or MitM attacks.

o   Aruba’s RFProtect

o   Meraki’s Air Marshall

o   Aerohive’s wIPS

o   Cisco’s Adaptive Wireless IPS

o   Ruckus wIPS

·       Upgrade to the latest version of code that specifically addresses these vulnerabilities.   Having not researched these updates in depth it is assumed that since the goal of the attack against the AP requires the attacker to replay a re-association request frame, these updates will remove the ability to retransmit a re-association in an 802.11r enabled WLAN.  That sounds rash but if true it could impact WLAN performance.  The updates may just ensure that 802.11r is disabled by default.  Still researching this one. 

·       As of this writing, WrightCore’s wireless manufacturing partners have addressed these vulnerabilities with updates:  

o   Cisco Enterprise:  Cisco has released an advisory shown below.  They have identified three additional vulnerabilities not mentioned in today’s announcement.  https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20171016-wpa

o   Meraki: Fixed with Meraki 24.11 and 25.7.   Information on the vulnerability is on customer dashboards.  Also see the above Cisco advisory.

o   Aruba: Fixed and customers notified.  Please see:  http://www.arubanetworks.com/support-services/security-bulletins/

o   Aerohive is releasing 8.1r2a later this evening.   For a full announcement and updates please see: https://www3.aerohive.com/support/security-bulletins/Product-Security-Announcement-Aerohives-Response-to-KRACK-10162017.html

o   Ruckus released a tech blog from Miss Mo Williams that I like https://theruckusroom.ruckuswireless.com/wi-fi/2017/10/16/commonsense-approach-uncommon-problem/ and also a tech advisory listed here https://support.ruckuswireless.com/documents/2040-faq-security-bulletin-101617-wpa2-vulnerability-krack-attack with the affected products and recommended code.

A concern of mine going forward is how some knee-jerk updates and remediation steps may fix this particular problem but doing so at the expense of your wireless network's performance.   In my opinion, I don’t see WPA going anywhere, anytime soon.   Take a breath.   Apply a common-sense approach to securing your network with a solid wIPS solution that guards against MitM attacks and ensuring quality testing of updates and patches before applying them.  To me, this will help settle some upset tummies out there.   Until the next shoe falls, good luck to all!   And if you need any help, give us a call. 

Lame I know.  But it's been a long day.