KRACK WPA Vulnerability - Key Reinstallation AttaCK

TL;DR at the end.

Short summary

It is a new vulnerability in the WPA handshake implementation that allows in certain cases to decrypt a lot/all the WPA traffic without knowing the key (and it won't reveal the key).

Most devices are affected but Linux and Android are most affected. Patching will fix the issue.

The attack works if you are connecting to a legitimate access point, which means the attacker has to be in range of both devices. If you are far away from your legitimate AP (such as traveling), it won't affect you.

Proof of concept code (to test the vulnerability) hasn't been published yet.

Who needs to worry?

Businesses and governments are more likely at risk due to (trade) secrets and personal information they handle.

Even though your device(s) are most likely vulnerable, there is no reason to worry. It is a bad flaw but the chances of having it exploited is rare, especially considering the PoC hasn't been published yet.

To put it in comparison, there are still WEP access point around but that doesn't mean they are attacked all the time. However, it isn't a reason to keep vulnerable stuff around, fix (or replace) them.

More details please

• A very detailed website
• Original paper

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.

CWE

• CWE-323: Reusing a Nonce, Key Pair in Encryption

You might also want to check out Ars Technica (even though their title is a bit dramatic in my opinion), US CERT advisory which includes some affected vendors and the FixKrak website.

How to test it?

Mathy Vanhoef, the author of this vulnerability, posted tools on his GitHub to test AP/client vulnerability.

How to fix it?

Update (or patch) your systems when updates are available, plain simple (and keep them up to date).

Some vendors as well as some Linux distributions already provided a fix and if you keep your devices up to date, then they should already be patched. For other devices, you are dependent on the vendor to provide a patch.

If your (vulnerable) device is End of Life, it might be a good time to replace it (it is probably not be the only vulnerability in it).

A list of vendor responses is available here and here.

TL;DR

Don't worry, another day, another vulnerability. Just patch/update your stuff (computers, cellphone/tablets, AP/routers, IoT) and keep them updated. Businesses/governments should contact their vendors for a patch/press release regarding the vulnerability (devices are not always vulnerable) and if you are running an EoL device, it might be a good time to replace it.

On drivers, rtl8812au, WN722N, monitor mode, QCA6174, other news and status of linux-backports aka compat-wireless

When discussing in the forum/IRC, it feels that I'm repeating the same things again and again.

I deal with Wi-Fi, play with packets and develop around it every day so all that stuff is fairly easy for me but I realize it is not always obvious. Some of it is because a quick search in THE Google ;) or the Aircack-ng forums or Kali forum would give you the answer.

So here is a summary of some of the things I can think of.

Using another driver

I sometimes see questions or statements like this "This Broadcom driver doesn't work in AP/monitor mode, can I use ath9k for my (Broadcom) card?" or "Can I just use the Airpcap driver to get monitor mode in Windows?"
The answer to both of those is no. Drivers are made for a specific chipset (which is integrated on a wireless card) or a bunch of them that behave similarly.

Some will say this is wrong and they are partially correct: the only choice you have is pretty much VENDOR_DRIVER or open source driver. Where the VENDOR_DRIVER doesn't support monitor mode, so it is out of question. Yes, VENDOR_DRIVER sometimes can be made to support monitor mode, but they won't do it out of the box. Spoiler alert: manufacturers don't care about monitor mode.

You can't just use another driver because the other work better. If you look at the internals in the code, you will see they all are very different. Some of them even require a firmware (and even a specific version) to be loaded so they can work.
Most firmwares are closed source, so if a card behave badly or crashes, the only thing that you can do is bother the manufacturer to fix it, Linux kernel driver developers often can't do much about it.

If you feel adventurous, start developing or fixing bugs in the wireless drivers, Linux kernel developer always need help. If you can't, search and report bugs and provide useful information.

Driver not working for card

This issue got exacerbated recently with rtl8812au and newer cards being released. If you look at drivers, you'll notice that they contains a list of USB IDs (or PCI ID if it's linked to the PCIe bus) for the known cards using the driver.
When a card is plugged on the system, the kernel read its ID and matches it with the appropriate driver.

Developers have a limited set of cards they can test stuff on and new cards with different IDs get released from time to time. So, a driver, even though it will work with a specific card will not be loaded and attached to the card because it doesn't have the IDs. Even if you force loading the driver (modprobe/insmod), it will not work.

An update of that ID table is required to support the new card as well as the driver to be recompiled.

rtl8812au support

The driver, from astam, which is also built as a package for Kali, supports monitor mode and injection.

This driver, as is, will most likely never be supported by airmon-ng. The reason is that it is kind of a Frankenstein driver and it doesn't behave the same way any other driver does. It mixes the old ieee80211 stack and the newer mac/cfg80211 stack.

Aircrack-ng tools can be used with it as long as it is in monitor mode but putting it in monitor mode is done in an usual way (check out the README.md on their GitHub for details in the link above).

Embedded chipsets

Those are tricky and most of them won't support monitor mode and even injection. The reason behind it is those need to use as little power as possible, so your phone can last longer.

With a few exceptions though:

• Raspberry Pi 3 or zero Wireless using Nexmon drivers: monitor mode and injection. For those who played with Kali images with the NexMon driver, if you download the current version of airmon-ng (in our subversion repository), it helps putting the card in monitor mode (even though it's an easy command, it's one less command to remember.
• Nokia N900: Capture and injection in 802.11bg (no n). With a 5000mAh battery and capturing 802.11 frames, the battery will last at most 4 hours and the chip emits a decent amount of heat. That 5000mAh battery usually gives 4-5 days in normal use.
• G1 (I think): same driver as N900 AFAIK.
• ESP8266 (and similar): they seem to support 802.11n in monitor mode (and limited injection?) but those are Arduino-type boards with a 802.11n chip.

So, to sum it up, your Android will most likely not have monitor mode (if you want it, you'll need to use NetHunter and a compatible card).
If you're using iOS, forget it, Apple doesn't care about it, that will never happen.

Monitor mode

We often see people wondering why they can't catch a handshake or data or see any traffic even though their device is connected. What happens is that the card you have probably doesn't support capturing in the mode your connected device is using. Some card that advertise 802.11n/ac capabilities sometimes cannot capture in that mode (and you are limited to 802.11bg), this is either a limitation of the driver/firmware.

802.11n/ac adds some more complexity: it might also not have enough streams (remember those 2x2, 1x1, 3x3?) to capture it: If the station is using 2 stream to send/receive data to the Access Point and your capture card is 1 stream, assuming it can capture in n or ac, will not be able to see the traffic.

There are other possible issues but those are the most common explanations.

QCA6174 (ath10k)

In summary, that card is a PoS. Firmware crashes very often (even for normal operations that would work with any other card) and it is very unlikely it will be fixed. It supports monitor mode but will not give a single packet.

The firmware being closed source, kernel developers are pretty much giving up on that specific chipset.

Ath10k, most of the time, work fine but this specific chipset is doomed. Throw it away and switch to ath9k compatible card, you won't regret it (or just use a supported USB card).
Or if you want to stick with it, you can bother Atheros (now Qualcomm) about it.

TP-Link WN722N

TP-Link recently released a new version of the card (with a different chipset, some Realtek IIRC) and when you buy this card, you don't get the AR9170 chipset (ath9k_htc) anymore.

For those using it in AP mode (as well as any other card using ath9k_htc driver), it has a limitation in the number of stations it can handle (between 5 and 8). It is a physical limitation, not the driver.

Linux-backports, aka compat-wireless

People also misname it to combat-wireless which is pretty funny.

Linux-backports is the latest name and is supposed to bring the latest updates to drivers for pretty much any kernel so you don't have to recompile the whole kernel. Recompiling a kernel is a daunting task, especially if you want to do it right (keep updated with security updates, making sure stuff still work, not breaking other stuff in your distro).

So, when you download, let's say linux-backport-4.1, it will bring the latest updates in the wireless drivers from kernel 4.1. The numbers here refer to the kernel version.

Unfortunately, due to lack of time, they haven't been updated in a long time. If you are able to compile them (most likely not due to the amount of changes), you will downgrade your wireless drivers.

TL;DR: DON'T USE COMPAT-WIRELESS/LINUX-BACKPORTS ANYMORE.

So, any more good news? 

• ath9k works fine in all modes. If you want to create a cheap attack box, look into the PCEngines APU.
• Some Ubiquiti 802.11ac AP can be used to capture in 802.11ac mode (with 3 or 4 streams depending on the unit you buy). Either out of the box or when flashed with OpenWrt.
• If you do a lot of GPU cracking and like AWS, Kali released instances ready to be used with hashcat. No need to install drivers or anything.
• Kali now has a book called Kali Revealed, you can either read it online or buy a hard copy on Amazon.

Lesser known feature of aircrack-ng: interactive mode and keys

Airodump-ng has an interactive mode and all the keys are detailed in the wiki. We'll go through some of them here.

The spacebar is probably the most useful as it can pause the display of airodump-ng such as when you notice something on the screen.
Don't worry, only the display is paused and it keeps capturing, saving all the files in the background. When hitting the spacebar again, it will go back to normal and refresh the screen with the current data.

Let's explore some of the interactive parameters (excerpt from the wiki):

The screen refresh can be adjusted with the '--update' parameter. So if you want it refreshed every 5 seconds instead of the 1 second default, use add '--update 5' to your airodump-ng command.


Now let's scroll through the access points list using Tab. Use the arrows UP and DOWN to navigate in the list.

The most useful feature in my opinion is the coloring one: 'm'. Once you hit that key, it will color the AP selected. To switch to other colors, keep hitting 'm'. You will notice that the associated stations will be have the same color as the access point.

Another key is 's'. It will change the sorting. Be careful, sorting can sometime be out due to the list of Access Points changing. In order to reset sorting (to the default 'Power'), use the 'd' key.

If you can't remember what they keys are, remember that every tool in the suite has a corresponding manual page. In this case 'man airodump-ng'. Look for "INTERACTION" in that page.

Lesser known features of Aircrack-ng

I recently received an email suggesting to adding features to aircrack-ng. Even though most of the stuff can be found in the documentation, it might be worth talking about.

Reading from compressed wordlist

Aircrack-ng can read words from a pipe, which is very convenient and you can use pretty much any program to generate words and display them on the screen (each line will be considered a word) and pass them to aircrack-ng.

About compressed files, there are tools to decompress files on the fly and display the output on the screen such as zcat who takes care of gzip compressed files (there are others and most compression/decompression tools have a feature to display decompressed output to the screen).

Here is how it would look like:

zcat file.gz | aircrack-ng pcap_to_crack.pcap -w -

In this example, it decompress file.gz and 'cat' the result to the screen, then we pipe it to aircrack-ng. Aircrack-ng reads wordlists files using -w and in order to tell it to get it from a pipe (to be technical, stdout from the previous command became stdin in aircrack-ng), you have to use the '-' as parameter for -w.

Rainbow tables

airolib-ng can generate tables (in SQLite format) or import them from cowpatty's format. Once the table is generated, use -r in aircrack-ng to read them (instead of a wordlist).

Distributed cracking

There is a tool in the script/ directory to do that called dcrack.py. As a matter of fact, check out that entire directory, there are a few useful scripts in there.

Running the script will give you a help screen. Here is what the architecture look like to better understand the different parameters:

The different clients represent the cracking systems, the server coordinates everything based on the performance of each client. Each client joining the server will have its performance assessed and when a wordlist is uploaded, it will be split according to each client's performance so they all take the same amount of time to process the dictionary.

The laptop (you) send commands to the server to upload dictionary, to upload capture files, to start the cracking process and obtain the status of the cracking process (as well as the key).

When uploading a PCAP  file, it is highly recommended to clean it up and just leave a beacon as well as the 4 EAPoL packets (or less if you have less) of the 4-way handshake or you'll risk aircrack-ng choosing the wrong packets when cracking. There is a tutorial about it in the wiki.

iw monitor mode flags

Out of curiosity, I looked at iw to set monitor mode and it has the following flags:



Pretty much all of them seem pretty self-explanatory but it's worth giving more details about each of them:

• fcsfail: FCS (Frame Check Sequence) is the checksum of the frame (CRC32), to make sure it was received correctly. By default, a driver should only forward valid frames to the monitor mode interface. This flag allow you to receive frame that also fail the test. One of the use could be monitoring the quality of a wireless network.
• control: There are 3 type of frames: data, management and control. Data is pretty obvious. Management help maintain a connection and control (beacons, probe request/response, authentication, association, deauthentication, deassociation, etc). Control help facilitate the transmission of frame between devices (ACK, RTS, CTS, etc). This is hardware-dependent.
• otherbss: It would allow receiving frames from other BSS (other than the ones to/from the access point the card is connected to or the clients this access point is serving). This is hardware-dependent.
• cook: Refer to a mode for HostAPd where authentication frames that mac80211 didn't actually look at. It is only for ancient versions of HostAPd.
• active: ACK is time sensitive and software is too slow to answer it quick enough so this would be done in the hardware itself instead of software. If an ACK is not received within a certain amount of time, the frame will be considered as lost and a new frame with the retry flag will be sent. The only exception would be very long distance links: the longer the links, the longer it takes for a frame to arrive and in some rare cases, software could be fast enough.

TL;DR: none is what you need.