258

Today new research was published on vulnerabilities in wireless network security called Krack.

What are the real-world consequences of these attacks for users and owners of wireless networks, what can an attacker actually do to you?

Also is there anything a wireless network owner can do apart from contact their vendor for a patch?

Anders
  • 64,406
  • 24
  • 178
  • 215
Rory McCune
  • 60,923
  • 14
  • 136
  • 217
  • 12
    Is it the devices (phones, laptops etc) or the access-points or both that will need patching? – billpg Oct 16 '17 at 11:02
  • 8
    @billpg - Both. Although they can apparently be patched in a backwards-compatible manner, meaning they don't need to be applied at the same time. – Robotnik Oct 17 '17 at 02:40
  • 12
    As it turns out, we've all been using [Bruce Schneier's configuration](https://www.schneier.com/blog/archives/2008/01/my_open_wireles.html) but didn't know it. I remember the US Army taking a keen interest in the 802.11 standard some time ago, and not to secure wifi at installations (wifi is forbidden for work, even on NIPR, as is carrying a wireless device into a sensitive area at all). It is ridiculous that IEEE's pubished standards are harder to access than the networks they claim to protect. – zxq9 Oct 18 '17 at 09:26

5 Answers5

174

Citing the relevant parts from https://www.krackattacks.com:

Who is vulnerable?

Both clients and access points are listed in the paper as being vulnerable. See the tables 1 and 2 on pages 5 and 8 for examples of vulnerable systems, and table 3 on page 12 for an overview of which packets can be decrypted.

The weaknesses are in the Wi-Fi standard itself, and not in individual products or implementations. Therefore, any correct implementation of WPA2 is likely affected. [...] 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.

What is the impact?

  • adversaries can use this attack to decrypt packets sent by clients, allowing them to intercept sensitive information such as passwords or cookies.

  • The ability to decrypt packets can be used to decrypt TCP SYN packets. This allows an adversary to [...] hijack TCP connections. [An adversary can thus inject] malicious data into unencrypted HTTP connections.

  • If the victim uses either the WPA-TKIP or GCMP encryption protocol, instead of AES-CCMP, the impact is especially catastrophic. Against these encryption protocols, nonce reuse enables an adversary to not only decrypt, but also to forge and inject packets.

  • our attacks do not recover the password of the Wi-Fi network

(Emphases mine.)

Can we patch it (and will we have incompatible APs/clients)?

There is a fix for both APs and clients, it doesn't matter which one you patch first.

implementations can be patched in a backwards-compatible manner [...] To prevent the attack, users must update affected products as soon as security updates become available. [...] a patched client can still communicate with an unpatched access point, and vice versa.

However, both client and router must be patched (or confirmed secure):

both the client and AP must be patched to defend against all attacks [...] it might be that your router does not require security updates. We strongly advise you to contact your vendor for more details [...] For ordinary home users, your priority should be updating clients such as laptops and smartphones.

How does it work?

When a client joins a network, it [...] will install this key after receiving message 3 of the 4-way handshake. Once the key is installed, it will be used to encrypt normal data frames using an encryption protocol. However, because messages may be lost or dropped, the Access Point (AP) will retransmit message 3 if it did not receive an appropriate response as acknowledgment. [...] Each time it receives this message, it will reinstall the same encryption key, and thereby reset the incremental transmit packet number (nonce) and receive replay counter used by the encryption protocol. We show that an attacker can force these nonce resets by collecting and replaying retransmissions of message 3 of the 4-way handshake. By forcing nonce reuse in this manner, the encryption protocol can be attacked, e.g., packets can be replayed, decrypted, and/or forged.

Is there anything a wireless network owner can do apart from contact their vendor for a patch?

As mentioned, WPA-TKIP or GCMP are slightly worse, so make sure you use AES-CCMP for the lowest impact -- if your router allows you to choose that (many don't). Other than that, you can't truly mitigate it on a protocol level yourself. Just update as soon as possible.

Generally, use HTTPS for anything that needs to be secure (you should do this anyway, also over ethernet, but especially over Wi-Fi now), use a VPN as an extra layer, etc.

Luc
  • 31,973
  • 8
  • 71
  • 135
  • Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/67232/discussion-on-answer-by-luc-consequences-of-the-wpa2-krack-attack). – Rory Alsop Oct 17 '17 at 14:28
  • 1
    Where do you see that this attack requires e.g. HackRF or wifi adapters with modified firmware? – user2497 Oct 17 '17 at 16:02
  • ^ Would also like to know the answer to this, none of the sources I've read on this have made mention of that part. – Hashim Aziz Oct 17 '17 at 20:21
  • 1
    @Hashim I read it in a Hacker News comment by someone who sounded like it made sense (I forgot which one it was exactly). Trouble is, it's hard to search for and I don't hear anything to the contrary. Guess I'll remove it until there is clearer evidence. – Luc Oct 17 '17 at 22:00
  • 3
    I'm 95% sure HackRF is not required. This is the same as capturing wifi packets with airmon-ng and forging packets with python to go out an interface. – Tim G Oct 18 '17 at 00:06
  • 1
    I thought this website was informative: https://documentation.meraki.com/zGeneral_Administration/Support/802.11r_Vulnerability_(CVE%3A_2017-13082)_FAQ . It appears that APs are affected only if 802.11r fast roaming is enabled. So if my client is patched, and 802.11r is disabled, I don't need to update my AP- is that correct? – Mike S Oct 18 '17 at 15:23
  • I just want to emphasize that **if you use a VPN (such as L2TP) that authenticates the server via a pre-shared key, then USE A CRYPTOGRAPHICALLY SECURE PASSWORD!** Otherwise the attacker can pretend to be the server, "authenticate" you, and then MITM you... – user541686 Oct 19 '17 at 08:26
  • 1
    If I do not broadcast my SSID (I think thats what its called), does that help protect against this sort of attack? It does not show up as available WIFI to devices and I must enter the wifi name and password but I am thinking the WIFI signals can still be detected and intercepted. – Joe Oct 19 '17 at 14:58
  • 5
    @Joe No, it does *not* help. It's a little like trying to remain anonymous at a conference by not wearing a nametag, while people still call "hey Joe!" all the time over at least 20 meters of distance. – Luc Oct 19 '17 at 17:24
  • @TimG That's what I read too. You are man in the middle of an encrypted connection trying to guess the password still. I think there might be an oversimplification too. Isn't the REAL encryption key the first and last thing sent with the established PTK? – BenPen Oct 19 '17 at 22:31
  • "_use HTTPS for anything that needs to be secure_" I think this should read "use TLS for anything that needs to be secure" – curiousguy Oct 22 '17 at 00:42
  • 3
    @curiousguy Not only tech people read posts like these, that's why I consciously chose to use https instead of ssl/tls/encrypted connections/whatever. Https is very tangible and a clear example. – Luc Oct 22 '17 at 11:43
  • *"If the victim uses either the WPA-TKIP or GCMP encryption protocol"* - who must support these protocols? Client, AP or both? – Smit Johnth Nov 11 '17 at 23:02
  • @SmitJohnth The AP advertises support, and the client picks which one it wants to use. If the AP does not support TKIP, then a client cannot negotiate with TKIP. – forest Aug 06 '18 at 22:14
13

What are the real-world consequences of these attacks for users and owners of wireless networks

Already a great answer here, but thought I would add my viewpoint to a part of it. There have been a lot of "sensationalist" headlines and misinformation in recent days that portray this vulnerability as much more serious than it really is.

Ultimately, this vulnerability, while very serious, will have very little impact on the day to day of most users and I don't expect to see this exploit much "in the wild." Frankly, there are far too many open networks that are much easier to exploit for an attacker to gather personal information.

The attack vector using KRACK is simply too small (and will continue to decrease) to make these attacks widespread. There are 10 CVEs associated to this vulnerability, 9 client related and 1 infrastructure related. Patching the infrastructure mitigates 8 of the CVEs (including the most serious) mainly leaving client-to-client connections vulnerable (when was the last time you used and ad-hoc or Wi-Fi Direct 802.11 connection?). Patching the client mitigates all but the infrastructure CVE. Don't want to patch the OS? Patching even the network driver on the client will mitigate at least 2 of the CVEs.

Two of the biggest target operating systems, Windows (7+) and iOS (10.3.1+), were not vulnerable on day 0 unless on a network with 802.11r (fast roaming/transition) enabled. Of those two, Windows already had a patch released over a week ago. Patches are also out for most of the common flavors of Linux and in beta for all Apple OSes. You can expect most of the current mainstream operating systems (and nearly all the Linux variants) to have a patch released within a couple weeks. All in an age where OS upgrades are easier and more automated than ever.

This leaves the legacy operating systems and IoT to consider. Fifteen to twenty years ago, legacy devices would have been much more of a concern but today with commodity electronics that are much cheaper and often replaced every couple years (if they last that long), we have a much lower percentage of "old" devices hanging around. For the IoT? If you really want to watch my lights (or whatever) turn off and on, please feel free. Yes there is potential for more meat on the IoT bone, but mainly only in very limited corner cases and not to the average user.

When it comes to 802.11r, most consumer access points (aka "routers" by many) simply do not support 802.11r. Vendors tend to see little value in adding support for it when the majority of their equipment is deployed to environments where it is the only wireless AP. Single AP means no roaming which certainly precludes the need for fast roaming and also means no patch needed. Of the ones that I have seen that support it, most have 802.11r disabled by default (primarily due to issues some clients who don't support 802.11r have with it).

802.11r is much more widespread in multi-AP deployments and most of the common vendors for such environments (Cisco, Aruba, Ubiquiti, Ruckus, Aerohive, etc) have patches out already for some or all of their devices. These are also the environments that are more likely to have paid staff or support consultants that are aware of this exploit.

Many "high value" targets are also out as they enforce the use of multiple layers of encryption when using wireless. Yes, you can break the 802.11 encryption, but not the VPN encryption in use on the connection or the HTTPS traffic within the VPN tunnel. Targets that depend on keeping their data secure aren't trusting to encryption that only covers from the client to the AP.

Even targets that aren't high value are often using other encryption without any change in behavior. Most "big" websites already push all their traffic to HTTPS as do most sites handling any sort of financial or personal information.

To perform many types of MitM attacks (which really require bidirectional control), an attacker needs to have targets that are either using GCMP or have both using 802.11r and clients with the 4-way handshake vulnerability. GCMP isn't common yet and we have already hit on 802.11r and client patching. So while the MitM demonstration shown as a proof of concept is impressive, the real world implications are fairly limited.

If you understand this vulnerability enough to exploit it successfully, you will quickly realize what I already mentioned above....it is much easier to exploit the many open wireless networks that exist all around us.

YLearn
  • 3,967
  • 1
  • 17
  • 34
3

anything a wireless network owner can do ...?

If the devices themselves form a sort of unknown "man-in-middle" potential attack, a network owner can caution clients to consider using VPNs, Tor proxies, https, ssh, and various other encrypted software-based networking methods that prevent a potential WPA2 middleman/eavesdropper from being able to derive much advantage it.

agc
  • 131
  • 4
  • 1
    This makes another sort of high value target, since the Proxy or whatnot has session establishment too, but encrypted setup of this VPN/Proxy connection under WPA2 survives everything but the dictionary attack. KRACK is a bit oversold for everything but Linux/Late Model (6.0+) Linux. It boils down to having to derive the key by cracking for everyone else, with a bit of a statistical edge. – BenPen Oct 19 '17 at 22:29
3

"What can a Wi-Fi user do?" Get loud with their ISP and hardware manufacturers. This failure has been known for a considerable amount of time, yet I'm not finding people who are even aware of the problem, let alone have read the excellent paper.

Maddening that on Oct 18, I talked to an Apple Retail employee about my concerns. He said that it "sounded technical" and I'd need to make a Genius Bar appointment to talk with someone, but it wouldn't be before tomorrow.

The same day, a doctor who uses her phone to process CC payments was unconcerned, saying only that "We do a lot on the Internet these days."

On the 19th I talked to a ISP tech doing an onsite here. He hadn't heard of KRACK. It was unpleasant to have him act condescendingly to me. SE user Dale Wilson posted this paper by Mathy Vanhof here two days ago-an excellent resource with diagrams.

We took our wireless out of our network for the moment, as we can sneakernet or Ethernet cable the key machines I want locked down. It is time to find a bona fide VPN; meanwhile, I'll be interested in the fix.

MACer
  • 31
  • 2
  • 5
    Don't get too worked up over this, the press makes it sound worse than it currently is. For example, most consumer "routers" don't have 802.11r enabled as they assume a single device and therefore don't need fast roaming. This means many consumer "routers" running stock code and not acting as repeaters aren't vulnerable. A doctor using a phone to process CC payments is almost guaranteed to be using some form of HTTPS for the transaction. I don't expect a retail employee or onsite ISP tech to know more than I generally do on any given day. No need to disable your wireless, just use HTTPS/VPN. – YLearn Oct 20 '17 at 03:30
  • The lone exception to YLearn's tempered view of the vulnerabilities is Android 6.0/7.0. There will be unpatched android devices running around until the end of time. These two versions have such a horrid vulnerability. If you are a high value target, and if your vendor doesn't patch soon, do a risk assessment on your unencrypted traffic. As stated elsewhere, for all high value uses you should consider implementing an internal VPN for use within your WiFi encryption to bridge your traffic over to wired at an invulnerable point in your network. Then only device takeovers matter. – BenPen Oct 20 '17 at 17:47
  • Also, if you were immediately concerned when dealing with critical data, it's currently safe to send it over your cellular data connection too, if you turn off your WiFi. But over all, state sponsored hackers drool over being able to access cellular data, so keep your ears open... – BenPen Oct 20 '17 at 17:51
  • @BenPen, agreed to an extent. However even those Android devices on a patched 802.11 network are limited in impact. At worst then the broken encryption is only one way, which severely limits what can be done with the vulnerability. Combined with the high (and increasing) percentage of patched wireless clients that will be out there and the easy availability of open networks will generally make this attack a lot of work for very little gain barring specific targeted attacks. – YLearn Oct 20 '17 at 19:56
  • AH, right, one way. And the good stuff you send out is likely to be https anyway. Sure. And if you don't KNOW what data you want, it's not very useful. Drop your middle man in a useful area to target a company and hope, though I suspect certificate based authentication makes it hard to talk with the official network as a middle man with the 4way handshake exploit... The world isn't going to end until someone finds a tasty something to go along with this. It sounded bad originally though. splash splash. – BenPen Oct 22 '17 at 00:30
  • @YLearn was this the same guy with the ridiculously brute force ssl key attack (I forget the details..) where you had to learn each character by brute force one at a time? This guy was very lucky to find the Android 6/7 bug at the same time, without a cleartext demo, this wouldn't have been that compelling. – BenPen Oct 22 '17 at 00:44
  • On the other hand, this is JUST the sort of thing that state intelligence operations would love. Good to have one of those out of service I guess. – BenPen Oct 22 '17 at 02:31
0

What are the real-world consequences of these attacks for users and owners of wireless networks, what can an attacker actually do to you?

Nation states are no doubt already developing offensive capabilities to exploit this; I expect some have already succeeded. The very first victims will likely be high-value government and military targets that haven't had time to do their initial round of patching.

Right now, nobody is aware of the attack being replicated in the wild, so there is still a brief sense of peace. During this time large enterprises and security minded enterprises will have the impetus and funding to get their equipment up to date. But many small to medium sized organizations won't have the budget to upgrade their older systems, so they'll have a lot of unpatchable and vulnerable devices for the foreseeable future.

Once exploit code is developed, it will probably quickly become available on the dark web. We'll probably see the first public attacks on low-risk, low-value soft targets.

A short while after that we should expect to see an increase in ordinary penetration attacks focused on vulnerable routers and access points. Attackers will attempt to use these victim access points to remotely KRACK devices belonging to neighbors of the victim, gaining access to a broader array of victims.

John Deters
  • 33,650
  • 3
  • 57
  • 110
  • KRACK has no effect on "open networks" so it will never be used on such "soft targets." As for attacks on "routers and access points," your description is seriously flawed. KRACK doesn't give you access to a network, it doesn't reveal the PSK or credentials of an authenticated device. Additionally, most consumer "routers" aren't capable of using 802.11r so they are not vulnerable to KRACK at all. Ultimately because we will see the majority of client devices patched in relatively short time, there likely won't be much focus on exploiting this in the wild unless other vulnerabilities are found. – YLearn Oct 20 '17 at 05:29
  • @YLearn, good point about open networks! However, you missed the point about home routers: the bad guys aren't going to use KRACK against your home router, they are going to use normal penetration attacks to subvert your home router to perform a KRACK attack against your neighbor's WiFi devices. – John Deters Oct 20 '17 at 11:59
  • What you describe is unlikely. First, the attack vectors to exploit KRACK are limited and shrinking as systems get patched. Second, to exploit KRACK by any current method requires close proximity to the client which with the exception of multiple unit buildings will be rare. Third, any such use of the compromised AP will prevent it from providing service, revealing itself as compromised. What serious attacker is going to risk exposing a compromised AP (where information is certainly compromised) for the dubious chance of maybe compromising connections for neighboring devices with dubious info? – YLearn Oct 20 '17 at 19:19