American fuzzy lop is a security-oriented fuzzer that utilizes unique compile-time instrumentation and genetic algorithms to automatically discover test cases that trigger new internal states in targeted binary software. This significantly enhances the functional coverage for the fuzzed code.
AFL can be found at https://lcamtuf.coredump.cx/afl/. However, there is a new project called AFL++, which is a fork of AFL with numerous improvements and new features. AFL++ can be accessed at https://aflplus.plus/ and its source code is available on GitHub. In this article, we will explore the use of AFL++ for fuzzing IoT binaries.
Fuzzing is most effective when the source code of the binary is available. Unfortunately, IoT binaries often lack source code. However, AFL++ (as well as AFL) provides a companion tool (such as afl-gcc or afl-clang) that serves as a drop-in replacement for standard build tools like gcc and clang. This tool injects instrumentation into the generated binaries during the compilation process. The instrumented binaries can then be fuzzed using afl-fuzz.
Fuzzing closed-source applications poses a challenge. For fuzzing such binaries, AFL++ offers different modes of binary-only instrumentation including Qemu mode, unicorn mode, and Frida mode. These modes utilize Qemu, unicorn, and Frida respectively. However, these modes are not as efficient as source code instrumentation. In this article, we will focus on using Qemu mode.
In Qemu mode, AFL++ leverages Qemu user mode emulation to execute the binary. A modified version of Qemu is used to instrument the basic blocks of the program as it executes. The generated instrumentation information is then used to generate new test cases that trigger different code paths, thereby improving code coverage. Additionally, AFL++ in Qemu mode can also instrument binaries with foreign architectures, making it ideal for fuzzing IoT firmware binaries, which often use ARM or MIPS architecture.
It’s important to note that AFL++ and similar fuzzers (such as AFL, hongfuzz, and radamsa) only work with file inputs. This means that the program being fuzzed must only accept input from a file, and not from a socket. To fuzz socket-based programs, there are two approaches:
1. If the source code of the application is available, the application can be modified to accept input from a file. This can be achieved by implementing a small test function that reads data from a file and uses it to call the targeted function for fuzzing. This approach eliminates the need for socket-based input.
2. In the case of closed-source apps where source code modification is not possible, there are hacks available to convert a socket-based binary to use files instead. Tools like Preeny and desockmulti can be used to override socket functions and redirect input/output to files. However, these tools may not always work seamlessly.
To compile AFL++, it can be done on any Linux system. The following steps illustrate the compilation process:
1. Update the system:
“`
$ sudo apt update
“`
2. Install necessary dependencies:
“`
$ sudo apt install git make build-essential clang ninja-build pkg-config libglib2.0-dev libpixman-1-dev
“`
3. Clone the AFL++ repository:
“`
$ git clone https://github.com/AFLplusplus/AFLplusplus
“`
4. Navigate to the AFL++ directory:
“`
$ cd AFLplusplus/
“`
5. Compile AFL++:
“`
$ make all
“`
6. Move to the qemu_mode directory:
“`
$ cd qemu_mode
“`
7. Build Qemu support for the desired CPU architecture (e.g., ARM):
“`
$ CPU_TARGET=arm ./build_qemu_support.sh
“`
Now that AFL++ is compiled, we can proceed to fuzzing simple IoT binaries. As an example, let’s consider fuzzing the jsonparse and xmlparser1 binaries found in the /usr/sbin/ directory of the Cisco RV130 VPN router firmware (which can be downloaded from https://software.cisco.com/download/home/285026141/type/282465789/release/1.0.3.55?i=!pp).
Before starting the fuzzing process, we need to understand how the program accepts input. By running the respective binaries with qemu-arm-static and the “–help” parameter, we can determine their usage and parameters. Both jsonparse and xmlparser1 accept input from a file.
For fuzzing xmlparser1, create a test XML file and run xmlparser1 with the test file. To initiate the fuzzing process, afl-fuzz needs an input file to generate further test cases. Create input and output directories for xmlparser1, and move the test XML file to the input directory.
Launch afl-fuzz as shown below:
“`
$ QEMU_LD_PREFIX=./squashfs-root/ ../AFLplusplus/afl-fuzz \
-Q \
-i input-xml/ \
-o output-xml/ \
— ./squashfs-root/usr/sbin/xmlparser1 -f @@
“`
In a similar manner, fuzzing can be performed on the jsonparse binary using a test JSON file. Create input and output directories for jsonparse, and move the test JSON file to the input directory. Launch afl-fuzz as shown below:
“`
$ QEMU_LD_PREFIX=./squashfs-root/ ../AFLplusplus/afl-fuzz \
-Q \
-i input-json/ \
-o output-json/ \
— ./squashfs-root/usr/sbin/jsonparser @@
“`
During the fuzzing process, AFL++ will generate interesting test cases in the output directory, which may include crashes or hangs. These test cases can be further examined to identify potential bugs or vulnerabilities.
Please note that this article focuses on fuzzing binaries that accept input from files. Fuzzing socket-based binaries requires additional approaches, such as rewriting the application to accept file input or using tools like LD_PRELOAD to override socket functions. Identifying and triaging crashes is beyond the scope of this article.
In the next part, we will explore how to fuzz socketed binaries that accept input over the network. If you have any comments or suggestions, feel free to leave them below.
