Ari Takanen is the CTO of Codenomicon and a regular speaker at security conferences.
He’s presenting today at RSA Conference Europe and in this interview he discusses fuzzing, a software testing technique that provides unexpected, random or invalid data to the inputs of a program.
What are the benefits of using fuzzing?
Fuzzing benefits come in three areas, depending who is using fuzzing. A software developer will do fuzzing to find problems in his own code, before releasing the product. A system integrator or network service provider will use fuzzing to verify the stability and reliability (including security) in test lab environment. Finally an end-user such as a large bank or government agency will use fuzzing to verify the reliability of the critical services they use.
In short, all these proactive product security teams look for zero-day problems before anyone else finds and abuses them. The fourth group that everyone is competing with are the (black or white) hackers who use fuzzers to find problems in other people’s products, services or networks.
That is what everyone is racing against. No matter how good intentions security researchers have when finding and disclosing problems, most players in the industry prefer finding and fixing the problems in quiet, without urgency. That way the security updates will also be better quality.
Based on your experience, how important would you say fuzzing is in the overall penetration testing process?
It is not critical. 95% of penetration testers only look for known issues. And majority of their customers do not even know to ask for anything more. The networks are in such bad shape today that just running a nessus scan will find numerous issues in critical networks. But then, in some other areas, just finding those known issues is not enough. When you go in the area of zero-day discovery, fuzzing is the most efficient method. Not everyone wants to read code or do reverse-engineering to find new unique bugs in code.
What tools and techniques would you recommend for penetration testers looking to making the most out of fuzzing during their work?
Using open source fuzzers is very educational starting point. With that, you will understand the challenges of building a GOOD fuzzer. Simple fuzzers are often enough to beat all competitors and then when you need more serious fuzzing you turn to ready-made commercial fuzzers.
It is more a matter of time and quality of testing. When you build your own fuzzers, your customer sometimes ends up paying weeks worth of work for something that is not necessarily giving them much test coverage.
What are some of the most bizarre discoveries you’ve made while fuzzing?
Mostly we do not actually do the fuzzing, but give our tools for manufacturers, service providers and consultants to use. I think the craziest stories are related to fuzzing cars, and heavy duty telecommunication networks. Large rooms full of machinery crashing is always impressive. And being able to reboot a car always makes you think on life-critical systems, and their quality. I am not sure I even want to know the quality of hospital systems. That would really be scary.