Monthly Archives: October, 2009

More powerful searches, by looking at what’s NOT there…

Sometimes when I read our past blog posts it seems like OSVDB moderators are a broken record. We seem to always say that we had these ideas a long time ago…. We seem to frequently say that VDBs need to evolve……. We say that we would love to do something about it but need resources…….. Times are changing for OSVDB. As you have seen over the past couple weeks, we are extremely thankful for our lead developer Dave as he is making a lot of these ideas happen!

OSVDB has publicly stated several times (e.g., SyScan04 , CanSecWest 2005 and OSBR) that we felt it was important to achieve active integration with security tools to streamline the process of identifying and setting priorities for the creation of vulnerability checks. Our goal is for OSVDB to assist tool developers to identify vulnerability checks or signatures that are not already represented in their products, and will provide a way to identify the high-priority vulnerabilities for immediate attention.

Today we took our first huge step forward to make this happen thanks to yet another improvement in our search engine. A couple days ago I was discussing this idea again with Jericho and the possibility of trying to finally bring it to life. To make it really happen we agreed we would need the search engine to function in a way it hasn’t yet done…. it would need to search for things that are NOT in OSVDB, and need to search based on CVSS scoring / criteria. After spending some time chatting with Jericho he said…… it may be complicated to implement. Well, he definitely underestimated Dave’s ninja development skills as this was knocked out in several hours over two days!

What is the big deal about this feature anyways?

What if for example….

  • …you were wondering which vulnerability scanner / IDS / IPS has the best coverage?
  • …you were trying to figure out which check you should write for your favorite scanner / IDS / IPS?
  • …you were trying to figure out what are the most important vulnerabilities missing from a scanner?

OSVDB can now show you a listing of all vulnerabilities with certain characteritics that are missing a reference as well. Even more powerful, the ability to search by CVSSv2 score or specific attribute.

For example, we can have OSVDB show a listing of all vulnerabilties that have the following:

  • CVSS score between 9 to 10
  • are for Microsoft
  • can be exploited from remote/network
  • and do NOT have a Metasploit reference

Check out the results from OSVDB for the example above.

This search shows that there are 175 entries in OSVDB that Metasploit is missing a check for, that have a high impact. Perhaps this list would be useful to HD and the folks over at Metasploit to determine which exploits need to be included next. As you can see there is a lot more you can do with it. Check out the OSVDB Advanced Search and play with it a bit!

As mentioned this is just the first step and is what we believe will be the basis for much more to come. OSVDB is positioned to be the central source to help review and determine the completeness of commercial security solutions. We believe that OSVDB has an extremely high coverage of all disclosed vulnerabilities and will be able to provide insight into what vulnerabilities are covered (or missing) from a given scanner or tool. We will be able to show the gaps and even provide guidance to users as to which scanner or tool would be best for their organization. Instead of listening to a sales pitch that says “trust us we cover the most vulnerabilities!”, OSVDB will have real data to show that Product X has more coverage than Product Y. We will be in a position to allow a security practitioner to ensure that the products that are critical to their organization are covered in the scanner they are potentially purchasing. As shown above, we can show which vulnerabilities do not have checks (Metasploit, Nessus, Snort, etc) for critical vulnerabilities.

You know… when we find some time it would be a great idea for OSVDB to conduct a bake off on coverage between the top vulnerability scanners and IDS/IPS products. This of course relies on having vendors that are open and share their vulnerability mappings in a format that can be imported into OSVDB. So far, Nikto, Metasploit and Tenable’s Nessus have provided us with these mappings. Another upcoming feature will be a system that allows these vendors to automatically upload updated mappings to keep OSVDB current. Three vendors down, who will be the next to step up?

Some day.

Malware to Vulnerability Mappings.. Anyone?

Unbeknownst to many of us, MITRE’s Common Malware Enumeration (CME) project was declared dead, and apparently has been for a while. What is CME? From their site:

CME was created to provide single, common identifiers to new virus threats and to the most prevalent virus threats in the wild to reduce public confusion during malware incidents. This community effort was not an attempt to replace the vendor names used for viruses and other forms of malware, but instead to facilitate a shared, neutral indexing capability for malware.

With the demise of CME, are there any projects or companies that perform the same role? Specifically, do any maintain mappings between malware and the exploit they use for propagation? Are there any anti-virus vendors that are specifically good about cross-referencing CVE identifiers (or any VDB) to malware?

OSVDB maintains a classification to denote if a vulnerability has been “wormified”, but does not have a mechanism to map more details. When readily available, we will include the malware’s name in keywords, but that is not a flexible solution either. With CME gone, and no obvious vendors or projects that perform this, OSVDB is considering enhancements to fill this void. Before we begin, we’d really like to be sure we aren’t re-inventing a wheel, just replacing a lost wheel (R.I.P. CME). To be clear, we’d only seek to track malware that had a ‘vulnerability’ component to it, not every variation of “CLICKMESTUPID.EXE”. We’ll leave that to the malware detection shops.

What features are sorely lacking from VDBs?

For over ten years, most Vulnerability Databases (VDBs) have done little to evolve. In some cases, they appear to be devolving. OSVDB recognized this many long ago but has struggled for years with a lack of resources, particularly developers. Now that we have saved up enough money, we have hired our only developer part time. Within weeks, Dave has implemented CVSSv2 scoring, enhancements to search, fixes dozens of bugs and already has working mock ups of several additional new features that should fully demonstrate our commitment to evolution. That lead me to think.. while we have dozens of ideas for enhancements and features, what do the users want? Or more to the point, for people who don’t use our database, what features do you find missing from OSVDB or your favorite VDB? What could a VDB do differently, or do better, to make it a (more) valuable resource? No promises on what we can or will implement, but we are all ears. Mail moderators[at]osvdb.org!

