Cyber-security nowadays is getting more and more competitive, and it certainly is a battlefield where companies can suffer losses of huge proportions when hit. Even zero day exploits can cost vast amounts of money if not remedied in time, and that is just one of the effects. Damaged reputation also costs, perhaps in more insidious ways, with effects that are difficult to estimate all at once.
Due to this, cyber-security is trying to keep up with the field enemies, be they malicious organizations or individuals, or just software faults.
Promoted by some as “security testing as you’ve never seen it”, fuzz testing is a way of discovering hidden vulnerabilities and bugs by injecting or inputting randomized malformed/semi-malformed data into software programs in an automated or semi-automated manner, in order to generate exceptional reactions.
What is also specific to fuzz testing (or fuzzing, as it is alternatively known) is that it requires no access to the source code, therefore a company that would employ external specialists to test their software this way shouldn’t have to worry about the risks of their products being duplicated due to this stage of testing (at least not in theory). Due to this characteristics, this method is also considered a way of black-box testing. Only when a crash/issue is detected, it is necessary for the fuzzing results to combine with the source code in order to fix the discovered vulnerability.
Fuzz testing and its evolution
Even the most basic online sources point out that fuzz testing originates in a 1988 class project of Barton Miller’s, taught at the University of Wisconsin, which expanded into a command-line fuzzer that tested Unix programs. Seven years later the concept allowed GUI-based tools to go through the same testing proces. In 1991 the first tool applying this method –crashme- put to test “the robustness of Unix and Unix-like operating systems by executing random machine instructions”.
Professor Miller’s and his students’ work is available online on this page dedicated to fuzz testing of application reliability. Considering the latest progress in automation, it is only logical that their concept can meet the proper software capabilities further on. Smart software, or even artificial intelligent programs can take fuzzing to a whole new level, while cyber-security needs to benefit from such upgraded tools.
Specific terms in fuzz testing
The massive inputs of random data are called fuzz, while the “diagnostician” tool, which indicates potential vulnerability causes when the system/software crashes, is the fuzzer or the fuzz tester.
Currently, the problems for which fuzz testers are best-suited range from buffer overflow, DDoS attacks or cross-site scripting to SQL injection. Bugs are also a target of fuzz testing, and the benefit-to-cost ratio is said to be high.
Usually, fuzz testing comes in conjunction with classical black-box testing and other debugging techniques, a combination justified by the fact that fuzz testing by itself tends to find the bugs and/or vulnerabilities specific to specific or exceptional circumstances, as opposed to the other tools that aim for normal software activity characteristic faults.
The fuzzers have to be previously configured (as in many automated processes, of course), and the degree of sophistication and intelligence they dispose of determines the accuracy of the testing. As a matter of fact, they classify into dumb and smart fuzzers, depending on whether they have built-in intelligence regarding the program to be tested or not – where obviously, the smart fuzzers benefit from a greater level of intelligence.
Other classifications mention mutation-based (which mutate existing data samples in order to create test data), and generation-based fuzzing (where new test data is defined based on models of the input), as well as variations into the type of testing. While black-box testing is the most encountered type, there also exist white and grey.
No wonder that recently in 2016 Microsoft introduced Project Springfield, which is a cloud-based fuzz testing service that invites users to upload their binaries (one-time configuration and sample inputs) in order for the multiple fuzzers to test them, to identify the high-value bugs and to report actionable test cases. Fuzzing in the cloud is expected to revolutionize security testing. As we mentioned before, due to AI developments, fuzz testing has finally meet its big moment.
The new Microsoft service is “suitable for testing in-house software, software acquired through M&A, and even third-party software being considered for purchase”.
Perspectives in fuzz testing
Microsoft’s move could be a road opener for what Ars Technica has already dubbed “fuzzing-as-a service”. It all depends on how this limited preview takes off, since the company is currently scanning for customer feedback and interest in order to decide where it will take this project. However, considering the amplitude of Project Springfield and the company behind it, it is rather unlikely for this cloud fuzzing to miss its target.
Another prominent field where fuzz testing is often mentioned, in combination with penetration testing, is the mobile security, in its extended version. By extended we mean IoT, smart vehicles, connected devices and networks. Fuzz testing is employed in automobile industry software testing, due to its similitude with the real life cyber-attacks that seek indiscriminate disruptions – the Experimental Security Analysis of a Modern Automobile paper details in what way fuzzing benefits components’ cyber-security, allowing manufacturers to prepare in advance for possible attacks.
A different source mentions fuzzing as one of the focus points in the IoT Emerge 2016 event, held in Chicago’s McCormick Place during November 2 -4. Among the expert topics, fuzz testing seems to occupy its honorable place, due to the exciting possibilities it opens up in security analysis, now that the concept is perfecting itself via experience and automation.
