Metasploit creator sees no end to software security vulnerability issues

Metasploit creator and vulnerability expert H.D. Moore says secure coders are doing a better job creating applications with fewer bugs, but an ever increasing number of applications leaves no shortage in the number of new software vulnerabilities. In this interview conducted at the 2010 RSA Conference, Moore explains how Metasploit contributes to helping people test their systems against new software security vulnerability issues to demonstrate the risks posed by new flaws before attackers have a chance to use them.

Explain how Metasploit contributes to software security.
Metasploit is a software framework for both finding vulnerabilities, exploiting them and using them in a pen test. It's an open source toolkit that is really driven by the community. It started about seven years ago. Anytime a new vulnerability is discovered we create a safe version of that exploit and add it to Metasploit allowing anybody from network admins to students to researchers and government agencies to be able to test their systems and make sure that their products and systems are patched properly. So for us it's kind of a check and balance system for the vendors where if the vendor says, 'I've released my batch,' you can use Metasploit to verify that the patch was not only installed, but works correctly and there wasn't some additional step that you had to go through to make sure the it works properly. Some have raised concerns in the past about Metasploit not contributing to the whole issue of responsible disclosure. Where do you stand on the whole debate?
At this point the term responsible disclosure has actually been defined by the software vendors. In the scheme of things there are really only two players really involved: the person finding the vulnerability and the vendor who is responsible for fixing it. There's no formal contract between these two parties. The researcher finds a vulnerability and they say here's the issue, here's how I produced it. They tell the vendor and tell the world and eventually the vendor fixes it. Metasploit really doesn't get involved in that whole debate at all. Instead what we do after a vulnerability has been exposed or otherwise published someplace, we'll make it easy for folks to actually verify that their systems aren't vulnerable to it or if they are vulnerable to be able to demonstrate what the real impact of the vulnerability is. Publishing exploit code prior to a patch actually helps software security?
Until there's actually a public proof-of-concept available for a given exploit or for a given vulnerability it's anyone's guess what the real impact is. Sometimes you have vulnerabilities that look really bad on the surface where it says anyone can run code on your computer but when you actually get down to brass tax and try to exploit it you find that there's all these limitations. If you have data execution prevention (DEP) enabled or if you're running this platform or that platform or running in this configuration or that configuration it's really not a big issue at all. So by having a platform that people can use to test these vulnerabilities and verify the real impact of these software flaws it gives people more confidence about not only what they should be doing on the network but whether what they already have in place is working correctly or not. About how many exploits and payloads are available in Metasploit right now?
Everyday it goes up by a couple. I think we're currently up to about 530 exploits and by exploits we define them as any exploit that takes an actual payload. In addition to our 530 or so real exploits we have another 220 or so auxiliary modules, which allow you to exploit configuration errors, do brute force attacks and exploit vulnerabilities that don't provide code execution, but provide data access. For example, being able to grab the content of a c: drive from a server. If you look at the number of Common Vulnerabilities and Exposures (CVE) numbers we cover in Metasploit we're close to almost 500 or so unique CVEs. We have a lot more vulnerabilities that don't have a CVE identifier that we have exploits for. Not every vulnerability has been categorized or has a label placed on it of what it is and what it means. A lot of things have changed for you over the past year. You used to actually pay for Metasploit expenses yourself. How does the acquisition by Rapid 7 actually help the project?
On the Metasploit side, what it's allowed us to do is spend a lot more resources on the areas that really needed it; for example, QA, back-end automation, and database schemas. All the really unsexy parts of the framework that nobody ever wanted to work on. That's what used to be entirely on my plate. Getting a release out used to be entirely on my plate. It involved me spending my entire weekend testing, doing installers and configuration stuff and updating websites. I now have a team that I can hand it off to that can get it done much faster. So, hopefully for the project this means we'll have updates coming out much quicker, more documentation for the features we do add and in the long run we'll have more releases more often. How did the community react to the acquisition? Were there some detractors?
As we continue to put out more code, more releases and more features, I think that skepticism is kind of wearing away. We have seen a lot of new community contributors come on board because of the stability that Rapid 7 brings to the project. Previously folks would use Metasploit internally, but they didn't really feel like they could depend on the project being there a year from now or two years from now. Now that we've got a budget, people and staff who are invested heavily into making sure Metasploit succeeds a lot more folks are willing to contribute to the project because they think it will be around. Is software security getting any better? For example, Microsoft has made a lot of effort in the security world, but it's still issuing a lot of security bulletins each month.
Software security is actually getting much better in piecemeal parts. For vendors like Microsoft where they have a huge budget to work on security issues and have the security lifecycle being built into the software development lifecycle they're actually getting much better relative to where they were five or 10 years ago. The problem is that there are so many software vendors out there and so much of our day-to-day life depends on using software for travel to going on line to ordering a taxi. Everything uses a computer and software at some point. Now every single company that have Microsoft's challenges it had 10 years ago of addressing security vulnerabilities, has to do it all over again. The reason why we see so many flaws and so many vulnerabilities isn't that any particular vendor is doing very poorly. It's just that the number of software applications out there keeps growing day-to-day.

Dig deeper on Security Testing and Ethical Hacking

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close