Fuzz testing or Fuzzing, a technique originated in 1988 by Professor Barton Miller at the University of Wisconsin, is a software testing technique where invalid, unexpected, and or random data is input into the system at various levels in an effort to uncover unexpected system behaviors and system failures including system crashes, failing code assertions, and memory leaks.

Fuzzing attacks or testing might include combinations of attacks on numbers, chars, metadata, and binary sequences and could encompass any I/O including the UI, command line options, import/export and any URLS, forms, user generated content, requests, etc.

Fuzzing can be targeted to specific “Fuzz Vectors” which focus data generation around known dangerous values for specific input field types or known vulnerabilities for various file formats, source code languages, and or protocols. In the world of security testing, we use the idea of fuzzing to generate data to trigger specific security vulnerabilities.

What is “Fuzzing”?

Fuzz testing or Fuzzing, a technique originated in 1988 by Professor Barton Miller at the University of Wisconsin, is a software testing technique where invalid, unexpected, and or random data is input into the system at various levels in an effort to uncover unexpected system behaviors and system failures including system crashes, failing code assertions, and memory leaks.

Fuzzing attacks or testing might include combinations of attacks on numbers, chars, metadata, and binary sequences and could encompass any I/O including the UI, command line options, import/export and any URLS, forms, user generated content, requests, etc.

Fuzzing can be targeted to specific “Fuzz Vectors” which focus data generation around known dangerous values for specific input field types or known vulnerabilities for various file formats, source code languages, and or protocols. In the world of security testing, we use the idea of fuzzing to generate data to trigger specific security vulnerabilities.

According to Wikipedia, there are two main categories or types of fuzzing programs:

  1. Mutation Based – which is modification of existing data samples to create test data
  2. Generation Based – which is generation of new test data based upon input models

The Open Web Application Security Project (OWASP) defines two broad categories of stateless protocol fuzzing:

  1. Recursive Fuzzing – defined as the process of fuzzing a part of a request by iterating through all the possible combinations of a set alphabet
  2. Replacive Fuzzing – defined as the process of fuzzing part of a request by means of replacing it with a set value (Fuzz Vector).

For security testing, a common technique is to focus testing on specific fuzz vectors that include tests geared to trigger specific kinds of vulnerabilities:

  • Cross Site Scripting (XSS)
  • Buffer Overflows and Format String Errors
  • Integer Overflows
  • SQL Injection
  • Active/Passive SQL Injection
  • LDAP Injection
  • XML/XPATH Injection

Need/Justification

Fuzz Testing is one of several testing techniques that can be applied to identify application security vulnerabilities, and should be included in any comprehensive testing suite.

Fuzzing is also used by hackers seeking to gain information about systems and system responses to use in formulating attacks, so it is important to identify and evaluate vulnerabilities and risk using tools that will be utilized in attacking your applications.

For those of us working on DoD projects, Fuzz testing is a test requirement (APP5100) specified in the Application Security and Development STIG (ver3 rel4) for all application software development projects.

Advantages/Disadvantages

Advantages:

  • Fuzz testing enhances software security testing
  • Bugs found with Fuzzers are sometimes severe, and include defects that could be exploitable by hackers including unhandled exceptions, crashes, memory faults/leaks, etc.
  • Bugs found with Fuzzers often fall into areas overlooked by testers or areas that are omitted due to time and resource constraints.

Disadvantages:

  • Generally finds very simple faults
  • Data from Fuzzers can be difficult to interpret
  • Can require significant time/labor to perform/implement effectively

How Accomplished

Fuzz testing can be executed manually or through the use of “Fuzzing” programs. There are many automated and semi-automated tools available on the market but the tools can be limited in test scope and or fuzz vectors and or require significant programming efforts (LOE) to implement and make effective. The tools are very good at generating test data to suite specific fuzz vectors. Some readily available (free) open-source fuzzers are listed below along with a link to find out more information about each tool:

—  Power Fuzzer – http://www.powerfuzzer.com/#documentation

—  WebScarab – http://dawes.za.net/rogan/webscarab/#current,

—  Jbro Fuzz – http://sourceforge.net/projects/jbrofuzz/

—  Peach Fuzzing Platform – http://peachfuzzer.com/WhatIsPeach.html

 

Conclusion 

While fuzzers certainly cannot identify all security bugs in your applications, they are a great way to get started to illuminate some of the most common vulnerabilities and should be part of any comprehensive test strategy.

Leave a comment

Your email address will not be published. Required fields are marked *

X