Son of SATAN? Weighing Security Software's Risks
ryanr writes "Rob Lemos put out an article on the new metasploit relese. The article reminds me of the furor over the original SATAN being released. H.D. Moore, who wrote it, rightly points out that there are commercial tools that do it better, and it's known that the kiddies have copies of those. Why pick on the open-source tool? I think Rob is being a bit provocative." Despite the headline ("Security tool more harmful than helpful?"), the article is actually pretty balanced.
This is nothing more than a API for hackers. It could be used as a security tool but the vast, overwhelming, majority of people who download this will be using it to hack people.
Some sleepy thoughts before I crash...
This is the time-old argument of gun's dont kill people, people kill people. Except, it is now being applied against electronic "tools". Another saying comes to mind "if you outlaw xyz, then only outlaws will have xyz".
A decade ago, black-hat hackers and security administrators did not have the same access to information and tools that we have today. Crackers are no longer working in the dark, reverse engineering operating systems and applications/services from scratch. Operating system source code is readily available for both the open-source systems (Linux/BSD), along with most of the commercial variants (HP/Solaris/etc) in the black-hat community. With access to this information, they're able to literally scan the code for bad programming practice (grep sprintf) to quickly identify vulnerabilities.
This open-source transparency has been both a blessing and a curse for the open OS's - in that vulnerabilities can quickly be found by an enterprising auditor, but likewise can be quickly closed by any decent programmer. This is not the case however with the closed platforms, because the source is not available.
Likewise with penetration tools. When a vulnerability comes out, such as the infamous PHF bug, a cracker can within a few minutes put together a crude scanner to identify these systems for exploitation. Likewise a security administrator can and needs to use a similar tool to audit his network for any sign of the vulnerability.
However, there should be some industry self-policing going on regarding the public release of certain tools. For example, if a vulnerability emerges and you want to scan and actively "test" whether you are vulnerable (instead of soley checking a service banner - you try to exploit the vulnerability), the test does not need to grant you uid 0. Instead, you can release a binary tool which simply created a root-owned file on the server, in / , called "YOU_ARE_VULN_TO_X". Both tools will confirm whether or not you are vulnerable - but one is significantly less vulnerable to abuse (by the average script kiddy) than the other.
However, in the long run, the security industry is a very profitable one, and one way to get a head start is to be prolific and vocal in releasing high-quality exploits (and hoping to get noticed by a security company). This is as much about ego as it is about getting a cool job, and while that attraction is there, you're going to keep seeing security tools with no restrictions emerge.
This one.
Dave Aitel
Immunity, Inc.
how is this post any better than The original story posted a couple of days back?
sheesh! you guys are seriously losing it when an AC like myself can come along and whoop your sorry posting asses!
maybe Slashdot can have a new points system where proven dupes can get points taken from their posters!
RMS already made that prediction, in The Right To Read (which is a really interesting read, by the way). The relevant passage:
His version of the prediction is a bit different, but it's the same idea. If you read through the entire story you will find an astonishing list of seemingly absurd predictions which are coming true one at a time. It's a bit unnerving to read, really.
The original SATAN was introduced by Dan Farmer back in 1995.
The article reminds me of the furor over the original SATAN being released. H.D. Moore, who wrote it, rightly points out that there are commercial tools that do it better, and it's known that the kiddies have copies of those. Why pick on the open-source tool? I think Rob is being a bit provocative." Despite the headline ("Security tool more harmful than helpful?"), the article is actually pretty balanced.
Is this sig nificant?
Dameware is a good example of a commercial tool, albeit not designed specifically for security probing, it is for remotely controlling (if maliciously: exploiting) machines. I've seen examples used "in the wild" to take over machines to serve as warez sites, and it is "standard" enough that you can often monitor plenty of dameware-specific traffic on an infested network. Versions have also been modified or grafted onto other programs to do malicious probes. So, by themselves, no, there aren't necessarily tools to run exploits and install shellcode, but remote administration could be regarded as equivalent in some ways, or with a bit of tweaking, turned to such ends.
If cracking tools are widely available, they will be used to more quickly exploit whatever vulnerabilities exist, giving the author less time to patch. It's better for everyone if these tools are hard to come by.
There are a number of things wrong with your last statement. The biggest is that most people don't patch at all, and if they do, it is often only after some news media has reported major exploitation going on in the wild.
Another thing is that software companies don't release patches unless there is an exploit (This is changing for the better though), and often the so called "fix" only stops that particular exploit from working.
And thirdly, in order for exploit tools to be "hard to come by", you have to stop telling people that there is a problem/bug (otherwise, there is always some kid who will create a exploit, in order to educate himself about security problems, and then release it for the recognition by peers).
In short, you would have to go back to the "good old days" of ~1990 where very few people had access to security information and the few that had the exploits could walk in and out of whatever systems that interested them. The print spooler exploit existed for at least two years before the problem was patched (three years for Sun systems because they patched it a year after everybody else) !!
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
Hang out on the IRC channels where hackers congregate. Get to know them. Gain their trust. See what kinds of tools they use.
Admittedly, most of these script-kiddies can't write the tools they use. But when they find a good tool they spread it around quickly. They ARE using commercial tools that have been hacked. If this particular tool seems better for their hacking than what they have, they'll use it too. Does that mean we have to take the tool out of white hats' hands because the black hats might get it and use it?
This reminds me too much of the old gun argument: if security tools are outlawed, then only outlaws will have security tools.
I've tried all of them: metasploit, CANVAS and CORE IMPACT. CORE IMPACT is by *FAR* the best.
p ://www.metasploit.org/m /CANVAS/
http://www.corest.com/products/coreimpact/
htt
http://www.immunitysec.co
core impact: (i've tried v3.2 & v3.3): very well polished, lot of exploits (remote,locals,client side) (reliable exploits), full of information gathering tools. Weekly updates of exploits. nice GUI. very nice reports.
exploits are in python.
Ask for a demo, buy it or use edonkey.
metasploit (I've tried 2.0): few exploits, some of them reliables. no information gathering tools, no reports. no GUI.
exploits are in pearl.
free.
CANVAS (I've tried 3.0): few exploits. no Information gathering tools, no reports. portable GUI.
exploits are in python.
buy it or search in chinesie sites.
If you're thinking in doing a serious pent. test use impact.
metasploit is an open source framework.
But I think impact and canvas also has some "open source" code. In fact, "inlineegg" which was released in metasploit is one of impact's open source projects.
http://oss.coresecurity.com/
canvas has its own "inlineegg" called mosdef:
http://www.immunitysec.com/MOSDEF/