On Oct. 16, researchers announced security flaws in IEEE 802.11 wireless (Wi-Fi®) networks. The flaw appears to affect nearly all wireless clients, and it is usually implemented by the operating system vendor. All major operating systems’ clients are vulnerable, with varying degrees of impact. Specifically, the flaw affects the handshake processes defined in the robust security network association (IEEE 802.11i-2004), or what is commonly known as “Wi-Fi Protected Access 2” (WPA2) from the Wi-Fi Alliance.
What's the Issue?
The most notable issue is the discovery of flaws in the way the client (supplicant) handles the replay of data packets from the access point (authenticator) during the four-way handshake process. The flaws affect networks using pre-shared keys as well as enterprise networks performing IEEE 802.1X authentication. In most circumstances, an attacker might be able to decrypt arbitrary packets from the victim client. If the transport protocols are secure – such as those employing cryptographic protocols – the data would still be encrypted to the attacker. In some circumstances, attackers might be able to decrypt and inject traffic in networks using older encryption. The mishandling of replayed data packets is both an oversight in strictly specifying the client's state machine in the 802.11 standard, as well as a failure of client software to implement declarative statements in the 802.11 standard.
Additional attacks were found in the PeerKey, group key, and fast basic service set (BSS) transition handshakes as well. Together, the authors of the research refer to these as key reinstallation attacks (KRACKs). These vulnerabilities allow the key stream to be reset and allow cryptographic replay attacks through the reuse of cryptographic nonce values. Reuse of nonce values is prohibited in the protocol, but when poorly implemented by client software, it does not handle this situation appropriately. According to Mathy Vanhoef’s research, the execution of the attacks required a man-in-the-middle attack. The fast BSS handshake does not require a man-in-the-middle attack, so it is even more vulnerable to the KRACK attack. That extra step can be removed, adding to the complexity of this attack.
The authors have been working with major software vendors to fix the flaws over the past several months. Major vendors have already released fixes to their wireless clients. Of the software that is vulnerable, the platforms of most concern are Android™ and Linux™, which rely on the wpa_supplicant client code. The wpa_supplicant was found vulnerable to all of the KRACK attacks and in some versions even allows a key with all zeros to be reinstalled. Client software on Apple iOS™ and Microsoft™ Windows™ operating systems appears to be the least affected, only allowing the group key handshake to be attacked. It is worth noting that the group key, shared by all clients, was already a known concern in WPA2.
Who's Affected?
Any organization with wireless networks should be concerned. Vanhoef, who discovered the KRACK attack, stated it simply: “… if your device supports Wi-Fi, it is most likely affected.” Several resources exist for organizations to determine if they have been affected. The Carnegie Mellon University Computer Emergency Readiness Team (CERT) offers this list of vendors that might or might not be affected.
What Should Organizations Do?
Well-managed security programs should be well equipped to handle the challenges posed by these attacks. The WPA2 protocol is still considered the most secure wireless authentication and encryption standard available, and there is little reason to panic.
The Wi-Fi Alliance has already issued a statement and is taking steps to ensure Wi-Fi networks will continue to deliver secure wireless connections. Organizations should begin to inventory their wireless clients and identify vulnerable software. They should also keep an eye on the Common Vulnerabilities and Exposures (CVEs) and affected vendor lists to make sure timely patches are being issued for their devices.
Major software vendors are already releasing software patches to address the attacks against wireless clients. Microsoft has issued a patch and Apple has confirmed that a fix is already in the beta releases for its iOS, macOS®, watchOS®, and tvOS™ operating systems and will be provided in their next release. Patching older Android and Linux clients might prove difficult, and organizations relying heavily on devices running these clients (such as printers, touch screens, televisions, and security systems) should begin to identify these devices and create a plan to manage their risk.
Problems will arise for organizations with a weak patching process. Some clients might not fit into the common patch process, and that will present additional challenges for organizations. The greatest impact will be felt in cases in which a large number of distributed wireless devices are combined with devices that are not easily patched, such as embedded systems, healthcare, industrial control systems (ICS), and supervisory control and data acquisition (SCADA) devices. Planning how to update wireless devices that fall outside an organization's common patching process should begin immediately.
General security recommendations for 802.11 wireless networks have not changed. Organizations should continue taking the following steps:
- Use WPA2 to secure wireless networks
- Disable WPA and Wired Equivalent Privacy (WEP) support
- Disable TKIP (RC4) encryption
- Require CCMP (AES) encryption
- Physically secure wireless equipment
- Enable 802.1X authentication
- Use certificates to identify the official network
- Train users to spot rogue networks
To address the issues with these latest attacks, organizations should immediately perform the following until a fix is implemented:
- Disable support for 802.11r (also called fast roaming or fast BSS transition)
- Disable support for GCMP (AES) encryption
For organizations that use WPA (not WPA2), allow TKIP encryption, or allow GCMP encryption, immediate changes may be needed to protect their wireless networks. The context of a network's contents and an organization's ability to secure the network both physically and above the transport layer will also factor in. The use of TKIP is long deprecated, but some organizations continue to allow its use to maintain backwards compatibility with older clients.
Lastly, organizations can take several steps to harden networks and devices to make sure this attack is further mitigated:
- Determine if SSL certificates are being used. Secure sockets layer (SSL) and transport layer security (TLS) are cryptographic protocols used in conjunction with several services. The most common one is hypertext transport protocol (HTTP) used for website URLs. SSL and TLS can help ensure that protocols such as HTTP Secure (HTTPS) are still encrypted, even if an attacker was able to conduct a KRACK attack.
- Remove HTTP and force redirection to HTTPS if available. After ascertaining if SSL and TLS are being used, make sure they are configured correctly. SSL and TLS should always be used, especially when submitting sensitive data. Make sure the website’s certificate is configured correctly and signed by a reputable certificate authority (CA). Consider using browser plug-ins to support the use of encrypted communication (for example, HTTPS Everywhere). In the event an attacker was able to conduct a KRACK attack and attempted to force the use of clear-text HTTP via SSL Strip attacks, then the user, at the very least, would receive a warning that their communication might be intercepted.
- Use HSTS on all websites. HTTP Strict Transport Security (HSTS) is an even more elegant solution for enforcing the use of HTTPS. HSTS is a security header that can be added to web applications to help ensure HTTP is not used. When a browser visits a website with HSTS enabled, the browser will send all communications through HTTPS.
- Use a virtual private network (VPN). A user can also use a virtual private network (VPN). A VPN is a protocol used to create an encrypted tunnel between a private network and a public network. In essence, it allows a user to send traffic on a remote private network through the current network via an encrypted tunnel. If a VPN is being used, and the VPN private network is not compromised, then a man-in-the-middle attack would not be possible on the user’s device. The user just has to make sure that the VPN connection is active and is not being dropped when submitting sensitive data.
- Use a wired network. An even simpler solution is to not support wireless networks at all. If an attacker does not have a wireless network to attack, then users are protected from KRACK attacks.
- Segment wireless networks. If a wireless network is required, it should be segmented from the business network. Guest networks should always be used to help ensure packets aren’t being sniffed or changed on business devices. This also provides the additional protection of segmenting attackers from having direct access to an organization’s other devices.
Stay Proactive
In cybersecurity, vigilance is key. Staying abreast of cyberattacks is important, but organizations that take a proactive approach to cybersecurity – instead of only reacting to the latest event – will be better prepared when the next attack hits.
Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corp. in the United States and/or other countries.