How do you decide what exploits to work on?
H D Moore: I work on whatever exploit that happens to look interesting, useful, or immediately relevant to other things I am working on.
Is there any plan to develop attacks for embedded devices such as routers, smartphones, PDAs, iPhones, etc?
H D Moore: Absolutely. The difficulty with adding a new platform to Metasploit is that we can't just add exploits and payloads; we must also add architecture-specific encoders, decoding stubs, and nop-generation modules. This is a question of free time and development resources, which have both been very low while we worked on completing the 3.0 release.
And what about rootkits?
H D Moore: Rootkits and other forms of persistent backdoors have not been the focus of the Metasploit Project. We believe there are quite enough tools out there already for this purpose and have no interest in duplicating those efforts. At the same time, we realize that payloads such as VNC injection and the Meterpreter come awfully close to being a backdoor. The distinction is that no new security flaws are created by the use of these payloads. For the most part, all traces of the Metasploit payloads disappear as soon as the victim process exits or the system is rebooted.
Some people claim that your project helps the bad guys do bad things...
H D Moore: The Metasploit Framework strives to be an open platform that anyone can use for just about any purpose. Our users include security researchers, academics, system administrators, penetration testers, software vendors, and yes, even script kiddies. The value provided by making the software available to everyone outweighs any damage caused by the minority that uses the software to illegally access computer systems. The Framework isn't all that great as a script kiddie tool, since the amount of disk space and library requirements make it cumbersome to transfer between compromised hosts.
When you imagine a typical Metasploit user, what do you think of?
H D Moore: If I had to pick an average, I would say a sales engineer at a security product vendor. These folks use Metasploit to demonstrate what their products can do and what their competitor's products can't. I believe these folks actually outnumber the security researcher community.
Some pen-testers prefers doing things "by hands" and don't believe in automatic tools...do you think Metasploit is giving more power to script kiddies, or pros need it as well?
H D Moore: The Metasploit Framework is definitely a "hands-on" tool. Every aspect of exploitation can be controlled, configured, and monitored by the user. Many of the convenience features, such as automatically attaching to a spawned command shell, can be disabled at run time. The automation features in version 3.0 are crude and would likely cause havoc if used on an enterprise network.
The framework is a great way to enhance existing tools and skill sets, but will never replace the role of the penetration tester or skilled analyst. On the flip side, you really need to understand security testing to effectively use the Metasploit Framework. The user must select an exploit, understand which target would be most effective, and choose a payload appropriate for the task. Compared to commercial solutions like Core Impact, Metasploit has a high learning curve and a serious "geek factor". We like it that way.
Do you see a day when exploits and/or frameworks like Metasploit are regulated by the law?
H D Moore: Exploits are already regulated by law in some countries (France and Germany). I do what I can to prevent this from coming to pass in the United States, by donating to the EFF and trying to make a strong case for the usefulness of exploit code. In the US, exploit regulation would kill research and lead to a degrading state of security for all US companies. Vendors patch because exploits are available, without "above ground" exploits that anyone can access, there is no motivation to patch flaws.
Federico Biancuzzi is a freelancer. In addition to SecurityFocus he also writes for ONLamp, LinuxDevCenter, and NewsForge.
This article originally appeared in Security Focus.
Copyright © 2007, SecurityFocus