Category Archives: General Vulnerability Info

Rebuttal: Dark Reading’s “9” Sources for Tracking New Vulnerabilities

Earlier today, Sean Martin published an article on Dark Reading titled “9 Sources For Tracking New Vulnerabilities“. Spanning 10 pages, likely for extra ad revenue, the sub-title reads:

Keeping up with the latest vulnerabilities — especially in the context of the latest threats — can be a real challenge.

One would hope this article would help with that challenge, and it most certainly is one. First, a disclaimer; I was involved with OSVDB for roughly 10 years and the primary curator over that time. Further, I am now involved with Risk Based Security’s VulnDB commercial vulnerability database offering. Both of these are mentioned in the article, so my comments below will most certainly have some level of bias.

To help readers, Sean Martin writes “In no particular order, here are nine key vulnerability data sources for your consideration.” With that, flip to the next page of the article.

It’s important to understand the source — and backing for your source — to avoid getting left without a solid vulnerability database. A good example is the case where many had to say goodbye to their vulnerability feed when minority-player Open Source Vulnerability Database (OSVDB) was shut down.

“Not having OSVDB any longer, while sad for those that relied on it, may actually reduce the complexity in making sure there is integration across all products, MSSPs, services, and SIEMs,” says Fred Wilmot, chief technology officer at PacketSled

I am not sure how OSVDB constituted a “minority-player” in any sense of the term given the broad coverage for a decade. While historical entries were often incomplete, the database was commercially maintained from just before January, 2012, and the information was still given away for free, despite competing with the company providing the support and updates. Since the quote specifically mentions that OSVDB shut down, and it did on April 5, 2016, it’s nice to hear people give belated appreciation to the project. OSVDB shutting down, I would argue, does not reduce the complexity of anything for those knowledgeable about vulnerability disclosure. On the surface, sure! One less set of IDs to integrate across products sounds like a good thing. However, you have to also remember that OSVDB was cataloging thousands of vulnerabilities a year that were not found in the other sources listed in this article. That means there is a level of complexity here that is horrible for companies trying to keep up with vulnerabilities.

Page 3 tells readers about NIST’s National Vulnerability Database (NVD):

NVD is the US government repository of standards-based vulnerability management data. This data enables automation of vulnerability management, security measurement, and compliance. NVD is based on and synchronized with the CVE List (see next slide).

First, since NVD is synchronized with CVE, it is curious that they are listed as separate sources. For those not aware, NVD is a sort of ‘value add’ to CVE in that they generate CVSS and CPE data for the vulnerabilities cataloged by MITRE for the CVE project. Monitoring NVD means you are already monitoring all of CVE and getting the additional meta-data. It is also important to note that the meta-data is outsourced to a contractor who employs ‘junior analysts’ to do the work. This becomes apparent if you consume there data and actually look at their CVSS scores over the last ~ 8 years. Personally, I stopped emailing them corrections many years back due to the volume involved. To this day, you can still often see them scoring Adobe Flash vulnerabilities as CVSSv2 10.0, meaning they miss the ‘context-dependent’ (a.k.a. ‘user-assisted’) aspect which means the access complexity moves from ‘L’ow to ‘M’edium per the CVSSv2 scoring guide on FIRST, resulting in a 9.3 score. Seems minor, but that reclassifies a vulnerability from ‘Critical’ to ‘High’ for many organizations, and should make you question their scoring on more complex issues.

Page 4 tells us more about CVE and offers some “insight” into it that is horribly wrong:

CVE is a dictionary of publicly known information security vulnerabilities and exposures. CVE’s common identifiers enable data exchange between security products and provide a baseline index point for evaluating coverage of tools and services.

Morey Haber, VP of technology at BeyondTrust, offers these examples:
Scanning tools most commonly use CVEs for classification
SIEM technologies understand their applicability in reporting
Risk frameworks use them as a calculation vehicle for applied risk to the business

First, I cannot over-share Steve Ragan’s recent article titled “Over 6,000 vulnerabilities went unassigned by MITRE’s CVE project in 2015“. Consider just the headline, and then think about the fact that CVE does not catalog at least 47,267 vulnerabilities historically. Now, re-read Haber’s examples of how CVE is used and what kind of Achilles’ heel that is for any organization using security software based on CVE.

Fred Wilmot’s quote about CVE is what prompted me to write this entire blog. This is so incredibly wrong and misleading:

