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?
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.
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!
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.
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!
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.
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:
- 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.
- 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.
- Ensure the CVSSv2 score is part of the database dumps, available for download.
- 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.
- 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.
- 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!