Search Enhance: by CVSS Score or Attribute

Using the ‘Advanced Search‘, you can now search the database by entering a CVSSv2 score range (e.g., 8 to 10) or by a specific CVSSv2 attribute (e.g., Confidentiality : Partial). To search for entries with only a 10 score, use the search range 10 to 10.

Using this search mechanism, we can see there are 3,217 entries in the database with a score of 10 and 9,266 entries that involve a complete loss of availability.

We hope this flexibility allows for even more refined searches to better help your project or organization. Stay tuned, this is one of many new search features planned.

Metasploit Reference Support Added & More

This week, HDMoore of Metasploit and OSVDB moderators discussed cross-reference support for each product. As many are now seeing, Metasploit has a search module that allows for fast searches by a number of external references, including OSVDB.

On the OSVDB side, we now support a ‘Metasploit ID’ that currently uses the corresponding OSVDB ID to link and auto-search their database. Based on our testing, this is working great and offers cross-references to 400 Metasploit exploit modules! At the risk of pre-empting HDMoore, I am happy to announce that this is only the first step in the support each project will offer.

In the coming weeks, Metasploit will migrate to a numeric ID scheme to catalog their exploit archive. Each exploit will have it’s own page with what you see now, plus a lot more. With those unique IDs, OSVDB will change the way we link to Metasploit so there is a 1:1 mapping between projects. This will allow us to have accurate coverage for 100% of the Metasploit modules. When this happens, we will display these links under “Tools & Filters” instead of “References” along with a Metasploit logo.

If you weren’t aware, HDMoore created the concept of OSVDB and participated in the original design (~ Aug 2002). That means he has been supporting OSVDB for over seven years now. We’re pretty sure that means we owe him a beer.

Classification: Exploit Status Overhaul

OSVDB’s classification system is designed to categorize certain attributes of a vulnerability. This facilitates custom searches by a specific attribute, helps researchers develop metrics and gives a better picture of the vulnerability landscape. Until now, we’ve tracked if an exploit is ‘available’, ‘unavailable’, ‘rumored / private’ or ‘unknown’. While this was a good start for exploit status, it has quickly outgrown usefulness. Today, OSVDB overhauled the exploit classification to use the following:

  • exploit public – A working exploit is publicly available.
  • exploit rumored – An exploit is rumored to exist, but cannot be confirmed.
  • exploit private – An exploit exists, but is not available to the public or in a commercial framework (e.g., vulnerability pre-disclosure groups like iDefense or ZDI, researcher developed but unreleased).
  • exploit commercial – An exploit has been created and is available to customers in a commercial framework such as Canvas or CORE Impact.
  • exploit unknown – The status of a working exploit is unknown.

In addition, we are moving one existing classification to the ‘exploit’ column since it is relevant to this category:

  • exploit wormified – An exploit has been crafted to spread via ‘worm’ or ‘virus’.

As always, if you have suggestions or questions about the classification system, please mail moderators[at]osvdb.org!

Classification: Minor Touch-ups and Reorganization

In addition to overhauling the ‘exploit’ classification, additional touch-ups and reorganization has been done to the classification system. For volunteers that help mangle entries, watch out as items have shifted in flight. For users of OSVDB, these will be mostly cosmetic changes and should not impact searching.

  • Disclosure column has been re-ordered
  • Location column has been re-ordered
  • Several locations have been touched-up. Use of ‘required’ is consistent now.
  • Context-dependent – Moved from OSVDB to Location
  • Mobile Phone expanded to include ‘Hand-held’ devices that may not be a phone
  • Patch now includes RCS as some fixes are only available from CVS, SVN, etc.
  • Removed ‘best practice’, no longer useful. We do not support SANS Top 20 x-refs any longer, since they don’t support the “20” in the Top 20.
  • Removed ‘no solution’. Until we have more volunteers and timely updates for all entries, ‘solution unknown’ is more accurate.
  • Removed ‘hijacking’ attack type. Obsolete, not really an attack type of its own.

OSVDB Now Supports CVSSv2 Scoring

OSVDB now displays CVSSv2 scores, mostly as calculated by the National Vulnerability Database (NVD):

cvss-score

Along with the score, we display the date that NVD generated it and give users a method for recommending updates if they feel the score is inaccurate. While this is long overdue, this is one of many CVSS related features we will be adding in the near future. For those wondering about the delay in adding CVSS support, the cliff notes answer is “we had reservations about the scoring system”. Back in 2005, Jake and I had a long chat with a couple of the creators of CVSS and brought up our concerns. Our goal was to create our own scoring system, but internal debate (and procrastination) lead to neither being implemented. Rather than creating our own system, we finally opted to use what has become an industry standard. Some of our planned CVSS score enhancements on the to-do list, no particular order:

  1. Method for adding our own CVSS score. There are thousands of entries in OSVDB that do not have a CVE assignment, and as a result, no NVD based CVSS score.
  2. A more robust moderation queue to handle proposed changes. This may optionally have a one-click method for us to notify NVD of our change so they may consider revising their score.
  3. Ensure the CVSSv2 score is part of the database dumps, available for download.
  4. Method for tracking CVSS score historically. As NVD revises their score, or we do, a user should be able to see the history of changes.
  5. Compare our/NVD scores with other public tools, display discrepancy if different. For example, if a Nessus plugin scores an issue differently than NVD, show both scores so users may consider which is more accurate.
  6. Track researcher generated CVSS score. While infrequent, some advisories provide scoring. If different than NVD, display the discrepancy.

As always, if you have ideas on how we could better handle CVSS scoring, or have additional ideas for features, please contact us!

Follow

Get every new post delivered to your Inbox.

Join 5,028 other followers