KRACK - It's Not As Bad As You ThinkBy Tom Carpenter On 10/18/2017 - 100 Comments
The recent reveal of the key reinstallation attack (KRACK) caused much stir in the wireless LAN community. This post addresses the reality of the attack, what should be done immediately, and lessons we should learn from it.
KRACK (key reinstallation attack) was widely published this week and is based on previously available information hinting at its potential. KRACK is not a hacking tool, but is a collection of vulnerabilities that will eventually be exploited by hacking tools. It exposes a weakness in 802.11 WLANs that should be addressed and can be addressed through patches and firmware upgrades from AP and client vendors. First, some basic details on the attack.
KRACK is in the category of a replay attack. Replay attacks are used to inject information into communication streams, to execute previously used authentication packets, and other actions. In the case of KRACK, it is used in relation to the 802.11 4-way handshake. The 4-way handshake is an exchange of four messages used to properly install encryption keys for communications between two devices and transfer group encryption keys for use within a WLAN by broadcast and multicast communications.
To execute a KRACK attack effectively a Man-in-the-Middle (MitM) attack is launched to perform the reinstallation. A MitM attack occurs when the attacker inserts the attack machine between two devices and receives all communications from both directions and also modifies information using various methods. In wireless, it is typically performed with a spoofed AP (an AP configured to look like the real thing).
A total of ten vulnerabilities impacting Wi-Fi in various ways were documented with the release of the KRACK information. One of these is AP-related and the others are client-related. The AP-related problem is easily fixed with vendor patches and many vendors have already released those patches. The client problem can also be fixed with patches, but this will take much more time and, in some cases, where vendor support no longer exists (the vendor has gone out of business or simply no longer supports the old device) they may never seen an actual patch.
NOTE: In the real world, the vulnerability in Android clients is the most important. It is not Android-specific, Linux clients using similar software are also vulnerabile if not patched, but Android devices make up the bulk of clients impacted by the vulnerability that allows the installation of an all zero key, effectively removing encryption from that client's link. Make sure you apply patches for your Android devices when they are available. If you aren't seeing them, contact your vendor and encourage all your friends to do the same until a patch is available.
The reparation process requires patches on both the APs/wireless infrastructure and clients. Apply AP patches as soon as they are available and most of your enterprise data concerns are gone. Apply client patches to protect your clients whether they are on your network or another network. Where client patches are not available, encourage the use of VPN connections on all public hotspots (I use these anyway) and you will have protection for those clients as well.
In the end, KRACK should be a reminder to us that security awareness, vulnerability testing, and response plans should be part of every secure implementation. When it is, you have a plan to respond to such incidents. Fear need not rule the day and actions can simply be put into place to begin problem remediation. Having a response plan is a far more peaceful road to travel than not having one.
In this post, I've attempted to give you a high-level overview of the issue without getting into technical details. If you want the technical details, view the Revolution Wi-Fi blog here: WPA2 KRACK Vulnerability.
Vendor patches are simply too many to list within just three days of the announcement of KRACK. This is good news. Check with your vendor to ensure they have provided patches for this, including patches for 802.11r roaming if it is used on your network.Tagged with: KRACK, security, WPA2, WPA, PTK, GTK
Blog Disclaimer: The opinions expressed within these blog posts are solely the author’s and do not reflect the opinions and beliefs of the Certitrek, CWNP or its affiliates.