Fuzzing: Avoid Zero-Day Attacks -- Build Security In, Don't Add it!

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.

By Ari Takanen | Posted Feb 23, 2010
Page 1 of 2
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn
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. At the same time, a growing share of vulnerabilities is never disclosed publicly. Instead, they are sold and distributed within underground hacker communities. Software development companies can no longer rely on user communities to find bugs, they need to find new ways to protect their products and services. Many companies have moved away from reactive post-deployment security add-ons and started to endorse in-built security by integrating software security practices into their Software Development Lifecycle (SDLC).

"Software development companies can no longer rely on user communities to find bugs, they need to find new ways to protect their products and services.”


Ari Takanen
Codenomicon

Zero-Day vulnerabilities are unknown bugs hidden in software code. In contrast to known disclosed flaws with available patches and updates, vendors are unaware of these unknown bugs, and therefore they are not prepared to provide fixes for them. Attackers need to find an unpatched bug in a system to exploit it. If a system gives an abnormal response to an input containing anomalies, then there is a bug in the system and the attackers will continue to edit their inputs until they get the system to behave the way they want. However, zero-day bugs do not always need to be exploited for criminal purposes to cause problems. Sometimes the bugs can be triggered by normal use or system maintenance. But one thing that ought to be realized is that a zero-day vulnerability is a ticking time bomb, it does not really matter what eventually sets it off. The important thing is to get rid of them.

It is generally acknowledged that the earlier a vulnerability is discovered, the easier and the cheaper it is to fix it, and the more comprehensive the fix is. Therefore, the best way to avoid vulnerabilities is to write good code, and testing is the easiest way to ensure the quality of your code. Fuzzing is a software testing technique, in which unexpected data is fed to the inputs of a system, and the behavior of the system is then monitored. If the system fails, e.g., by crashing or hanging, then there is a bug in the software. Fuzzing enables testers to accurately simulate potential attacks against their own code and to patch the found vulnerabilities before somebody else finds them and exploits them. Fuzzing is a risk-based approach: It does exactly what the attackers would do, but before them.

By integrating fuzz testing into your software development process, you can discover flaws at the earliest possible moment. By building security in, you can avoid external security features, which merely add to the complexity of your system by increasing its attack surface. The same applies to VPN systems, IDS/IPS, firewalls and anti-virus programs. Furthermore, application service providers, like online-banks and web stores, cannot build fortresses around their application, because their customers need to be able to use their services. Any system that is exposed to the Internet is also exposed to attacks, and should be fuzz-tested for security.

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter