One thing that we emphasize when talking about our database is what it really represents. While we catalog tens of thousands of vulnerabilities more than any other database, we are also upfront that there are still thousands, possibly tens of thousands more vulnerabilities that are already public, but just haven’t found their way into a VDB yet. These are not 0days, vulnerabilities that exist, have been discovered, but remain private. These are public and out there to be cataloged. We have been actively scouring a variety of resources to catalog those vulnerabilities over the last ten years, and we have a long ways to go.
Earlier today I saw an image that really visualizes this point on Twitter via @nitr0usmx. He indicates that the image originates from Fuzz Testing for Dummies by Art Manion and Michael Orlando. As you read about vulnerabilities and patch your systems, remember the bigger picture.
In our pursuit of a more complete historical record of vulnerabilities, we’re offering a bounty! We don’t want your 0-day really. OK sure we do, but we know you are stingy with that, so we’ll settle on your ~ 12,775 day exploits!
First, the bounty. This is coming out my pocket since it is legacy and doesn’t immediately benefit people using us as a vulnerability feed. As such, this isn’t going to be a profit center for you. In addition to the personal satisfaction of helping preserve history, shout outs on this blog and multiple Twitter feeds, I will send you something. Want a gift card for Amazon? Something else I have that you want? I’ll make my best effort to make it reasonably worth your while. I know it isn’t a cool $1,337 Google style unfortunately, but I will try!
Now, what am I after. Not “a” vulnerability, but any of several lists of vulnerabilities from decades ago. These were maintained in the 1980’s most likely, one of which was internal at the time. I am hoping that given the time that has passed, and that the vulnerabilities have long since been patched and most products EOL’d, they can be disclosed. If you don’t have a copy but know someone might, send me a virtual introduction please! Any lead that results in me getting my hands on a list will be rewarded in some fashion as well. If you have a copy but it is buried in a box in the garage, let me know. I will see about traveling to help you dig through junk to find it. Seriously, that is how bad I want these historic lists!
- The Unix Known Problem List (this was not one of the vendor-specific lists, but those may be groovy)
- UC Santa Cruz hack method list
- Mt. Xinu bug list (later than 4.2 or with more details than this copy)
- Matt Bishop’s UNIX Hole List
- Sun Microsystems Bug-List (internal at the time no doubt)
- ISIS mail list archive (one run by Andrew Burt in 80’s)
- Bjorn Satedevas’ systems administration mailing list archive
- The “inner” Zardoz mail list archive (split from the main one, less members)
Any public-referenced vulnerability before 1980 that we do not have in the database. I know there has to be more out there, help us find them!
Bonus bonus bounty (for SCADA types):
Any SCADA or ICS vulnerability before 1985-06-01!
That’s it! Pretty simple, but may require some digging mentally or physically.
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.
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?
Steven Christey of CVE posted asking a question about VDBs and the inclusion of coffee makers. Yes, you read that correctly, vulnerabilities are being found in coffee makers that are network accessible. Don’t be surprised, we all knew the day was coming when every household appliance would become IP aware.
Before you laugh and spew your own coffee all over the keyboard, consider that the vulnerabilities are legitimate in the sense that a remote attacker can manipulate how the device performs and possibly do physical damage to the unit. This is really no different than SCADA devices such as air conditioners that are IP aware.
Some replies (like mine) were a bit more serious suggesting this type of vulnerability is definitely worth inclusion in OSVDB. If we can’t draw the line between coffee makers, air conditioners and other SCADA devices today, we will be able to in a year or years from now? At some point, the blur between computing device and household appliance will be too hard to distinguish. Rather than waste too much time arguing that line, why not track these few vulnerabilities now that might be a bit primitive, but will surely show historic value if nothing else.
Other replies were a bit less serious but fun, suggesting that making weak (or no) coffee would lead to disgruntled code writers that produce poor code filled with more vulnerabilities. Either way, count on us to include vulnerabilities in your favorite IP aware devices, kitchen, computing or otherwise, to this database.
Layered Technologies has provided hosting for the OSVDB production and development servers since October 2007 and continues to support the project. The new servers have been a critical contributing factor to the success and deployment of OSVDB 2.0. In fact, OSVDB 2.0 and the new services that we are now offering have been more resource intensive than we originally thought and we must upgrade.
On Friday, May 16th at 9pm EST we will be taking the OSVDB server offline. The outage should be minimal and service will be restored as soon as possible.
We would like to take a moment to thank Jeremy Suo-Anttila for his assistance and support of the OSVDB project. If you are interested in high quality but affordable hosting with very responsive support we recommend that you contact Layered Technologies.
I should have started a series of these posts long ago. One of the more frustrating parts of most VDBs is the lack of a helpful search function. Searching for some products (SharePoint) is easy enough, as the name is distinct and not likely to find many matches. If you happen to know the script affected (logout.php), that too can make the search fast and painless. However, what if you want to list all vulnerabilities in PHP?
CVE: searching for “php.net” yields 0 matches, while searching for “php” gets 2896 BID: search by vendor, PHP ISS: advanced search, “php.net” will find most, but also include non PHP vulnerabilities SecurityTracker: search “php.net” will find some, but a world of additional threads/advisories Secunia: search “php.net”, pick a PHP vulnerability, click the software link, click vendor link, click the 6 links below corresponding to the major versions
If OSVDB had a complete data set, you could search fairly easily off the vendor name due to our vendor dictionary and listing associated products. Until then, one tip is to search references for “php.net” to pull up a list of all PHP native vulnerabilities. This won’t work for most vendors, but for the bigger vendors we’re trying to standardize our entries and references to facilitate easier searches.
If you know the specific GUID (e.g. 3d742890-397c-11cf-9bf1-00805f88cb72) related to an advisory, or some other odd number or unique identifier, try searching the reference for it. This also goes for advisory identification numbers. Again, the data set is far from complete but we’re trying!
Many years ago I opened a ticket to create a new feature that allowed one to search for vulnerabilities by associated port. Curious what vulnerabilities are related to TCP port 1234 or UDP port 5432? No problem! Until we can get more developers on board and knock out some of these projects, search reference for “tcp port 1234” or “udp port 5432”.
Hopefully, more search tips to come.
I had the need to search for Apache vulnerabilities today for the pesky day job. One word, one search and four hours later I realized just how bad our Apache entries were. Enter headache #1. Unfortunately, the rest of the VDBs were no better. What did I want a concise list of?
- Apache web server vulnerabilities
- Apache Tomcat vulnerabilities
Seems straight forward, and the second search is relatively easy to get at any VDB as “Apache Tomcat” is a consistently used name for the product and distinct enough not to catch other products. So why isn’t the first? Many moons ago, Apache was just “Apache” and everyone knew it was the web server. Eventually Apache branched out and currently maintain an incredible amount of projects. The old “Apache” we all know is really “Apache HTTP Server” which VDBs don’t consistently use, especially the older ones. This is understandable because when CVE added an Apache vulnerability in 1999, that was all there was. These days, just using “Apache” to describe any of their projects is overly vague and irresponsible. Thus, four hours later i’d like to think that OSVDB’s entries are a lot better off for many reasons, that being the first and most simple.
Searching OSVDB by title for “Apache HTTP Server” will now list all vulnerabilities related to the classic web server. One thing you will notice is the different in naming convention for modules. Enter headache #2! Apache modules are not created equal. According to the Apache documentation, module status is labeled according to one of four values:
- Base – modules that are compiled and loaded into the server by default
- Extension – modules that are not normally compiled by default, but must be selected during compilation/installation
- Experimental – modules that are available as part of the apache kit; not necessarily supported
- External – modules that are not included with the base Apache distribution; not supported by Apache
Modules like modinclude and modimap are ‘base’ modules and are part of the Apache web server for most installations. Vulnerabilities in these modules will impact most Apache users. Modules like mod_rewrite are extension modules and must be specifically selected during the configure/make process.
Modules like modperl are .. what? Hello Headache #3. If you check the modperl homepage, you don’t see the easy to spot designation if it is ‘base’ vs ‘extension’, even though it is part of the Apache project. This is more understandable with modssl since it’s an extension and maintained on a non-Apache web page. Apache module authors: please make this clear! Before you fire up your e-mail client to send me obnoxious mails, consider that these are “some” of the supported modules Apache offers, and there are 443 more modules that aren’t supported but definitely useful to many folks. What about moddigest_apple and others? Not fun for those who are tasked with tracking vulnerabilities.
As a result of all this, OSVDB is now using consistent titles to help distinguish all of the above. Here are a few guidelines to help better understand it, and we hope that other VDBs will follow suit to assist their users.
- “Apache HTTP Server” is used for the Apache web server (httpd).
- If the module is ‘base’, ‘extension’ or ‘experimental’, meaning it is part of the Apache distribution, we use “Apache HTTP Server mod_whatever”
- If the module is ‘external’, meaning it is not part of the Apache distribution, we use “mod_whatever for Apache HTTP Server”.
This will help our users more easily distinguish if the vulnerability affects them, assist in searches with more concise results and generally make me feel better about the VDB world.
Yet another “Month of..” bug campaign. This time, the Month of ActiveX Bugs (MoAxB) will focus on vulnerable ActiveX controls. Do a quick title search for “activex” and you will see a healthy history of vulnerabilities related to ActiveX controls. There is already a debate on the Full-Disclosure list regarding if this will be a month of annoying Denial of Service issues, or something more severe.
I previously blogged about the Month of PHP Bugs [MOPB], an effort lead by Stefan Esser and the Hardened PHP Project to raise awareness about vulnerabilities in the PHP language. The month has come and passed and of course I have to wonder about a few things.
1. The project ended up releasing 45 vulnerabilities over 31 days, many of them remotely exploitable. For anyone that was under the delusion that PHP was “pretty secure”, think again. Not only were some remote, many were methods for bypassing the native protection methods PHP offers like open_basedir or issues with various functions designed to filter bad input.
2. These “Month of X Bugs” always get a press blitz before it happens, but we rarely see the same news outlets cover the same thing a month later. It’s nice to see the results of the project, the number and type of vulnerabilities as well as any insights (see comments on previous blog post) the developers had.
3. The PHP project thankfully responded to many of these vulnerabilities already. PHP 5.2.1 and 4.4.5 fix a lot of security issues. Oh wait, that was released two weeks before the MOPB. Where is the next big release that fixes the unpatched issues?
All in all, a very impressive effort. Esser and the Hardened PHP Project have certainly raised the bar for the “Month of X Bugs” projects.