Monday, October 16, 2017

WPA, the Krack Attack, and Kismet

The Krack Attack

[ Edited on 2017-10-17 to include definitive information about the ESP chip, additional commentary on TKIP mode, device scanning, and commentary on who it impacts]

[ Edited on 2017-10-19 to include additional info about Kismet alerts and clarification on what Krack is /not/ ]

Of course you've heard about the Krack attack by this point:


I strongly recommend reading the krackattack site, if not the full paper, too: They do an excellent job describing the attack and the real-world impacts. 

Definitely everyone should read the https://www.krackattacks.com/#faq Q&A section first!

What it is

  • A collection of vulnerabilities that impact both access points and clients.
  • A method to decrypt some traffic, and on some specific clients, all traffic.
  • The largest vulnerability in the WPA suite to date, by a wide margin.
  • A very significant attack against Linux, Android, and OpenBSD clients.
  • Something to be concerned about and patch for.

What it isn't

  • A method to expose the WPA key.
  • A method to compromise encrypted communications (VPN, HTTPS, SSH, etc)
  • A method to compromise corporate credentials via EAP (assuming proper client configuration)
  • The end of the world.

How it works

There are many other breakdowns of the attack, including the excellent one on the Krack website itself, but at a 1000-foot-view:

WPA establishes a per-session key via 4-way handshake system which passes a public component of the unique session key (the Nonce).  By creating a fake access point and manipulating the handshakes, it is possible to fool a device into re-using a keystream; given two packets encrypted with the same keystream, it's possible to derive that keystream and decrypt them (but NOT the passphrase, remember).

Some devices have additional vulnerabilities (those using wpa_supplicant from Linux, including Android) which cause them to essentially disable encryption completely - resetting the key to all zeroes.

Detecting Krack with Kismet

The git-master version of Kismet is introducing alerts to attempt to detect a Krack-style attack underway.  To accomplish this, Kismet tracks several things used by the attack:
  1. Spoofed AP/Multichannel AP detection.  Kismet has had a long-standing alert for access points changing channels.  Currently, to manipulate the handshakes, the Krack vulnerabilities clone an access points MAC, but on a different channel.  Kismet will generate CHANCHANGE or BSSTIMESTAMP alerts for the two conflicting access points.  This is likely the most obvious indication that an attack is ongoing, however as the attack is refined in the future it may no longer be obvious.
  2. Key removal/degradation.  This variant of the attack is used against OpenBSD clients, and transmits a handshake with a zero-length key and zero nonce.  Kismet detects this by a fingerprint and raises the NONCEDEGRADE alert.
  3. Nonce retransmission.  Nearly all of the attacks in the Krack suite retransmit a previously used Nonce value, either as the 3rd handshake Nonce, or the first handshake ANonce value.  Kismet tracks the previous 128 Nonce and ANonce handshakes seen, and if a repeated Nonce is spotted, raises the NONCEREUSE alert.
Currently, most of the described Krack attacks - replaying a Nonce against a traditional supplicant - require spoofing the access point.  This should, in almost all cases, cause Kismet to be very noisy regarding the CHANCHANGE or BSSTIMESTAMP alerts.

In the future it may be possible to optimize these attacks so that there is no visible duplicate AP, but the current state of those attacks should be very obvious.

The 802.11r FT injection appears to be much more subtle - and much more difficult to detect, as different vendors implement the IV reset process differently.  Additional research will be needed to create an alert for those attacks.

Weaknesses in detecting Krack with Kismet

To detect the Nonce re-use, Kismet needs to actually observe the handshake packets.  Typically, Kismet channel hops across all channels supported by a card; this reduces the chance that Kismet will see the handshake.

Kismet supports multiple data sources simultaneously - this increases the chance of capturing the nonce, but also can introduce some false positives if two cards see the same packet.  Kismet now has packet de-duplication, which is turned on by default, which attempts to detect identical packets seen by multiple sources; in practice, this system still needs tuning.