“Now that you have a common calculator for interoperability among vendors, the fact that CVE is maintained completely transparently to the community is a HUGE pro,” says Fred Wilmot, chief technology officer at PacketSled. “There is no holdout of exploits for vulnerabilities based on financial gain or intent. It’s altruism at its best. The weakness in the CVE comes in the weaponization of that information and the lack of disclosure for profit and activism, as two examples.”

Where to start…

  1. There is no common calculator for “interoperability among vendors” in the context of CVE. That isn’t what CVE is or does.
  2. CVE is most certainly not maintained transparently to the community. It is not maintained transparently to the volunteer Editorial Board (now known simply as the ‘CVE Board’) either. The backroom workings and decisions MITRE makes on behalf of CVE without Board or public input have been documented before. The last decision that lacked any transparency was their recent catastrophic decision to change the CVE format to a new ‘federated’ scheme. If you have any doubt about this being a backroom decision, look at the first reply from CVE Board member Kurt Seifried.
  3. Wilmot’s characterization that CVE is “altruism at its best” also speaks to a lack of knowledge of CVE. While MITRE, the organization that maintains CVE, is technically a not-for-profit organization, they only take non-compete contracts at incredible expense to the U.S. taxpayer. CVE, and a handful of other ‘C’ projects related to information security, bring in considerable money to the company. In 2015, they enjoyed over $1.4 billion in revenue and maintained $788 million in assets. The fact that the contract to maintain CVE is non-compete, and cannot be bid on by companies more qualified to run the project, speaks to where the real interest lies and it isn’t altruistic.
  4. The weakness in CVE is certainly not the “weaponization” of that information. A significant majority of weaponized exploits that lead to the thousands of data breaches and organizations being compromised are typically done with functional exploits that enjoy little technical information being made public. For example, phishing attacks that rely on Adobe Reader or Adobe Flash are usually patched by Adobe eventually, and the subsequent disclosure has no technical details. Even if researchers post more details down the road, the entries in CVE are rarely updated to include the additional details.
  5. The last bit of Wilmot’s quote, I will need someone to explain to me. “The weakness in the CVE [..] comes in the lack of disclosure for profit and activism.” I don’t know what that means.

Page 5 tells readers about the CERT Vulnerability Notes Database:

The Vulnerability Notes Database provides information about software vulnerabilities. Vulnerability notes include summaries, technical details, remediation information, and lists of affected vendors. Most Vulnerability notes are the result of private coordination and disclosure efforts. For more comprehensive coverage of public vulnerability reports, consider the National Vulnerability Database (NVD).

“This is nice to have, but it still uses CVEs as reference,” says Fred Wilmot, chief technology officer at PacketSled. “NVD is not nearly as practical to consume directly as CVE — the disclosure form is fine, but why would I go there and not directly to MITRE for CVE establishment first? However, it’s probably a good place to spend time during an investigation.”

The CERT VNDB is not a comprehensive vulnerability database, and does not aim to be one. As mentioned, their information is primarily via their assisting researchers in coordinating a disclosure with a vendor. Since CERT is a CNA, meaning they can assign CVE IDs to vulnerabilities they coordinate, it means that over 99% of their entries are covered by CVE and thus NVD. Monitoring NVD will get you all of CVE and almost all of CERT VNDB. The very few CERT VU that do not get CVE IDs assigned before disclosure are rare, and I believe they get assignments shortly after from MITRE.

Once again, Wilmot speaks about these sources and doesn’t appear to have real working knowledge which personifies my term ‘vulnerability tourist’. CERT VNDB disclosures appear on their site before they appear in CVE or NVD. It may be 24 – 72 hours before they appear in fact, meaning that while it still uses CVEs as a reference, for timely monitoring of vulnerabilities it may be important to keep an eye out on CERT directly. Next, Wilmot goes on to say “NVD is not nearly as practical to consume directly as CVE”, apparently not realizing that NVD makes its data available in XML. While MITRE makes the CVE data in several formats, it doesn’t mean NVD is not easy to consume. The most important distinction here is that NVD comes with CPE data where CVE does not. For any medium to large organization, this is basically mandatory meta-data for actually putting the information to use.

Page 6 tells readers about Risk Based Security’s VulnDB offering. The curious bit to me is the quote from Morey Haber:

“VulnDB does not contain audit information, but it is a good source for solutions that need to reference vulnerability information in their products such as firewalls or IDS/IPS and do not want to rely on open source or to build/maintain a library,” said Morey Haber, VP of technology at BeyondTrust.

