Metasploit Hacking Tool To Get Services-Based Model

ancientribe writes "Metasploit hacking tool creator HD Moore told Dark Reading that the open-source hacking tool soon will come with back-end services-based features aimed at offloading resource-intensive penetration testing tasks. This is a departure for the software-oriented Metasploit, and Moore and company just may be on to something: it turns out commercial penetration testing tool vendors are looking at adding services-based versions of their software. Immunity Inc. will do so this year, and Core Security Technologies is considering doing so as well."

Legal minefield

[Anonymous Coward]

Do they really expect professional penetration testers to use a third party to attack production networks? Most companies hardly have the guts to even hire a penetration tester. I doubt they'll be thrilled that the list of their vulnerabilities is shared with another company.

Re:

[Who Is The Drizzle]

Do they really expect professional penetration testers to use a third party to attack production networks?

That's what she said!

Re:

[wastedlife]

Not third-party tools, the article is about a third-party company conducting the tests. However, I doubt this is intended for professional pen testers. I think this is intended for companies that do not have a security professional on staff to use.

Re:

[Tekfactory]

But in this case you'd be sending password hashes to Metasploit, they'd crack them and send them back in the clear.

I don't think I'd endorse that to a customer.

Secondly, there are some customers that don't have Internet access to their system, I don't know how useful the password cracking and opcode stuff would be unless you encrypt/export it and sent it to them via FTP.

Production

[jgtg32a]

Who the hell would run a simulated attach on a production network, run it against the test environment, which should mirror production.

Re:

[Tekfactory]

Its about belief, some folks won't trust the model to simulate the production environment. Even if you make the VM or Ghost image right off of the real hardware, and put it onto another machine of the same model with the same specs, someone in the chain of command or legal will want to know if you tested the real thing.

And if it goes far enough, say after a data breach, leave it to a lawyer in court to ask if you on the stand, if tested the live system or some rigged demo designed to fool the auditors.

This doesn't seem timed well

[arogier]

Coming off of the Kaspersky breach yesterday this hitting the news today seems like it should raise some eyebrows. If one well regarded security firm has trouble controlling customer data, does offloading actual penetration testing of your network to a remote system seem very bright. Especially if the penetration test reveals flaws that leave vulnerable information on the remote machines. I don't think its a strictly legal minefield so much as well, a minefield.

"offloading resource-intensive penetration tests"

[timeOday]

In my day we just called them botnets.

Re:"offloading resource-intensive penetration test

[jo42]

In my day, we just ran nmap [nmap.org] on remote Linux boxes.

Re:

[BunnyClaws]

I still do that. I need to get with the times.

Resource intensive?

[Bert64]

Maybe if they hadn't decided to rewrite metasploit in ruby it wouldn't be so resource intensive...
The speed difference between 2.x and 3.x is absolutely insane. Calling the msfcli interface results in 10+ seconds of initialization before it even starts trying to exploit the target, when you have a script calling msfcli multiple times it soon gets tiring... And this is on a fairly modern dual core box. I used to run metasploit 2.x on a much slower single core box and it performed quite well.

Re:

[mindstrm]

This really isn't an obstacle to a professional pen-tester - 10 seconds to fire up metasploit is not a problem.

It's possible that without Ruby, we'd have a much faster, much less feature-rich framework.

Re:

[Anonymous Coward]

A few points:

1. If you are scripting with msfcli, you are probably doing it wrong and should be writing plugins or resources scripts for msfconsole.

2. The module count between 2 and 3 has more than doubled.

3. Its only using one core no matter what, so core counts aren't relevant.

I agree that 3.x is still pretty damned slow, but I disagree that its the languages's fault. The basic issue is a lack of "real" module caching, something we will try to tackle for 3.3. Thanks for the feedback!

Re:

[Shadow-isoHunt]

Agreed. I've griped about Ruby with hdm(you can reach him on freenode, btw), but it's not my project. It does allow rapid development of new modules though, and is simple enough that you can patch together an exploit by copy and pasting bits of code from other modules and then throwing your shellcode in. In short, Metasploit's still the best framework we've got... although nmap's scripting engine is sorta sexy too.

Re:

[Bert64]

You could also rapidly develop new modules in the way you described in perl...
Perl provided a good compromise between speed and ease of development, ruby however, and assembly at the opposite end of the spectrum, just sacrifice too much.
Perl is also already installed and well supported on virtually everything...

Ditching the perfectly working perl framework and rewrite it in what amounts to a "fashionable" language, while effectively rendering the whole thing useless on small devices (think wireless aps, net