Home

Awesome

Identifying Software and Protocol Vulnerabilities in WPA2 Implementations through Fuzzing

User Manual

Description

Nowadays many activities of our daily lives are essentially based on the Internet. Information and services are available at every moment and they are just a click away. Wireless connections, in fact, have made these kinds of activities faster and easier. Nevertheless, security remains a problem to be addressed. If it is compromised, you can face severe consequences. When connecting to a protected Wi-Fi network a handshake is executed that provides both mutual authentication and session key negotiation. A recent discovery proves that this handshake is vulnerable to key reinstallation attacks. In response, vendors patched their implementations to prevent key reinstallations (KRACKs). However, these patches are non-trivial, and hard to get correct. Therefore it is essential that someone audits these patches to assure that key reinstallation attacks are indeed prevented.

More precisely, the state machine behind the handshake can be fairly complex. On top of that, some implementations contain extra code to deal with Access Points that do not properly follow the 802.11 standard. This further complicates an implementation of the handshake. All combined, this makes it difficult to reason about the correctness of a patch. This means some patches may be flawed in practice.

There are several possible techniques that can be used to accomplish this kind of analysis such as: formal verification, fuzzing, code audits, etc. Among all of these, software fuzzing is, de facto, one of the most popular vulnerability discovery solutions and for this reason has been selected. Feasibility and methodology on how to fuzz an open-source implementation with a goal to detect potential flaws will be discussed and presented. The goal of this thesis is then to define whether it is possible to detect software bugs in a protocol implementation, including protocol- level vulnerabilities like KRACK, using a systematic approach and in an automated way.

Goals

Project Structure

Getting Started

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes.

Prerequisites

Linux based machine is required to allow the functioning of the bash script created and for the correct functioning of both AFL and iwd. It's possible to find the specs used for carrying out tests in this work in the box below. We suggest to have a similar configuration to obtain similar results.

OS -> Linux Ubuntu
Version -> 16.04.6 LTS (Xenial Xerus)
Architecture -> x86 64
ArchiteCPU op-mode(s) -> 64-bit
CPU(s) -> 16
Thread(s) per core -> 1
Model name -> Intel Core Processor (Broadwell, IBRS)
CPU MHz -> 2399.994

Installing

The project can be installed and build directly using the provided initialise.sh bash script. Run the bash script initialise.sh in order to clone and install on your machine:

Run the following command:

$ cd Thesis
$ ./initialised.sh

Running the tests

Once AFL and iwd have been correctly configured, it's possible to run test by issuing the following command:

$ cd Thesis
$ ./start_fuzzing.sh

The bash script will automatically create a directory in the fuzzer_result directory, with the current time in order to be distinguished from the other. The data-frame used to run the test is coded into the script itself. To provide a different data-frame is necessary to give the name and the path where it is located. It's sufficient to create a copy of the desidered data-frame and locate into the data_message folder. The script will retrieve it automatically and pass it to the fuzzer. The script provide different options (showed when executed without any parameters) that can be used to perform different type of analysis based on different function, different compilation (see for reference [http://lcamtuf.coredump.cx/afl/README.txt] for more info ).

An example running is showed below

$ ./start_fuzzing.sh -p -t "example message"

This command will start an istance of the fuzzer using the function correspondent to the -p parameter (ptk_function), -t plus a message in quotes to add notes for that kind of execution .

fuz_ptk

The image above shows how the AFL is presentend to the user. The GUI is divided in different box covering different important information that should be checked during the execution. For further reference to this check the link above

Running Code Coverage tests

It's possible to run additional test on the results obtained by AFL using a companion tool called afl-cov (see here for more [https://github.com/mrash/afl-cov]). It is already installed and working for our project. To perform the analysis we are requested to make a copy of the target code that we have analysed with AFL and compile it with the the predifined option:

$ cp iwd-gm iwd-gm-cov

Then in iwd-gm-cov/Makefile of the project we need to change the compilation option with: gcc -fprofile-arcs -ftest-coverage.

After all these steps are done it is possible to use the script bash stored under the fuzzer_result directory. It will be enough to run the script to automatically retrieve all the information needed to the lcov to perform its analysis.

$ cd fuzzer\_result
$ ./start_coverage.sh -d dd_mm_yyyy/ptk/hh:mm:ss

Once the tool has completed in the corresponde folder passed as parameter, under [...]/cov/ it will be possible to access the different xml file generated showing the coverage obtained. An example is showed in the image below

ptk_coverage

Plot data results

To plot the result of a specific results it is possible to use afl-plot tool, already installed with this project. It is needed to go in the result folder that need to be plotted and issue the command showed in the example below:

$ cd fuzzer\_result/31_05_2019/ptk_gtk/08:01:00/output
$ afl-plot . out_plot

The images below show the three different plot that it is possible to build starting from the results obtained by AFL during the execution.

exec_speed

high_freq1 low_freq1

Crash Database & Exploitable

Along with all the other tool available in this project it is possible to add another one to allow a better view of the crashes. afl-collect (see here for reference [https://github.com/rc0r/afl-utils]) and Exploitable (see here for reference [https://github.com/jfoote/exploitable]) can be used to copy all crash sample files from an afl synchronisation directory (used by multiple afl instances when run in parallel) into a single location providing easy access for further crash analysis. The installation of this is left to the source page, in our project can be used as follow:

$ afl-collect -d db_storage/ptk_crashes.db -e  gdb_script 
~/Thesis/fuzzer_result/29_05_2019/ptk/13:52:39 
~/collections/ptk -j 8 -- ~/Thesis/iwd-gm/unit/test-eapol

The image below shows an example of the result after the execution of the command.

gdb_expl

Providing a db extension file where to store our crashes and using exploitable to make crash sample removing and and executing gdb script to evaluate the severity of the bugs found.

Author

Contributors