The 802.11 protocol allows for automatic retransmit of data frames which are not acknowledged - and EAPOL exchanges are data frames.  This leads to multiple, different copies of the same EAPOL frame potentially being seen - this is exacerbated by the fact that Kismet may see the original, while the receiver may not!  To combat false-positives on EAPOL Nonce replays, Kismet now uses the timestamp of the packet - multiple Nonce or Anonce injects (Frame 1 or Frame 3 of the handshake), with the 'Retransmit' bit set in the dot11 frame control, in a very short period of time (0.1s) will be treated as valid.

Once the proof-of-concept code is release (or alternate proof-of-concept code is developed), the logic of the alerts will need to be tested.

How do I fix it

Generally speaking, the only fix is to upgrade your devices - you'll need upgrades for your access point firmware as well as upgrades to all of your client devices.

If you are using Linux or OpenBSD, fixes for wpa_supplicant should already be available.  Similar fixes are available for Windows 10 and OSX.

If your access point runs OpenWRT or LEDE there may be updated packages available, either through the package repository or by compiling new firmware.

Fixes for Android will depend on the security schedule for your device.  Typically, Google devices get patches monthly, devices from other manufacturers may take longer to get patched.

Kristopher Tate has created a Github repo tracking the update status of various vendors at https://github.com/kristate/krackinfo


Can I just disable TKIP?

While parts of the Krack attack impact CCMP (WPA2), the worst impacts appear to be against TKIP (WPA1).  Many access points support WPA1 and WPA2 simultaneously, which leads to using TKIP as a group cipher (required for clients to send broadcast packets to other clients, regardless of WPA association type).  This has led some people to recommend disabling TKIP as a group cipher in your access point; it is unclear if this is actually successful.  From the FAQ of the Krack documentation:
I'm using WPA2 with only AES. That's also vulnerable?
Yes, that network configuration is also vulnerable. The attack works against both WPA1 and WPA2, against personal and enterprise networks, and against any cipher suite being used (WPA-TKIP, AES-CCMP, and GCMP). So everyone should update their devices to prevent the attack!
This would imply that simply disabling TKIP isn't a silver bullet against the attack, unfortunately.  It may also cause problems with large installations / corporate networks with multiple devices.

Should you care?

This is a significant breach of the WPA security model.  You should care - but only to a point.

If you are responsible for a financial, high-profile corporate, or government Wi-Fi install, you need to care, and be able to explain the risk.  Fortunately, in these situations, you'll also likely have vendors to talk to directly as well as management of the devices on your network.

If you're a home user - probably not.  The chances are, there won't be roving gangs of hooded youths cracking all the WPA networks in the neighborhood. 

In either case: patching is important, and should be done as soon as possible, but the chance that a new WPA vulnerability with no (currently) released code is the weakest point in your network is pretty slim.  Update immediately.  Update your users and customers immediately.  Pressure your vendors to update if they haven't already.  Find the devices on your network which have not gotten updates.


Scanning for vulnerable devices

At this time, there is no simple way to determine if devices are vulnerable, however there should be tools available in the future from the Krack developer which can perform some active probing to determine if a stack is vulnerable.

Currently, the Kismet detections only detect the replay of nonces, and cannot passively detect vulnerable devices; if a method to do so becomes available, it will be included in Kismet.

Detecting vulnerable devices will be a particular problem for anyone who has to manage a BYOD network, where users may continue to bring outdated, vulnerable devices onto the network for the foreseeable future (such as unpatched Android devices).

The risk in the future

When WEP was first shown to be vulnerable, it required the collection of millions of packets over the course of hours or days before it could be attacked.  Once the method was refined, the network could be cracked in a matter of minutes or even seconds.

There is always the chance that this attack, or ones derived from it, will be refined into a much more significant, automated, or wide-ranging attack.  Patching as soon as possible is the panacea against this.

The largest risk in the future is likely to be devices for which no patch is available:  abandoned mobile devices which no longer receive patches from the carrier or manufacturer, appliances and vehicles with Wi-Fi included, and embedded and IOT devices which use a Linux or Android Wi-Fi stack including wpa_supplicant.  As bad, fully embedded systems based on chips like the ESP8266 may also be vulnerable.

The inability to update many devices in the wireless ecosystem means these flaws will persist and remain as potential jumping-off points for more advanced attacks against networks for a long, long time.


No comments:

Post a Comment