Facts About the WPA/WPA2 Flaw: The KRACK Attack
I'd like to highlight some things about the KRACK attack. Regarding The Straits Times article "Security Flaw Prompts Fears on Wi-Fi Connections", it is important to highlight some very major facts about the WPA/WPA2 flaw in order not to spread unnecessary fear, uncertainty and doubt (FUD) among less-security-savvy individuals and organisations:
The KRACK attack is a single-session attack (particularly if you are looking at the injection and replay variants) against a session setup between the wireless client and the access point that seeks to capture or modify an attacked user's traffic flow. Therefore, it does NOT result in the WPA/WPA2 password of the user as set on the access point or client-side computer being revealed.
As I have explained to attendees of the technical OSSA and OSWA classes that I have delivered over the last 5 years, such then-future-at-that-time attacks against the WPA/WPA2 protocol can be mitigated by using payload-level encryption at the upper protocol layers (either the network layer 3 or application layer 7) such as IPSEC (what we call VPN-over-LAN or VPNoL), TLSv1.2 (i.e. what the public knows as HTTPS), or application-layer encryption such as PGP/GPG and so on. An attacker can only steal what he can decrypt and see. Though the KRACK flaw allows an attacker to decrypt, capture and inject wireless frames to see the wireless IEEE 802.11-based traffic payloads, IF the user uses the aforementioned mitigations (i.e. IPSEC for enterprises, TLSv1.2 for web transactions and PGP/GPG for file attachment transfers, etc), the KRACK flaw WILL NOT result in any sensitive data being discovered, exploited and/or manipulated by an attacker because what the attacker will capture and see after decrypting at the IEEE 802.11-level is further encrypted upper-protocol data within the payload of the decrypted IEEE 802.11-based frame. Such defences would then require the attacker to daisy-chain and perform further more complex attacks against different protocols to be able to see the plain-text data such as passwords, file-contents and transactional data.
Using the mitigations described in point 2 above (see my earlier preceding post #1), WiFi individual and user organisations can mitigate not only this WiFi-specific protocol weakness but any future yet-to-be-discovered WiFi-specific protocol weaknesses as well. While some may argue that HTTPS-based protection can still be bypassed, it is currently only possible in situations where TLSv1.2 and the recommendations of the OWASP are not implemented correctly. Therefore, as cybersecurity-practitioners, we must ensure that we do not spread unnecessary FUD; We must treat and address every flaw based on the actual facts and an understanding of how the different layers of the OSI 7-layer model can work in conjunction with each other to mitigate such layer-specific vulnerabilities while vendor or protocol patches to fix the root cause are in development.
Contributed by Julian Ho, THINKSECURE(r) PTE LTD