Metasploit and software vulnerability testingDate: Apr 09, 2010
Metasploit is a free tool that can be used to pen test for new and potentially damaging vulnerabilites. In this interview, H.D. Moore, creator of Metasploit, explains how the tool works and what it can contribute to software security.
Also, watch this demo and learn how to use Metasploit for penetration testing.
Read the full text transcript from this video below. Please note the full transcript is for reference only and may include limited inaccuracies. To suggest a transcript correction, contact firstname.lastname@example.org.
Metasploit and software vulnerability testing
Rob Westervelt: Hello. I am Rob Westervelt, the News Editor of
Thank you very much for joining us and watching this video. Today we
are going to be talking about vulnerability management and Metasploit
with H.D. Moore. H.D. is Chief Architect of Metasploit, and also Chief
Security Officer of Rapid 7. H.D., thank you very much for joining us.
H.D. Moore: Thank you for having me, Rob.
Rob Westervelt: H.D. let us start off with just an overview. Explain how Metasploit
actually contributes to software security.
H.D. Moore: Metasploit is a software framework for both finding vulnerabilities,
exploiting them, and using them in a pen test. It is an open source
toolkit that is really driven by the community and for the community,
started about seven years ago, where anytime any vulnerability is
discovered, we create a safe version of the exploit, add it to
Metasploit and allow anyone from network admins, to students, to
researchers, to government agencies to build a test and make
sure that their products and their systems are patched properly. For
us, it is a check and balance system for the vendors, where if the
vendor says, 'I have released my patch,' you can actually use
Metasploit to verify that the patch was not only installed but works
correctly and there was not some additional step you had to go through
to make sure the patch actually works properly.
Rob Westervelt: 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?
H.D. Moore: Responsible disclosure is an interesting issue where at this point,
the term responsible disclosure has actually been defined by the
software vendors. In the scheme of things, there are only two players
really involved: there is the person finding the vulnerability and the
vendor who is responsible for fixing it. There is no formal contract
between these two parties. The researcher finds a vulnerability, they
say, 'Here is what the issue is. Here is how we reproduced it,' they
can tell the vendor, they can tell the world, and eventually the
vendor fixes it and patches it. Metasploit does not really get
involved in that debate at all. Instead what we do is after a
vulnerability has been exposed or otherwise published someplace, we
will make it easier for folks to actually verify that their systems
are not vulnerable to it, or if they are vulnerable, be able to
demonstrate what the real impact of the vulnerability is.
You can say, 'This new Internet Explorer vulnerability came out, it is
used to hack into Google and these other companies. How does this
affect my systems? Do my existing protection mechanisms protect me
against that?' That is a case where we got access to a vulnerability
that was unpatched. We add it to Metasploit, and even though there is
no patch available, it was public knowledge at that point, and it
allows anybody with enterprise network that wants to verify that what
they have actually works properly, to test their own systems.
Rob Westervelt: Publishing exploit code prior to a patch actually helps software
H.D. Moore: That is what we see. For the most part when, until there is actually
a public-proven concept available for a given exploit or for a given
vulnerability, it is 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 in your computer. When you actually get down
to brass tacks and try exploiting it, you find all these limitations
saying, 'If you have DEP enabled, NX enabled, or if you are running in
this platform or that platform, of you have configured it in this way,
you can get around it and it is not really a big issue at all.' By
having a platform, people can actually 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.
Rob Westervelt: About how many exploits and payloads are available in Metasploit
H.D. Moore: It is flying up, everyday it goes up by a couple; I think we are
currently at about 530 exploits. By exploits we define them as any
exploit that takes an actual payload, and that is native Shell code
executions, command executions, something like that. In addition to
our 530 or so real exploits, we have another 220 or so, what we call
auxiliary models, which allow you to exploit the configuration errors,
do brute force attacks, exploit vulnerabilities that do not provide
code execution but provide data access. For example, being able to
grab the contents of the C drive from a server, we have exploits for
like Veritas Backup Exec products. We have models for that, that fall
into auxiliary category, but not the exploit category. If you look at
the total number of CV IDs that we cover in Metasploit, we are close
to, I want to say we are almost to 500 or so, unique CVs, but we have
a lot more vulnerabilities that do not have a CV identified, that we
have exploits for.
Not every software vulnerability has been categorized, or otherwise
has a label placed on it about what it actually is and what it means.
We have 500 bugs that we know are ones people know about and
understand, and another 250 or so, that are issues that are anything
between a default password or a misconfiguration, where there just is
no patch for, or there is no CV identifier for it. There are a lot of
software products where in the course of Intervest getting one flaw
that was patched by a particular issue, we find three or four more,
and they are all patched, they are all part of the same thing, but
they do not have the same CV ID because they are different issues,
Rob Westervelt: A lot of things have changed for you over the last year. You used to
actually pay for Metasploit expenses yourself. How does this
acquisition by Rapid 7 actually help the project?
H.D. Moore: On the Metasploit side, what it has allowed us to do is spend a lot
more resources on improving areas that really needed it. For example,
QA, back-end automation, database schemas, all the really unsexy parts
of the framework that nobody ever wants to work on, that is what we
used to be entirely on my plate. Getting a release out used to
basically, involve me spending my entire weekend just testing,
testing, testing, doing install, different integration stuff, and
updating websites. I now have a team that I can hand that off to, to
actually get it done much faster. Hopefully for the project this will
mean that we have updates coming out much quicker, much faster, more
documentation for the features that we do add and in the long run, we
will actually add more releases more often.
Rob Westervelt: How did the community react to the acquisition? Were there some
H.D. Moore: As we have continued to put out new code, new features, and new
releases, I think a lot of the skepticism is wearing away. What we
have seen is a lot of new community contributors came on board because
the stability that Rapid 7 provides to the project. Previously, people
would use Metasploit internally, but they did not really feel they
could depend on the project being there a year from now or two years
from now. Now that we got a budget and people on staff, and we are
actually invested heavily in making sure Metasploit succeeds, a lot
more folks are willing to contribute to the project, because they
realize we will be around two years from now.
Rob Westervelt: H.D., is software security getting any better? Microsoft for example,
last month had 13 bulletins patching 26 vulnerabilities. I know they
have made a lot of efforts in the security world with their SDL,
making it public so that other companies can use it.
H.D. Moore: 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 this security lifecycle being built into
their product development cycle, they are actually getting much
better, relative to where they were five or ten years ago. The problem
is there is just so many software vendors out there. So much of our
day-to-day life really depends on using software for booking travel,
to going online, to ordering a taxi; everything uses a computer and
software at some point. Every single company that had the same
challenge that Microsoft did ten years ago of, 'How do we address
security vulnerabilities?' has to do it all over again, for each of
these little sub-companies out there. The reason why we see so many
flaws and so many vulnerabilities is not because any vendor's doing
particularly poorly, it is just that the number of unique software
applications out there just keeps growing day-to-day, so there is
probably going to be an increasing number of vulnerabilities, as long
as we have software.
Rob Westervelt: There is some researchers out there that are actually working on
self-defending applications, the whole notion of building in defense
and detection capabilities into applications. Do you think that will
H.D. Moore: At the end of the day, software is designed for a particular purpose,
whether that is ordering coffee, getting you a taxi, or getting a Word
document. The more resources you spend, specifically on security for
things like Action Defense, the more you are taking away from the
development of your product itself. One of the reasons why we see so
many software flaws is that these products are designed to go to
market at a certain point, at a certain date, with certain feature
sets. If you have to cut corners to get there, it happens, it is a
business decision at that point it is not a software security
decision. Having the ability to do self-healing and self-defending
software is great, but it is all going to be at the cost of either
licensing for the technology or development time to get it integrated.
I commend them for doing it, I think it is a great idea, hopefully it
will have good long term impact, but I do not believe it will
significantly make a difference in the short term.
Rob Westervelt: H.D., thank you very much.
H.D. Moore: Thank you for your time.
Rob Westervelt: Thank you for joining us. For more information on this topic you can
go to SearchSecurity.com, or for more videos check out