Fuzzing: Avoid Zero-Day Attacks -- Build Security In, Don't Add it! - Page 2
The greatest security challenge today is discovering new vulnerabilities. Software release cycles are getting faster and new technologies are increasingly complex, a perfect breeding ground for bugs.
Most traditional vulnerability auditing solutions focus on scanning the systems for previously known bugs. The benefit of such testing methods is that they do not actually trigger any vulnerability, and therefore they are usually safe to use even in production networks. But their biggest weakness is that they cannot find previously unknown vulnerabilities. This is especially problematic with emerging technologies and proprietary protocol extensions: there are no ready bug lists, and thus it is impossible to find weaknesses using vulnerability or security scanners. In my opinion, the main strength of fuzzing is its ability to find completely new vulnerabilities.
In robustness testing, thousands and even millions of misuse-cases are created for each use-case, thus most robustness testing solution contain at least some degree of automation. The most comprehensive fuzzers, so called model-based fuzzers, utilize protocol specifications to intelligently target protocol areas most susceptible to vulnerabilities. Stateful model-based tests can also genuinely interoperate with the system under test and find vulnerabilities even in deeper protocol layers with high accuracy, making it possible to test complex protocols, like XML, accurately. Test targeting also significantly reduces the number of test cases needed and the test run times, making it possible to integrate tests into regression tests or to perform automated tests, for example, with every build. This creates an obvious advantage: If vulnerabilities are fixed early on during the software development process, there simply will not be any time for anyone to devise an attack.
With emerging technologies the specifications needed to create model-based tests are not always available: there might be no consensus or the specifications can be proprietary and not available to testers. In such cases traffic captures can be used to create mutation-based fuzzers. As these fuzzers are based on real traffic samples, no additional knowledge of the system under tested is needed. In addition, these test cases are quick to create and to execute, due to limited scope of the tests. But traffic captures are only samples of network traffic, and thus they only cover a limited selection of the implementation. For example, they completely ignore rarely used features, such as legacy technologies or other hidden features. Yet, if no model-based fuzzers are available, it is better to use some kind of traffic sample based robustness tests, than to not test the resilience of the system at all.