First, BeyondTrust is not a user of VulnDB, which is a commercial offering unlike CVE/NVD/CERT. They did a short-term trial in 2012, during the beginning of the offering and opted not pursue it as a source of vulnerability intelligence. Second, what does “audit information” even mean in the context of a VDB? Audit information about your own environment maybe? Something that a vulnerability intelligence provider can’t possibly deliver. An audit trail is maintained for each vulnerability entry and is available to customers, but I doubt that is what he means since calling VulnDB out on this doesn’t make sense and the other sources of vulnerabilities listed in this article don’t maintain such a trail.

While VulnDB can certainly be used to reference vulnerabilities in security products as he says, that is the tip of the iceberg. With over 47,000 vulnerabilities not found in CVE or NVD, the breadth of information is incredible. Further, VulnDB has made a concerted effort for years to track vulnerabilities in third-party libraries, and builds on top of the robust meta-data that has been generated for over a decade. Haber’s comments do not reflect actual knowledge of the VulnDB offering.

Page 7 tells readers about the DISA IAVA Database And STIGS. Haber gives commentary on this as well:

“IAVA, the DISA-based vulnerability mapping database, is based on existing SCAP sources, and once in a while it contains details for government systems that are not a part of the commercial world,” says Morey Haber, VP of technology at BeyondTrust. “For any vendor doing .gov or .mil work, this reference is a must.”

While some of the IAVA advisories may contain additional detail, it is important to note that these will not provide any vulnerabilities above and beyond CVE/NVD, and their advisories lag well behind the issues being published in CVE/NVD. Haber is right, that this is a vital resource for .gov and .mil contractors, for several reasons.

Page 8 tells readers about SecurityTracker.com, which is a long-running site that aggregates vulnerabilities to a degree. Haber once again provides commentary:

“The website tends to focus on non-OS vulnerabilities, but they are certainly included in the feed,” says Morey Haber, VP of technology at BeyondTrust. “Infrastructure and IoT tend to make the front page the most, and this site is a good third-party reference for new flaws.”

Actually, they do focus on OS vulnerabilities and that can routinely be seen on their site. As I write this, 2 of the 5 vulnerabilities listed on the front page are in operating systems. The biggest thing to note about this offering is that publicly, they just don’t aggregate a significant volume of vulnerabilities for public consumption. Their most recent ID is 1037091, meaning they have ~ 37,000 entries in their database. Note that they operate like CVE though, where multiple vulnerabilities can be associated with a single ID. Regardless, reading their Weekly Vulnerability Summary emails for the past five weeks shows their volume: Sep 26 2016 (32 alerts), Oct 3 2016 (17 alerts), Oct 10 2016 (26), Oct 17 2016 (31), and Oct 24 2016 (32 alerts). To put that into perspective, VulnDB averages 46 new entries a day in 2016, with the most being 224 in a single day in 2016. For the most part, SecurityTracker may beat CVE on adding to the database, but they are almost entirely covering entries that have CVE IDs.

Page 9 tells readers about the Open Vulnerability And Assessment Language (OVAL) Interpreter And Repository. This is a curious addition to the article because it is not a source of vulnerability intelligence. Instead, it is a standard for reporting about systems. From the OVAL page:

OVAL® International in scope and free for public use, OVAL is an information security community effort to standardize how to assess and report upon the machine state of computer systems. OVAL includes a language to encode system details, and an assortment of content repositories held throughout the community.

While OVAL is certainly useful to some organizations, it does not belong in a list of vulnerability sources.

Page 10 tells readers about Information Sharing And Analysis Centers (ISACs). This is another curious addition as ISACs typically trade information on active attacks, threat actors, and which vulnerabilities may be targeted more heavily. They are generally not a source of vulnerabilities in the same context as most of the resources above.

In summary, Sean Martin’s article says it will share “9 Sources For Tracking New Vulnerabilities”. In reality, based on that quote and context, the article only tells readers about CVE/NVD, CERT VNDB, RBS VulnDB, and SecurityTracker. Several of the sources listed are not really for tracking new vulnerabilities, rather augment the vulnerability threat intelligence in various ways.

Unknown Vulnerabilities

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.

known_unknown_vulns

We’re offering a bounty… of sorts!

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 targets:

  • 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)

Bonus bounty:

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.

Ferreting Out Unique Vulnerability Data in OSVDB

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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”.
  5. 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.

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.

Coffee makers are SCADA, right?!

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 Continued Support of OSVDB

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.

OSVDB Search Tips & Tricks

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.

VDB Searching Headache: Apache

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.

Month of ActiveX Bugs…

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.