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."
As always, it sounds like this is a double egded sword -- won't this give script-kiddies a new engine for quickly scanning for possibly vulnerable targets?
Not that I'm saying this is a bad thing -- it's just one more tools that security professionals will have to use to stay ahead of the competition.
Just in time for July 6th!
Now that's security by obscurity! <rimshot />
Thank you, ladies and germs, I'll be here all week.
Carousel is a lie!
so we've just replaced script kiddies with a (very small) shell script?
Free as in mason.
This could also be used to create a "Super" Nessus. Remember that script kiddies and system administrators both use such tools. I think that in the long run, it will help the latter more.
You can't judge a book by the way it wears its hair.
I know security is the first thing that leaps to my mind when I read that name. ;)
The coolest voice ever.
I've used Nessus to scan mine own boxen for months now. Very useful and powerful. Having this shouldn't raise any warning flags, being that a similar tool for this has been around for a long time now.
By the by, turn off stuff you don't need and you'll find most vulnerabilities disappear like magic.
Also, remember to scan your machines from private and public access just in case.
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.
It's a very simple idea, but I've never seen anything like it in an open website. Is this new only because it's not a black hat operation?
From the site:
This database is intended to enable the maintenance of a peer group based set of XML descriptions for web application attacks.
Most people here are comparing this to vulnerability scanners like nessus, but acording to the description provided by the website this appears to be something entirely different. It doesn't check for known vulnerabilities versus services, but rather tries various attacks on web applications. I'm sure that something out there has been created along these same lines before, but I've never heard of it. This sounds like a good idea, and an easy way for inexperienced web application designers to insure that they're not vulnerable to a large database of known attacks.
Sounds pretty cool to me.
...since tomorrow is apparently Defacement Day.
libertarianswag.com
For those interested in open standards for vulnerability assessment, you should check out the Open Vulnerability Assessment Language (OVAL - http://oval.mitre.org/). OVAL provides assessments that DO NOT PERFORM THE ACTUAL EXPLOIT but rather specify logical conditions on the values of system characteristics and configuration attributes to characterize which systems are susceptible to a given vulnerability.
The assessments use SQL syntax but there is an XML version coming soon.
The Open Security Project (OpenSec - http://www.opensec.org/) is also developing a similar standard. The Advisory and Notification Markup Language (ANML - http://www.opensec.org/anml/) is not only working on assessment but an entire advisory format in XML.
If people would stick to the relational model, then XML would not be of much use above what a slightly improved comma-delimited format could provide.
I know, some of you don't feel that highly about relational and prefer the older "navigational" formats, but I think relational offers more consistent and logical organization rules and has a better "algebra" to go with it. It is harder to make cross-reference, normalization, and referential integrity rules with structures like XML (except under rare circumstances).
Dr. Codd was a terrible marketer, but he was otherwise a genius.
Table-ized A.I.
That is very interesting. .
http://www.devmaster.net/ - A Game/Graphics Development website.
Immunity's SPIKE Proxy (http://www.immunitysec.com/spike.html) offers a python, GPL, VulnXML engine, and has for some time. VulnXML is superior to Nessus-style scripting in many ways for purely web-based assessments. Similar to how Nessus says "for all ports that have a web server on them, run these tests" VulnXML allows a fully interoperable and "self-descriptive" way to say "For all files on the web server, check for file.bak, but ignore custom 404 pages that return 200 OK, etc".
Why not just ZIP, RAR, or otherwise compress the file? Does there need to be a separate standard?
Why not just ZIP, RAR, or otherwise compress the file? Does there need to be a separate standard?
Because processing reams of text-delimited markups and arrays of text-encoded numbers or blobs is sloooooow. It's not about compression, but you can GZIP/whatever either text or binary.
For scientific data in XML, the process is to take an array of numbers, convert the numbers to text (expensive), compress the numbers (which is slow, especially because of the bulk of the numbers), transport, uncompress, and re-parse the numbers (expensive) back into binary. It's much more sensible to take the binary numbers, dump them out in a raw write(), compress (faster, because of less input plus extra speedup with GZIP anyway because of data properties), fetch with a raw read(), and sometimes do endian swap. No encode/decode, and the GZIP compressed data anyway is actually smaller (less redundant junk in the stream to begin with).
1. take VulnXML db
2. convert to OpenSTA script
3. run OpenSTA
Ceci n'est pas une signature
The only thing to fear (potentially) is that all those signatures are getting written now! And I'll agree with SHEENmaster that the creation of security tools, while a double-edged sword, benefits defenders even more than attackers.
-
Wouldn't a machine-readable vulnerability database allow for a worm that could keep up to date with the latest vulnerabilities by itself?