KRACK vulnerability breaks encryption over every Wi-Fi networks
A new vulnerability in the WPA protocol potentially affecting all Wi-Fi networks has been discovered, its name? KRACK. Back in 2016 Belgian researchers Mathy Vanhoef and Frank Piessens of the University of Leuven had published a research paper; on the 16th October 2017, they published the details about what they call KRACK: multiple attacks to void the encryption provided by the WPA protocol.
KRACK: a match made in airwaves
How many times have you used Wi-Fi? Many, am I right? Now, how many times have you thought you could be spied through Wi-Fi? Not that many, am I right? Well, there are of course unsafe Wi-Fi public networks such as the ones you might find in pubs or cafes. But what if your own Wi-Fi network wasn’t safe? You don’t think that much about this do you? We all know how hard it is sometimes to remember those long “passwords” to access Wi-Fi… That’s probably the WPA protocol or one of its sons you’re dealing with.
The WPA protocol ensures the communication between the access point and the client are encrypted using a cryptographic key. A new research paper has just been published, and it’s worse than we thought: the WPA protocol is insecure at the moment and anyone could potentially read your communications over Wi-Fi protected by WPA. This means the protocol that should protect your communications is flawed.
A KRACK in the air
The worst part about this vulnerability is that it lies in the protocol itself, so every implementations true to that protocol is vulnerable; every WPA or WPA2 network, regardless of the specific settings. The good news is that it is patchable and it mostly affects clients rather than Access Points. Another good news is that the attacker needs to be physically close to carry out the attack.
When WEP was deemed insecure, WPA2 (and WPA) was there to replace it. But unfortunately, we don’t yet have WPA3. According to Mathy Vanhoef, one of the researchers behind the research that led to KRACK, that’s not needed either. The flaw in the protocol can be patched through software. Since most of the KRACK attacks target clients rather than Access Points, the most vulnerable targets are currently smartphones and laptops.
An attacker carrying out a KRACK attack may read all the data sent to/from the client. Once the attack is complete the attacker may be able to deceive the client and make it think he is the access point, rather than the real one. The attacker is now actively listening and will be able to capture all the packages sent/received for later use. This means that all the data sent unencrypted, such as the plain unprotected HTTP, will be readable by the attacker.
Here’s a video demonstration of a type of KRACK attack:
KRACK: are you vulnerable? Which AP? Operating System?
Since the protocol itself is vulnerable, all implementations true to it are vulnerable. All the operating systems are vulnerable, but Android and Linux have been hit pretty hard. On top of that a large amount of Access Point are vulnerable. Here you can find a list of operating system/network providers and their stance on KRACK:
- Android: devices with 6.0 “Marshmallow” and higher are particularly vulnerable, Google is working on a fix but it will take time to work with all the different manufacturers.
- Apple: claims all its operating systems have been patched (no source).
- Cisco: has released a detailed list of affected products.
- DD-WRT: has released a patch, but not all the devices may be protected.
- Debian: has released updated packages for the Debian operating system.
- Fedora: Red Hat has released a patch for the Fedora operating system.
- FreeBSD: has released a patch for its FreeBSD operating system.
- Fortinet: has a security advisory regarding the attacks, latest version of FortiGate/FortiAP/FortiWLC are patched.
- Intel: has released updated drivers for its products.
- Juniper: has a list of affected devices.
- Lineage OS: has a patch, update as soon as possible.
- Linux: is mostly affected through hostapd and wpa_supplicant, patch is available, refer to your distribution for more information.
- MicroTIK: RouterOS is not affected but has released patches to comply with recent guidelines.
- Netgear: has released patches for its devices.
- OpenWRT/LEDE: has a patch.
- RHEL: Red Hat has a page for the vulnerability. A patch for RHEL7 is available, one for RHEL6 is still pending at the moment of this article.
- SUSE: Novell has released updated packages for the SLES operating system.
- Tp-link: is working on the issue.
- Synology: is working on the issue.
- Ubiquity: has released a patch for the Ubuntu operating system.
- Ubuntu: Canonical has released a patch, it should already be installed with latest updates.
- Windows: Microsoft has released a security update for its Windows operating system, if you routinely update your system you should already have it.
- Zyxel: has released a list of devices affected and estimated patch release date.
You can find an extensive list of affected manufacturers here. If you need more information you should get in touch with your product’s manufacturer.
Do I hurry and change “Wi-Fi Password”? Will it protect me?
Absolutely not! The problem lies in the WPA protocol and it doesn’t depend on the key/key size. The best thing to do is to patch all the devices using Wi-Fi.
If you can’t patch your devices since no patch has been released (take a look at the list above), here are a few tips:
- Avoid public Wi-Fis until a patch for your device is released.
- Ensure you’re using HTTPS at all the times using extensions such as https-everywhere.
- Get in touch with your AP manufacturer and ask if a patch is planned.
- Consider using cellular networks on affected smartphones.
Technical details
Our main attack is against the 4-way handshake of the WPA2 protocol. This handshake is executed when a client wants to join a protected Wi-Fi network, and is used to confirm that both the client and access point possess the correct credentials (e.g. the pre-shared password of the network). At the same time, the 4-way handshake also negotiates a fresh encryption key that will be used to encrypt all subsequent traffic. Currently, all modern protected Wi-Fi networks use the 4-way handshake. This implies all these networks are affected by (some variant of) our attack. For instance, the attack works against personal and enterprise Wi-Fi networks, against the older WPA and the latest WPA2 standard, and even against networks that only use AES. All our attacks against WPA2 use a novel technique called a key reinstallation attack (KRACK).
If you want to know more about this new technique, you can head over to the official site or read the research paper.
CVEs
KRACK-related vulnerabilities have been assigned the following CVEs:
- 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.
- 2020 A year in review for Marksei.com - 30 December 2020
- Red Hat pulls the kill switch on CentOS - 16 December 2020
- OpenZFS 2.0 released: unified ZFS for Linux and BSD - 9 December 2020
Recent Comments