Researchers from KU Leuven, a university in Belgium, have disclosed a long standing flaw in the way WiFi is secured. The flaw exists in the WPA2 protocol which manages the secure connection between devices and the WiFi network. They have dubbed the attack KRACK which is an acronym for Key Reinstallation Attack. The seriousness of the flaw has caused a chain reaction as technology companies scramble to issue patches to resolve it.
The researchers, led by Mathy Vanhoef, have made it clear that this is not about any one vendor. Instead it is far more serious than that. The flaw is in the Wi-Fi standard. This is a document that will have been poured over by experts and researchers many times. The failure to spot the problem previously will raise questions over how standards are validated.
How bad is KRACK?
According to Vanhoef: “..attackers can use this novel attack technique to read information that was previously assumed to be safely encrypted. This can be abused to steal sensitive information such as credit card numbers, passwords, chat messages, emails, photos, and so on.”
This is not just about the risk to data theft. Vanhoef goes on to say: “The attack works against all modern protected Wi-Fi networks. Depending on the network configuration, it is also possible to inject and manipulate data. For example, an attacker might be able to inject ransomware or other malware into websites.”
It is already a major challenge for web teams to protect against malicious code injection. There is a seemingly endless string of vulnerabilities enabling hackers to compromise websites. This attack raises the threat level significantly. What is critical is that organisations react to patches as they are issued and make sure that they are installed immediately.
This is not just about Wi-Fi devices. It affects operating systems as well. Vanhoef says: “During our initial research, we discovered ourselves that Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys, and others, are all affected by some variant of the attacks. For more information about specific products, consult the database of CERT/CC, or contact your vendor.”
A devastating attack against Android and Linux
To prove that this was not just a paper threat, Vanhoef and his team demonstrated a key reinstallation attack against an Android phone. He said: “In this demonstration, the attacker is able to decrypt all data that the victim transmits. For an attacker this is easy to accomplish, because our key reinstallation attack is exceptionally devastating against Linux and Android 6.0 or higher. This is because Android and Linux can be tricked into (re)installing an all-zero encryption key.”
Vanhoef says that other devices are harder to attack because of the way they encrypt packets. Importantly, while some packets can be decrypted a large number cannot. This limits the full scope of the attack but does not defeat it.
Google has already said that it is working on a patch and will be sending it out to devices in the near future.
KRACK creates 10 new vulnerabilities
As a result of KRACK, CERT has assigned 10 Common Vulnerabilities and Exposures (CVE) identifiers. These can be viewed online and there is more information in vulnerability note VU#228519. This will also provide more details of which devices are known to be affected.
The 10 vulnerabilities and links to them are:
CVE-2017-13077: Reinstallation of the pairwise encryption key (PTK-TK) in the 4-way handshake.
CVE-2017-13078: Reinstallation of the group key (GTK) in the 4-way handshake.
CVE-2017-13079: Reinstallation of the integrity group key (IGTK) in the 4-way handshake.
CVE-2017-13080: Reinstallation of the group key (GTK) in the group key handshake.
CVE-2017-13081: Reinstallation of the integrity group key (IGTK) in the group key handshake.
CVE-2017-13082: Accepting a retransmitted Fast BSS Transition (FT) Reassociation Request and reinstalling the pairwise encryption key (PTK-TK) while processing it.
CVE-2017-13084: Reinstallation of the STK key in the PeerKey handshake.
CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake.
CVE-2017-13087: reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
CVE-2017-13088: reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
Don’t panic
This is a serious security incident and one that has rocked the networking and security world. However, there is no reason for panic and the researchers have done all they can to prevent such a response. This hasn’t stopped PR companies from sending emails to journalists saying things like “The majority of Wi-Fi connections hacked” or “Wi-Fi flaw gives hackers easy access to user data.”
It is essential to realise that there is no evidence of this attack being exploited. In the FAQ at the end of the document detailing the attack (available on www.krackattacks.com) the research team have provided a very good FAQ. Among the questions is has sought to provide guidance on is: “Are people exploiting this in the wild?”
What the researchers say is: “We are not in a position to determine if this vulnerability has been (or is being) actively exploited in the wild. That said, key reinstallations can actually occur spontaneously without an adversary being present! This may for example happen if the last message of a handshake is lost due to background noise, causing a retransmission of the previous message. When processing this retransmitted message, keys may be reinstalled, resulting in nonce reuse just like in a real attack.”
They also make it clear that people should keep using WPA2 not revert to older and weaker protocols such as WEP.
What does this mean
The older a standard is the more likely it is to contain flaws. WPA2 was adopted in March 2006 and since then researchers have developed many new tools to test security. What will worry many researchers is that KRACK should have been detected before the protocol was adopted.
At the heart of KRACK is something called a NONCE. It is a random number that is supposed to only be used once. It turns out that this number can be reused and this is what makes the attack so serious. Researchers approving the protocol should have checked that there was no possibility of reuse. They didn’t.
It will take some time before we know why this was allowed to happen. One possible reason is that once it had been looked at by one researcher, everyone else just signed off on it. This is the same systemic flaw that allowed several vulnerabilities in OpenSSL, such as Heartbleed, to go undiscovered for years.
Once the full details of the failure are in, there will be a need for protocol and standards bodies to look closely at how they work. The security industry is working towards a wider standards driven world. If those standards and the underlying protocols are flawed then trust will be lost and the idea of open and secure networking goes away.
