What is Fuzzing?
Fuzz testing is a testing technique
that provides malicious input to the application. Fuzz testing is crashes,
assertion failures, and memory leaks when program fails to handle the malicious
input. Fuzz testing identifies vulnerabilities which are severe in nature. The
typical fuzzing checks the application for buffer overflow, format string
vulnerability which can be highly automated. http://en.wikipedia.org/wiki/Fuzz_testing
Fuzz testing can also
be used to find out XSS, Sql injection like vulnerabilities. Google
developing a tool called Lemon
which can be used to find out XSS, Sql
Injection, HTTP response splitting, Cookie poisoning, Stack trace leaks,
Encoding issues and Charset bugs.
For more info: http://itknowledgeexchange.techtarget.com/security-bytes/google-developing-xss-fuzzing-tool-called-lemon/
Fuzzing can have a great impact on the quality of source code.
Below method need to fuzz tested as it accepts
the data in the form of given file name.
public static byte ReadFile(String FilePath)
FileStream fs = new FileStream(FilePath, FileMode.Open, FileAccess.Read,
int length = (int)fs.Length;
byte data = new byte[length];
// Perform some action with the data read
Types of Fuzz Testing
Randomly changing data and then supplied
into an application.
Changing specific data with the knowledge
of underlying format the application accepts.
How it works?
The process of fuzz testing is quite
simple as described in the below steps.
every unhandled exception/crash is vulnerability. It is a bug. Further analysis
can determine if it's a security bug.
- Program accepts the file.
- Create malformed data.
- Program accepts the malformed data.
program breaks or unhandled exception occurs, the vulnerability has been
To analyze crashes use
!exploitable Crash Analyzer
is the used to automate crash
and risk assessment.
Minifuzz File Fuzzer
Minifuzz tool helps in detecting
security flaws that may expose application vulnerabilities in file handling
code. The Minifuzz tool accepts the file content and creates a multiple
variations of the same file to identify the application behavior for handling
different file formats. You should first need to define the file content the
application accepts and based on that you should run Minifuzz for the applicable
It is simple fuzzer designed to ease adoption of fuzz testing
by non-security professionals who are not familiar with file
Minifuzz testing must be performed during Microsoft security
development lifecycle (SDL) Verification Phase.
Below is the sample demonstration of
MiniFuzz File Fuzzer.
Here we will be fuzzing Agent.exe
Below is the parameter we need to set in order to perform fuzzing.
|Process to fuzz
||This is the full path and the name of the executable under
|Command line args
||Place holder and optional switches to pass to the process under test.
%1 is a placeholder for the name of the corrupted file, and because the name is
random, you won't know the filename ahead of time but the fuzzer does. If your
tool requires a command line switch to set the name of the file, then you should
include that also. For example, if your application requires you set the
filename using the /F: option, then you can use this:
|Allow process to run for
||This is the maximum time in seconds to allow the process to run
before killing the process. Whatever time you set, it should be long enough to
allow the process to render or parse the file. If the application does not die
in the allotted time, MiniFuzz will terminate the process.|
Important: Do not
be overly aggressive with this value by making the value very small because the
application under test might not have time to start up, configure itself, load
the file and then render the file before MiniFuzz tears the process down. Start
out at 2.0 seconds, and then after a couple of tests, throttle back to 1.5, then
if needed 1.0 or, the lowest possible value, 0.5 seconds.
Also, for very
large files, over 1Mb, you should increase this setting substantially because it
will take time for the process under test to load the file off the
||MiniFuzz can close an application down by using one of three
Thread Injection injects a new thread into the target process and
then calls ExitProcess on that threat. This works for all Windows applications
and is a graceful shutdown. This is the default setting.
WM_CLOSE is the most
graceful shutdown method as it instructs the application to shut down cleanly.
This only works for graphical applications, not for console
TerminateProcess is a Windows API that tears the application
down. It's brutal, and it can lead to some resources left un-freed. Any
application type can be shut down this way, but it should be used as a last
Do not be alarmed if you see dozen of your target processes running
at once, this is quite normal because shutting processes down can take time for
some kinds of processes. If you see hundreds of instances of you application,
then the fuzzer is not shutting the process down correctly, or your application
is preventing shutdown.
||This is where you have stored your set of template files; you can
override this setting if you need to.|
||This is the location of all the corrupted files. MiniFuzz deletes
these files in the background, so it's not unusual to see about ten files in
this folder at any given time. MiniFuzz will also attempt to delete any files
remaining in this folder when MiniFuzz exits. This location is configurable
through the XML configuration file described in "Step 2: Configure MiniFuzz" on
||This is the location of the log file that tracks all crashes. More on
this file in a moment.|
||In the application under test crashes, the offending file is removed
from the temporary folder and written to this folder. This location is
configurable through the XML configuration file described in "Step 2: Configure
MiniFuzz" on page 3.|
||This setting determines how much of the incoming file to fuzz. There
is no value that is better than any other number because sometimes a very subtle
single bit change might trigger an application to fail. Large changes may render
a file so badly malformed that your parsing code rejects the file very early in
the parsing process. In short, you need to work out what the most appropriate
level or aggressiveness is for your parsing code.|
|Always on Top
||This means MiniFuzz always runs as the top-most window.|
||As the name suggests, this starts the fuzzing process once you have
set all the appropriate settings.|
||Stops the fuzzing process, but does not reset the progress data.
|View Log Dir
||Opens the folder that contains all the log files. |
||Opens a dialog box that allows you to view and configure Visual
Studio Team Foundation Server settings.|
||Brings up the About dialog box.|
||This section lists ongoing tally information such as the number of
files read and the number of crashes. |
the fuzzing is started, leave the application to run for at least an hour or
two. Minifuzz then creates different variations of the file which is then passed
to the application. Security Development Lifecycle (SDL) recommends to test
patterns for each file format. Below figure shows the different
variations of file created by Minifuzz
below show the file for which the application got crashed.
can be seen in log file.