At a glance, it may appear as if the OSVDB project has fallen by the wayside. Some of our public facing pages have not been updated in several years, the last string of blog posts was over a year ago, and a recent update caused a few functions to fail (e.g., data exports). On the other hand, anyone paying attention to the data has noticed we are certainly present and moving forward. We have had one person working full time on OSVDB for over a year now. He is responsible for the daily push of new vulnerabilities and is scouring additional sources for vulnerabilities that didn’t appear through the normal channels. Given the nature of the project, we place data completeness and integrity as the top priority.
The OSVDB project is coming up on its tenth year anniversary. The last ten years have seen some big changes, as well as many things that have not changed one bit. The biggest thing that hasn’t changed is the lack of support we receive from the community. The top ten all time contributors are the core members of OSF, the handful of longstanding dedicated volunteers we have had over the years, or some people we have been able to pay to help work on the project. Beyond those ten people, the volunteer support we lobbied for years never materialized. We still enjoy a couple dozen volunteers that primarily mangle their own disclosures, or add CVE references, which we appreciate greatly. Unfortunately, the rate of vulnerability disclosures demands a lot more time and attention. In addition to the lack of volunteers, community support in the form of sponsorship and donations has been minimal at best. Tenable Network Security and Layered Technologies have been with us for many years and have largely been responsible for our ability to keep up with the incoming data.
Other than those two generous companies, we have had a few other sponsors/donations over the years but nothing consistent. In the last year, we have spent most of our time trying to convince companies that are using our data in violation of our posted license to come clean and support our project. In a few cases, these companies have have built full products and services that are entirely based on our data. In other cases, companies use our data for presentations, marketing, customer reports, and more while trying to sell their products and services. Regardless, the one thing they aren’t doing is supporting the project by helping to update data, properly licensing the data or at least throwing us a few bucks as an apology. In short, several security companies, both new and well established, that sell integrity in one form or another, appear to have little integrity of their own. After a recent server upgrade broke our data export functionality, it was amazing to see the number of companies that came out of the woodwork complaining about the lack of exports. Some of them were presumptuous and demanding, as if it is a Constitutional right to have unfettered access to our data. Because of these mails, and because none of these companies want to license our data, we are in no hurry to fix the data exports. In short, they don’t get to profit heavily off the work of our small group of volunteers, many of whom are no longer with us.
Even as an officer of OSF and data manager of OSVDB, I honestly couldn’t tell you how we have survived this long as a project. I can tell you that it involved a lot of personal time, limping along, and the hardcore dedication of less than a dozen individuals over ten years that made it happen. With almost no income and no swarm of volunteers, the project simply isn’t sustainable moving forward, while still maintaining our high standards for data quality. We gave the community ten years to adopt us, and many did. Unfortunately, they largely did it in a completely self serving manner that did not contribute back to the project. That will be ending shortly. In the coming months, there will be big changes to the project as we are forced to shift to a model that allows us to not only make the project sustainable, but push for the evolution we have been preaching about for years. This will involve making the project less open in some aspects, such as our data exports, and has required us to seek a partnership to financially support our efforts.
For ten years we have had a passion for making OSVDB work in an open and free manner. Unfortunately, the rest of the community did not have the same passion and these changes have become a necessity. The upside to all of this is that our recent partnership has allowed us to develop and we will be offering a subscription data feed that has better vulnerability coverage than other solutions, at a considerably better price point. That said, the data will remain open via HTTP and for a 99% of our users this is all that is required. When exports are fixed, we will offer a free export to support the community, but approval will be required and it will contain a limited set of fields for each entry. We are still working out the details and considering a variety of ideas to better support a wide range of interest in the project, but doing so in a sustainable manner. In the end, our new model will help us greatly improve the data we make available, free or otherwise and ensure OSVDB is around for the next 10 years.
In previous blog posts and on Twitter, I have shown and mentioned various methods for searching OSVDB to find interesting data. However, there is no written guide to the ins-and-outs of the data. The search interface is simple enough, but it can be used in a manner that allows for some complicated and useful searches that are not immediately obvious. This blog post will show several examples and highlight some of the interesting data we have available, along with an explanation to the method of our madness.
The OSVDB classification system allows for a variety of one-click searches. Using the search interface and selecting any of the classifications (single, or multiple) will let you quickly search for denial of service, exploit public, security software, and a lot more. Note that our data set is not complete, and not all of our entries have classification data. Do not rely on this type of search for complete results. Over time as the data set is completed, it will provide powerful one-click searches that will make for interesting metrics.
While our classification system is robust, it has been a struggle for us to determine if we want to add classes of issues as a new classification option, or use specific keywords that can be searched for. While a classification box is convenient, it can quickly become bloated if there are hundreds to choose from. We have “security software” as a classification because of the irony in software designed to protect you from threats adding to your vulnerability footprint. In the coming year, we may expand the ‘OSVDB’ classification box to allow for additional searches, where that box can be hidden entirely if desired. Until then, there are several fun keyword-based searches you can do:
- SCADA, the hot topic lately. Using the “vulnerability text” field, input “SCADA” and select “All Text” (defaults to “Titles only”). This will bring back all vulnerabilities related to SCADA products.
- Another field that has been interesting to us for several years, that will likely gain more attention this year in the wake of recent election problems, is Electronic Voting Machines. We’ve all read articles about the insecurity of Diebold for example. But have you looked at just how bad it is, and how bad the other vendors are? Do a “vulnerability text”, “all text” search for “electronic voting machine”. Prepare to be scared for the coming elections.
- There has been an increasing interest in vulnerabilities in embedded computers found in cars. While “car hacking” has been going on for many years, a big part of that field is based on modding and enhancing a car, not so much exploiting vulnerabilities in it. OSVDB has only delved into this topic a little bit so far, but it has been on our radar for some time. Doing the same “all text” search for the word “automobile” will bring up what we have. There are dozens of research papers and sites on our list to check out as time permits.
- We have spent a lot of time digging into the history of encryption algorithms, noting when they were effectively compromised or proven vulnerable to varying degrees of practical attacks. Having these in the database makes for an interesting history, great reference, and potentially helpful to pen-testers that find applications using insecure algorithms. Even if you don’t have time to leverage the weakness during the test, you can provide a standardized reference in the report. To find these, do a “vulnerability text”, “title only” search for the word “algorithm”.
- Using specific keywords in our standardized titles, quick searches can be performed for other interesting sets of vulnerabilities. For example, the word “hardcoded” is used to denote when a vendor uses an account name, password, community string, or other piece of identifying / security information in a manner that does not allow the user to change it. It is scary to see that hardcoded accounts and credentials are still being used in 2012, by security vendors no less. In a similar vein, the word “persistent” is used to denote other conditions where some form of weakness will continue to be present, regardless of administrative action.
Other interesting search tips:
- “all text” word searches; botnet shows the increasing vulnerabilities found in botnet software
- Want to find vulnerabilities in Drupal, but not all those third-party modules? Title search “drupal -module -theme” to see the ‘core’ software issues.
- Similarly, title search for “wordpress” and “wordpress -plugin” to get a feel for the disparity in vulnerabilities between the core software and third-party plugins.
These represent just a few examples of the types of searches you can perform using OSVDB to ferret out interesting data and vulnerabilities that tend not to make it in the other VDBs.