Richard Brain is the Technical Director at ProCheckUp and in this interview he discusses vulnerability research, his favorite security tools, fuzzing as well as the vulnerability disclosure process.

Many upcoming security professionals are interested in hunting for vulnerabilities. What advice would you give to those just starting out?

In order to become proficient in finding vulnerabilities you should set up a test lab containing some software without patches. Once ready, apply published exploits to understand how the published vulnerabilities interact with the software, and how it affects the software's security stance. This testing process will change your mindset and you will learn how to make software fail and behave unexpectedly.

Vulnerability research is both hard work and time consuming so do not be disheartened by a lack of results, especially when investigating popular software which has been studied by vulnerability researchers over a number of years. Though nothing is more satisfying than to find a serious new vulnerability.

A recent example of the serious flaw within popular software is the ProCheckUp ColdFusion directory exploit which allowed the admin password file to be read, ColdFusion versions back to ColdFusion 6 (released in 2002) were found vulnerable. An example of finding more new flaws in existing software than those published, would be the ProCheckUp SAP BusinessObjects research published earlier this year. Where I managed to find about fifty new vulnerabilities within the software, some of which gave limited admin access.

What are your favorite tools when it comes to vulnerability research?

ProCheckNet - Reason for using ProCheckNet is that it shares no common heritage with other testing tools, and produces unique attacks.

DirBuster - A quick and friendly tool for discovering hidden files and management systems within web applications.

Burp Proxy - A surprisingly good application scanning tool, which when properly used produces superior and repeatable results to the $5K+ commercial scanners.

IDA PRO - A very competent debugger and dissembler, great for analyzing programs written in machine code.

We've seen a lot of talk about fuzzing in the past year. Based on your experience, how important is fuzzing in the overall vulnerability research process?

I hardly use fuzzing software to find new vulnerabilities, as personally feel it's best to understand how the software interacts with both the underlying OS and the language it is written in. However fuzzing on its own does occasionally find new flaws as it elicits unexpected responses from programs and thus indicates which code areas need further attention.

Some vulnerabilities tend to remain unpatched for a long time and eventually researchers opt to disclose details that lead to exploits. How much should they wait before disclosure? Should they be scolded for pointing out critical issues or are they doing the community a favor?

Software vendors dislike the negative publicity generated when vulnerabilities are publicized, specifically those vendors already having a poor reputation for security or who sell security products. From experience I can tell you that some software vendors ignore communications, or delay the announcement until a large number of product patches are grouped together thus lessening the publicity impact of individual flaws.

The security industry has been scolded by critics for releasing exploit code, as they do not understand the necessity for doing this. Security testers and testing tools need to have functional and working exploits to validate if their customer's sites are secure. If exploits are not released they cannot do their job.

The following article appears on Search Security. Please click here to read it in its original source.