Wi-Fi Capacity Infographic

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.

The Wi-Fi Capacity Infographic covers:

  • An overview of airtime and why it is important
  • Understanding the two primary factors affecting airtime:
    1. Airtime within a cell
    2. Airtime across cells
  • Methods to maximize airtime efficiency to get the most out of your WLAN
  • Channel inventory as it relates to capacity
  • How client capabilities affect airtime consumption, and hence capacity, in a WLAN
  • Factors to consider when selecting infrastructure to deploy
  • Factors to consider with infrastructure placement and configuration
  • Features available within Ekahau Site Survey to set you up for success

Download the Wi-Fi Capacity Infographic today!

WPA2 KRACK Vulnerability, Getting Information

*** 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

  1. 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.
  2. WPA2 encryption is NOT broken, attackers cannot decrypt Wi-Fi traffic in bulk... with one serious exception:
  3. 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!
  4. 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.
  5. 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!

First, go read the security researcher's website on the attack details:
https://www.krackattacks.com/

The author, Mathy Vanhoef, has also released a test script for the AP-related 802.11r vulnerability (this is related to the 1 AP vulnerability of the 10 released):
https://github.com/vanhoefm/krackattacks-test-ap-ft

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:

Third, here's the US-CERT page collecting information on vendors affected:
http://www.kb.cert.org/vuls/id/228519

Fourth, the Wi-Fi Alliance is enhancing future testing and certification for this vulnerability:
https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-security-update

Remediation

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.

  1. Patching client systems is the ultimate fix for the 9 client vulnerabilities.
  2. 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:

  1. 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>
  2. 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.
  3. 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. 
    1. 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?
    2. 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.
    3. 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)?
    4. 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.
    5. 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?
    6. 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?
    7. 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.
    8. 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:

Known Impact Assessments

Android 6.0 and above implementations appear to be especially vulnerable to the worst variants of the attack that include decryption of actual client transmitted frames (e.g. one-way traffic)!
41 percent of Android phones are vulnerable to 'devastating' Wi-Fi attack
https://www.theverge.com/2017/10/16/16481252/wi-fi-hack-attack-android-wpa-2-details

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/

Apple appears to have patched this vulnerability in previous "beta" releases for iOS, MacOS, and tvOS. We are still waiting for the patch to be released into a "public" release.
http://appleinsider.com/articles/17/10/16/apple-confirms-krack-wi-fi-wpa-2-attack-vector-patched-in-ios-tvos-watchos-macos-betas

Note - Apple's policy is not to discuss security issues until a patch is released. You might want to follow Apple-centric providers as well, such as my employer Foundation Technologies: https://fndtn.com/2017/10/16/security-alert-wpa2-and-krack/

Microsoft released patches for all currently supported operating systems on Oct. 10th with their regular monthly patch cycle: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-13080 and
https://www.theverge.com/2017/10/16/16481818/wi-fi-attack-response-security-patches

Staying Abreast of Software Patches

Wi-Fi client manufacturer security advisory websites:

Wi-Fi infrastructure manufacturer security advisory websites:

Known patched products (in alphabetical order):

Patches announced for future release:

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:

Cheers,
Andrew

 

P.S. - From a standards development standpoint, the IEEE is taking renewed heat for a notoriously closed process and peer review. There is an interesting take on that here: 
https://blog.cryptographyengineering.com/2017/10/16/falling-through-the-kracks/

Capacity Planner Version 2.0 Released

Modern Wi-Fi networks are complex beasts. Despite all the fancy new features in products, the technology is only becoming more complex and the demands on the network are only growing. Wi-Fi is the most heavily used method to transport user data today, eclipsing cellular and LAN traffic volumes according to multiple reports from analysis firms including Cisco, Ofcom, Mobidia, Ovum, and others. Meanwhile, the technical complexity contained within the IEEE 802.11 standard results in a technical document that is over 3,200 pages long!  This means deploying a network right is no easy task.

One of the most difficult aspects to get right when deploying a Wi-Fi network is understanding capacity requirements. It is not sufficient enough to use rule-of-thumb guidelines based on number of clients per access point or number of access points per square foot/meter since they often result in networks that do not adequately meet actual end-user demands and perform poorly. More rigor is required while maintaining simplicity of use so that most network administrators can be confident of a successful outcome.

Essential to wireless network performance and capacity planning is understanding the interaction between access point capabilities, network configuration, client device capabilities, and the RF environment. Many administrators still focus exclusively on the access point capabilities and, to a lesser extent, network configuration and RF environment. However, it is really the interaction of all four aspects that determines network performance. Complexity is introduced because wireless client devices have a wide range of capabilities, including protocol versions from 802.11b through 802.11ac Wave 2, from 1-3 spatial streams, 20 vs 40 vs 80 MHz channel width support, single-band vs dual-band support, and antenna design characteristics that vary between devices based on form-factor and manufacturer product objectives. In addition, the RF environment is always changing, even for stationary devices, because of signal reflections, multipath, and other objects moving within and through the physical environment. What this really means is that capacity is consumed in a dynamic fashion on the WLAN, each client consuming capacity differently and varying by the microsecond as the RF environment changes and affects client signal-to-noise ratio (SNR) and data rate selection.

Two years ago, the Revolution Wi-Fi Capacity Planner ™ was released as a proof-of-concept tool for free to the community, with the objective to promote better capacity planning for every WLAN. It provides a simple tool to estimate client airtime utilization and understand how many APs are required given the variables described previously: AP capabilities, network configuration, client capabilities, and RF environment. The most critical aspect of the tool is to define the client device mix, which can be as simple as generic device types (laptops, tablets, smartphones, etc.) or as comprehensive as possible if the administrator has reliable data on the specific devices in use.

Ubiquiti has partnered with Revolution Wi-Fi to release version 2 of the capacity planner, that improves the tool by adding the following features:

Capacity Analysis – visualize network utilization and a breakdown of capacity by client devices with varying capabilities. Analysis data is provided by protocol version, frequency band, application type (bulk data vs. voip/real-time), spatial streams, and channel width. Quickly and easily determine the impact of legacy clients on the network!

Capacity analysis visualizations

Capacity analysis visualizations

Mesh Network Planning – plan 5 GHz single-channel mesh networks to determine how many root nodes are necessary to meet capacity requirements and the per-hop mesh network performance. Use an existing client capacity plan or manually configure mesh network capacity requirements.

Mesh network performance

Mesh network performance

Improved Growth Planning – networks are constantly changing and the capacity plan that you develop today should accommodate future growth. The capacity plan now provides a detailed breakdown of capacity per-radio, including the amount of frequency reuse required to achieve the forecasted capacity, as well as the capacity available for future growth given the client mix modeled by the user.

Capacity breakdown per-radio and future growth analysis

Capacity breakdown per-radio and future growth analysis

Exportable PDF Reports – save the capacity plan data, capacity analysis visualizations, and mesh network plan as a PDF report. Great for project documentation and for communicating with management to explain technical concepts in an easy-to-understand format to influence budgeting and planning.

Capacity reports

Capacity reports

Head on over to the Revolution Wi-Fi Capacity Planner ™ webpage to learn more, download this free tool, and start deploying better Wi-Fi networks! Also, check out the videos that help explain these concepts in more depth.

And stay tuned for more, as Ubiquiti and Revolution Wi-Fi continue to collaborate on bringing Wi-Fi capacity planning enhancements to users!