Fuzzing — where is the logic?

How random can it get?

Security testing is one of the most important phase of the software development life cycle. It lets the developers examine and know the various bugs, evaluate the operational efficiency and data security of an application. Considering the case of a web application under development; developers perform code reviews, penetration testers test the overall security of the application and make sure that the application is hardened enough for their customers. One such method of testing applications used is Fuzzing.

Fuzzing is the act of sending invalid, unexpected arbitrary code to an application and then examining the response to determine its efficiency. It’s the combination of systematic and non-systematic approaches derived out of feeding random input and output testing. It adds an extra layer of proactive approach to the preexisting code review, penetration testing and debugging mechanisms. At times its also referred as Monkey or Random Testing. Fuzzing can be done by a using a software or even piece of randomization code written by the testers. Fuzzing helps in finding bugs in the code, detecting undefined behavior, testing against certain cases of denial of service (DoS), memory leak finding, detecting deadlocks in the code etc.

What constitutes a fuzzer?

An ideal fuzzer is a combination of,

→ An usable CLI/GUI

→A solid fuzzing engine

→Unconventional protocol API support

Depending upon the extent of fuzzing being done, the tester can opt to choose the command line interface or the graphical interface. In certain expert level fuzzing, testers would usually implement a script based fuzz that may vary from application to application and they tend to rely on CLI due to higher operational control and visibility. Whereas, standard fuzzing with any preexisting logic can be very easily and instantly done using a GUI.

The success of a fuzzing project relies heavily on the fuzzing engine. A fuzzing engine may be described as an algorithm that contains the list of most notable tests and their common exploit codes. For example, the fuzzing logic of a brute force test against all the input channels of an application may involve combination of inputs such as aaa, aa$, a/23# etc.. The fuzzing engine maybe a collection of such logical combinations that can be tested out against an application.

Almost every application utilizes APIs (Application programming interfaces) and they’re mostly protocol bound. Now what happens when these protocols are violated? Its an essential module of fuzzing where the tester tries various unconventional ways of API support and may lead to the discovery of unattended bugs and issues. Hence, every fuzzer must be equipped with logic to test unconventional API support.

Fuzzing code can be a combination of Numbers (signed or unsigned, integer or floating point), Characters (Random CLI inputs, URI’s etc…), Random metadata and user input texts, Pure and random binary sequences. It can also use known to be dangerous values such as:

→ Usage of zero, negative integers and very lengthy numbers against integer input

→Escape and non interpret-able characters such as SQL quotes against character input

→Usage of random binary values

Categories of Fuzzing?

Based on the type of exploitation method, fuzzing can be categorized into three types:

1. Application Fuzzing
2. Protocol Fuzzing
3. File Format Fuzzing

Application fuzzing aims at exploiting the application on the whole via targeting all possible input combinations, Protocol fuzzing aims at testing and exploiting the protocols and APIs that a particular application is dependent on and lastly File Format Fuzzing aims at exploiting the file input stance of the application i.e. If an application is only aimed at analyzing images what will happen when we submit a .mp3 file or an executable file in place of the images and analyzing the application’s response.

Based on the type of logic used for fuzzing, fuzzing can be classified into two types:

1. Smart fuzzing(aka Generation Based Fuzzing)
2. Dumb fuzzing(aka Mutation Based Fuzzing)

Dumb fuzzing involves sending random data and observing the output without really understanding the complete structure, protocol and API usage of the application. It has its own disadvantages as most applications don’t accept random data as part of secure development. For complete success, it should always be used in combination with Smart fuzzing.

Smart fuzzing first involves the understanding of the structure, protocol and API usage of the application and then implementing the testing with changes done to specific values without changing the overall structure or format of the application’s acceptable input.

Current market offers multiple variety of fuzzers. One important thing to remember while choosing a fuzzer is the uniqueness of the logic being used i.e.

→ Usage of Recursive fuzzers: This lets the user slightly edit the preexisting fuzzing logic

→Usage of Non Recursive fuzzers: This involves replacing the preexisting fuzzing logic completely with a new one. This is considered the most efficient method but if implemented incorrectly, it can lead to many undesired and unsupported protocol usage errors.

How do I fuzz?

A step by step guide to fuzzing can be described as follows,

1. Evaluate all entry points
2. Rank all points by privilege and accessibility.
3. Find an easy target and input malformed data.
4. Try using automated fuzzing first.
5. Then implement smart/manual fuzzing.
6. Analyze the outputs, crashes, errors and exceptions to identify severe loopholes in the application
7. Fix them
8. Retest the application involving all above steps again until you’re satisfied with the strength of the application.

What are the available fuzzing tools?

The following is the list of recommended fuzzers by the OWASP organization,

1. JBro Fuzz
2. WSFuzzer
3. American Fuzzly Lop
4. Microsoft SDL MiniFuzz File Fuzzer
5. Peach Fuzzing Platform etc…

Pros & Cons?

There’re multiple pros of fuzzing like discovering several severe vulnerabilities, code defects and can most likely be automatized by the tester. However, it also has certain cons like it doesn’t detect vulnerabilities that involve information exposure and errors that cause exception.

This brings us to the end of the article. And please note that the above article is a combined and simplified version of all open sourced materials available on the internet and I’m not yet a security testing expert to validate the same. However, I’m open to suggestions and any corrections required to make this a better resource of everyone!