Fuzz testing, also known as “robustness testing”, is a proven method for discovering unknown vulnerabilities in software. It involves sending intentionally invalid data to an application in the hopes of triggering an error condition or fault. The objective is to expose these error conditions before they form the basis of a new unknown vulnerability.
Fuzzing doesn’t need source code to do its work. Any application that processes inputs can be put through fuzzing to determine how robust the underlying code is. In fact, fuzzing is the number one method used by hackers and security researchers to trigger failure modes and discover new vulnerabilities in released software.
Fuzzing software automatically sends unusual input to the application via its open interfaces. Such input could include illegal values, tough strings or good checksums on bad data. How the application responds to these unanticipated situations is automatically captured. If the error state exposes a security vulnerability, then steps need to be taken to fix it.
Fuzzing offers proactive approach
In a typical situation, developers take a reactive approach to vulnerabilities. They do some basic security testing but without fuzzing. A bug in the code goes undetected and the application is released. A hacker finds the bug and uses it to perform a zero-day exploit, causing economic or reputation loss to the user.
After the damage is done, security researchers expose the vulnerability and patches are issued by the developer. If other users are lucky, they are able to patch their software before a similar attack happens to them. But part of this can be avoided if the developer used fuzzing to discover and fix the bug before the application was released.
“Whether you like it or not, your software will be fuzzed,” says Olli Jarva, Senior Solutions Architect with Synopsys Singapore. “It’s better that you are the one discovering the unknown vulnerability and fixing it, rather than a hacker finding it and exploiting it.”
Fuzzing in action
In 2014, the world of secure Internet transactions was hit by the Heartbleed crisis. Hackers exploited a SSL/TLS vulnerability found in certain older versions of OpenSSL. It was discovered by the Synopsys research team in Finland using Synopsys’ fuzzing solution Defensics. Within the first month, roughly half of the vulnerable IP systems on the Internet were either patched or otherwise mitigated.
There are instances when a commercial software vendor uses Open Source code or components and releases the software to customers. Neither the vendor nor the customer knows in detail what code went into the software. When a vulnerability emerges, the question of who is responsible or liable in the instance of a breach would arise. Fuzzing by the developer or end customer would avoid this problem.
A 2016 Forrester Consulting study on a Synopsys customer using Defensics and Coverity (Synopsys’ Static Application Security Testing solution) found that there was a 5x reduction in defect or vulnerability remediation costs due to earlier detection in the development phase, and a 2x cost reduction in the testing phase. The customer saved US$9.5 million over 3 years.
What to look for in a fuzzing solution
When looking for a fuzzing solution, look for a fully automated testing platform with an intuitive user interface and pre-built test suites. It should employ next-gen technology using various techniques to generate effective test cases, and detect failures.
Also important is the range of protocols that are covered as different industries require different protocols to be fuzzed. There should also be a clear path to the remediation. Failure conditions should be repeatable to facilitate fixing and should also be easily captured for reporting to suppliers.
For more information on Defensics, visit here.