OWASP's VulnXML Database
Ingo Struck writes "The
Open Web Application Security Project released the VulnXML db for early access to the public. VulnXML is a description of static known vulnerabilities. It provides all necessary information to let an execution engine automatically craft and launch appropriate HTTP, SOAP or WebDAV requests and analyse the response whether the attack had success. Besides it provides some human readable classification of the
described vulnerability. A tool to execute VulnXML records is currently being developed and will help developers to check their web applications against a suite of well-known vulnerabilities described in a portable format."
so we've just replaced script kiddies with a (very small) shell script?
Free as in mason.
This doesn't seem as bad as that...
Scanning scripts exist everywhere, but this isn't one of them. This is a repository for known vulnerabilities, which will serve admins far more than kiddies.
I can quickly check the db for issues on any proposed software, etc....
This is not another virlab.
You'd rather have security through obscurity??
I honestly don't see the purpose in this site or the tool being developed to use it. I use Nessus on a daily basis and it seems to work just fine for this task.
I mean what more could you ask for... a client/server based vuln. scanner that will give you reports in xml, csv, txt, html, doc... Since the site and database has been created, maybe you should just write a program that exports the exploit tests as Nessus nasl scripts so we can do the tests and Snort rules so we can detect testing.
There is no real cure to make tools only available to system administrators and not to script-kiddies. One way that would work is making it very difficult to use, but there will be obviously a nicer frontend for such a tool within weeks (if not days).
I must confess that one of the advantages of closed source is that a vendor could integrate a security measure that would bind a certain serialcode or flexlm key to a certain pool of machines that may be checked by such a tool. This would also slow down script kiddies in getting such a tool to work, but would never be foolproof.
The best way to retain script kiddies from such tools, is educating youngsters before they become 'script-kiddies'. I know of a couple of projects that are trying to do this (for example the Mostly Harmless team in the Netherlands).
-- Cliff Albert