Latest Posts From Revolution Wi-Fi | Andrew von Nagy
Wi-Fi Capacity Infographic November 13, 2017
Learn tips and tricks for building a high-performance WLAN!
I teamed up with the great staff at Ekahau to put together this infographic about how to design and deploy high capacity Wi-Fi. It's the second poster in the series, following the Wi-Fi Design Poster that focused on radio frequency (RF) factors.
WPA2 KRACK Vulnerability, Getting Information October 16, 2017
*** This page is being updated regularly. Please check back periodically. ***
I'm sure everyone who does anything with networking or Wi-Fi has heard about the announced WPA2 KRACK vulnerability. I'd like to start a collection of useful information in one single place.
The Main Points You Need to Know
Wi-Fi Protected Access (WPA2) has a very technical vulnerability in how it distributes encryption material that could be used by an attacker in physical proximity as a starting point to try to leverage other unrelated vulnerabilities to hijack application sessions. There is a very small window of exposure of the first few frames after the client associates to an AP and installs the encryption key.
WPA2 encryption is NOT broken, attackers cannot decrypt Wi-Fi traffic in bulk... with one serious exception:
Android, Linux, and other clients using the open-source wpa_supplicant software library can be tricked into using an all-zero encryption key, meaning effectively no encryption. Android devices are the serious concern with these vulnerabilities!
Remediation requires installing software patches. Some are out already, some are not, some may never be (depending on manufacturer support). See the patch section below.
A workaround exists to mitigate the issues... patching APs. But this is not a complete workaround, just minimizes exposure. Clients are still vulnerable when they are on other Wi-Fi networks that aren't patched.
My Opinion - the attack vector for all systems (except Android and Linux) is very small. This is a security vulnerability that should be handled with calm, not overreaction. This isn't WEP protocol flaws part deux. Apply patches to clients that will have them published and review defense-in-depth practices if clients are no longer supported or won't receive patches (e.g. IoT, legacy operating systems). Take this as an opportunity to review the security and compliance program within your organization as a whole; usually these types of situations provide the impetus and justification for maturing such programs.
Overview of the Basics
There are 9 vulnerabilities that are client related and 1 that is AP / Infrastructure related. The vulnerabilities revolve around improper reuse of the encryption keystream because an attacker acts as a man-in-the-middle (MiTM) and blocks certain encryption key negotiations early on during the negotiation between AP and client, triggering the AP to retransmit a request for confirmation that the encryption key was installed properly by the client. Most clients, when receiving this retransmitted request will reset their encryption Packet Number (PN) counter, which is supposed to ensure each frame has a unique encryption keystream used to protect the data (if it's reused, that's a weakness cryptographically). However, the client may have already started sending data frames, so when the PN is reset but the same encryption key is used, then subsequent data frames may reuse the same keystream. When the encryption keystream is reused, and the client transmits different frames with the same keystream, it becomes easier for an attacker to decrypt those frames. The resulting impact is that an attacker can potentially decrypt very specific frames that are sent right after association and reuse the same keystream (due to the attack); these frames likely contain well-known content (e.g. can be guessed) which is what allows decryption of the frame(s) that used the same keystream, which would practically speaking be ARP, DHCP, or TCP SYN packets. Using decrypted TCP SYN frames, the attacker could then try to leverage other unrelated vulnerabilities and attacks to hijack an application session. Wi-Fi data in general CANNOT be decrypted. Most importantly, as the author states, "Note that our attacks do not recover the password of the Wi-Fi network. They also do not recover (any parts of) the fresh encryption key that is negotiated during the 4-way handshake." One big exception to this is how Android and Linux clients using wpa_supplicant version 2.4 and above handle the replay scenario by installing an encryption key of all zeros, allowing full decryption of all data sent by the client.
All are effectively implementation issues by allowing reuse of keystream material, meaning software patching can fix them! Of the 9 CVE's related to clients, the most serious of them (7 of the 9, related to the 4-Way Handshake and Group Handshake) can be mitigated with AP / Infrastructure updates as a workaround, but the infrastructure won't be able to determine if failure is from packet loss issues or attack. A few can't be mitigated by AP patches (Peer-Key and tunneled direct link setup [TDLS]), which are peer-to-peer related vulnerabilities, but these methods of communication are rare and practically never used in my experience. The long-term fix is definitely client software patching. Patching Wi-Fi drivers can also fix 2 of the 9 client vulnerabilities (see Intel driver information below). The 1 CVE related to AP / Infrastructure is related to 802.11r Fast Transition - if you have it enabled you should patch ASAP. If not, no big deal. Many, many thanks go to Hemant Chaskar, Mojo Networks, and Pentester Academy!
It should be noted that these vulnerabilities were responsibly disclosed to manufacturers in July, which is a large reason there are patches available on day zero (Oct. 16th)! Thank you to Mathy Vanhoef for his work to find and report these issues in a way that helps improve Wi-Fi and in a manner that minimizes customer impact!
Second, read these articles and watch these videos by experts:
Patching systems will be important over the coming hours/days/weeks/(what you take longer than a week or two to patch?!?). Client systems are the most affected, but infrastructure systems also have a few related issues requiring patching too.
Patching client systems is the ultimate fix for the 9 client vulnerabilities.
Patching APs is the ultimate fix for the 1 infrastructure vulnerability
See the software patch section below for information on manufacturer patch availability.
Mitigation / Workarounds
Patching takes time. Here are some workarounds you can take until all clients can be patched:
AP Configuration - investigate your WLAN vendor to see if they provide users control over the EAPOL settings. If they do, set the EAPOL retries setting to 0 (zero) in order to prevent the AP from retransmitting message 3 of the 4-Way Handshake, which will prevent the client from "reinserting" the PTK encryption key and resetting their Packet Number counter. For example, on a Cisco WLAN you use the following command: wlc> config advanced eap eapol-key-retries <value>
Patch APs - this holds potential to mitigate 7 of the 9 client vulnerabilities when they are connected to your Wi-Fi network. It is still unclear if AP vendors' patches will change default EAPOL settings to mitigate the client issues, so this may or may not prove effective. Regardless, when clients are connected to other Wi-Fi networks they could still be vulnerable.
Review Security, Compliance, and Risk Assessment in your organization: Security should never be reliant on a single point of protection. Utilize "Defense-In-Depth" practices to provide multiple points of protection.
Review Business Reliance - how critical are the unpatched and vulnerable devices to your business? What business applications rely on their use? What data can these devices and applications access? Establish how important the devices are to your business operations or efficiency. This will help you weigh the risks involved with continued use of the devices and access to corporate data versus the cost of data breach. One last aspect: does your organization include budget for risk of loss or data breach?
Assess Application Security - if users are using corporate applications, review them for additional layers of security, such as HTTPS, SSL, TLS, etc. Additional layers of security and encryption can protect sensitive application data even if specific clients are vulnerable to these Wi-Fi attacks.
Review Network Access - what access do these devices have on your network infrastructure? Are they segmented from network resources that they don't require access to by traditional network firewalls, or can they be? Can access be restricted to minimize risk of data breach? Is restricting access through a VPN a viable option to provide an additional layer of security for sensitive data access by vulnerable devices until they can be patched? Should vulnerable devices be prevented from accessing the corporate network completely until patched (perhaps especially for Android and Linux)?
Review Network Defenses - are wireless or wired intrusion detection, intrusion prevention, or application layer firewalls in place that can monitor for suspicious behavior and alert or prevent attacks? What would it take to add these capabilities? It should be noted that these attacks rely on a man-in-the-middle (MiTM) attacker AP, which is easily detected and alerted on by most enterprise wireless networks without an overlay IDS/IPS. Review what capabilities your wireless system has to alert on honeypot APs using your SSID, evil twin APs, and spoofed MAC addresses. For examples of WIPS mitigation see Jim Vajda's blog here and Mojo Network's "countermeasures | part 5" video here.
Review Logging, Correlation, and Alerting Systems - are there centralized or aggregated logging systems in place that can correlate suspicious behavior across multiple systems and provide visibility into how an attacker may be moving through your network and systems?
Review Incident Response Procedures - if network, application, and logging/alerting systems are in place, what is the incident response process? Is it mature, does your staff know how to handle incidents properly and quickly when they arise?
Security Policies and Procedures - do you have security policies and procedures that cover the use of these devices for business purposes, Wi-Fi access, data classification and handling, etc.? Now would be a great time to ensure these policies are in place and up-to-date. It would also be a great time to make sure the policies are enforced throughout your IT environment.
Security Awareness - users are typically the weakest link in data security. Does your organization have a security awareness program to educate users on data security practices? Consider making a special awareness campaign for this Wi-Fi issue and getting easy-to-understand (non-technical) information out to your users with clear instructions.
It's normal to need help with the security, compliance and risk assessment, especially for smaller organizations. Find a specialist to help you formalize and mature these if necessary!
I covered many of these organizational security, compliance and risk assessment points on Twitter as well. See the thread that starts with this tweet:
Unpatched systems ARE an issue w/ #WPA2#KRACK. It comes down to use-case analysis, defense-in-depth practices, & risk analysis. 1/x
Apple and Microsoft appear to only be affected by a subset of the vulnerabilities. iOS and Windows are not vulnerable to the one set of exploits because they don’t accept retries of handshake message 3. Specifically, they don't allow key reinsertion of the PTK used for unicast frames and unique to each client, but are still vulnerable to the GTK group key reinsertion variant. This is much less concerning. https://www.macrumors.com/2017/10/16/krack-wifi-vulnerabilities-patched-apple-ios-macos/
Also, I'm not tracking every manufacturer, only the most prominently deployed from my perspective. There are a few sites compiling a detailed list tracking patches from a multitude of manufacturers that you may want to check out: