[Autogenerated] The team that discovered the key reinstallation
attack or crack in October 2017 only released proof of concept
scripts rather than a full working exploit these scripts allow us to
test client devices to determine if they're vulnerable to crack
another related vulnerabilities.
Let's first run through how we can get set up for
running the crack test scripts.
Full instructions are provided on the crack GitHub repository,
but the key steps are shown here First.
We install some dependencies such as libraries.
Net tools for configuring and controlling the wireless network interface
and escapee for packet crafting once those are installed,
we can clone the crack scripts from the Git repository.
The next step recommended by the authors is to disable hardware encryption.
However,
there have been reports of this step causing operating system
crashes and that the scripts still work.
Even if this step is skipped.
Host A P D.
Is used to create a local access point using our wireless network interface.
It's highly configurable,
but at a minimum you should ensure that the correct wireless network
interface is specified as host A pD defaults to W LAN zero.
You may also want to create a new S.
S I.
D and password.
Once the configuration changes are made, we need to compile host a P.
D.
Using the build shell script.
Finally,
we create a python virtual environment with the
dependencies listed in the requirements file to ensure
we're using compatible python libraries.
We do this by running the pie set up shell script.
The steps we've just run through.
Only need to be carried out once but there are a number of steps we need
to carry out before each new use of the crack scripts.
The first is to disabled Network manager using Network
manager cli and specifying radio wifi off with then soft
unblock Wi-Fi using our F kill.
Finally we create a python virtual environment instance
within which we can run the scripts.
Okay, so now we're ready to start running the scripts.
There are seven standard scripts in the crack suite but we'll look at just
a few here to illustrate their use the replay broadcast script which tests
whether the client accepts replayed broadcast frames is the best place to
start because if the client accepts replayed broadcast frames then we have
to patch that first.
Otherwise subsequent scripts won't be able to accurately determine if
the group key is being re installed on the client being tested
because that will always appear to be true.
When we run the script,
it first creates an access point based on the configuration
specified in the host A pd dot com file.
In this case the network is called Test network.
It then prompts us to connect to the access point from the test client.
The default password for connecting to the access point is A B C D E F G H.
But if you make changes in the host a P D configuration file,
use that instead the script then continues with the test and eventually
confirms that the client doesn't accept replayed broadcast frames.
This next script tests for key reinstallation in the four way handshake by
repeatedly sending encrypted message threes to the client.
The script is essentially testing for the original vulnerabilities
by monitoring the traffic sent by the client to see if the pair
wise transient key is being reinstalled.
The script starts in the same way as the broadcast replay script by
creating an access point and prompting us to connect to it.
The script performs two tests.
First it determines whether the pair wise transient key is reinstalled
and then whether the group temporal key is reinstalled.
If the client isn't sending enough uni cast frames you
can try pinging the access point.
All of the scripts run fairly quickly and in this case we get
confirmation that the client doesn't reinstall the pair wise
and group keys in about 50 seconds.
The G.
T.
K.
In its script tests whether the client installs the group key in the
four way handshake with a given received sequence counter by
continuously executing new four way handshakes after creating the access
point and connecting to it from the client.
The test starts now.
Unfortunately if any handshake messages are missed while
this script runs there can be synchronization issues which
can make the test unreliable.
The most effective way to minimize this is to test in low
noise environments and to run the script four or five times
to ensure a consistent result.
This test can sometimes take a little longer than some of the others,
but eventually we get a report that the client always installs the group
key in the four way handshake with a zero replay counter.
Notice also that the script identifies that the
result could be caused by the client, except in broadcast replay frames.
But as we've already tested for that,
we can rule it out now that we've learned some new
skills to carry out wireless attacks.
Join me in the next module to see how we can use them
to eavesdrop on wireless traffic,
divert clients to domains under our control and cause
denial of service to wireless networks.